§
§ · saas development company

SaaS built for the stage you're at, not the one you imagine.

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.

§ 01 · idea to $10M ARR

A SaaS at $0 needs different engineering than a SaaS at $1M.

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 or Paddle for billing, AWS or Vercel for hosting, and Supabase or PostgreSQL for data.

Four moss-green liquid drops of progressively increasing size representing the idea, MVP, scale, and enterprise revenue stages of a SaaS company
Fig. 1 · four stages · idea → MVP → scale → enterprise
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.
§ 02 · multi-tenancy, decided

Three architectures. One right call.

"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.

option 01 · default

Shared schema

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.

Cheap at scale
Easy backups, easy migrations
!RLS bugs = cross-tenant leaks
!Noisy-neighbor queries possible
hybrid
option 02 · middle ground

Schema-per-tenant

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.

Isolation for skittish buyers
Per-tenant backups possible
!Migrations run N times
!Breaks around 500+ tenants
option 03 · regulated

Database-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.

Regulatory-grade isolation
Per-tenant region residency
!Cost climbs with tenant count
!Cross-tenant analytics is hard

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.

§ 03 · the compliance scorecard

Five frameworks. When each actually matters.

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.

SOC 2 Type II

The first framework most US B2B buyers ask about. Type I documents controls exist; Type II verifies them operating for 6–12 months.

matters at
first $50K contract
cost
$15K–$50K audit
timeline
6–12 months
auditor
Vanta, Drata, Secureframe
GDPR EU

Mandatory if any EU resident touches your product. Data-processing agreements, right to erasure, data portability, consent UX, breach notification within 72 hours.

matters at
first EU user
cost
engineering, not audit
timeline
bake in at MVP
penalty
up to 4% rev or €20M
HIPAA healthcare

Required for any SaaS handling protected health information in the US. Business Associate Agreements, encryption in transit and at rest, access logs, breach notification.

matters at
first healthcare buyer
cost
engineering + BAA ops
impact
often DB-per-tenant
vendors
AWS HIPAA, Azure HealthCare
PCI DSS payments

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.

matters at
if handling raw PANs
dodge it
Stripe Elements, tokens
SAQ level
A (token) vs D (full)
cost if full
$50K–$250K
ISO 27001 enterprise + EU

International information-security standard. Required by many EU enterprise buyers and UK government. Overlaps substantially with SOC 2 — smart teams pursue them together.

matters at
EU enterprise deals
cost
$25K–$80K
timeline
9–12 months
overlap
85% shared w/ SOC 2

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.

§ 04 · billing model, chosen

The wrong billing model is the slowest rewrite in SaaS.

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.

model 01

Per-seat

Charge per named user. Classic B2B SaaS. Works when seats correlate with value.

Predictable revenue, easy to forecast
Buyers understand it instantly
!Seat-stuffing hack: one account, many users
pick ifCRM, communication, project management, HRIS, collaboration tools
model 02

Usage-based

Charge per API call, per event, per GB, per compute-minute. Scales with customer consumption.

Low friction at the top of funnel — you use, you pay
Revenue scales with customer value
!Unpredictable bills = procurement heartburn
pick ifcompute, email, SMS, API platforms, observability, data pipelines
model 03

Flat tiers

Three pricing tiers with different feature sets. Starter, Growth, Enterprise. Classic SMB SaaS.

Easiest for customers to compare and self-serve
Predictable unit economics
!Revenue doesn't grow with engagement
pick ifproductivity tools, site builders, design tools, small-biz software
fastest growth
model 04

Hybrid

Seat minimum plus usage overage. Flat tier with usage add-ons. Captures both predictability and growth.

Predictable floor plus upside
Procurement-friendly, growth-captured
!Complex to explain — pricing page design matters
pick ifmodern B2B SaaS at scale: Linear, Notion, Stripe, Retool
§ 05 · the SaaS-specific stack

Six decisions every SaaS gets wrong once.

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.

01 · auth

Buy. Do not build.

Clerk, Auth0, or WorkOS. SSO, MFA, passkeys, SAML, SCIM provisioning — all included. Hand-rolled auth is why first-enterprise-deal reviews fail.

02 · billing

Stripe + metered events

Stripe for invoicing and tax. A separate metering service (Orb, Lago) if usage-based. Webhooks idempotent with a deduplication table, not "it usually works."

03 · multi-tenancy

tenant_id + RLS

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.

04 · feature flags

PostHog or LaunchDarkly

Per-tenant feature gating from day one. Let sales toggle beta features per account without a deploy. Enables "enterprise tier" without a fork.

05 · observability

Sentry + PostHog + Axiom

Errors to Sentry. Product analytics to PostHog. Structured server logs to Axiom. Three clearly-bounded tools, not one do-everything platform.

06 · admin surface

Don't build it twice

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.

§ 06 · honest post-mortems

Five ways SaaS products die.

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.

  1. 1.

    Wrong multi-tenancy, discovered at year three.

    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.

  2. 2.

    Billing model baked into the database.

    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.

  3. 3.

    Compliance debt at Series A.

    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.

  4. 4.

    Hand-rolled auth that can't ship SSO.

    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.

  5. 5.

    Observability as afterthought.

    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.

§ 07 · published rates

Four shapes. Stage-matched.

audit

SaaS rescue + audit

$18,000

3-week architecture + security audit. Multi-tenancy, auth, billing, observability, SOC 2 readiness. Prioritized remediation plan you can implement yourself or with us.

for · existing product, unknown debt
mvp

MVP SaaS build

$35K–$75K

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.

for · idea → paying users
most picked
pmf-to-scale

Scale build

$85K–$250K

12–20 weeks. Multi-tenant, integrations, billing model v2, observability, first SOC 2 posture. For products already earning revenue.

for · PMF → $1M ARR
enterprise

Enterprise engagement

$200K+

20+ weeks. SOC 2 Type II, SSO/SAML, audit logs, role-based access, regional deployments, HIPAA or PCI if required.

for · $1M+ ARR, enterprise deals

Prices valid through 2026-Q3. Ongoing embedded-engineer pairings available post-launch at $11K/mo. Three-month minimum on retainer.

§ 08 · questions

Six quick answers.

What does a SaaS development company actually do?

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.

How much does custom SaaS development cost?

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.

Should I build multi-tenant from day one?

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.

When do I need SOC 2 Type II?

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, usage-based, or flat pricing — which?

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.

Can you help if our SaaS has technical debt?

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.

ready to ship

Start with your stage.

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.