Key facts
- An MVP tests one core assumption with real users
- Cut features until it hurts, then cut one more
- Use proven tools: Laravel or Next.js, Stripe Billing, a UI component library
- Build it properly enough to extend, not as a throwaway prototype
- Decide what you will measure before you launch
- dijitul quotes MVPs at a fixed price after a free chat
What an MVP is, and is not
An MVP is not a cheap version of the full product. It is the smallest thing that tests your riskiest assumption: that people have the problem, that they will use your solution, and ideally that they will pay. For a booking platform, that might be one type of booking with card payment and email confirmations. For a B2B SaaS tool, it might be the core workflow for one user type, with billing done manually for the first few customers.
Sometimes the right MVP is not software at all: a landing page, a spreadsheet and a lot of phone calls. Build software when you know what to build.
Choosing what goes in
- Write down the one job your product does for one type of customer.
- List every feature you have imagined.
- For each, ask: can the first ten customers succeed without it? If yes, cut it.
- Keep what protects trust: secure login, data protection, reliable payments.
- Do manually what you can at first: onboarding calls, invoicing, reports.
Things commonly cut from MVPs: native mobile apps (a responsive web app or PWA will do), complex permissions, admin dashboards beyond the basics, integrations other than payments, and multiple pricing plans.
Technology choices that won't box you in
Pick mainstream, well-documented tools so you can hire later and change direction cheaply:
- Application: Laravel (PHP 8) or Next.js (TypeScript), both with large ecosystems.
- Database: PostgreSQL or MySQL. Design the data model with multi-tenancy in mind if you plan to sell to businesses.
- Payments: Stripe Checkout or Stripe Billing, rather than building subscription logic yourself.
- Hosting: a simple managed setup, with Docker if it helps consistency. Avoid complex microservices at this stage.
- Auth: the framework's built-in authentication, with SSO added later if enterprise customers ask.
An MVP should be built well enough to extend. A throwaway prototype that has to be rewritten the moment it succeeds is expensive at exactly the wrong time.
Launch, measure, decide
Before launch, agree what success means: sign-ups that complete the core task, weekly active use, conversion to paid, or a number of customer interviews. Add simple analytics and talk to users directly. After a few weeks of real use, decide: build the next most requested feature, change direction, or stop. Each decision is cheaper with an MVP than after a full build. Our guides on web app costs and build time help with planning the next stages.
Common MVP mistakes
- Building in secret for months. The longer you go without real users, the more assumptions harden into code. Show early versions to potential customers as soon as they work.
- Too many user types. A marketplace with buyers, sellers, admins and affiliates is four products. Start with the side that is hardest to win, and handle the others manually.
- Gold-plating the admin. In an MVP, the founder can update settings in the database or a simple admin screen. Polished back-office tools can wait.
- Building subscription billing from scratch. Stripe Billing handles plans, trials, proration, invoices and failed payment retries. Use it.
- Ignoring the basics of trust. Cutting security, backups or data protection to save time is a false economy: one incident can end a young product. Our UK GDPR guide covers the essentials.
- No analytics. If you cannot see what users do, you cannot learn from the MVP, which defeats the point of building it.
- Choosing technology for a CV. Microservices, Kubernetes and exotic databases add cost and complexity an early product does not need. A single, well-structured application is easier to change.
- No plan for after launch. Budget for a second phase of changes based on what you learn. The first version is rarely right, and that is the point.
Avoiding these does not need a large budget. It needs discipline about scope and a clear question the MVP is meant to answer.
When to talk to dijitul
dijitul builds MVPs and SaaS products for founders who want working software, not slide decks. We help you cut the scope to what matters, build it on mainstream technology you own, and plan the phases after launch. Start with a free chat, then get a fixed-price quote for the MVP.
Frequently asked questions
What is an MVP in software?
A minimum viable product is the smallest usable version of a product that lets real customers do the core job, so you can learn whether it is worth building more. It tests your riskiest assumption with the least time and money.
How much does an MVP cost in the UK?
It depends on the scope you choose, which is why cutting features matters so much. Our guide to web app costs lists published UK market ranges. dijitul gives a fixed-price quote for a defined MVP scope after a free chat.
Should my MVP be a mobile app?
Usually not at first. A responsive web app or progressive web app works on phones, avoids app store reviews and needs one codebase. Build native apps once you know users want the product and need device features.
Can an MVP be scaled into the full product?
Yes, if it is built on mainstream frameworks with a sensible data model and tests. That is the difference between an MVP and a throwaway prototype. Plan for growth, but do not build for scale you do not have yet.
Do I keep the code for my MVP?
With dijitul, yes. You own the code and data, and the repository sits in an account you control. That matters when you raise investment, sell the business or hire your own developers, because investors and buyers will ask.
Related
Tell us what you need to build
Free chat, clear scope, fixed-price quote. You own everything we build.