Tenancy, billing, and permissions are decided in week one and paid for forever. Here is how to make those SaaS product development calls before they harden.
Codestreaks Team
SaaS product development is mostly ordinary web engineering wrapped around three decisions that are cheap in week one and expensive forever after: how you separate tenants, how you handle billing, and how you model permissions. Everything else can be refactored. Those three get baked into every table and every query, and changing them later is a migration project with revenue attached.
We have delivered 30+ projects to production since 2024, and the SaaS builds that ran into trouble did not fail on features. They failed because one of those three was decided by default rather than on purpose.
Here is how to make each call, and what it actually costs you later if you get it wrong.
Shared database with a tenant column is the default and it is right for most products. It is cheap to operate, easy to query across customers, and simple to deploy.
It stops being right when a customer contract says their data must be physically separate, or a regulator says it, or you sell into a market where a single noisy customer can degrade everyone else. Then you are looking at schema-per-tenant or database-per-tenant, which multiplies your migration and backup work by the number of customers you have.
The honest way to decide: look at who you expect to be selling to in two years. If that list includes regulated enterprises, design for isolation now, because retrofitting it means rewriting every query that assumes one database. If it is small teams and self-serve, take the shared model and stop worrying about it.
Whichever you pick, enforce the tenant boundary in one place, not in every handler. A shared row-level policy or a single query layer that cannot be bypassed is the difference between a boundary and a convention. Conventions get forgotten under deadline pressure, and the resulting bug is one customer seeing another customer's data.
Everyone changes pricing. Plans get renamed, tiers get merged, one large customer negotiates something bespoke, and a usage component gets bolted on. If your billing logic is scattered across the codebase as plan-name comparisons, every one of those changes is a code deploy and a risk.
Model entitlements instead. The application asks whether this account can do this thing, and how much of it is left. The plan is data that maps to entitlements, not a string checked in forty places. That one indirection makes pricing experiments a config change rather than an engineering project.
The second billing trap is treating your payment provider as your source of truth for access. Webhooks are late sometimes, and they get retried. If a failed webhook can silently leave a paying customer locked out, or a cancelled one with access, you need reconciliation, a job that periodically compares your view of subscriptions against the provider's and fixes the drift.
Most products ship with a role enum. Admin, member, viewer. It works until the first customer asks for a person who can see billing but not export data, or an external contractor who can access two projects out of thirty.
The upgrade is to check permissions, not roles, in the code. Roles then become named bundles of permissions, which means a new customer requirement is a new bundle rather than a new branch in every handler.
And the thing that actually hurts, the one we find most often in reviews of existing SaaS code: an endpoint that fetches a record by id and returns it without ever comparing the owner to the caller. The code looks correct. The tests pass, because the tests fetch records the test user owns. Nothing errors in production either, right up until somebody changes a number in a URL. Authorization is application semantics, so no scanner tells you the comparison is missing. The only reliable check is a second account and a deliberate attempt to read the first account's data.
The scope cut that predicts launch success is the one that removes the feature you were most attached to. Our writeup on SaaS MVP development goes deeper, but the short version is that the first release should do one job completely rather than five jobs partially.
A useful test: can you describe what the product does in one sentence that mentions no other features? If not, the scope is still too wide to validate anything.
Prototypes lie. A demo that works on five hand-picked examples tells you nothing about the five thousand real ones. Most of our work across projects is reliability engineering rather than the first demo, and on SaaS that means the boring middle, retries, idempotency, backfills, and what happens on a partial failure.
Our typical engagement runs 4 to 8 weeks from kickoff to live deployment, at $8,000 to $60,000 fixed price. A focused SaaS MVP with one core workflow, authentication, tenancy, and billing sits comfortably in that window at the lower to middle end.
What pushes a SaaS build past it is almost always integrations and enterprise requirements rather than product surface. SSO, audit logging, data residency, and per-customer configuration each add real work, and they tend to arrive together with your first large customer.
One piece of advice that costs nothing: do not build SSO and audit logs before anyone has asked. Build the boundary that lets you add them without a rewrite, then wait for the deal that needs them.
The other cost nobody models is the second year. Support tooling, admin impersonation for debugging a customer's account safely, usage reporting, and the migration scripts you now need because real data exists all arrive after launch. They are not glamorous and they are most of what a product team does once customers are live, which is the argument in our writeup on SaaS lifecycle management. Plan for the maintenance shape of the product, not only the launch shape, because the launch is the cheap part.
If your product has an AI feature, keep the model behind an interface you own. Model names change quarterly, pricing changes with them, and the thing that compounds is your evaluation set, your prompts, and your data, not the provider.
Inference cost is usually manageable. Production agents typically run $50 to $2,000 per month, and good engineering around caching, model routing, and prompt design cuts that by 3 to 10 times. The failure mode that hurts is shipping a feature with no evaluation suite, so nobody notices when quality degrades after a model update. That is how a working feature becomes a support queue without a single deploy on your side.
A focused first version with one core workflow, tenancy, authentication, and billing typically ships in our 4 to 8 week window. Enterprise requirements such as SSO, audit logs, and data residency usually add a phase rather than fitting inside the first one.
Shared multi-tenant is right for most products and much cheaper to operate. Choose isolation when contracts, regulation, or noisy-neighbor risk require it, and decide before launch, because retrofitting isolation means rewriting every query that assumes one database.
Hardcoding plan names throughout the code instead of modeling entitlements, and checking roles instead of permissions. Both are cheap to do properly at the start and expensive to unwind once customers depend on the behavior.
Outsourcing works well for a bounded first version where the requirements are clear. Whoever builds it, insist on full code ownership. Every client of ours gets 100% ownership of the repository and 30 days post-launch support, because owned software compounds and rented software does not.
Cut until the product does one job completely. Anything a customer would not cancel over on day one is a candidate for the next release, and the discipline is easier to hold before launch than after.
If you are scoping a SaaS build, the useful conversation is about tenancy, billing, and permissions before it is about screens. We offer a free 30-minute scoping call and reply within two business days. We take two engagements per quarter and we say no when the scope does not fit.
See how we approach SaaS development, or start a project and tell us who your first ten customers are.