What a Custom SaaS Platform Actually Costs to Build in 2026

Most quotes for a custom SaaS platform are wrong in the same direction. They price the screens. The screens are maybe 40% of the work. The rest is tenancy, authentication, billing, permissions, background jobs, migrations, observability, and the six weeks after launch when real data arrives and breaks assumptions nobody wrote down.

So a founder gets a $60,000 number from one shop and a $400,000 number from another for what looks like the same product, and has no way to tell which one is lying. Usually neither is. They are pricing different scopes and different definitions of "done." One is quoting a demo. The other is quoting something that can take a credit card from a stranger at 2am and survive it.

We build and operate our own products alongside client work, so we pay these bills twice. What follows is where the money actually goes, what the honest ranges look like in 2026, and a scoping method you can run before you talk to anyone.

The four cost tiers, and what separates them

Ranges below assume a US-based senior team, fixed-scope phases, and a working product at the end of each tier — not a prototype. Blended senior rates in the US market in 2026 sit roughly in the $100–$200/hour band, and studio pricing is usually a phase fee derived from that.

Tier 1 — Validation build: $25,000 to $60,000

One workflow, one user type, one tenant model that assumes everyone is in the same table. Hosted auth, Stripe Checkout, no admin panel beyond a database GUI. Six to ten weeks. This is the right spend when you have not yet proven anyone will pay, and the wrong spend when you already have a signed pilot with three companies who each want their own data boundary.

Tier 2 — Commercial v1: $75,000 to $180,000

Multiple user roles, real multi-tenancy, subscription billing with plan changes and proration, entitlement gating, an internal admin tool, email and notifications, audit logging, CI/CD, and error tracking you actually look at. Three to five months. This is where most funded startups and most SMB-facing platforms belong.

Tier 3 — Platform: $200,000 to $600,000+

Per-tenant databases or strict isolation, offline capability, third-party integrations that break on someone else's schedule, background job orchestration, mobile, or AI features with spend controls. Retailer OS is in this tier: offline-first POS that reconciles on reconnect, per-location inventory, and marketplace sync to Google, Meta, Amazon and eBay. Each of those four marketplaces is its own multi-week project because each has its own taxonomy, rate limits and rejection semantics. You can read the Retailer OS breakdown for what that actually involved.

Tier 4 — Regulated or hardware-adjacent: no useful range

If you need HIPAA or PCI scope, SOC 2 before your first enterprise deal, or hardware a browser cannot reach, the compliance and device work can exceed the application work. Nobody should quote this from a discovery call. Price a paid discovery phase first.

The line items that blow up budgets

In our experience these five items are underestimated on almost every first pass, by clients and by shops quoting them:

• :Billing. "Add Stripe" is a two-day task. Subscription billing with trials, plan upgrades mid-cycle, proration, dunning, tax, entitlement checks in the app, and a metering pipeline that survives a webhook arriving twice is four to eight weeks. We built usage metering and AI spend wallets with auto-recharge, and the wallet logic alone — reserve, consume, reconcile, refund on failure — took longer than the feature it funded.
• Permissions. Roles look cheap until someone asks for per-location access, or a user who belongs to two tenants. Retrofitting that is a rewrite of every query in the app. Decide the shape on day one.
• Data migration and imports. Every B2B customer arrives with a spreadsheet. Import tooling with validation, dry runs and a reconciliation report is real product surface, not a script.
• Admin and support tooling. If your team cannot impersonate a tenant, replay a failed job, or fix bad data without a deploy, your support cost becomes an engineering cost forever.
• The integration you assumed was easy. Third-party APIs are where estimates go to die. Assume any integration you have not personally authenticated against takes 2.5x what the docs suggest.

A scoping method you can run before you hire anyone

Do this on paper. It costs nothing and it changes the quotes you get, because it forces every shop to price the same thing.

