The operator I built for making apps opens by trying to talk you out of making the app.
Not as a disclaimer. As the first stage of the process, before a line of code exists. I wrote it that way on purpose and it’s the decision I’m most confident about in the whole file.
Sponsored · Productive Studio What could your AI be doing while you sleep? Two minutes tells you where you stand — and what to hand over first. Take the quiz →The expensive mistake isn’t a bad build
When people imagine software going wrong, they picture it breaking. Bugs, crashes, a developer who disappears.
That’s not where the money goes. The expensive failure is a thing that works perfectly and nobody needed.
It gets built properly. It launches. It does exactly what the brief said. And then it sits there, because the problem it solves turned out not to be a problem anyone would change their behaviour over. Every penny spent on it was spent competently, which somehow makes it worse — there’s nobody to be annoyed at.
A build you abandon halfway costs you half. A build you finish and don’t need costs you all of it, plus the months, plus the ongoing maintenance of something you now feel obliged to keep alive because of what it cost.
The operator in this postForge — App Builder OperatorValidates the idea, writes the brief, then builds it.
See Forge
What validation actually means here
It doesn’t mean market research in the formal sense. It means answering a short list of questions honestly before anything gets made, and being willing to hear the wrong answer.
Who specifically has this problem, and how do you know? Not a category — “small business owners” is not an answer. A person you could name, whose problem you have watched happen.
What are they doing instead right now? There’s always something. A spreadsheet, a notebook, a group chat, paying somebody, or quietly tolerating it. If you can’t describe the current workaround in detail, you don’t understand the problem well enough to replace it.
Is the workaround actually painful enough to abandon? This is the one that kills most ideas, and it’s the one people skip. Humans tolerate an enormous amount of mild inconvenience. A tool has to beat not just the workaround but the inertia protecting it.
What’s the smallest version that would prove it? Usually far smaller than the thing you’re picturing. Often it isn’t software at all.
What would make you stop? Decide now, while you’re calm. Afterwards you’ll be invested, and invested people don’t set thresholds, they move them.
The cheapest build in the world is the one you worked out you didn't need.
Why this is in a product that sells building
The obvious objection: an operator that sells building apps has an incentive to encourage building apps.
That’s exactly why the stage is there. The incentive runs one way, so the process has to run the other, or the incentive wins by default. This is the same reason the marketing operator won’t tell you ads will fix a weak offer — when a tool’s interests and yours diverge, the correction belongs in the tool, written down, where it can’t quietly erode.
And practically: I’d rather you build one thing that matters than three that don’t. You own the operator either way. The second build costs nothing extra. So there’s no version of this where talking you out of a bad idea costs me anything — but there is a version where letting you build it costs you a great deal and sours you on the whole approach.
The part that changed how I think about it
Here’s what I didn’t expect when I wrote the stage.
The validation questions are useful even when the answer is build it. You come out the other side with a sharper idea of who it’s for, what it has to beat, and what the smallest provable version is. That’s most of a brief. The thing you build afterwards is smaller, more pointed, and done sooner — not because you cut corners, but because you stopped carrying the parts nobody asked for.
Most of what makes software take a long time isn’t typing. It’s building things that turn out not to be needed, discovering that late, and unpicking them.
Pairs well with thisCharter — Flowchart BuilderTurns a process you only know by heart into a diagram.
See Charter
What this costs you
Hours. Possibly an afternoon of answering uncomfortable questions about an idea you were enjoying.
Against that: commissioning the foundation of a working app — frontend, backend, database, logins — runs into tens of thousands of dollars at market rates. That’s the thing you’re deciding whether to spend. An afternoon is a cheap way to find out whether you should.
And if the answer is no, you haven’t lost the afternoon. You’ve kept everything you were about to spend after it.
The cheapest build in the world is the one you worked out you didn’t need.
The Big Five Websites, apps, ads, content and video — the five premium operators, together. See the Big Five →