Application layer
FastAPI routes, web workflows, REST endpoints, business rules, and integration boundaries.
Production business application
East Bay AV
Business OS
A purpose-built FastAPI and PostgreSQL application connecting the operational record from public lead intake through customer work and invoice history.
01 · Problem
One operation, fragmented records
Customer context, sites, job activity, labor, materials, leads, and invoices are related, but separate tools break that relationship. The application needed to reflect the actual workflow while keeping administrative access and public intake appropriately separated.
I designed the application around the business entities and transitions that need to remain connected over time.
The system covers customers and sites, jobs, CRM activity, leads and opportunities, labor and materials, discounts, invoicing workflows, invoice history, and administrative controls. A public lead path feeds structured information into the same operating model without exposing internal workflows.
Data layer
Relational PostgreSQL models implemented with SQLAlchemy and evolved through Alembic migrations.
Access controls
Authentication, server-side session controls, CSRF protection, login throttling, and administrative boundaries.
Operations
Regression testing and deployment on Debian behind Nginx and Cloudflare Tunnel.
The architecture separates public and administrative entry points from application rules and persisted business data.
Application boundary
Interfaces
Public lead intakeStructured external requests
Administrative webInternal workflows
REST endpointsDefined integrations
Application
FastAPIRouting + validation
Session + securityAuth · CSRF · throttling
Business rulesConnected workflows
Data + services
PostgreSQLRelational source of record
SQLAlchemy + AlembicModels + migrations
InvoiceShelfInvoice integration
Model relationships explicitly
Customers, sites, jobs, activity, labor, materials, and invoices remain connected so context is not reconstructed from separate tools.
Treat schema change as application change
Alembic migrations provide a repeatable path for evolving production data alongside application behavior.
Separate public and privileged workflows
Lead intake accepts public submissions while sessions, CSRF protection, throttling, and administrative controls protect internal actions.
The engineering work extends beyond implementing features: the application has to preserve records, control access, and move safely between versions.
Layered request protection
Authentication is supported by session controls, CSRF protection, login throttling, and restricted administrative capabilities.
Durable history
Job activity and invoice history remain attached to their business context rather than disappearing into disconnected transactions.
Repeatable deployment
Database migrations and regression tests reduce risk as the application changes; Nginx and Cloudflare Tunnel provide the production delivery path.
This case study intentionally excludes customer records, credentials, internal URLs, and private infrastructure details. The source repository is private.
05 · Engineering result
The operation became the domain model.
The project demonstrates the full application lifecycle: translating operational knowledge into relational models, implementing backend workflows and security controls, integrating external invoicing, testing behavior, migrating data, and operating the result in production.