The first working version of your product — small on purpose, and built to survive being right.
An MVP is not a cheap version of the finished thing. It is the shortest path to finding out whether the idea holds, put in front of real people who can accept or reject it. The hard part is almost never the code; it is deciding what to leave out, and being disciplined enough to actually leave it out.
What’s included
Framing the question first — what you need to learn, and what evidence would count as an answer
Scope built around that question, with a written record of what was deliberately deferred
A working, deployable product on a modern, maintainable stack — not a demo held together for one meeting
The unglamorous essentials that make it real: accounts, payments, data handling, and somewhere for it to run
Iteration once actual users arrive and start doing things nobody predicted
Clean handover: your repository, your infrastructure, documented well enough for another developer to pick up
Where this differs from our other software work.Custom software and integrations is for a business that already knows its process and needs the tooling to match it. This is for a product that does not exist yet, where the process is the thing being tested.
Best for founders and teams validating a new product, and for established businesses launching something outside their existing systems. Delivered remotely, anywhere.
Common questions
How small should an MVP actually be?
Smaller than feels comfortable. The point is to learn something specific — that people will sign up, or pay, or change how they work — and everything not serving that question is cost you are carrying before you know whether the idea holds. We start by writing down what you are trying to find out, then cut back to the shortest thing that answers it.
Will we have to rebuild it if it takes off?
Not if it is built properly the first time. There is a real difference between a small product and a throwaway prototype: a prototype takes shortcuts you have to unpick later, while a small product is simply fewer features on a stack that holds up. We build the second kind, because the version that succeeds is the version you are then stuck running.
Who owns the code?
You do — the code, the repository, and the infrastructure it runs on. It is built on a mainstream, maintainable stack rather than a proprietary platform only we can service, so bringing in your own developers later or moving to another firm is a normal handover rather than a rescue.
What will it cost and how long will it take?
That depends entirely on what the thing has to do, and any number quoted before that conversation would be invented. What we can tell you early is the range work of a similar shape usually lands in, and what would move it up or down. How we scope and charge is written up on the pricing page.
We are not technical. Is that a problem?
No — it is the common case, and it mostly changes how we work rather than whether we can. You bring the knowledge of the problem and the customers; we translate that into decisions about what to build. What we will not do is hide the trade-offs behind jargon, because you are the one who has to live with the product afterwards.
What if you think the idea will not work?
We say so, before you spend money. Sometimes the honest answer is that an off-the-shelf tool already does it, or that a spreadsheet and a landing page would test the demand for a fraction of the cost. Telling you that costs us one engagement and is the only thing that makes the rest of our advice worth listening to.
