SaaS Startup Platform

ARCHITECTURE A single deployable application behind a managed load balancer, a managed PostgreSQL instance, object storage for user uploads, and a managed email provider. One environment for production, one for staging, both created from the same definitions. Background work runs in the same deployable until there is a measured reason to separate it. Sessions and caching live in the database until a measurement says otherwise. This is the shape most SaaS products should have for longer than they think, and its defining property is that one person can hold all of it in their head during an incident. Resist the temptation to start with the architecture you expect to need at scale you do not have. Splitting later is work; operating a distributed system before you can staff it is a permanent tax. ASSUMPTIONS A team of roughly one to ten engineers, a customer base that tolerates a short maintenance window, and no regulatory requirement for multi-region residency. It assumes nobody is on call full-time, which is precisely why the component count matters. If you already have several teams releasing independently, or a compliance regime that mandates isolation, this is the wrong starting point. SECURITY Managed identity provider rather than hand-rolled authentication. All secrets in the platform's secret store, never in the repository. Database reachable only from the application's network, with no public endpoint. Dependency updates on a cadence rather than on an advisory (see /devsecops). Backups encrypted, and the restore tested. The highest-value control at this size is boring: least-privilege cloud credentials for the deploy pipeline, so a leaked CI token cannot delete the database. OBSERVABILITY One place for logs, one for metrics, one for errors — and make sure an exception reaches a human. Structured logs with a request id from day one; retrofitting correlation is far more expensive than emitting it. Uptime checking from outside your own infrastructure, because in-host monitoring cannot report that the host is unreachable. Alert on the customer-visible path — can someone sign up, can someone pay — rather than on resource graphs. AVAILABILITY Two application instances so a deploy or an instance failure is not an outage. Managed database with automated backups and a documented restore. Be honest about the objective: a single-region deployment with a tested restore is a reasonable posture for most early SaaS, and publishing an availability figure you cannot support is worse than publishing a modest one. COST CONSIDERATIONS At this stage the dominant cost is usually the managed database and egress, not compute. Set a billing alert before you need it. The expensive mistake is over-provisioning for imagined scale: buy the small instance and resize, because resizing a managed database is a routine operation and paying for unused capacity for a year is not recoverable (see /finops). IAC GUIDANCE Everything in one Terraform or OpenTofu root module, in the application repository. Do not split state until two people are changing infrastructure concurrently. Remote state with locking from the first day — a corrupted local state file is a bad afternoon at any size. PRODUCTION READINESS Before the first paying customer: automated deploys with a tested rollback, database backups with a verified restore, an error reaching a human, uptime checked externally, secrets out of the repository, and a written answer to "what do we do if the database is gone". The production deployment checklist at /checklists is the short version; /assess measures whether the practices exist.