We Don't Fix Your Vibe-Coded App.
We Read It.

Founders have started arriving with apps. Real ones. They boot up, accept logins, and walk through a demo flow. They were built over a weekend or two with AI coding tools, and the founder is asking us to make them production-ready.

We've realised that we need to push back on that request. The work isn't beneath us, and the apps aren't bad. The request mishandles what the artifact actually is.

The pattern is consistent. A founder spends a few weekends with Claude or Cursor or one of the other coding agents. The demo works. The screens look real. The login flow runs without breaking. They send us a link, walk us through what they've built, and ask the natural next question: how long to make it ready for customers?

The pattern shows up in different industries. A logistics tool that worked for one customer profile and broke on every other. An internal dashboard that displayed numbers the founder could not trace back to their source. A project tracker the model had given seven different ways to record the same field. The specifics differ. The shape of the conversation is the same.

The actual answer is that "ready for customers" isn't the right conversation. The thing we're being asked to finish is not a half-built product. The architecture was decided by the model under pressure to make the demo flow. The data model came along for the ride. Patterns were chosen by whichever response Claude returned at three in the morning. Calling it eighty percent done would be generous, and not in a useful direction.

If we accepted the brief as written, we'd charge a small sum to "finish" the app, then spend three months in a rebuild dressed up as a clean-up while everyone got more frustrated by the week. We've watched that movie play out elsewhere. We've decided not to be in it.

So we read the app instead.

This isn't bug-hunting or tech scrutiny. It is not judgement. It's closer to how an architect reads a draft, or how a translator reads a half-finished letter. We're looking for what the founder was trying to say. The architecture they expected sits right there in the file structure, however wrong it is. Features they thought were core show up as the ones they made the model fight for. Where they got stuck, the code paths get convoluted, because they kept asking the model to make those parts work and the model kept improvising. Screens they cared about are detailed; the ones they didn't are placeholder. The data model, however broken, is what they were imagining when they pictured the app working.

That is more information than we've ever pulled out of a discovery call.

We've started calling the artifact an intent record. It's not a product. A specification it isn't either, because a specification describes what should be built, while the intent record describes what someone tried to build before they knew how to say it. Figma prototypes show a chosen surface. Bubble apps are opaque to this kind of reading. The intent record sits in a category developers haven't had before, and the right name for it is the one we landed on: a runnable record of intent.

The first session looks like a reading group. Wilfred or Armand will sit with the founder and walk them through their own app, section by section, calling out what the artifact is showing. Most founders have never experienced this. They've never seen their idea reflected back at them in a form they can't edit on the fly. It tends to clarify things very quickly.

After that, we do the work we've always done. Design the system on a clean foundation, with a brief that finally reflects what was wanted. The vibe-coded thing has done its job. We don't need it any more.

If that sounds like more work than "finishing the app", it's the same work, done with a real brief instead of a guess at one. Founders who've come through this process tell us the conversation in the first session was the most useful hour they'd spent on the project. We agree.

A claim, with the appropriate humility. We feel this is the next way of work. Founders will keep building these apps. The tools are getting better, faster, and more impressive every quarter. The skill of reading them well is going to matter, and it's the skill we're building inside ReadyRun.

Whether this becomes the way of work everywhere, we don't know. Who knows where things go. For now, it's the way that has stopped everyone from being angry at each other by month three.

So bring the vibe-coded thing. We'll read it before we build.