A stage-aware SaaS development company: different architecture at $0 than at $10M ARR, different billing at per-seat than at usage-based. We build what ships next, not a five-year architectural fantasy.
Most agencies ship the same architecture to every client — whether the team is pre-revenue or approaching Series A. We don't. The right multi-tenancy, billing model, and compliance posture at MVP is wrong at scale. Here's how engineering should change per stage. We ship against Stripe Billing or Paddle for billing, Vercel or AWS for hosting, and Supabase or PostgreSQL for data, and Next.js with Clerk or Auth0 for the auth surface, classified per schema.org/SoftwareApplication.
| Stage | ARR range | What engineering actually does |
|---|---|---|
| idea pre-product | $0 | Prototype on a single-tenant Supabase project. No multi-tenancy yet. Auth via Clerk. Stripe in test mode. One workflow. Ship something you can learn from in 3 weeks. |
| MVP launch | $0 → $100K | Shared-schema multi-tenancy with row-level security. Real auth with passkeys and MFA. Subscription billing live. Minimum admin. Basic audit log. Structured logs to Axiom. Sentry on day one. |
| scale PMF to $1M | $100K → $1M | Feature flags via PostHog or LaunchDarkly. Billing model v2 (usage-based or hybrid if that's where the value is). First integrations (Zapier, HubSpot, Slack). Role-based access. SOC 2 controls installed. |
| enterprise $1M → $10M+ | $1M+ | SOC 2 Type II. SSO + SAML. Company accounts. Audit logs as a UI feature. Regional data residency. Schema-per-tenant for the customers who need it. HIPAA or PCI posture if relevant. White-glove onboarding. |
"Multi-tenant" is the buzzword. The actual decision is which shape. Shared schema, schema-per-tenant, or database-per-tenant — each right for a different stage and risk profile.
one DB · one schema · tenant_id on every row
Every table carries a tenant_id. Row-level security in Postgres enforces isolation. Cheapest to run, fastest to develop, easiest to query cross-tenant for analytics.
one DB · schema per customer
Each tenant gets a Postgres schema (namespace) in one database. Application routes queries to the right schema based on the authenticated user. Stronger isolation than shared, simpler ops than DB-per-tenant.
one DB per customer
Each tenant gets their own Postgres database. Maximum isolation. Required by some healthcare and financial buyers. Operationally the heaviest — every migration, every backup, every observability query multiplies.
Our default is shared schema until a specific customer or regulation forces the upgrade. The "upgrade path" matters more than the starting point — we architect so migration between options is a week, not a quarter.
Most SaaS founders buy compliance badges reactively when a deal demands them. That costs 3× more and delays the deal a quarter. Here's when each framework actually matters, what it costs, and what we install at MVP to keep it cheap later.
The first framework most US B2B buyers ask about. Type I documents controls exist; Type II verifies them operating for 6–12 months.
Mandatory if any EU resident touches your product. Data-processing agreements, right to erasure, data portability, consent UX, breach notification within 72 hours.
Required for any SaaS handling protected health information in the US. Business Associate Agreements, encryption in transit and at rest, access logs, breach notification.
Required if you touch raw card data. The trick: don't. Stripe, Braintree, and Adyen absorb PCI scope, so you drop from Level 1 to Level 4 just by never storing cards.
International information-security standard. Required by many EU enterprise buyers and UK government. Overlaps substantially with SOC 2 — smart teams pursue them together.
What we install at MVP so the audit is cheap later: structured audit logs, RBAC scaffolding, encryption at rest by default, vendor-management tracking, retention policies per data class. None add timeline; all save weeks.
Per-seat baked into the schema means usage-based is a database migration, not a pricing page change. We architect billing so the model can move when your market does.
Charge per named user. Classic B2B SaaS. Works when seats correlate with value.
Charge per API call, per event, per GB, per compute-minute. Scales with customer consumption.
Three pricing tiers with different feature sets. Starter, Growth, Enterprise. Classic SMB SaaS.
Seat minimum plus usage overage. Flat tier with usage add-ons. Captures both predictability and growth.
Not generic web stack (those decisions live on the web development page). These are the six specifically-SaaS decisions we've watched teams reverse at great cost.
Clerk, Auth0, or WorkOS. SSO, MFA, passkeys, SAML, SCIM provisioning — all included. Hand-rolled auth is why first-enterprise-deal reviews fail.
Stripe for invoicing and tax. A separate metering service (Orb, Lago) if usage-based. Webhooks idempotent with a deduplication table, not "it usually works."
Postgres row-level security as the enforcement layer. tenant_id on every row. Tests that actually verify one tenant can't read another's data.
Per-tenant feature gating from day one. Let sales toggle beta features per account without a deploy. Enables "enterprise tier" without a fork.
Errors to Sentry. Product analytics to PostHog. Structured server logs to Axiom. Three clearly-bounded tools, not one do-everything platform.
Retool or internal dashboards for your ops team. Different URL, same auth, same data. Customer-facing admin is a separate product surface — not the same one.
We've either seen each of these kill a product, or helped rescue a team a few weeks from it. Architecture is the leading cause of preventable SaaS death — and every one of these is preventable at MVP.
Shared schema picked at MVP; first enterprise customer requires schema isolation at $400K ARR. Moving them is a two-quarter project. Losing them is a 15% revenue hit. We've seen both happen. The fix is architecting the upgrade path from day one, not locking in an answer.
Per-seat pricing where seat counts live in half a dozen tables. Market shifts toward usage-based. Rewriting the billing model requires migrating every pricing-adjacent entity. Teams have missed a pricing pivot by a year because of this.
First enterprise buyer asks for SOC 2 Type II. Team hasn't thought about audit logs, access controls, or vendor tracking since year one. The audit becomes a six-month rewrite the team doesn't have engineering to spare for. The deal dies or closes at a discount.
Engineering built sign-in from scratch "to save money." The first 50-seat buyer asks for SAML. Adding SSO to a hand-rolled system is effectively rewriting auth. Meanwhile, Clerk or Auth0 would have shipped it on day zero for a fraction of the monthly cost.
No structured logs, no tracing, no error budgets, no alert routing. A paying customer hits a bug the team can't reproduce. Support spirals. Churn climbs. The team reacts by rewriting features instead of adding observability — which is what would have saved the feature in the first place.
Four published rates, matched to where revenue sits today: $18K rescue audit, $35K–$75K MVP, $85K–$250K scale, $200K+ enterprise. Pick the shape, not the discovery call.
3-week architecture + security audit. Multi-tenancy, auth, billing, observability, SOC 2 readiness. Prioritized remediation plan you can implement yourself or with us.
8–12 weeks. Auth, billing, one core workflow, minimum admin, analytics, CI/CD. Ships to real users, not a demo. SOC-2-ready scaffolding included.
12–20 weeks. Multi-tenant, integrations, billing model v2, observability, first SOC 2 posture. For products already earning revenue.
20+ weeks. SOC 2 Type II, SSO/SAML, audit logs, role-based access, regional deployments, HIPAA or PCI if required.
Prices valid through 2026-Q3. Ongoing embedded-engineer pairings available post-launch at $11K/mo. Three-month minimum on retainer.
Six questions we hear most: scope of work, cost, multi-tenancy timing, SOC 2 readiness, pricing model selection, and rescue paths for an existing SaaS carrying technical debt.
Engineers cloud-delivered software products end-to-end: architecture, multi-tenant database, auth (SSO/MFA/SAML), billing and subscriptions, admin and customer product surfaces, integrations, observability, CI/CD, compliance posture (SOC 2, GDPR, HIPAA as needed), post-launch iteration. At Digital Heroes, we build stage-aware — an MVP ships with different engineering than an enterprise build.
MVP SaaS build: $35K–$75K over 8–12 weeks. PMF-to-scale: $85K–$250K over 12–20 weeks. Enterprise engagement: $200K+ over 20+ weeks. SaaS rescue + audit: $18K over 3 weeks. Published rates, no discovery-call sales funnel.
Yes — but not always with full schema isolation. Shared-schema with row-level security is the default for most B2B SaaS. Schema-per-tenant when a customer requires isolation. Database-per-tenant for healthcare, finance, or sub-tenant sprawl. Decision matrix in § 02 above.
First time an enterprise buyer asks for your security questionnaire — usually around the first $50K–$100K/yr contract. Type I documents controls; Type II verifies 6–12 months of operation. We build SOC-2-ready from MVP so the actual audit is paperwork, not a rewrite.
Per-seat works when seats correlate with value (CRM, communication, PM). Usage-based works when consumption varies wildly (compute, API, email). Flat tiers work when value is predictable (productivity tools). Hybrid (usage + seat minimum) is the fastest-growing model in 2026. Decision guide in § 04.
Yes. The 3-week SaaS rescue + audit is the entry point. Architecture, auth, multi-tenancy, billing, observability, SOC 2 readiness reviewed. Prioritized remediation plan with effort/impact scoring. Implement it yourself or engage us for the build. No pressure either way.
Four shifts shaped the 2026 SaaS stack: Stripe Connect became the default for multi-tenant billing, Postgres 16 plus pgvector pushed vector search into the same database as relational data, managed Postgres providers reached production parity with self-hosted, and auth standards (PKCE, MFA, passkeys) crossed the line from optional to expected at first compliance review.
The billing decision is now binary. Stripe Connect's docs spell out the platform-versus-marketplace flows, fee splits, and 1099 tax reporting in one place; for non-marketplace SaaS, Stripe Billing plus usage-based metering replaces a year of custom invoice code. The database decision is similarly compressed: Postgres 16's feature matrix plus pgvector covers AI features, JSON workloads, and traditional relational schemas without bringing in a second store.
Managed Postgres is finally good. Supabase's Postgres-with-auth-and-realtime stack ships row-level security, edge functions, and storage in one provider; on the edtech course platform build, the entire backend (auth, billing webhooks, real-time chat, file storage) ran on one provider with one Postgres schema, which compressed the MVP timeline by roughly six weeks.
What this means for your project: if your SaaS is pre-$1M ARR in 2026, default to Postgres plus Stripe plus a managed provider (Supabase, Neon, Vercel Postgres). Re-architect to your own infrastructure when one of three things breaks: cost, latency, or a compliance regime your provider does not yet cover.
Related reading + work: See our SaaS MVP in 90 days playbook, the SaaS pricing page design guide, the edtech course platform case, and our SaaS MVP development and React development pages for adjacent work.
Tell us where you are — idea, MVP, approaching $1M, past it. We come back with an architecture, a billing call, a compliance read, and a price. Within 24 hours. No deck.
Account Manager · UK Retail & Fashion · London · 5 posts on the site
Published · Last updated .