Most ideas don't survive contact with users. The first version isn't a product — it's a question you're asking the market: would anyone actually use this? Done well, that question costs days of work and a fraction of the budget. I build minimum-viable software in days, not months, with AI compressing what an agency would scope for a quarter. Your first version is free, so you find out fast — and the answer is real, not theoretical.
The temptation, when you've got an idea you believe in, is to build everything. Every feature you've imagined. Every edge case covered. Six months and a quarter-million dollars later, you've got software — and now you find out whether anyone wanted it. Sometimes they did. Often they didn't. Either way, the answer cost too much.
There's a better order. The first version isn't a product. It's a question you're asking the market: would anyone actually use this? The cheapest, fastest version of that question is the right one. Most founders I talk to don't need to build the whole thing — they need to build the smallest piece that gets a real user to do the real action, then look at what happens, then decide what gets built next.
The hardest part of an MVP isn't writing the software. It's having the discipline to ship something that feels embarrassingly small, put it in front of real users, and watch what they actually do — instead of what they say they'd do, or what you hoped they'd do.
Tell me the idea, the user, the one action that matters, and what you've already tried. I'll tell you straight whether there's an MVP here or whether you've got more talking-to-users work to do first.
One or two days of my time. Real software, deployed to a staging environment, with one user-flow that works end to end. Not a clickable mockup, not a Figma file — actual code that real users can touch.
Show it to three to ten real users. Watch what they do, not what they say. The data answers questions you couldn't have asked before. From there you decide: keep building, pivot, or shelve. All three are valid outcomes.
Not a sales tactic with fine print. The first version is genuinely free — up to about forty hours of my work on a tight, well-defined scope. That's how I prove the work is worth paying for, without asking you to trust me first.
Code, repository, deployment, documentation — all handed over. Then I show whoever's going to maintain it how to make changes using AI. Adding a field, tweaking a flow, swapping a step — your people do it in minutes, not by waiting on a developer.
Not on the first version — on the months and years after, when an MVP works and we keep building. But you choose to come back. It's never a trap. The free first version is how I find clients I want to work with for the long run.
The right stack for an MVP is the stack you can move fastest in and that someone else can pick up later. Nothing exotic. Nothing chosen for fashion. Whatever your eventual engineering hire will already know.
Independent engineer. Twenty years of shipping first-version software for businesses — back-office tools, internal apps, product MVPs, integrations. Practiced at finding the smallest piece that proves something.
I've been building software for businesses since 2004. A lot of that work was first versions — the moment a company realised the spreadsheet wasn't enough anymore, the moment a founder needed something to show real users, the moment a team needed to test an idea before committing to it. The shape of the work has stayed the same: build the smallest thing that's actually true, put it in front of real people, learn faster than your competition.
What changed in the last two years is AI. Used the right way, it lets a solo engineer ship at the pace of an agency — and then some. The first version that used to take two months now takes two weeks. The validation loop that used to take a quarter now takes a month. That's the difference between testing two ideas a year and testing eight.
Based in Chicago. Working worldwide — US, EU, and Asia timezones. Direct contracts, or through a US entity, or via Upwork — whichever suits your legal setup.
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 a real audience to hand it to. Build the user 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. Come back when you have those names.
Depends on what we're building — every engagement is scoped individually. The honest way to find out: we have a thirty-minute call, I build your first version free, and if we continue, I write a scope document with a fixed price before any paid work starts. No hourly billing, no surprise invoices.
One or two days for the first user-flow, if the scope is genuinely minimum. Most founders bring me a 'small MVP' that's actually months of work in disguise. The conversation is usually about cutting it down to the one thing that proves the model. The rest can wait until we know whether it's worth building.
Almost always start with web. Apps are an order of magnitude more work — App Store, Play Store, two codebases or React Native, push notifications, updates. Most early ideas can be tested on web. Build the app once you know users want the thing badly enough to install something.
Then we do, with weekly shipping and fixed-price phases. The first version is built clean enough to grow into the full product — no rewrite required. You don't have to start over to scale up.
Then you've saved months and tens of thousands of dollars finding out. You keep the code, you keep the learning, and you decide what to do next — pivot, shelve, or come back to it later. The whole point of an MVP is to make 'doesn't work' a cheap answer instead of an expensive one.
Yes — that's a core deliverable. When the project wraps, I train whoever's going to maintain the system on how to modify it using AI, the same way I do. Most small changes — new field, different copy, an extra step in a flow — they'll handle themselves in minutes. You're not dependent on me.
Yes — most of my MVP clients are non-technical. You bring deep knowledge of your business, your users, and the problem you're solving. I bring twenty years of building software around exactly that. We meet in the middle. You don't need to learn to code, and I don't need you to write specs in technical language.
Yes. Standard mutual NDA before we discuss anything sensitive.
First call this week. Free first version typically starts within one to two weeks, depending on current bookings. Urgent? Ask — sometimes there's slack.
No hidden catch, no fine print, no automatic billing after the trial. You see the work, you decide.
I won't ship a Figma file or a no-code mockup and call it an MVP. Production-deployed code from day one — even if the scope is small. Real users on real software is the only signal that matters.
The first version isn't throwaway code. If the MVP works, we build phase two on top of it — not on a rewrite. You're not paying twice for the same architecture.
From day one, everything I build is yours. Your repository, your hosting, your credentials. No SaaS dependency on me, no vendor lock-in.
I train whoever's going to maintain the MVP on how to make changes themselves using AI — same tools I use daily. Small tweaks happen in minutes without calling me back.
If the data says your idea isn't working, I'll say so — even though it costs me future work. Better you hear it from me now than spend a year denying it.
Book a thirty-minute call this week. Tell me about the idea — but more importantly, tell me about the user. If there's a real first version to build, I'll build it. If there isn't yet, I'll tell you what to do before you spend a dollar on engineering.