Stop Paying the Token Tax. Write a PRD.

You describe the tool in a paragraph. The builder — Lovable, Replit, Claude, whichever one you are in — produces something plausible in about four minutes, and it looks good enough that you show someone. Then you start using it and find the bits you never mentioned. What happens when the form is empty. Who can see other people''s data. What it does on a phone. Where the file actually saves. So you go back and ask for a change. The change works and breaks something else. You fix that. Something else drifts. Two days later you are still going, and the tool you are building is now defined by an argument you had with a machine rather than by a decision you made. Call it the token tax. Every decision you did not make gets made by the builder, usually in the most obvious way rather than the way you wanted — and you pay to have it made, then pay again to have it changed. On credit-based tools you are paying in literal credits. On a frontier model you are paying by the token, and the bill arrives whether the output was right or not. Everywhere else you are paying in time and attention, which is worse, because you have less of those than you think. The tax is not charged for building. It is charged for not having decided. Move the decisions to where they are cheap A PRD — product requirements document, and the name is the least interesting part of it — does not remove the decisions. It moves them to the cheapest place to make them: a conversation, before any code exists, where changing your mind costs nothing. It is a plain document. What is being built, who it is for, what it must do, what it deliberately does not do, and how you will know it worked. Then you hand the whole thing to your builder as the opening instruction, rather than describing the project again from memory and hoping you remember the same things twice. Twenty minutes, usually. Against two days of drift, that is not a close call. The questions you cannot answer are the point Whether you use a structured process for this or just sit down with a notepad, expect five to eight questions. One at a time. Some of them you will not be able to answer. That is not the process being awkward. A question you cannot answer in the chat is a decision that has not been made yet, and if you cannot answer it now, the builder will answer it for you later — and you will not be in the room when it does. Better a question in the chat than a surprise in the build. Four that earn their keep: The problem, separately from the solution. If you arrive asking for a chatbot, expect to be asked what the chatbot is meant to fix. Sometimes the answer turns out to be that you do not need a chatbot. Much cheaper to find that out before the chatbot exists. Who it is actually for. Not "everyone". The named person who opens it on a Tuesday and tries to get something done. What you are deliberately leaving out. People skip this section and it saves the most. A build has no natural edges — it will keep growing for as long as you keep having ideas. Writing down what you are not doing is what stops a fortnight becoming three months. Who is allowed to see and do what. A small table: what a stranger can see, what a logged-in user can see, what an administrator can do. It looks like a formality. It is not. Leave it blank and your builder will make those choices for you, and it will make the permissive ones, because permissive code is easier to write and appears to work. A good share of the nastier surprises in AI-built apps trace back to that table not existing. If the tool is just for you and holds nothing sensitive, say so and move on. One line is a perfectly good answer. Borrow two rules from people who write code for a living Developers have been fighting the over-build problem for decades, and two of their rules of thumb transfer straight across to anyone building with AI. YAGNI — you aren''t gonna need it. Do not build the tool you might want later. Build the tool you need now. It comes out of the extreme programming movement of the late 1990s, and it exists because "while we''re in here, let''s also…" is how projects quietly die. DRY — don''t repeat yourself. Every rule should live in one place. If the same logic is written into four different screens, you will change three of them and then spend an afternoon confused about the fourth. The principle was named in The Pragmatic Programmer by Andrew Hunt and David Thomas, published in 1999. AI builders are poor at both by default, for an understandable reason: they are trying to be helpful, and helpful looks like more. Ask for a date picker and you can end up with an installed library, a wrapper component, a stylesheet and an unsolicited discussion about timezones — when the browser has had a native date input for over a decade. Which brings me to Ponytail. Ponytail is a ruleset for AI coding agents, published on GitHub by Dietrich Gebert in June 2026 under an MIT licence. It makes the agent climb a short ladder before writing anything: does this need to exist at all, is it already in the codebase, does the standard library handle it, is there a native platform feature, is there a dependency already installed that covers it, can it be one line — and only then, the smallest thing that works. Rung one is YAGNI. Rung two is DRY. It ships adapters for Claude Code, Codex, Copilot, Cursor, Gemini and a long list of others. Two honest caveats, because this is a young project and the numbers are its own. The repository reports roughly 54% less code and around 20% lower cost against the same agent without it. That is the maintainer''s own benchmark, run across twelve tasks with a small sample on a single model, and I have not reproduced it. An earlier and much larger claim was challenged publicly and corrected by the maintainer, which is a good sign about the project and a good reason to treat the current figures as indicative rather than settled. The repo itself notes the effect can reverse on some reasoning models. At least one reviewer has argued the whole thing amounts to telling the model to follow YAGNI, which it already understands. Test it on your own work before you quote the number to anyone. The second caveat is one non-coders tend to miss: YAGNI and DRY pull against each other. Aggressive DRY — spotting a pattern and building an abstraction to cover every future case — is itself a form of over-building. Two similar things are not yet a pattern. Wait for the third. You do not need to install anything to get most of this. Writing into your PRD that the build should use the smallest thing that works, reuse what already exists rather than write new, and prefer native features over new dependencies will get you a long way on its own. The rules are the useful part. The packaging is optional. Bring more, get asked less Everything you supply up front is a question nobody has to ask you, and a piece of context nobody has to guess at. Worth having ready: messy notes and voice memos, because a rambling brain-dump beats a tidy paragraph — it contains the things you would have forgotten to mention. Your website or brand documents, if the tool is customer-facing. Anything that already exists: screenshots, the spreadsheet you are trying to replace, the manual process you currently do by hand. An example of something you like, because "like this, but for us" carries a surprising amount of information. And the awkward constraints — the deadline, the budget, the system you are stuck with, the approval you need from someone else. Those shape a build far more than the features do, and people leave them out because they feel like excuses. Supply little and you get more questions. Supply a lot and you skip straight to the gaps. Both routes work. One is faster. If you are in a hurry Stop and write the document with the gaps marked TBC. A document with visible holes is genuinely useful. A document with plausible invented answers is dangerous, because nobody knows to check them. Do not let a model fill in numbers, deadlines, budgets or research to make the page look finished. If you did not say it, it should not be in there. What to do with it Read it once and argue with it. The first draft is a mirror — if something in it feels wrong, that is a decision you had not consciously made yet. Give the whole document to your builder as the opening instruction. Keep it open while you build, and when you are tempted to add something mid-build, check whether it is in there. If it is not, that is scope creep, and now at least you can see it happening. Update it when you change your mind, because a PRD that no longer matches the build is worse than no PRD at all — people trust it. What this does not fix It will not make your idea good. It will not tell you whether anyone wants the tool, and it will not catch every problem. Plenty of builds fail for reasons that have nothing to do with unclear requirements. What it removes is one specific and very common failure: building the wrong thing carefully, then paying over and over to reshape it into the right thing. What you get instead is a build that finishes, and a bill you recognise. Your frontier-model budget goes on the hard parts rather than on a machine guessing what you meant, and the argument you would have had with it on day two happens on paper instead, for free. Twenty minutes of questions before anything exists. That is the whole trade. Work through your next build with us If you have a build in mind and want a second pair of eyes before you burn the tokens, get in touch. A working session, not a sales pitch — we will sit with the idea, mark the gaps, and hand you a PRD you can walk into any builder with.