Build your MVP — An MVP is an experiment, not a small product.
What to launch with, when to launch it, and who to put it in front of — and then the build itself, with your team or in place of one. For founders at the idea stage, and for those holding a prototype and no clear view of whether it will hold.
- 20+ years building products
- Founded and exited a studio
- B Corp founder
- Prototype to production
What the work covers
In the order that matters. Most of what an MVP costs over its life is decided by how the first question gets answered.
What to launch with
The smallest version that answers the question you actually need answered — which is rarely the smallest version of everything you eventually want. Most first releases are too big, not because anyone argued for scope, but because nobody was responsible for taking it out. We work through what goes in, what is explicitly deferred, and what gets cut for good, and we write down which assumption each remaining feature is there to test. If a feature is not testing anything, it is not in version one.
Technical architecture
The choices made in the first fortnight — data model, auth, hosting, what you build against and what you buy — are the ones that decide how expensive the next two years are. Almost none of them need to be enterprise-grade at this stage, and picking the heavyweight option early is as costly a mistake as picking the throwaway one. This includes reviewing prototypes built with AI coding tools: telling you plainly which parts are a foundation, which are a demo wearing a foundation costume, and what it would take to make the difference.
When, and who to launch to
A launch to the wrong audience returns flattering noise, and a launch at the wrong moment returns nothing you can act on. We work on who sees it first and what you are asking them, so the response is a signal rather than encouragement. That usually means fewer people than founders expect, chosen because they have the problem badly enough to be honest about whether you have solved it.
Building it
Where you have a team we lead the work or sit alongside it, and where you have not, we write the first version ourselves. It gets built to be handed over: a stack an ordinary developer can pick up, a data model that will take another year of change, and the decisions written down rather than carried around in someone’s head. A first version should be replaced one day by a second one written with everything you have since learned — and getting there should not cost a rewrite. Quoted as a piece of work rather than charged as a monthly fee, because it has an end.
From first note to working together
A conversation
Forty-five minutes on the idea, anything you have already built, and what you are actually trying to find out. No deck required.
A product and technical review
A short piece of work: the scope, the architecture, and — where one exists — the prototype itself, gone through properly. You get a written view whether or not it goes further.
The launch plan
What is in version one and what is explicitly out, the technical decisions that need making now rather than later, and who sees it first. Written so a developer could pick it up and start.
Through the build
As much or as little as you need — a standing call while your team builds it, technical leadership over the work, or writing it ourselves where there is no team yet.
This is probably you if
- You have an idea and no clear view of what the first version should actually contain.
- You have a prototype built with AI coding tools and cannot tell whether it is a foundation or a demo.
- You are about to spend real money on developers and want the brief to be right before you do.
- You have been quoted for a build and would like someone independent to sanity-check the scope.
- You have shipped something and cannot work out who to put it in front of.
- You want to launch in weeks rather than quarters, and need someone willing to say what comes out.
- You would rather one person owned both the decisions and the code than brief an agency on a spec you are not confident in.
Build your MVP — common questions
What counts as an MVP?
The smallest thing you can put in front of real people that settles a question you cannot otherwise answer. That is a narrower definition than most founders start with, and the difference matters commercially: a small version of the whole product tests nothing in particular and costs most of what the whole product would. An experiment has a hypothesis, an audience and a result you are prepared to act on — including the result where you stop.
We built a prototype with AI coding tools. Is it any good?
Usually it is an excellent specification and a poor foundation, and those are not the same judgement. What these tools produce is the clearest requirements document you will ever have — something real, that people can use and react to, which no written spec achieves. What they rarely produce is code that survives a second year of change: the data model, the auth, the boundaries between things. We go through it and tell you which parts to keep, which to treat as a drawing of what you want, and what rebuilding properly would actually cost. Sometimes the answer is that it is fine to ship as it stands, and knowing that is worth the review on its own.
Do you build it, or only advise?
Either. Where you have a team, we lead the work or sit alongside it. Where you have not, we write the first version ourselves — built to be handed to a team, because one day it will be. That is the same seat described under fractional CTO and CPO, and it is priced as a piece of work rather than a monthly fee, because it has an end.
How long does this take?
The review and the launch plan are usually two to three weeks. The build depends entirely on what survives the first conversation, which is the point: the fastest way to launch sooner is to launch with less, and that decision is worth more than any amount of speed afterwards.
How is it priced?
The review and launch plan are quoted as a fixed piece of work, priced on their own so you can stop there if that is all you needed — plenty of founders do, and take the plan to their own team. Anything beyond it is either a fixed monthly fee against an agreed remit or a quoted build, depending on which you are asking for.
Tell us what you are trying to launch.
What the idea is, anything you have built already, and what you are hoping to find out. That is enough to start — we read everything ourselves and reply to most notes within a couple of working days.
Or email hello@lode.venturesThanks — that's with us.
We read everything ourselves and reply to most notes within a couple of working days.