Journal · The AI Architect · 2026-07-14
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?
I’ve watched a lot of smart people spend six months building something that Zapier and a fifteen-dollar subscription would have solved in an afternoon. The tension isn’t really about laziness versus ambition. It’s about the fact that building feels like progress, and buying a solution feels like giving up before you’ve started. That instinct is almost always backwards, and it’s worth understanding why before you write a single line of code.
The cost of building is never just the building
When you decide to build something, you’re not signing up for one project. You’re signing up for a maintenance contract with no end date. Every dependency you add is something you now have to update, secure, and understand well enough to fix at 11pm when it breaks. Every feature you build is a feature you have to explain to new users, document, and eventually migrate when you change your mind about the architecture.
The seductive part is that the initial build often feels fast. You get a working prototype in a weekend and think, “that wasn’t so bad.” What you don’t see yet is the accumulation: the edge case a user hits in month four, the security patch you need in month nine, the moment eighteen months from now when you want to change platforms and realize how much is tangled up in this thing you built because it seemed simple at the time.
A good, cheap app that already does the job comes with someone else absorbing that cost. Their team patches the security holes. Their support handles the edge cases. You pay a small, predictable fee instead of an unpredictable tax on your future attention.
Try this: before starting a build, write down every existing tool that does something close to what you want. Give yourself thirty minutes, no more. Then ask honestly: could I get 80 percent of the value from one of these, today, for less than fifty dollars a month? If yes, use it for at least a month before building anything. You’ll learn what the real gaps are, and they’re often smaller than you imagined.
Ask what’s actually yours to build
Not everything worth doing is worth doing yourself. This sounds obvious, but our instincts fight it constantly, especially if you enjoy building things. The question “is this mine to build” is really asking: does my specific context, knowledge, or need make this different enough from the generic solution that building it creates real value?
Sometimes the answer is genuinely yes. If your workflow has an unusual shape, if you’re solving a problem nobody else has quite framed correctly, if the existing tools force you into someone else’s assumptions about how the work should go, that’s a real signal. Build then. But that’s a smaller slice of situations than most of us want to admit, because building is fun and using someone else’s tool can feel like admitting your problem wasn’t special.
The harder, more honest version of this question is: am I building this because it needs to exist, or because I want to be the one who built it? Both are legitimate reasons to spend a Saturday. They are not legitimate reasons to spend a year, or to convince yourself you’re saving money when you’re actually paying yourself in unpaid labor to avoid a subscription fee.
Let the cheap app be the research
Here’s a reframe that helps: using an existing tool isn’t surrender, it’s reconnaissance. When you pay for the cheap app and use it for real work, you learn exactly where it disappoints you. That disappointment is data. It tells you precisely what a custom build would need to do differently, instead of you guessing at requirements from a blank page.
Most custom builds fail not because the code is bad but because the builder guessed wrong about what mattered. Using the existing solution first removes the guessing. If after real use you still hit a wall the cheap app can’t get past, you now have a specification instead of a hunch. That’s a much better starting point for building something that’s actually yours to build.
Try this: keep a running note, right inside whatever cheap tool you’re using, of every moment it frustrates you. Not vague complaints, specific ones: “had to export to a spreadsheet to do X,” “can’t combine these two views.” After a month, read the list. If it’s short, you’ve saved yourself a build. If it’s long and consistent, you’ve got your project brief.
I go into more of the specifics of this in the book, including how to tell the difference between a real gap and a preference, and what to do once you’ve decided building really is the right call. But the short version is this: the app existing is not the enemy. Skipping the honest question is.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.