The question I get asked most often is some version of "what should I build with AI?" It is usually asked hoping for a list of app ideas. That is the wrong shape of answer, because the interesting change is not that there is a new category of app. It is that the cost curve of software changed, and different things are worth building now.
The thing that actually changed
Before, the constraint on most side projects was not the idea. It was the two weekends of scaffolding between the idea and anything you could look at. Auth, forms, a table with sorting, a settings page, the eleventh CRUD endpoint. Nobody abandons a project because the core idea was too hard. They abandon it during the boring middle.
That middle got dramatically cheaper. Not free, and not zero-judgment, but cheap enough that the calculation changes.
Two consequences follow, and they matter more than any list of ideas:
Small-audience software is now viable. A tool useful to two hundred people was never worth a month of evenings. At a fraction of that cost, it is. The long tail of "software that would be genuinely useful to a specific group but could never justify a team" is now reachable.
The bottleneck moved to knowing what is worth building. When implementation was expensive, picking the wrong thing cost you time. Now that implementation is cheap, picking the wrong thing is nearly the only cost. Taste and problem selection became the scarce inputs.
Things genuinely worth building now
Internal tools that were never worth the effort
Every team has three or four processes running on a shared spreadsheet and someone's memory. Nobody builds the tool because it would take a week and serve six people.
That maths has changed. The on-call handoff checklist, the release dashboard, the thing that reconciles two systems nobody wants to touch. These are unglamorous, have obvious users, and have an obvious definition of done, which also makes them well-suited to agentic development.
Personal tools with an audience of one
The most underrated category. A tool built for exactly your workflow, with none of the generalization that makes commercial products mediocre.
Reading queue. Expense categorizer that understands your specific bank's CSV export. Dashboard that pulls the four numbers you actually check. These were never worth building because you cannot amortize the effort across users. Now you do not have to.
Glue between systems that should already talk
An enormous amount of professional life is a human moving data between two systems. Export from here, reformat, import there.
This work is legible, has clear correctness criteria, and is exactly what agents handle well. It is also where MCP is most useful, because the systems already have APIs and only lacked someone to wire them together.
Things with a hard, verifiable core
Here is a heuristic worth keeping: AI-assisted development works best where correctness is checkable.
A parser, a scheduler, a pricing calculator, a data pipeline. There is a right answer, you can write tests for it, and an agent can iterate against those tests. Contrast with "an interface that feels premium", where there is no test that passes when you get it right.
Build the checkable part with heavy assistance. Reserve your own attention for the judgment.
Traps
Some honesty, because the enthusiastic version of this article is not useful.
Building a wrapper with no moat
"ChatGPT for X" where X is a prompt template and a text box. If your product is a prompt, your product is copyable in an afternoon, including by the model provider.
The question is not whether AI is in your product. It is what you have that is hard to replicate: proprietary data, real distribution, deep workflow integration, an actual relationship with users.
Assuming cheap code means cheap software
Writing the code was never the expensive part of software over its lifetime. Maintenance, support, security, migrations, on-call, and the accumulated weight of decisions are.
An agent generating ten thousand lines you do not understand has not saved you work. It has deferred it, at interest. The teams that get burned here are the ones treating generated code as finished rather than as a first draft that still needs review.
Skipping the part where you learn something
If you generate a codebase you cannot debug, you have not built a project. You have acquired a liability with your name on it.
This does not mean writing everything by hand. It means reading the diff, understanding the architecture, and being able to change it in six months. The engineers doing well with these tools are not the ones who read the least code. Frequently they read more, just faster.
Confusing a demo with a product
Agents are very good at the first eighty percent. The last twenty, the empty states, the error handling, the accessibility, the thing that breaks only on Safari, is where products live or die and where assistance helps least.
Budget accordingly. A demo in an afternoon does not mean a product in a week.
How to actually pick
A few filters that have held up:
Do you have the problem yourself? Being your own user solves the hardest input: knowing when it is good.
Can you tell whether it works? If you cannot define done, you cannot delegate any of it, and you will not know when to stop.
Is the boring part the majority? If yes, that is exactly the leverage. If the hard part is the majority, you are doing most of it yourself either way.
Would it be worth building if it took three times longer? A useful check against the excitement of speed. Speed is not a reason to build the wrong thing.
The uncomfortable conclusion
The bar for what counts as impressive went up, not down. When anyone can produce a working CRUD app in an evening, producing a working CRUD app in an evening is not a differentiator.
What is left is the part that was always the hard part: knowing what to build, having taste about how it should feel, and caring enough to finish the last twenty percent. Those did not get automated. They got more valuable, because everything around them got cheaper.
The best answer to "what should I build with AI" is still "the thing you actually wanted, that you kept not building because the boring middle was too long." That list is probably already in your notes app.
If you want the tooling side of this, start with the practical guide to Claude Code.
- #AI
- #Product
- #Engineering
- #Claude Code
- #Side Projects