SaaS and MVP Development
Most failed software products did not fail because the engineering was poor. They failed because eighteen months and a large budget went into a full product before anyone found out whether people would pay for it. We build first releases small enough that what you learn in the first six months shapes what gets built in the next twelve.
One to two weeks of discovery and scoping, ending in a written scope and a fixed price · Ruthless prioritisation of the feature list, with what is excluded written down · Two to three weeks of design and a clickable prototype you can test on real potential customers · Eight to fourteen weeks of build in two-week sprints, deployed to a staging environment throughout
On this page
- What is a minimum viable product, actually?
- What goes into a first release?
- What deliberately stays out of a first release?
- Why will a properly scoped MVP feel too small?
- What is genuinely different about building a product rather than a system?
- What do we build into a SaaS product?
- How long does an MVP take, stage by stage?
- What happens after the MVP?
- Who owns the product and the intellectual property?
- What happens if you want to move to another developer?
- What drives the cost of a SaaS build?
- What running costs should a founder budget separately?
What is a minimum viable product, actually?
An MVP is the smallest thing that lets a real customer complete the core job and pay you for it. Not a demo. Not a prototype. Not a cut-down version of the full vision with everything half-built. A genuinely working product that does one thing properly.
The term gets used loosely, which is why so many first releases are neither minimum nor viable. The discipline is in what you leave out. Almost every founder we speak to has a feature list that could be cut in half without touching what makes the product worth buying.
That is the cheapest work in the whole project, and it happens in a room before anyone writes code. If a feature is not required for a customer to do the job and pay, it belongs in the second release — which you will scope far better once you have real usage data than you can today.
What goes into a first release?
Five things, and nothing else. The core workflow, accounts, payment, enough admin to support a customer, and analytics. Everything on that list exists because without it a paying customer cannot complete the job, cannot pay, or cannot be helped when something goes wrong. Everything not on it waits.
- The one workflow the product exists to serve, working properly end to end
- Sign-up, login and account management
- Payment, if you intend to charge — and you should, because a customer who has paid tells you far more than one who has not
- Enough admin for you to support customers
- Analytics, so you can see what people actually do
What deliberately stays out of a first release?
Six categories of work that feel essential and are not. Each one is genuinely needed eventually; none of it tells you whether the business works, and all of it is cheaper to build once real customers have told you what shape it should take.
- Every feature that is “obviously needed later”
- Deep configuration and customisation options
- Integrations nobody has yet asked for
- A full permissions matrix before you know the team structures your customers have
- Native mobile apps, in almost all cases — a responsive web app first, and a native build only when the requirement genuinely calls for one
- Anything built for a scale you do not have
Why will a properly scoped MVP feel too small?
Because it is supposed to. If the first release is scoped properly, you will look at the feature list and feel something is missing — that feeling is the point. The alternative is spending the budget on assumptions nobody has tested, then finding out which of them were wrong.
What is genuinely different about building a product rather than a system?
The user. An internal system is used by people you employ, who can be trained and told; a product is used by strangers who signed up without speaking to anyone. Every other difference follows from that one — who pays, what onboarding has to do, what support costs, and what a bad decision costs you.
| Internal system | SaaS product | |
|---|---|---|
| Who the user is | People you employ. They can be trained, and they will tell you when something is wrong. The system is built around a process your own team already follows. | Strangers who signed up without speaking to anyone. They will not read the instructions and they will not report the problem — they will simply stop using it. |
| Who pays | The business that commissioned it, once, plus whatever maintenance it needs afterwards. | Every customer, every month, by choice. Revenue is a subscription that can be cancelled without a conversation, which is why retention matters more than sign-ups. |
| What happens to a bad decision | Someone works around it and raises it at the next review. You fix it in the following phase. | People leave quietly. You see it in the cancellation figures rather than in an email, and the reason is guesswork unless the product was instrumented before launch. |
| What onboarding has to do | Support a training session and a written process that already exist. | Carry the whole job alone. A first-time user has to reach the point of value with nobody in the room, which is why a sign-up flow deserves the scrutiny usually reserved for a checkout that is losing people. |
| What support looks like | A named person inside the business who knows the system and can be asked directly. | A queue from people who have never met you, growing with every sale. Admin and refund tooling is a first-release requirement rather than a later convenience. |
| What version two is for | The requirements that did not fit phase one, already written down and waiting. | What paying customers actually did, which is rarely what the roadmap said. It is the reason the first release is scoped as narrowly as it is. |
What do we build into a SaaS product?
Eight components: multi-tenancy, authentication and accounts, subscription billing, the product interface, admin tooling, analytics, a public API, and the infrastructure under all of it. Multi-tenancy and billing are the two that must be right at the start, because both are close to a rewrite if added later.
- Multi-tenant architecture. Many customers on one system, with their data properly separated. Getting this right at the start matters enormously, because retrofitting tenancy into a single-tenant application is close to a rewrite.
- Authentication, accounts and roles. Sign-up, login, password reset, email verification, team accounts, invitations, and a role model that fits how your customers are organised. Single sign-on later, when enterprise customers ask.
- Subscription billing. Plans, trials, upgrades, downgrades, proration, failed payment handling, dunning, cancellation and reactivation, through an established provider such as Stripe. Billing is where a surprising amount of MVP budget disappears, because the edge cases are endless and every one of them touches your revenue.
- Product interface. The screens where the actual job gets done. This is where design effort should concentrate, and where most of it goes instead into the marketing site.
- Admin and support tools. The back office you will need from week one: find a customer, see their account, fix their problem, issue a refund. Founders consistently forget this and then run the business through database queries.
- Analytics and event tracking. Instrumented from the start. Which features get used, where people drop out of onboarding, what distinguishes the customers who stay. Without this you are guessing about your own product.
- Public API and integrations. For when customers start asking to connect it to what they already use — usually not in the first release, and worth designing towards. The API work itself is the same discipline as building an API onto an existing business system.
- Infrastructure. UK or EU hosting, automated deployment, monitoring, backups, and an architecture that can grow without being rebuilt — while not paying for scale you do not yet have.
How long does an MVP take, stage by stage?
Typically 14 to 22 weeks from first conversation to paying customers. We publish this because most agencies will not, and because a founder deciding between suppliers deserves to know what they are committing to. Faster is possible with a genuinely narrow first release; considerably slower usually means the scope was not cut hard enough at the start.
| Stage | Duration | What happens |
|---|---|---|
| Discovery and scoping | 1 – 2 weeks | Understanding the customer, the job, the market and the business model. Ruthless prioritisation of the feature list. Output: a written scope and a fixed price. |
| Design and prototype | 2 – 3 weeks | Core screens designed and made clickable. You test the flow with real potential customers before a line of production code exists. |
| Build | 8 – 14 weeks | Two-week sprints, working software at the end of each, deployed to a staging environment you can use throughout. |
| Beta and hardening | 2 – 3 weeks | Real users on real data. Fixing what they break, which is always something nobody predicted. |
| Launch | 1 week | Production deployment, billing live, monitoring and analytics confirmed. |
What happens after the MVP?
The MVP is the beginning of the useful part, not the end of the project. In the first three months after launch you learn what people actually do, which is never quite what you expected, and we work in continuous sprints on what the data shows rather than on the original roadmap.
From month three to month twelve it becomes the features real customers ask for, the integrations they need, and the scale problems that appear as volume grows. Some clients keep us as their engineering team indefinitely. Others hire in-house developers and we hand over — documented code, standard technologies, and support through the transition. Both are fine, and we would rather you built a team than stayed dependent on an agency.
On scaling, our position is deliberately unfashionable: we build so the architecture can grow, but we do not over-engineer for a scale that may never arrive. Building for a million users when you have none is one of the most common and most expensive founder mistakes. The right time to solve a scale problem is when it is visible on the horizon — the same judgement we apply to any bespoke system we build.
The point
On scaling, our position is deliberately unfashionable: we build so the architecture can grow, but we do not over-engineer for a scale that may never arrive.
Who owns the product and the intellectual property?
You own everything. Source code, database, designs and infrastructure accounts transfer on final payment, with the repository handed over. Your intellectual property is yours and stays yours, the technologies are standard ones any competent developer can pick up, and nothing in the arrangement makes leaving harder than arriving.
- We do not reuse your product's code in another client's project. Generic internal libraries and tooling remain ours; anything specific to your product is not.
- Infrastructure sits in accounts registered to you, so you are never locked out of your own product or its data.
- No lock-in. Standard technologies and documented code, so you can hire anyone to continue it.
- If you leave, you leave with a working product and the ability to hand it to another team — the same terms we apply to a custom CRM or internal system.
What happens if you want to move to another developer?
You leave with a running product and everything required to keep it running. The package is the repository and its history, the database and a full export, the credentials, the billing configuration, the documentation and the accounts — including the payment account, which is the one founders most often discover is not in their name.
- The repository with its full commit history rather than a snapshot of the current files, so a new team can see how the product got to where it is.
- The database schema and a full data export — customers, subscriptions, usage — in a standard format, so the product can be stood up elsewhere with real accounts in it.
- The tenant data model written down: how one customer's records are separated from another's, and where that separation is enforced. It is described in the components a SaaS product is assembled from, and it is the easiest thing for a new developer to break.
- The Stripe or payment-provider account in your company's name, with the products, plans, coupons and webhook endpoints configured inside it. A product whose billing lives in somebody else's account is not fully yours — the same argument as store accounts registered to the client rather than the agency.
- The subscription and billing logic documented: trials, proration, upgrades, downgrades, failed payments, dunning, cancellation and reactivation. That is where the edge cases live, and a surprising share of any first release goes into them.
- Environment variables and third-party credentials — payment keys, mail delivery, analytics, error tracking and file storage — listed with what each one is for.
- The API documentation, with endpoints, authentication and webhook payloads, for whatever the product exposes to its customers.
- Deployment and build instructions: how to run it locally, how a release reaches production, and what the automated pipeline does at each step.
- The domain, DNS, hosting, monitoring and error-tracking accounts, already registered to you, so a move to an in-house engineering team is an administrative transfer rather than a negotiation.
What drives the cost of a SaaS build?
Scope drives it, and scope is the one thing entirely within your control. What moves a SaaS quote is how many workflows the first release carries, how many roles and team structures it has to model, how complicated the billing rules are, and whether integrations and a public API are in from the start.
| Stage | What it covers |
|---|---|
| Validation MVP | One core workflow, accounts, billing, basic admin, analytics. Narrow by design, and the release most founders should be aiming at. 14–18 weeks. |
| Full first release | Several workflows, team accounts and roles, richer admin, integrations, more design investment. Five to eight months. |
| Scale and platform | Established product needing significant extension, enterprise features, public API, high volume. Scoped individually, because no two are alike. |
What running costs should a founder budget separately?
Four: hosting, payment processing fees, transactional email, and monitoring and error tracking. All four are modest at first and grow with usage, none is included in the build price, and a proposal that does not mention them is not telling you what the product costs to own.
- Hosting, which starts small and scales with the load your customers put on it
- Payment processing fees, charged as a percentage of what you take
- Email delivery for transactional messages, verification and notifications
- Monitoring and error tracking
How We Work
Discovery and scoping
One to two weeks. Understanding the customer, the job, the market and the business model, then ruthlessly prioritising the feature list. Output: a written scope and a fixed price.
Design and prototype
Two to three weeks. Core screens designed and made clickable. You test the flow with real potential customers before a line of production code exists.
Build
Eight to fourteen weeks. Two-week sprints, working software at the end of each, deployed to a staging environment you can use throughout.
Beta and hardening
Two to three weeks. Real users on real data, fixing what they break — which is always something nobody predicted.
Explore Related Services
Frequently Asked Questions
How much does it cost to build a SaaS MVP in the UK?
Scope, and it is the one driver entirely within your control. What moves the figure is how many workflows the first release carries, how many roles and team structures it has to model, how complicated the billing rules are, whether integrations are in from day one, and how much design the interface needs.
How long does an MVP take to build?
Typically 14 to 22 weeks from first conversation to paying customers: one to two weeks of scoping, two to three of design, eight to fourteen of build, two to three of beta, and a week to launch. If someone quotes you six weeks for a full product, ask precisely what is being left out.
Do I own the code of my MVP?
Yes — code, database, designs and infrastructure accounts, on final payment, with the repository handed over. We do not reuse your product code elsewhere. Generic internal libraries and tooling remain ours; anything specific to your product is not. If the product moves to another team, the data export and the billing configuration go with it.
What happens after the MVP is finished?
Most founders move to continuous development on a day rate or a monthly arrangement, working on what real usage data shows rather than the original roadmap. Some hire in-house and we hand over. Both are normal and we will support either.
How will my SaaS be hosted and maintained?
UK or EU cloud infrastructure, in accounts registered to you, with automated deployment, monitoring, error tracking and backups. Hosting starts small and scales with the load your customers actually put on it rather than sitting at a fixed monthly figure. Maintenance is either a retainer or day-rate work.
Can you take over a SaaS product another agency started?
Often. We begin with a code review and give you an honest assessment: whether it is a sound foundation, what it would cost to continue, and whether rebuilding would actually be cheaper. Sometimes it is. We would rather tell you that than inherit something we cannot stand behind.
How do you handle multi-tenant architecture and data separation?
Multi-tenancy is designed in at the start, because retrofitting it is close to a rewrite. Each customer's data is separated with enforcement at the data access layer rather than application logic alone, so a bug in a query cannot leak one customer's data to another. The approach depends on your data sensitivity and expected scale.
Do you work with pre-revenue startups?
Yes. Most MVP clients are pre-revenue by definition. What we do need is a founder who has spoken to potential customers and can describe the problem specifically. We cannot help someone who wants us to work out what the product should be. A paid discovery phase exists for founders with a clear problem and an unclear solution.
Will my SaaS product be visible to search engines?
Only if it is built to be. Single-page applications routinely send an almost empty HTML shell to anything that does not execute JavaScript, which is why a technical SEO audit is worth running on the marketing side of a product before launch rather than after the first quiet quarter.
Let's Build Something That Matters.
Tell us what you're trying to achieve and we'll help you find the right solution.