The MVP Machine: turning 'one person can build now' into a product

Almost everyone with an idea is stuck at the same place: they can describe what they want, sometimes in vivid detail, but there's a chasm between the description and something that actually exists and runs. Historically, crossing that chasm required either learning to build it yourself over years, or finding and funding people who could. Both are expensive enough that most ideas never cross at all — they stay descriptions, and the world never finds out whether they were any good, because getting to the test was too costly.

What's changed is that the crossing has gotten dramatically cheaper for someone who's fluent with the modern tools and has the habits to match. The distance from idea to a working first version has collapsed, and a person with those tools can traverse it fast. The MVP Machine is built on the bet that this collapsed distance is the valuable thing — that the ability to quickly turn an idea into something real enough to test is exactly the capability most people are missing and most ideas die for lack of.

Most ideas never fail on their merits. They fail because getting to a version you could actually test was too expensive to reach.

The tempting way to offer this is as labor — I'll build your thing, here's my time. But selling hours doesn't productize anything; it just makes me a contractor, and it caps the whole thing at how many hours I have. The more interesting version is to productize the capability itself: to build a repeatable machine, a process and a set of tools, that reliably takes an idea to a working MVP, so the thing being offered is the machine's output rather than my raw time. That's the difference between a service and a product, and it's where the leverage lives.

This is genuinely hard, because a lot of what makes me fast is tacit — judgment, taste, accumulated instinct about what to build and what to skip. Turning that into a repeatable machine means externalizing the parts that can be externalized: the scaffolding, the patterns, the reusable pieces, the disciplined process for going from a fuzzy idea to a scoped, buildable plan to a running thing. The parts that don't externalize cleanly are exactly the interesting problem — how much of a personal capability can actually be captured in a machine, versus how much stubbornly stays in the person.

When I look hard at what externalizes, it's the discipline, not the flair. The parts of my process that survive being written down are the boring, repeatable ones. Plan the thing before building it. Stress-test the plan against the ways it could go wrong before a single line of code exists. Make every risky step reversible by default — snapshot the state before you overwrite it, run a change as a dry-run before you let it mutate anything real. None of that is talent. It's a checklist, and a checklist is precisely the kind of thing a machine can carry from one idea to the next.

The other externalizable half is the scaffolding — the reusable pieces I've stopped rebuilding from scratch. A project skeleton that already has deploys, health checks, and a sitemap wired in. Patterns for the seams that show up in every build: the boundary between the app and the database, the boundary between what a crawler sees and what a human sees. A new idea doesn't start on a blank page; it starts three-quarters assembled, and the person's actual idea is the last quarter. That running start is what a machine lends out — not the judgment, but the mile of setup you'd otherwise burn first.

What refuses to externalize is the deciding: what to cut, what to fake for now, which corner is safe to skip and which one is load-bearing. That's the tacit core, and I've stopped pretending a checklist captures it. So the honest architecture of the machine is a hybrid — the scaffolding and the discipline are the product, and my judgment sits on top of them where it still has to. The bet is that automating everything around the judgment leaves enough room to spend the scarce thing, the taste, only where it actually changes the outcome.

I want to be straight about the ways this can go wrong, because I've made enough mistakes to know the shape of them. The first risk is that the thing which makes me effective doesn't transfer — that too much of it is tacit, and a productized version delivers a hollow imitation that produces working-but-wrong MVPs. The second is the scale trap I keep falling into: the near-zero cost of spinning things up tempting me to produce volume over value, which is exactly the pattern that's burned me before. A machine that cheaply makes MVPs could just as cheaply make bad ones.

The third and realest risk is that a fast MVP is not the hard part of most ideas, and I could be productizing the easy half. Getting to a working first version quickly is valuable, but the distance from there to something people actually use and pay for is long and doesn't collapse the same way. If The MVP Machine oversells how much of the journey it covers, it's making the same overpromise I learned as a rep is fatal. So the honest framing is narrow: it collapses the idea-to-first-working-version gap, which is real and worth a lot — and it doesn't pretend to collapse the rest.

The reason I trust any of this is that the machine already ran once, on me. For a couple of years my own portfolio has been the test bench: a single content engine reused across a whole network of domains, a fleet of agents doing the SEO and CI and analytics work that used to need a team, and this very site built and deployed by the same hands. I wasn't theorizing about what one person plus good tools can do — I was living inside the result and writing down what broke.

That's the honest source of both the confidence and the caution. The confidence is that the idea-to-working-version gap really did collapse for me, repeatedly, across very different projects. The caution is that I also watched the failure modes up close — the volume trap, the working-but-wrong output, the long tail of turning a running thing into a used thing. So the machine I'd hand someone else comes with those scars already mapped, not discovered on their dime. Selling a capability I've failed and recovered with in public for years is a safer thing than selling one I'd only ever used in a demo.

Underneath the product is the same thing that drives everything else I build: the belief that the ability to make things is the thing worth spreading, not the finished things themselves. I've spent a while being the guinea pig for what one person can build now, running the experiment on my own projects. The MVP Machine is the attempt to hold that door open for other people — to take the capability I've been demonstrating in private and make it a thing someone else can walk through with their own idea.

Whether it fully works is genuinely undecided, and I'd rather say that than pretend otherwise. Productizing a capability that lives partly in tacit judgment is an open question, and I'm running it as an experiment with the risks named rather than a finished claim. But the direction feels right: if the tools have made one person capable of a great deal, the highest use of that isn't to keep the capability to myself. It's to build the machine that lends it out — and to be honest, along the way, about exactly how much of it a machine can actually carry.