1. Write the single sentence describing the transaction that makes you money. Not the vision. The transaction. "A shop owner rings up a sale and the inventory count drops."
2. List every screen and job required for that sentence to be true end to end, including the boring ones: signup, invite a teammate, pay us, get a receipt.
3. Mark each item must, should, or later. If more than a third are must, you have not made a decision yet.
4. For every must, name the failure mode. What happens if it is down, slow, or wrong? Items with expensive failure modes are where the engineering budget belongs.
5. Write your tenancy and permissions model in five lines. Who owns data, who can see across boundaries, what the smallest unit of isolation is.
6. Name the three integrations you cannot ship without, and go read their API docs yourself for thirty minutes each.
7. Set a launch date and a budget ceiling, then cut the should list until the two agree.

Step 5 matters more than the rest combined. Here is the entire artifact for a field-services platform, and it is enough for us to price the foundation:

tenant        = company (one Postgres schema per company)
user          = belongs to exactly one tenant
role          = owner | dispatcher | tech | readonly
isolation     = no cross-tenant reads, ever, including analytics
exception     = internal staff impersonation, audit-logged, 30-min TTL
billing_unit  = active techs per month, metered nightly

Six lines. It determines the database layout, the query layer, the admin tool, and the metering pipeline. We have written more about how to choose the tenancy boundary before writing code, because reversing it later is the single most expensive mistake in this category.

Year two costs more than you budgeted

The build number is the down payment. Plan on 15–25% of the build cost annually for maintenance — dependency upgrades, framework migrations, security patches, provider deprecations — before you add a single feature. That is not padding. Cloud providers retire services, payment APIs version, and mobile platforms force annual SDK bumps whether your roadmap agrees or not.

Infrastructure is usually the smaller surprise. A Tier 2 platform with a few hundred tenants often runs $300–$2,000 a month. Where it moves is per-tenant isolation and AI. We have operated 30+ Node microservices on Kubernetes across 100+ per-tenant Postgres databases; the per-tenant model buys clean blast radius and easy tenant export, and you pay for it in connection pooling, migration orchestration and idle capacity. Edge-first architecture on Cloudflare Workers, D1 and R2 with Postgres behind it flips that cost curve for read-heavy products, which is why we default there for new builds unless the workload argues otherwise.

AI features need a wallet, not a hope. Model spend scales with usage, and usage-based cost without per-tenant metering and hard caps is how a popular feature becomes a margin problem. Build the meter before you build the feature.

When you should not build custom at all

Custom is the wrong answer more often than a studio will tell you. Do not build if:

• An off-the-shelf tool does 80% of the job and the missing 20% is reporting or a light integration. Buy the tool, build the glue. That is a $15,000 project, not a $150,000 one.
• Your differentiator is distribution or service, not software behavior. Configure something existing and spend the difference on sales.
• You cannot name a single workflow specifically enough to write step 1 above.
• You are pre-revenue with no design partner. Get a signed letter of intent from someone who will pay, then build for them.

Custom becomes correct when the workflow is the product. BuildAEC exists because no existing estimating tool would run a vision model over raw construction plans and attach a per-line confidence score that directs a human to the twelve measurements worth checking. That behavior is not a configuration option anywhere — you can see how the takeoff pipeline works. Same for offline POS: retail hardware and a dead internet connection are constraints that off-the-shelf browser software cannot meet.

If your differentiator can be expressed as a settings page in someone else's product, you are about to spend six figures reinventing a settings page.

What to require in the contract

Price is the least useful thing to negotiate. These terms decide whether the number holds:

• Fixed-scope phases, not a fixed-price whole project. Anyone quoting a firm number for eight months of unbuilt software is either padding heavily or planning to fight you about change requests. Price discovery, then price phase one.
• Code and infrastructure in your accounts from day one. Your GitHub org, your cloud account, your Stripe. Not a handover at the end.
• A written definition of done per phase. Deployed to production, tests passing, runbook written, one non-author can deploy it.
• Named engineers. Who specifically is writing the code, and what happens if they leave.
• A deprecation clause. What it costs to have someone else take this over. If the answer is unclear, the architecture is a lock-in.
• Post-launch support terms priced before launch, not negotiated the week you go live.

We publish our phase structure and pricing model on our approach page for exactly this reason: the argument about scope should happen before anyone writes code, in writing, with a number attached to each phase.

The most expensive version of this project is the cheap one that gets rebuilt in month nine. If you have done the seven scoping steps and want a phase-by-phase number against them, send us the artifact — the five-line tenancy model included. That document alone tells us more than an hour of discovery.