Journal · The AI Architect · 2026-08-09
Before you build anything, ask: is this really mine to build, or does a good, cheap app already do it?
Before you build anything, ask: is this really mine to build, or does a good, cheap app already do it?
The tension isn’t whether you can build something. Anyone with a weekend and a login to a no-code tool can build something. The real tension is that building has become so easy it no longer tells you anything about whether it’s worth doing. Ease of execution has outrun clarity of purpose, and that gap is where a lot of wasted months live.
The itch to build is not a business plan
Wanting to build something is a feeling, not a strategy. It feels productive. It feels like progress. And often it’s just restlessness wearing a hoodie. The danger is that the feeling and the actual opportunity get treated as the same signal.
A useful habit is to separate the urge from the evidence. The urge says “I could make this better.” The evidence says “people are currently paying for a worse version of this, and I know why they’d switch.” Those are different claims, and only one of them should greenlight a project.
Try this: before writing a line of code or opening a builder tool, write down the name of three real people who have this problem right now, and what they currently do about it. If you can’t name three people, you don’t have a problem yet — you have a hunch. Hunches are fine, but they belong in a notebook, not a repo.
The “good, cheap app” test
Somewhere out there, a small team has probably already spent two years solving a milder version of your idea. They’ve handled the edge cases you haven’t thought of yet, they’ve priced it at something absurdly reasonable, and they update it quietly every few weeks. This is not a reason for despair. It’s a reason for research.
The instinct to build from scratch often comes from not having looked hard enough. Ten minutes of searching, reading reviews, and actually using a competing tool will tell you more than a week of speculative architecture diagrams. If the existing option is genuinely good and genuinely cheap, the honest question isn’t “how do I build a better one” — it’s “what does this option miss that actually matters to the people I named in the last step.”
That missing piece, if it’s real and specific, is worth building. The rest — the version that’s just “the same thing but mine” — is a hobby dressed up as a venture. Nothing wrong with hobbies. Just know which one you’re doing.
Try this: find the closest existing alternative and use it for a real task, not a demo. Keep a running list of the moments where it annoys you or falls short. After a week, look at that list. If it’s short and vague, that’s information too.
Ownership means responsibility, not just credit
“Is this mine to build” is really a question about what you’re willing to carry. Building something means you now own its bugs, its support requests, its slow Tuesday afternoons when nobody uses it and you have to decide whether that’s a phase or a verdict. Plenty of ideas are exciting to imagine and exhausting to maintain.
This is where it helps to separate two different desires that often get tangled together: wanting to have built something, and wanting to build something. The first is about identity. The second is about the actual, unglamorous work of keeping a thing alive. If what you want is the feeling of having shipped, a smaller project finished well will give you that faster than a big one abandoned quietly.
The question of ownership also cuts the other way. Sometimes a problem genuinely is yours — because you understand it from the inside, because you’ve lived with its bad solutions longer than anyone building for it from the outside, because you’ll still care about it in the unglamorous middle of a project when the initial excitement has worn off. That kind of ownership is worth trusting. It just needs to be checked against reality, not assumed.
Try this: write one paragraph on why you, specifically, are positioned to solve this better than someone else. If the paragraph is mostly about your skills, that’s a signal about execution. If it says something about your experience of the problem itself, that’s a signal about ownership. Both are useful, but only one answers the actual question.
None of this is meant to talk you out of building things. It’s meant to slow the moment right before you start, long enough to ask a plain question honestly. The book goes further into how to run this check without turning it into another form of procrastination — but the check itself is simple enough to try today, on whatever idea is currently sitting in your notes app waiting for permission.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.