Custom SaaS Development: How a Build Runs

The shape of a build

Most process diagrams show six neat boxes with week counts under each. Real builds overlap. Design starts before scoping is finished, QA runs inside every sprint, and the first customer conversation after launch rewrites half the backlog. The boxes are still useful, because each one ends with a decision that gets more expensive if you postpone it.

Our default stack for SaaS products and dashboards is React on the front end and Node.js on the server, with MongoDB when the data is naturally document-shaped and Postgres, often through Supabase, when the data is relational and needs strict permissions. Stack choice matters less than people think at this stage. Our MERN guide covers when that stack fits and when it doesn't.

The table below is the short version. The rest of the post explains each row.

Stage by stage at a glance

Discovery: decide whether to build at all

Discovery is research, not development. The UK Government's Service Manual puts it bluntly: you should not start building your service in discovery, and around four to eight weeks is typical for a government service. A focused startup product often needs less, but the principle holds. You are trying to understand who the users are, what they are doing today, and which constraints you cannot change.

A good discovery ends with a written problem statement in plain language and a list of the assumptions most likely to kill the product. It can also end with a recommendation not to build, or to buy an existing tool instead. The same manual notes that stopping after discovery is not a failure. We agree. A week spent learning that a $30-a-month tool solves the problem is the cheapest week of the project. If you are on that fence, read our custom software vs SaaS guide first.

Scoping: one workflow, written down

Scoping turns discovery into a first release small enough to ship. In practice that means picking the one workflow a paying customer would miss if it disappeared, and parking everything else. Each item in the backlog gets acceptance criteria a non-developer can check: "an admin can invite a teammate and assign the viewer role", not "user management done".

This is also when to settle the decisions that are painful to change later. Will each customer's data live in shared tables with a tenant ID, or in separate databases? What roles exist, and what can each one see? Who owns the repository, the cloud accounts, the domain and the payment account? Our answer to the last one is always the founder. If a studio holds your accounts, you don't fully own your product.

Design: every state, not just the happy path

Design for a SaaS product is mostly about states. What does the dashboard look like with no data yet? What does a user without permission see? What happens when a payment fails or an upload is too large? A prototype that only shows the happy path pushes all of those questions into development, where answering them costs more.

Keep the visual system small: a handful of components used consistently beats a large design kit nobody follows. Put the clickable prototype in front of two or three real users before any code is written. If they can't find the main action without help, that's a design problem, and it's cheap to fix now.

MVP build: thin slices and a staging link

Build in vertical slices: one feature working end to end, from database to screen, before the next one starts. It means you can click through something real early, and integrations like payments and email get tested in week two instead of the week before launch, when there's no slack left to fix them.

Ask for a staging URL from the first sprint and repository access from day one. Short, frequent demos beat long status reports. A common delay in software projects is not code. It's feedback waiting for a decision, so block regular time in your calendar to review what was built.

QA: permissions first

Testing should run through the whole build, but a dedicated pass before launch catches what sprint testing misses. Start with permissions, because a data leak between customers is the bug that ends trust. On Supabase, the documentation is explicit that a table in an exposed schema without row level security can be read and written by any role with a grant on it, and it recommends a policy for each operation with tests for both allowed and denied access.

Beyond that: check the OWASP Top 10 risks against your app, test keyboard navigation and contrast against WCAG 2.2, and try the core workflow on a cheap Android phone over a slow connection. Load your own messy data in, not tidy sample rows. You should receive a list of known issues alongside the fixed ones. A QA report with zero open issues usually means nobody looked hard.

Launch and iteration

Launch to a small group first. Five friendly customers who will tell you what broke are worth more than a big announcement. Before anyone outside the team logs in, monitoring should be switched on, backups should be confirmed and a restore should have been tried once. A one-page runbook covering how to deploy, roll back and who gets alerted is enough at this size.

Then the real work starts. Budget for iteration from the beginning, because the first month of usage always changes priorities. If you are planning the money side, our SaaS development cost guide and our breakdown of monthly SaaS infrastructure costs cover the build budget and the running bill.

Frequently asked questions

What to take from this

A custom SaaS build is a sequence of decisions, each made cheaper by the stage before it. Insist on written outputs at every step, keep ownership of your accounts, and protect time for feedback. Those three habits do more for a project than any choice of framework.

If you have a product in mind, our SaaS and custom software services page explains what we build, and the contact form asks for exactly the details listed in the FAQ above.