An MVP — a minimum viable product — is the smallest working version of an idea that a real user can actually use, built to answer one question: would anyone want this? Not a prototype, not a Figma file — real software, in front of real people.
Most software gets built the wrong way round. You believe in the idea, so you build everything — every feature, every edge case — and six months later you finally find out whether anyone wanted it. Sometimes they did. Often they didn't. Either way the answer cost too much. There's a cheaper order: build the smallest piece that gets a real user to do the real thing, watch what happens, then decide what gets built next. That's what MVP development services should actually do — and I build that first version in days, with the first one free.
What does a first version actually cover?
A first version is deliberately narrow — one user, one action, one flow that works end to end. What that looks like depends on where you are:
A founder's product idea — You have something you believe in and a few people who say they'd use it. The first version is the smallest slice that lets one of them do the core thing for real, so you learn from behaviour instead of opinions.
A company testing a new product line — You want to validate a new direction before committing real engineering to it. The first version proves or kills the idea on a fraction of the budget.
A workaround that hit its wall — The spreadsheet, the Airtable base, the WhatsApp group got you this far and now it's breaking. The first version is the smallest piece of real software that takes the strain.
An internal tool or process — A back-office job still done by hand that someone finally needs to systematise. The first version handles the one workflow that hurts most.
In every case the discipline is the same: ship something that feels embarrassingly small, put it in front of real users, and watch what they actually do.
Why most founders call me
Most founders who call me are in the same spot. They have an idea they believe in, and the instinct is to build all of it — every feature imagined, every edge case covered. They've had a quote come back at six months and a quarter-million dollars, and something about it feels wrong but they can't quite name what.
Here's what's wrong: the first version isn't a product. It's a question you're asking the market — would anyone actually use this? — and the cheapest, fastest version of that question is the right one. You don't need to build the whole thing. You need the smallest piece that gets a real user to do the real action, then you look at what happens.
The hard part was never the software. It's having the discipline to ship something small, put it in front of real users, and believe what they do instead of what they say. That's the work I help with — usually starting by talking you out of building too much.
How does an MVP project work?
First, a thirty-minute call. You tell me the idea, the user, and the one action that matters in version one. I push back on scope that's too big to be a real MVP, and I'll tell you honestly if you should talk to more users before we write any code. Free, usually this week.
Then I build your first version. I pick the single most important user-flow and build it end to end — real code, deployed to a staging environment your real users can touch. AI is in the loop the whole way, which is what compresses an agency's quarter of scoping into a couple of days. This first version is free.
Real users try it. You get it in front of three to ten real people and watch what they do — not what they say. I help you set up basic analytics so the signal is honest. A week or two of this usually tells you what you actually have.
Then we decide what's next. If the signal is real, I write a plain-language scope for phase two — what the next slice looks like, in what order, for a fixed price. If it isn't, I'll say so plainly, and you stop with everything you've learned and built so far.
What you get
A free working first version. One or two days of my work — real software, deployed to staging, with one user-flow that works end to end. Not a clickable mockup, not a Figma file. Actual code real users can touch.
A real decision, backed by data. After real users try it, you decide from evidence: keep building, pivot, or shelve. All three are valid outcomes — the point of an MVP is to make "it doesn't work" a cheap answer instead of an expensive one.
Everything handed over. Code, repository, deployment, documentation — all yours, on your servers, under your accounts, from day one. No SaaS dependency on me, no lock-in.
A team that can extend it. I show whoever maintains the software how to make changes using AI — the same tools I use daily. A new field, different copy, an extra step in a flow: your people handle it in minutes, not by waiting on a developer.
A foundation, not throwaway code. If the MVP works, phase two is built on top of the first version — not on a rewrite. You don't pay twice for the same architecture.
A first version in practice
A courier delivery company had three realities running in parallel — couriers on the street, dispatchers at desks, payroll on Friday. Three systems, three sets of data, nobody seeing the same picture. Time tracking was manual, route coordination happened by phone, and every Friday payroll tried to reconcile hours, orders, and shifts from separate sources — always with gaps, always with disputes.
We didn't try to build the perfect platform. We built the smallest thing that would let one dispatcher see one courier in real time, complete one delivery, and have payroll calculate one paycheck correctly. Two weeks, a handful of users, one flow that worked end to end. From that first slice we knew what the rest had to look like — and the company saw the value before committing to building everything.
From there the platform grew over months — a mobile app for couriers, a web admin for dispatchers, automated payroll. Dispatchers stopped chasing people by phone. Friday reconciliation that took days became an automated run. Each phase paid for itself before the next began — the whole system built one validated user-flow at a time.
Is an MVP project right for you?
A good fit if:
- You have an idea, a few real users to test it on, and a clear first action they should take
- You'd rather spend two weeks finding out something doesn't work than six months learning the same thing
- You want the option to pivot, abandon, or double down on real signal — not gut feel
- You're a non-technical founder who needs a technical partner for version one
- You're a company validating a new product line before allocating real engineering
Not a fit if:
- You haven't spoken to anyone who'd actually use this — do that first, come back when you have three real names
- You want me to design the product for you; that's your job, I build what you've thought through
- You want a fully polished, every-edge-case launch — that isn't what an MVP is, and rushing one only burns money
- You want the free first version with no intention of continuing — my time is finite, so please be honest about that
- Your project is 3D games, casino software, adult content, or adversarial scraping
Frequently asked questions
How do I know if I actually need to build an MVP?
The short answer: if you can't name three real people who'd use it, you don't yet. The hardest part of an MVP isn't writing the software — it's having real users to hand it to. Build that list first. If you can't get three names interested enough to commit to trying it, the first version goes nowhere even if it works perfectly.
What will an MVP cost?
The first version is free — one or two days of my work on a tight, well-defined scope. After that it depends on what we're building, and every phase is scoped individually with a fixed price agreed before any paid work starts. No hourly billing, no surprise invoices.
How fast can you actually ship a real MVP?
One or two days for the first user-flow, if the scope is genuinely minimum. Most founders bring me a "small MVP" that's really months of work in disguise — so the first conversation is usually about cutting it down to the one thing that proves the model. The rest can wait until you know it's worth building.
What if the MVP doesn't work?
Then you've saved months and tens of thousands of dollars finding out. You keep the code and the learning, and you decide what's next — pivot, shelve, or return to it later. The whole point of an MVP is to make "it doesn't work" a cheap answer instead of an expensive one.
What if it works and we want to keep building?
Then we do — weekly shipping, fixed-price phases. The first version is built clean enough to grow into the full product with no rewrite, so scaling up doesn't mean starting over.
Can my team take it over after launch?
Yes — that's a core deliverable. When the project wraps I train whoever will maintain it on how to modify the software using AI, the same way I do. Most small changes — a new field, different copy, an extra step — they handle in minutes. You're not dependent on me.
Let's talk
Bring the idea — but more importantly, bring the user. Tell me who they are, the one action that matters, and what you've already tried. If there's a real first version to build, I'll build it, free. If there isn't one yet, I'll tell you what to do before you spend a dollar on engineering. A thirty-minute discovery call is free — no deck, no sales.