SaaS product buildingBuilding it is six months.Finding out if anyone wants it is six weeks.
SaaS product building is an application plus everything that makes it a business: separate tenants that cannot see each other, subscription billing and trials, self-serve sign-up and onboarding, and the usage metrics that tell you which parts are used and which were a guess. Shipped as a first version, then iterated against real accounts.
Why it matters
A first version exists to answer one question: will someone pay for this. Everything that does not help answer it is a cost with no information attached.
Billing is not a later problem
Trials, failed cards, mid-month seats and downgrades are decided before the first screen. Retrofitting them into a product with paying accounts means migrating money.
Tenants separated at the database
Isolation is a constraint in the schema, not a filter someone must remember to add. The leak that ends a SaaS is one missing WHERE clause.
Instrumented, so the roadmap can be wrong
Activation, usage and churn are measured where they happen. The next decision comes from what accounts did, not from what the pitch deck assumed.
The part founders underestimate
The application is rarely the hard part. Billing states are: a trial that lapsed, a card that failed on the third retry, a team that added four seats mid-month, an account that downgraded and must lose exactly the right features and no others.
That logic is decided before the first screen is built, because retrofitting it into a product that already has paying accounts means migrating money. Get it right once and the rest of the product is free to change weekly.
See pricing for how engagements are scoped and what a phase includes.
How we do it
How the work runs.
- Narrow
- First version
- Billing
- Instrument
- Iterate
Narrow
One job the product does better than the spreadsheet it replaces. Everything else waits for evidence.
First version
The smallest thing a real account can sign up for and use, with billing wired from day one.
Instrument
Activation, usage and churn measured where they happen, so the next decision has something behind it.
Iterate
Weekly releases against what accounts actually do, with the roadmap re-cut when the data disagrees with it.
Built with
What this service is made of.
Interface
TypeScript
One language from the database call to the button, with the types checked at the boundary between them.
React
For interfaces with state worth managing — anything signed in, live or multi-step.
Tailwind CSS
A spacing and colour scale that holds across a large application without a stylesheet nobody dares delete from.
Application
Next.js
Server rendering, routing and server-side data access in one framework, so permissions are checked on the server.
Node.js
The runtime everything else assumes, and the same language the interface is written in.
Stripe
Subscriptions, trials and failed-payment handling. Card details never reach the application.
Data
PostgreSQL
Relational, boring and correct. Tenant isolation and constraints belong here rather than in application code.
Prisma
Schema as a file in the repository, with migrations reviewed like any other change.
Redis
Sessions, rate limits and job queues — the state that should disappear cleanly if it is lost.
Delivery
GitHub Actions
Tests, type checks and the performance and accessibility gates run on every push, not before a launch.
Playwright
The handful of journeys that must never break — sign-up, checkout, enquiry — tested in a real browser.
Docker
The same environment locally and in production, so "it works on my machine" stops being a category of bug.
Cloudflare
Edge caching, DNS and protection in front of everything we host.
Agents and workflows
Claude and GPT APIs
Model calls for classification, drafting and qualification, always behind our own validation.
Vector search
Retrieval over your own documents, so an agent answers from your content instead of its training data.
SaaS product building — from first version to paying users FAQs
Still have questions?The ones we get asked.
Can you build the first version before we have funding?
That is the usual case. The first version is deliberately narrow — one job, one plan, one way through it — because a product with four half-finished features tells you nothing about demand. It is bought as a fixed-price phase, so the cost is known before it starts.
Do you take equity instead of fees?
No. Fees only. An equity arrangement makes us a shareholder arguing for our own preference rather than a supplier you can replace, and it tends to end badly for the founder who has less legal support in the room.
Who runs it after launch?
Whoever you want. Some clients take the codebase and hire in-house once there is revenue to justify it; others keep us on a monthly engagement for releases and upkeep. The handover is the same either way — your repository, your infrastructure accounts, written documentation.
How do you handle payments and data protection?
Card details never touch the application: payment is handled by a PCI-compliant provider and the product stores only the subscription state. Tenant data is isolated at the database layer, backups are tested rather than assumed, and GDPR obligations such as export and deletion are built rather than promised.
Start with saas product building?
Tell us what you are trying to grow. We reply with what we would change first.