When founders ask how much an MVP costs, the answer is always a range — £25,000–£80,000, or similar. That range is accurate, but it is not useful when you are trying to decide what to build, what to cut, and where the budget is actually going.
This breakdown takes a different approach. Instead of an overall budget estimate, it examines what each component of a SaaS MVP actually costs to build — what drives the number up, what drives it down, and which components can be handled cheaply with off-the-shelf tools versus which ones require bespoke engineering.
The costs are expressed in engineering days rather than fixed pound amounts, because day rates vary significantly. A senior UK-based contractor day costs roughly £500–£700; an agency or offshore team scales differently. Use the day counts as your baseline and apply your own rates.
Authentication: Buy It, Do Not Build It
Authentication is one of the most time-consuming components to build correctly and one of the cheapest to buy. The options are clear.
A managed auth service — Auth0, Clerk, or Supabase Auth — handles password storage, OAuth integrations, session management, MFA, and magic links. Integration work is 1-3 days for a standard setup. Cost at MVP scale is effectively zero: most managed auth services have free tiers that cover the first few thousand users, and paid tiers start at $25–$50 per month.
Building custom auth from scratch means implementing secure password hashing, session token management, refresh token rotation, rate limiting on login endpoints, and account recovery flows. Done properly, this is 2-4 weeks of senior engineering work. Done improperly, it creates the kind of security vulnerabilities that will be expensive to fix later and potentially catastrophic if exploited.
There is no reasonable justification for building custom auth in an MVP. The cost savings do not exist — the managed service is free or near-free — and the security risk is real. The only exception is if your product operates in a regulatory environment that prohibits third-party auth providers, which applies to very few early-stage products.
Authentication cost: 1-3 days using managed service. Non-negotiable recommendation: use the managed service.
Payment Infrastructure: Right-Size It to Where You Are
Payment integration is where MVP scope creep is most common, because payment systems are genuinely complex and it is tempting to build them comprehensively from the start.
Stripe’s pre-built checkout, combined with their Billing product for subscriptions, covers the needs of most SaaS MVPs. Integration work is 3-5 days: set up products and prices in the Stripe dashboard, wire up the checkout flow, handle the webhook events for subscription created, updated, and cancelled, and reflect the subscription state in your user model. The result is a fully functional subscription system with card payment support, automated renewal, failed payment handling, and a customer portal for self-service changes.
What this does not include: usage-based billing, volume discounts, complex proration logic, custom invoicing, multi-currency with localised pricing, reseller or affiliate structures, or a custom billing dashboard. These are real requirements for some products — but they are almost never requirements for an MVP, and each one adds 1-3 weeks of engineering work.
The instinct to build the full billing system upfront is understandable — billing is hard to retrofit. But the correct response to that difficulty is to design the data model carefully from the start, not to build the full billing implementation before you have validated that users want the product. A clean Stripe integration with a well-structured subscription model is retrofittable. The 8 weeks you saved by deferring custom billing are better spent validating whether the core product has traction.
Payment cost: 3-5 days for Stripe pre-built checkout and subscriptions. Custom billing: 4-8 weeks, defer to v2.
Email and Notifications: Near-Zero at MVP Scale
Transactional email — account confirmation, password reset, billing receipts, product notifications — is a solved problem. Postmark, Resend, and Sendgrid all offer free tiers that cover MVP volumes (typically the first 100–1,000 emails per month), and integration is 1-2 days.
The mistake is conflating transactional email with a full notification system. A notification system that supports user preferences, in-app notifications, notification history, digest emails, and multi-channel delivery (email, push, SMS) is a significant engineering project — 3-6 weeks. It is also a project that should only be built when you understand enough about user behaviour to know what they actually want to be notified about.
In-app notifications — the bell icon with a dropdown — are similarly deferrable. Most MVP workflows do not require real-time in-app notifications. If a user completes an action and needs to know about a downstream result, an email works fine until you have enough usage data to understand how people are actually using the product.
Email cost: 1-2 days integration with transactional email service. In-app notifications and preference management: defer to v2.
Data Storage and Hosting: Scale to Your Actual Traffic
The choice of infrastructure at MVP stage has more impact on monthly running costs than on build costs. The build cost difference between deploying to Railway or Render versus deploying to AWS is significant; the operational difference at MVP scale is minimal.
Supabase, PlanetScale, and Railway are the right choices for most SaaS MVPs. Supabase gives you a managed Postgres database, storage, and auth in a single product. Railway and Render handle application deployment without the operational overhead of configuring EC2 instances, load balancers, and VPCs. Monthly costs at MVP scale are £50–£200, covering the database, application servers, and object storage.
Building on AWS or GCP from day one is appropriate if you have regulatory requirements, specific geographic distribution needs, or a technical team that already operates cloud infrastructure at that level. For most early-stage SaaS products, it adds 2-4 weeks of infrastructure setup work and £300–£800 per month in baseline costs before a single user has signed up. The scalability argument — “we might need to scale” — is premature. You can migrate when you have the usage that justifies the cost. Migration at that point is a known, well-understood process, not a risk.
Infrastructure cost: 2-4 days setup on managed platforms, £50–£200/month running cost. AWS/GCP: only if you have specific reasons.
Core Workflow: Where the Budget Actually Goes
Everything covered so far — auth, payments, email, hosting — can be assembled in 2-3 weeks using managed services and standard integrations. The remaining 60-70% of MVP build cost sits here: the actual product logic that makes your SaaS product do the thing it is supposed to do.
This is deliberately impossible to generalise, because it depends entirely on what the product does. A simple CRUD workflow for managing records of a single type is a week. A complex multi-step workflow with conditional logic, real-time collaboration, or heavy data processing can be 12-16 weeks.
The decisions that drive the core workflow cost up:
Data model complexity. A product where the core entity has many types, states, and relationships takes longer to model and build than one with a simple structure. Get the data model right before building the UI — mistakes here are expensive to fix.
Real-time requirements. Live collaboration, real-time updates, and websocket connections add 1-3 weeks to any workflow that requires them. Polling is an acceptable MVP shortcut if the use case allows a few seconds of latency.
Third-party integrations. Connecting to external APIs, syncing with other tools, or ingesting data from external sources adds significant complexity. Each integration is its own mini-project: API authentication, rate limit handling, error recovery, data mapping. One well-scoped integration is 1-2 weeks. Three integrations shipped in parallel is a risk.
Permissions and access control. Simple role-based access (admin vs. member) is a day or two. Fine-grained permissions per resource, custom roles, and inheritance structures can add 2-3 weeks.
The discipline required at MVP stage is ruthless scope reduction to the single core workflow that proves the product’s value. Build the one thing. Do not build the second and third things until the first thing is working and people are using it.
Onboarding Flow: A Discrete Investment Worth Making
Onboarding is distinct from the core workflow because it is the mechanism by which users get to the core workflow successfully. A product with a poor onboarding flow will show low activation numbers even if the core product is strong.
A basic onboarding flow — a welcome screen, 2-3 guided setup steps, and an empty state with a clear call to action — is 3-5 days of design work and 3-5 days of development work. That investment pays for itself through higher activation rates.
Progressive onboarding, where users are guided toward specific value moments over the first week through contextual prompts and in-app messages, adds 1-2 weeks of design and development. It is worth building into v1 if your product has a non-obvious first value moment that users are unlikely to reach without guidance.
What is not worth building in v1: interactive product tours, full help centre integrations, video walkthroughs, and personalised onboarding paths based on user role or use case. These are optimisations for a flow you have not yet validated. Build the basic guided path first; optimise it when you have data about where users are actually getting stuck.
Onboarding cost: 6-10 days for basic flow. Progressive contextual onboarding: add 1-2 weeks.
Analytics: Use the Free Tier, Skip Custom Instrumentation
Understanding how users are actually using your product is not optional — it is how you make decisions in v2. The good news is that the instrumentation cost at MVP stage is near zero.
PostHog’s free tier covers up to 1 million events per month, includes session recordings, funnel analysis, and feature flags, and takes 1-2 days to integrate. Mixpanel and Amplitude have similar free tiers. Any of these gives you enough data to understand where users are activating, where they are dropping off, and which features they are actually using.
What does not belong in an MVP: custom analytics infrastructure, data warehousing, bespoke reporting dashboards, or event schemas designed for advanced segmentation. These are useful at scale. At MVP scale, you do not have enough data to need them, and the engineering time is better spent on the product itself.
Analytics cost: 1-2 days integration with PostHog or equivalent free tier.
The Version Two List
The following features are common sources of scope creep at the MVP stage. None of them are inherently wrong to build — they are wrong to build before you have validated the core product:
- Multi-team and multi-workspace support
- Advanced admin dashboards with user management
- Public API with API key management
- Webhook infrastructure for third-party integrations
- Custom reporting and data export
- Complex notification preferences
- White-labelling or custom branding per account
- SSO and enterprise authentication (SAML, SCIM)
- Audit logs and compliance tooling
Each of these is a real product requirement that will eventually be necessary. Each of them is also a significant engineering investment that only makes sense once you know the core product is worth investing in. The teams that build these in v1 are usually the teams that run out of runway before they get to market validation.
Build the core workflow. Validate it works. Then come back for everything else.
Celvix builds scoped, production-ready SaaS MVPs — get a breakdown for your specific product at.
Service Offering: MVP Strategy & Build
Celvix helps founders and early teams scope, design, and build SaaS MVPs without wasting time on low-value features.
Explore MVP Development Service Explore MVP Development Service
