AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
8–14 wks
First tenant live
Auth, billing, and roles working
Scoped
Typical SaaS MVP
Multi-tenant, metered, billed
1
Billing system you didn't build
Stripe Billing, integrated properly
100%
Infrastructure yours
Terraform, your own cloud account
Architecture
Tenancy decisions that are expensive to reverse
Whether the application is single-tenant or multi-tenant gets decided in the first two weeks of a SaaS build and then lives in the data model for years. Retrofitting the wrong choice later means touching every table, every query, and every integration that assumed the old shape. These are the calls worth making on purpose, before a single migration runs against production.
Pooled multi-tenancy is the default
One application, one database, a tenant_id on every row, enforced with row-level security rather than trusted to application code. It is cheaper to operate, cheaper to scale, and the right choice for the large majority of B2B SaaS products. You get one set of migrations to run, one set of metrics to watch, and one deployment to roll back if something breaks.
Single-tenant earns its cost in specific cases
Healthcare, finance, and government buyers sometimes require a dedicated database or a dedicated deployment as a condition of the contract, not a preference. If the requirement is contractual, build for it. If it's a customer's assumption nobody has tested, ask before committing months to it.
Hybrid gets you both without maintaining two products
Pooled tenancy for most customers, a siloed deployment for the handful who require isolation, from the same codebase. It costs more up front than pure pooling and far less than running two separate applications side by side. The extra cost buys a deployment pipeline that can target either shape without a second engineering team maintaining a fork.
Isolation is a database decision, not a UI decision
Row-level security policies enforced by Postgres, not a WHERE clause a developer could forget in the fortieth query six months from now. The failure mode here is one tenant seeing another tenant's data, and that is not a bug you get to apologize for twice.
Data residency layers on top, it doesn't replace the model
A customer requiring EU-only or US-only storage is a deployment-region decision on top of pooled multi-tenancy, not a reason to abandon it. Treating residency and tenancy as the same problem adds cost that residency alone never required.
Tenant identification is a small decision worth getting right once
Subdomain (acme.yourapp.com), a custom domain the tenant brings, or an org-picker after a single login all work, and each implies different DNS, TLS, and session handling. Enterprise buyers increasingly expect the custom-domain option; deciding you'll never offer it is a real product decision, not a default you fall into.
What it costs
SaaS development pricing
Real ranges for the engagements we're actually asked to run. The variable that moves a quote is not feature count, it's how many plan tiers and billing models the product needs on day one, and whether metering has to be built or just wired to an existing plan structure.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Discovery & architecture | Fixed scope | 2 – 4 weeks | Tenancy model decided, isolation strategy chosen, billing plan designed, costed scope. Credited against the build if you continue. |
| SaaS MVP | Fixed scope | 8 – 12 weeks | Pooled multi-tenant application, one plan tier, Stripe Billing wired in, basic roles (owner, member), single onboarding flow. |
| Full platform build | Fixed scope | 4 – 7 months | Multiple plan tiers, usage-based billing, granular RBAC, admin console, churn and usage analytics, SSO, and the audit logging enterprise procurement will ask for. |
| Metering & billing retrofit | Fixed scope | 6 – 10 weeks | Usage metering added to a live product with paying customers, reconciled against Stripe invoices and backfilled against history. |
| Single-tenant to multi-tenant migration | Fixed scope | 8 – 14 weeks | Data model changed to support pooled tenancy without a rewrite; existing customers migrated with zero data loss and no visible downtime during cutover. |
Ranges assume US-based senior engineers and include the billing reconciliation, metering QA, and security review a platform needs before it's fit to invoice off. A quote well under these numbers usually means one of those three is missing, and it shows up as a support ticket the first time an invoice is wrong. It can also show up months later, as a finance team discovering the usage numbers on last quarter's invoices never matched the event log.
Billing
Buy your billing system. This one isn't close.
Stripe Billing, or an equivalent like Paddle or Chargebee, already handles the subscription state machine, proration, dunning, tax, and revenue recognition that took payment companies years to get right. We advise against rolling your own in almost every engagement, and we'll say so even when a client would rather pay us to build it. The build-versus-buy conversation usually takes ten minutes; the case for buying rarely needs more than that.
The state machine is bigger than it looks
Trials converting to paid, upgrades, downgrades, pauses, cancellations, and re-activations all interact, and every combination is a state your billing logic has to handle correctly or somebody gets charged wrong. Enumerate them on a whiteboard before writing code and the list is almost always longer than anyone guessed on the first pass.
Dunning is a product in itself
Retrying a failed card, emailing the customer, and deciding when to suspend access without losing them for good takes real tuning. Stripe has iterated on this against billions of transactions; a first attempt in-house has not.
Tax and revenue recognition are compliance work, not code
Sales tax varies by jurisdiction and changes without notice, and getting it wrong is a finance problem before it's an engineering one. Buying a billing platform is buying somebody else's compliance team along with it — one that tracks nexus thresholds and rate changes across every state and country you sell into, which is not a side project for an engineering team to own correctly.
The rare case for building your own
Usage-based pricing specific enough that no billing platform models it well, combined with volume that justifies the engineering cost of maintaining a custom system. This is uncommon, and most teams who think they qualify don't. A useful test: if you can describe your pricing model to Stripe's usage-billing docs and it fits within a page, you don't qualify.
What we actually build
The integration layer: webhooks that keep your database in sync with subscription state, the usage-reporting pipeline that feeds the metered price, and the admin tools support needs the day a customer's invoice looks wrong. That layer is where nearly all of a billing engagement's engineering time actually goes, not the checkout flow.
Chargebacks and failed-payment disputes need an owner
A disputed charge freezes funds and adds a fee regardless of who's right, and somebody on your team needs to respond with evidence inside the card network's window or lose automatically. Stripe surfaces the dispute; deciding who on your team acts on it within days is a process question we make sure gets answered before launch, not after the first one arrives.
Usage metering
Metering is harder than the pricing page implies
Charging by usage sounds like counting events and multiplying by a rate. In practice it's a distributed-systems problem with money attached, and most of the failure modes only surface after the first real invoice goes out. None of them are exotic — they're the ordinary edge cases of any event-driven system, except here the bug shows up as a wrong dollar amount instead of a stale cache.
Events get lost or double-counted
A network retry, a redeployed worker, or a redelivered queue message will duplicate an event unless every event carries an idempotency key and ingestion de-duplicates on it. Undercounting loses revenue quietly; overcounting loses a customer loudly.
Aggregation windows need a real definition
Whether usage rolls up by UTC day, billing-cycle day, or a rolling window changes the number on the invoice right at the boundary. Pick one, document it, and make sure support can explain it in a single sentence, because the customer disputing a charge at 11:58pm on the last day of the month will ask.
Proration is where the edge cases live
A plan change or a cancellation mid-cycle needs the same usage math applied to a partial period, and the two calculations drifting apart is the most common source of billing disputes we see.
Backfill and correction have to be first-class
A pricing bug discovered after invoices have gone out needs a path to recompute and credit without a manual spreadsheet. Building that path after the first incident costs more than building it up front, and the first incident is not a hypothetical — it is closer to a schedule than a risk.
Metered numbers have to match invoiced numbers, always
An alert that fires when your usage event log disagrees with what the billing platform actually invoiced is not optional. Silent drift between the two is how a SaaS company ends up owing customers money it doesn't know about, discovered months later during a finance reconciliation nobody was expecting to turn up a problem.
Free tiers and included allowances complicate the math
A plan that bundles the first 10,000 events before overage pricing kicks in needs the allowance tracked per billing period, reset correctly on renewal, and carried through mid-cycle upgrades without double-counting. It's a small feature that touches almost every other part of the metering pipeline once it exists.
Access and retention
Role-based access control and the analytics that predict churn
RBAC and churn analytics tend to get built by the same team, but they solve different problems: one controls what a user can do inside the product, the other tells you whether they're about to stop paying for it. Both get over-built early and under-built late, usually in that order, which is the opposite of how the cost curve actually runs.
Start with roles you can name
Owner, admin, member, viewer covers most B2B products at launch. Resist building a forty-toggle permissions matrix before a single customer has asked for one — it's expensive to build and awkward to explain in a sales call, and most of the toggles will sit unused, silently doubling the number of states your QA has to cover.
Custom roles are an enterprise-tier feature, not a v1 requirement
Granular, customer-defined permissions are real work — a permissions engine, an audit log, and a UI to manage both. Price and schedule it as its own project rather than folding it into the first release, where it will quietly absorb weeks that were supposed to go to the core workflow.
Audit logs are a sales requirement before they're a security one
Enterprise buyers ask for them in procurement, not after an incident. If the roadmap includes selling upmarket, design the audit log alongside RBAC rather than bolting it on afterward — retrofitting one onto a schema that never recorded who changed what is a rewrite, not an addition.
Churn analytics starts with product usage, not a dashboard
Login frequency, feature adoption, and seat utilization predict cancellation weeks before the cancellation happens. A churn dashboard built on data you aren't already capturing is a data-engineering project wearing an analytics costume, and the event tracking it depends on needs to be designed alongside the product, not bolted on after someone asks for a retention report.
Leading indicators beat a single churn score
One model that outputs a risk number is harder to act on than three or four clear signals — a workspace that stopped inviting teammates, an integration that got disconnected and never reconnected. Start with signals a human can act on.
SSO is a procurement gate before it's a security feature
Once a customer's security team is involved, SAML or OIDC single sign-on stops being a nice-to-have and becomes the line item that decides whether the deal closes. Building it after the first enterprise prospect asks is a rushed integration under deadline pressure; building it into the RBAC model from the start is a few extra days of design.
How we run it
From architecture decision to first invoiced customer
The sequence below front-loads the decisions that are expensive to reverse — tenancy model and billing plan — before a line of feature code gets written. Discovery and architecture happen first and in parallel with nothing else, because every subsequent estimate depends on both being settled.
Related
Related services
The work that most often runs alongside a SaaS build.
Questions
Common questions about SaaS development
What teams ask before a first call.
A pooled multi-tenant MVP with basic billing is the smaller shape; a full platform with usage-based billing, granular RBAC and an admin console is considerably larger. The table above shows what sits between them and where discovery fits in front of either.
What moves a quote is how many plan tiers and billing models the product needs on day one, and whether metering has to be built or can be wired to an existing plan structure. Metering is almost always underestimated.
Use Stripe Billing, or Paddle or Chargebee if you have a specific reason to prefer one of them. All three handle the trial, proration, dunning, and tax logic that took years to get right, and building it yourself is one of the more common ways early-stage SaaS teams lose six months they can't get back.
The exception is usage-based pricing specific enough that no platform models it well — and even then, most teams who think they're in this case aren't. What we build instead is the integration layer around whichever platform you choose, which is real engineering work without being a reason to reinvent the ledger underneath it.
Pooled multi-tenant, by default, for the large majority of B2B SaaS products. It's cheaper to operate and cheaper to scale, and row-level security in Postgres gives real tenant isolation without a separate database per customer to patch, back up, and monitor.
Single-tenant earns its cost when a contract, not a preference, requires a dedicated deployment — healthcare, finance, and government buyers are where this comes up most. Confirm the requirement is contractual before you build for it, and be wary of a sales team promising it to close a deal before engineering has agreed to support it.
Events get captured with an idempotency key, aggregated over a defined window — usually the billing cycle — and reported to your billing platform as a usage record against a metered price. The mechanics sound simple; getting them exactly right under retries, redeploys, and mid-cycle plan changes is most of the actual engineering effort, and it's where most of a metering project's timeline actually goes.
The part teams underestimate is reconciliation: an alert that catches your internal usage numbers disagreeing with what the billing platform actually invoiced. Without it, drift stays silent until a customer complains, which is the most expensive way to find a billing bug.
If you have three customers and expect the fourth to need meaningful customization, you may not have a SaaS product yet — you have a services business with software in it, and forcing multi-tenancy onto that too early adds cost with no buyer for it. Validate that a standard product, sold the same way to everyone, is actually what the market wants before architecting for it. A handful of manually configured single-tenant deployments is a legitimate way to sell to your first ten customers while that's still an open question.
If you already have that validation, pooled multi-tenancy from the start is cheaper than retrofitting it after a single-tenant prototype gets its first ten customers. The migration in the pricing table above is a real, and avoidable, cost — one we're regularly hired to run precisely because it was skipped the first time.
Eight to twelve weeks for a pooled multi-tenant application with one plan tier and Stripe Billing wired in, after a discovery phase that settles the tenancy model and billing plan. Usage-based pricing or multiple plan tiers extend that, usually by two to four weeks depending on how many plans need to be modeled.
The schedule risk is rarely the engineering. It's deciding the pricing model — flat, seat-based, or usage-based — which is a business decision that has to happen before the data model can be finalized, and teams often reach week one without having made it, which is exactly what the discovery phase exists to force.