SaaS MVP development in Seattle.

The technical reality of shipping an MVP in Seattle.

Questions from Seattle founders.

Does multi-tenant architecture need to be right from day one, or can it be fixed later?

The isolation model needs to be right from day one; the scaling machinery can wait. Tenant isolation is the one decision that is genuinely expensive to retrofit: row-level tenancy on Postgres with a tenant_id discipline enforced in the data layer (and tested, not assumed) costs almost nothing extra in week one and prevents the category of bug that ends enterprise deals. What can wait: per-tenant databases, sharding, regional deployment, and the noisy-neighbor engineering that matters at a thousand tenants. Ex-platform engineers founding companies here often over-rotate toward the infrastructure they ran at scale; the MVP needs the correctness half of multi-tenancy, not the capacity half. We build the first and document the upgrade path to the second.

We have AWS credits. How should that shape the stack?

Use the credits for what is genuinely good on AWS and resist letting a coupon design your architecture. The pragmatic split for a Seattle MVP: Postgres on RDS or Aurora, object storage on S3, background jobs on SQS, AI inference through Bedrock (which also simplifies your security story), all comfortably credit-funded. The application itself often still deploys best on Vercel-class platforms during the MVP year because preview deployments and zero-ops hosting move product velocity more than any credit offsets; that bill is small anyway. When policy or credits argue for all-in AWS, we deploy the app on ECS or App Runner with the standard discipline, and the runbook covers it. The principle: credits defray costs you would rationally incur; they should not buy complexity you would not.

When do SSO and SCIM become necessary, and what do they cost to add?

SSO becomes necessary at your first mid-market security review, which in Seattle's seller ecosystem can be embarrassingly early; SCIM follows at your first thousand-seat customer. The cost structure rewards preparation over construction: building on an auth foundation that is SSO-ready (standard OIDC/SAML patterns, organization-scoped identity) costs little in v1, and then enabling enterprise SSO per customer is configuration plus modest integration work. Retrofitting SSO onto a personal-accounts auth model is the painful version. Our default Seattle build ships SSO-ready with social/email login active, turns on SAML when the first enterprise pilot asks (often via WorkOS-class providers), and defers SCIM provisioning until a contract names it. That sequencing matches how procurement actually escalates.

Enterprise security questionnaires are already arriving. What can an MVP-stage company credibly answer?

More than you would guess, if the build was honest. An MVP on our standard pattern truthfully answers: data encrypted in transit and at rest, tenant isolation enforced and tested in the data layer, least-privilege access with audit logging, secrets in a managed store, dependency scanning in CI, backups with tested restores, and a documented incident process (a one-page process is still a process). What you cannot claim yet: SOC 2 (start the observation window when a contract justifies it), penetration tests (commission one when a deal demands it, a few thousand dollars), or a security team. Seattle reviewers are usually sophisticated enough to accept 'strong practices, audit scheduled' from a seed-stage vendor; what they reject is vagueness. We ship a pre-filled security-questionnaire baseline with every enterprise-leaning build, which turns a week of founder dread into an afternoon of edits.