Tenancy model
Shared data with tenant scoping or isolated data per customer. The answer changes the product foundation.
SAAS DEVELOPMENT
Multi-tenancy, billing, permissions, onboarding, and admin tooling form the infrastructure a SaaS needs before a customer can pay for it.
WHAT FOUNDERS UNDERESTIMATE
Most SaaS scopes describe the customer feature. Once the build begins, the operating system around it appears: sign-up, teams, billing changes, failed payments, trial expiry, support tooling, and usage limits.
None of that is the headline product. All of it has to exist before the product can be sold. Scoping it from the start makes the first number more realistic and the final number more trustworthy.
THE REALITY
The customer feature is only one part of a SaaS product that can successfully charge.
WHAT A SAAS BUILD INCLUDES
Every item below is a practical part of running a SaaS, not optional infrastructure discovered after the first customer arrives.
Data isolation between customers, chosen early because changing the tenancy model later is a migration project.
Plans, upgrades, downgrades, trials, failed payments, cancellation, and a clear source of truth for account state.
Sign-up, sign-in, invitations, role permissions, and SSO where it earns its place.
The internal panel used to understand customers, resolve issues, and operate the product every day.
The rules that enforce a pricing tier and track the activity a plan is allowed to use.
The first-run experience that gets a paying customer to value faster than another feature will.
The focused customer problem people are actually paying the SaaS to solve.
ARCHITECTURE DECISIONS
Shared data with tenant scoping or isolated data per customer. The answer changes the product foundation.
Simple roles work for most products until a larger customer needs granular control. That future needs an early answer.
Subscription state belongs in one deliberate place, not spread through the interface and webhook handlers.
A schema is the hardest part of a SaaS to change once customers have real data inside it.
MVP OR FULL BUILD
Most SaaS founders scope version one too large. The reliable approach is to build the smallest thing a customer would pay for, learn from real usage, and expand when the evidence supports it.
That does not mean building carelessly. It means fewer features built properly, with an architecture that can carry the rest when it is justified.
“A smaller first version usually produces a faster and more useful answer.”
The operating principle
TECHNOLOGIES
A production-focused stack for SaaS products that need dependable accounts, data, billing, and handover.
A responsive interface that supports the customer workflow and the internal team behind it.
The backend rules and account infrastructure the product relies on every day.
Reliable customer data and commercial state from the first paid account.
A release process and observability baseline your team can take forward.
If enterprise requirements need a different approach, that is raised during scoping rather than hidden in a generic stack list.
COMMON QUESTIONS
The questions worth settling before product scope turns into a long and expensive feature list.
It depends on scope. Price is fixed after requirements are understood, not guessed before the infrastructure is visible.
A focused MVP commonly takes ten to sixteen weeks including billing and account infrastructure. Larger scopes take longer.
Yes, after an audit. I assess the codebase before committing so the recommendation and price are honest.
Yes, including trials, proration, failed payments, cancellation flows, and the webhook handling around them.
MVP almost always. The smallest thing a customer will pay for gives the fastest useful answer.
You do, entirely, on final payment.
Tell me what customers would pay for. I will show you what has to exist around it and what a focused first build should include.