The AI Wasn't the Difference Between a $75 App and a £3,000 App. The Brief Was.

Two builders used the same "vibe coding" platform and the same frontier AI model. One spent an afternoon writing a brief before touching it. Here is what belongs in that brief, and why skipping it is the expensive part. I was on a podcast a week ago (Ctrl+Alt+Dev, with Sean Sale and Paul Rhodes), and the conversation kept coming back to a number that surprised them. On the same AI app-building platform, using the same frontier model, I built a full studio management tool for roughly $75 in API costs. People in my own network, on that exact same platform, have run up large bills building their tools. One mentioned £3,000. We were not building the same tools, but those costs did stick with me. It's not a story about who negotiated a better token rate. It's a story about who knew what they wanted before they started asking. "Vibe coding" (describing what you want instead of writing the code yourself) sounds like the AI is doing the hard part. It isn't. It's doing the fast part. The hard part is still entirely yours: knowing what "done" looks like before you open the tool. Skip that, and you're not saving time. You're renting it back to yourself, one clarifying question and one regenerated version at a time. Write the brief before you touch the tool Before you open whichever build platform you're using, put aside real time (an afternoon, not five minutes) and write a short brief. Not a technical spec; you're not a developer and don't need to pretend to be one. What problem does this solve, and for whom? What can the finished tool let someone do that they can't do today? What's deliberately out of scope for version one? And where do you genuinely not know the answer yet? Mark that "decide later" rather than guessing and hoping the AI doesn't notice. I know how that sounds: lots of work, before you get to the actual building. It is lots of work. Do it anyway. For the studio tool, I spent a couple of hours going back and forth with Claude, having it push back on my own logic and flag all the bits I hadn't thought through properly, before I ever opened the build platform. Then I uploaded that brief once. The model already knew the shape of the tool it was building, so it stopped needing to ask me what I meant. If you want the longer version of how that document is structured, we covered it in Stop Paying the Token Tax. Write a PRD. Every regeneration is billable Without a brief, you end up riffing: ask for something, see what comes back, ask for a change, repeat. Each round means the model re-reading everything that came before and rebuilding its understanding from scratch, so the bill climbs a lot faster than the number of changes you've asked for. With a brief in hand, most of that back-and-forth doesn't happen at all. Two habits help once the build's under way. Make the model check what already exists in the project before it writes anything new, or it'll happily write the same function three different ways and bloat the whole build. And once you're past the brief stage, drop the politeness in your prompts. "Please could you also..." costs tokens that "make the button red" doesn't. Petty on one message; on a full build, it adds up to real money. They say politeness doesn't cost anything; when using an AI builder, it does. "Done" needs a definition before the price means anything I'd be careful reading too much into any single £3,000 figure. It might genuinely be a bigger, more ambitious tool, and you can't call a number wasteful without knowing what it was meant to produce. That's exactly why the brief matters: write your definition of done as a specific line, not a vibe. No finish line, no way to judge whether you overspent, underspent, or built the wrong tool entirely. As Paul said, you wouldn't start building a house without a plan and just say, "put the door there, no, there, actually make it a window." Don't let it turn into shadow IT without anyone noticing The easier these tools get, the more of them appear across a business: one in marketing, one in ops, a couple nobody quite remembers commissioning. I follow MindStudio, and their new Remy platform exists because plenty of businesses now have thirty or forty small AI tools running with no one person able to say what they do, what data they touch, or who'd fix one if it broke. Remy is genuinely impressive and has many enterprise-level features, and takes care of many aspects for you automatically. Depending on your budget, Remy may not be an option. You don't need a platform to sort this for you. A single shared page does a lot of the job: what's been built, on what platform, by whom, and what data it touches. It means that when the person who built something moves on, the tool doesn't quietly get abandoned. Whatever option you choose, you need to make sure apps are tracked and recorded somewhere in your organisation. Ask "should this" before "can this" Paul made a point on the podcast worth repeating: just because AI's made a task fast and easy doesn't mean it's earned a place on anyone's to-do list. Easy execution is seductive: people start building tools because they suddenly can, not because anyone decided they should. Before your team ships another small tool this quarter, sit down with whoever owns the actual bottleneck (a lead that isn't converting, a report nobody trusts, a handoff that keeps dropping) and check the tool's aimed at something that matters before you spend an afternoon, or £75, or £3,000, building it. What this actually buys you Get the order right, and the economics genuinely work in your favour: a founder blocks out an afternoon, writes a proper brief, has an AI model interrogate it, and comes out with a working tool for the price of a round of coffees rather than a few thousand pounds. Do that a handful of times, add the one-page register, and three tools can become thirty without anyone losing track of what's actually running underneath the business. None of that buys blind trust in the result, mind. I don't take a build platform's word for it that the code it hands me is secure. Lovable, in my case, says its security is handled, and I'd guess it mostly is, but "mostly is" isn't good enough for anything touching real client data. I run my own prompts for code audit and security every time, but that's not the same as an outside pair of eyes. I'm putting one of my own live tools through a full third-party code audit with Paul and Sean rather than resting on the platform's say-so alone. I'll report back either way. Talk it through before you build If you've got a growing list of AI tools built by well-meaning people across your business, and you're not entirely sure what's running underneath them, that's a short conversation that needs to happen. Get in touch and we will map what you have, what it touches, and what is worth building next. A working session, not a sales pitch. You can also see how we approach this in our services. Frequently asked questions Do I need to be technical to write a brief for vibe coding? No. It's about clarity of intent, not code: what the tool should do, who it's for, and what's out of scope. Getting an AI model to interrogate your own brief before you build covers most of the technical gaps a non-developer would otherwise miss. Why can one AI-built app cost $75 and a near-identical one cost £3,000 on the same platform? Usually because one of them started with a clear brief and the other didn't. Without a brief, builders iterate conversationally with the AI, and every round of changes adds cost. With a clear brief, the model gets close to the finished result in far fewer passes. What's "shadow IT" got to do with AI-built tools? It's the small AI-built tools that pile up across a business (often genuinely useful ones) with no record of what exists, who built it, what data it touches, or who could fix it if the builder left. Should every idea AI can build actually get built? Not necessarily. AI making something easy to build isn't the same as it being worth building. Check it's solving a real bottleneck before you commit time or budget.