MVP Development
One idea, built far enough to launch
We take a single core idea to a working first release — small enough to fund, real enough to put in front of users, and built so that version two is not a rewrite.
Talk to us about your projectWhat we mean by a first release
An MVP is not a cheaper version of the whole product. It is the smallest thing a real person can use to produce a real answer — do they sign up, do they come back, do they pay. Everything that does not serve that question waits.
The hard part is not building it; it is agreeing what stays out, then holding that line when a good new idea arrives mid-build. We write the exclusions down at the start, so that conversation becomes a decision with a cost attached rather than an argument.
Capabilities
What goes into a first release
The mix changes per product. What does not change is that every item has to earn its place by serving the one question this release exists to answer.
Scope definition
A written scope doc naming the one core workflow, the screens it needs, and a numbered list of what is out of this release.
Product and interface design
Clickable Figma flows for the core journey before code starts, so the argument about screen order happens in a file rather than mid-sprint.
Web or mobile build
React and TypeScript on the web; Swift, Kotlin or React Native when it genuinely has to be an app rather than a mobile site.
Accounts, roles and billing
Signup, password reset, roles and a live payment flow through Stripe or Razorpay — the parts founders defer and then need on launch day.
Proven building blocks
We reuse patterns already shipped for auth, admin panels and file handling, so the budget goes to the part of the product only you have.
Admin and operations tooling
An admin screen where you can find a user, refund an order and fix bad data yourself, instead of emailing us for a database query.
Analytics and instrumentation
Event tracking on the few actions that tell you whether this worked: signup completed, first real use, second visit. Wired up before launch, not after.
Deployment and environments
A staging environment and a one-command deploy from your own repo, with the pipeline configured in CI so releases never depend on one person's laptop.
Built to be extended
Clear module boundaries and versioned database migrations, so the second release adds to this codebase instead of starting a rewrite of it.
What you get
What exists when we finish
All of it is handed over. If the next version goes to a different team, or in-house, nothing is missing.
- LIVE PRODUCT
- The release, in production
- Running on your hosting account or ours, on a real domain, with real accounts and payments enabled. Not a demo build that needs another week of work before anyone can use it.
- THE CODEBASE
- Source, repo and deploy pipeline
- In your Git organisation from the first commit, not handed over at the end. Includes CI configuration and environment setup, so another team can ship a change without booking time with us.
- SCOPE RECORD
- The scope doc and its exclusions
- What we agreed to build, what we agreed to leave out, and every change made along the way with what it cost. Useful months later, when nobody remembers why a feature is missing.
- OPERATING NOTES
- Running costs and the next list
- What the build revealed, which assumptions are still untested, what it costs to run each month, and the parts we would rework first if you carry on.
How we work
From idea to a product people can sign into
Timelines below are typical for a first release. We would rather tell you the scope is too big for the budget than start it and find out together in month three.
Scoping
1–2 weeksWe work out the one thing this release has to prove, then write down what is out. Sometimes that conversation shrinks the project into something much cheaper.
Design and plan
1–2 weeksClickable flows for the core journey, the stack decision with its trade-offs stated, and a build plan in weekly slices you will see landing on staging.
Build
6–10 weeksThe product itself, shipped in reviewable increments. When a slice turns out bigger than scoped, we say so that week and you decide what moves out to make room.
Launch and next steps
OngoingDeployment, the agreed bug-fix window after delivery, and an honest read of what real usage says. Many teams carry on; some pause here on purpose, and that is a fine outcome.
Is this the right service for you?
Worth reading before you get in touch — it saves both of us a call.
A good fit if…
- You can name the one thing this first release has to prove
- You are willing to cut features to protect the launch
- You have a budget in mind and want the scope shaped to it
- Someone on your side can make product decisions within a day
Probably not, if…
- You need the full multi-tenant platform now — see Web & SaaS Platform Development
- The build is a token or on-chain launch — see Smart Contract Development & Audit
- You already have a live product that needs rebuilding rather than starting
- Nobody on your side can decide what gets cut when scope has to shrink
Frequently Asked
Questions
Common questions about scoping, pricing and launching a first version.
Every MVP is quoted individually, because the number depends almost entirely on scope. Tell us the budget you are comfortable with and we will say honestly what fits inside it, rather than quoting a build you cannot fund. What moves the price: the number of distinct user roles, whether payments and third-party integrations are in this release, whether it needs a native app as well as a web app, and any compliance requirement. We will also tell you plainly when something can wait until later.
Roughly three months from first conversation to a product real users can sign into: one to two weeks scoping, one to two weeks design, then six to ten weeks of build. A single-workflow product lands faster. What stretches a timeline is almost never the engineering — it is decisions left open on your side, and integrations with systems we do not control, where the other party's API sets the pace. We plan in weekly slices so slippage shows up early enough to act on.
We would rather restructure than stop badly. Because the build is sliced weekly and each slice is deployable, there is usually a version at the current line that can go live, even if it is narrower than planned. We will tell you which remaining items are load-bearing for launch and which are not. If the honest answer is that what remains is not launchable, we will say that too. What we will not do is keep billing against a scope you can no longer finish.
You do, from the first commit. The repository sits in your Git organisation, and hosting, domain, database and payment accounts are created in your name with us added as collaborators. At the end we remove our access whenever you ask. There are no licence fees on anything we write for you, and no component that stops working when you stop paying us. Where we reuse a building block from earlier work, it ships as ordinary source code in your repo, not a dependency you rent.
Usually the settings pages nobody has asked for, extra user roles when one will do, a second platform, internationalisation, and every reporting screen except the one that answers the launch question. Also anything built for a scale you do not have yet. None of these are permanent decisions; they are sequencing decisions, and each is written down so it can be revisited with a cost attached. The exclusion list ends up the most useful document in the project.
It is built to be extended, and that is a design constraint from day one rather than a reassurance. Concretely: module boundaries that match how the product is likely to grow, versioned database migrations instead of a hand-edited database, and no shortcut taken quietly. Where we do take one on purpose to hit a date, it goes in the handover notes with what it will cost to undo. Some things genuinely should be rebuilt once real usage tells you what you got wrong.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.