What is SaaS development?
Building a web product that businesses pay a recurring fee to use. That means accounts rather than visitors, a subscription that can change halfway through a month, data from several customers living in one system, and a back office you can run the company from. The feature work is the same as any web app; the parts around it are what make it a different job.
I build it in Next.js and TypeScript with Supabase or PostgreSQL behind it, Stripe for billing, and coding agents doing the first draft of the routine work while I write and check the parts where being wrong costs money.
Should I use a no-code builder, an agency, or you?
All three get a real product on screen. They differ in what you own afterwards and what breaks when the business grows into the tool.
| The question | No-code SaaS builder | An agency | Me |
|---|---|---|---|
| Cost to start | Lowest | Highest | One fixed price, listed starting point |
| Speed to something clickable | Days | Weeks, after the discovery phase | Weeks, in chunks you can click |
| Who owns the code | The platform does | Depends on the contract, so check it | You do, in your repository and accounts |
| Billing and plans | Templates, inside the platform's rules | Custom, priced per change | Custom, on Stripe or a merchant of record |
| What breaks first | The limits: roles, data rules, anything the platform forbids | The handover, and the person who built it leaving | Capacity: I am one engineer, so scope and timeline are agreed in writing |
| Changing it later | Inside what the tool allows | Another agency quote | Any engineer with the repository |
How do you keep one customer's data away from another?
It is called multi-tenancy: one system serving many customer accounts, each certain it is the only one there. Every row carries the account it belongs to, and every read is filtered by that account at the data layer rather than in each screen. A forgotten filter in one component is a leak, so the rule lives where the query is built and gets tested the way a payment flow does.
Permissions sit on top of that: owner, admin, member, and sometimes a customer's own staff roles. I write them as a small table in the plan before the build, because retrofitting roles into a live product means touching every screen twice.
What does the first paid version leave out?
The cut list is the most valuable part of the plan. Version one ships sign-up, one workflow done properly, billing, and an admin view that tells you what people use. What waits: social logins, team invites beyond the basics, several plan tiers, a mobile app, a full design system, self-serve onboarding email sequences, integrations nobody has asked for, and dashboards you build before you have customers to read them.
Two things I do not cut, because they are expensive to add later: the account boundary in the data, and the billing relationship. Everything else can wait for a paying customer to tell you it matters.
How long does a SaaS MVP take?
Shorter than a plan, longer than a demo. The honest answer is that the calendar is set by the scope agreed in writing, and I work in chunks with something you can click at the end of each one, so a delay shows up in week two instead of at launch.
What actually decides the length is the number of workflows and how much of your existing data has to move in. Billing rules, roles and a migration are where the time goes, not the screens.
What does it cost?
A SaaS product is priced like the web app it is. A first paid version starts at $799, and the exact number is one fixed price agreed in writing after a free call, never an hourly meter that runs while you wait. Small jobs start at $49. That starting point is what covers the small changes around a live product: a copy fix, a new field, one extra report.
Two costs are separate from the build and I estimate both before it starts: the platform bills (hosting, database, Stripe fees, and the model spend if you have AI features), and the monthly care plan at $149 a month for fixes, small changes and someone watching it.
What happens after launch?
Monitoring for the errors customers feel first, backups that are actually restorable, and a monthly plan for the small changes that never stop coming. A subscription product also needs the boring money work: receipts, a failed-payment sequence, and what happens to a team's data when its account is cancelled.
I stay on for that if you want me. If you would rather hand it to your own engineer later, the repository, the accounts and a written note on how it fits together are yours from day one.