Everyone's Building With AI. Who's Actually Using It?

I built four side projects last quarter. Three of them work. Zero of them have users other than me.

That's not a confession of failure so much as a description of the current moment. A weekend project that took a month in 2020 takes an evening now. The friction that used to force a decision — is this worth the next three weekends? — is gone, and with it went the filter that the friction quietly provided.

This isn't an argument against AI coding tools. I use them constantly and my output is genuinely higher. It's an argument about what got cheaper and what didn't, and why the gap between those two things is producing an enormous amount of software that nobody asked for.

What Actually Got Cheaper

Be precise about it, because the imprecision is where the trap lives.

Much cheaper: writing the first version. Scaffolding, boilerplate, CRUD, integrating an unfamiliar API, standing up a frontend in a framework you don't know, wiring auth, deploying. All of it collapsed, and the effect is real — I now build things in domains I'd have avoided entirely two years ago because the setup cost exceeded my curiosity.

Unchanged or worse:

Knowing what to build. No tool tells you which problem is worth solving.
Finding users. Distribution was always the hard part and it just got harder, because everyone else is shipping too.
Maintenance. Dependencies rot, APIs change, security patches land. Code an AI wrote needs the same care as code you wrote, and you understand it less well.
Support. Real users have questions, bugs, and expectations.
Your attention. Still the hardest cap. Every live project is a small standing claim on it.
Trust. Users deciding your thing is worth their data and their time — if anything, harder now, because they're being asked by more things.

The build was maybe 20% of the total cost of a piece of software that people actually use. AI made that 20% nearly free and left the other 80% exactly where it was. Which means: cheap building didn't make shipping software cheap. It made starting cheap, and starting was never the bottleneck.

The Symptoms

You can tell when this has taken hold. Some of these are mine:

A folder of repositories, most of them working, none of them used.
The project you were excited about for three days and haven't opened since.
Starting the next thing before the last thing had any users — because starting is the fun part and now it's also the easy part.
Building a tool because you could, then realizing the problem it solves takes you four minutes a month.
A product that exists because the technology was interesting, with the use case reverse-engineered afterward.

That last one is epidemic right now. An enormous share of AI products in 2026 started as "what could we build with an LLM?" rather than "what problem do people have?" — and it shows, because the resulting products are solutions patrolling for problems.

💡

None of this applies if you're building to learn. A project whose purpose is understanding a technology is complete when you understand it, and it needs no users at all. The trap isn't building things nobody uses. It's building things nobody uses while telling yourself you're building a product.

The Filter

Five questions, before you start. They take ten minutes and they've saved me weeks.

1. Who is the specific person who has this problem?

Not a demographic. A person. Someone you could name, or a role you could describe so precisely that you know where they spend time online.

"Developers" is not an answer. "A backend engineer at a 50-person company who manually copies error traces from Datadog into Jira tickets twice a week" is an answer — and the specificity immediately tells you whether you know any of these people and where you'd find more.

If you can't name one, you don't have a user. You have a hypothesis, and the honest next step is to talk to someone rather than to open an editor.

2. What do they do today instead?

Every problem worth solving already has a workaround: a spreadsheet, a manual process, a competitor, or living with the annoyance. Know it precisely.

Then the real question: is your solution enough better to justify switching? Switching costs are brutally underrated. People stay with mediocre spreadsheets for years. A 20% improvement almost never overcomes the friction of changing behavior. You need something that's obviously, immediately better, or you need to be solving a problem that currently has no workaround at all.

3. How often does this problem occur?

Frequency drives everything. A daily annoyance can support a real product. A twice-a-year annoyance almost never can, regardless of how painful it is when it happens — people just forget your tool exists between occurrences.

Multiply honestly: frequency × pain × number of people. A lot of side projects are a small number multiplied by a small number multiplied by one.

4. Am I building this because it's needed, or because it's interesting?

Both are legitimate. But be honest about which, because it determines what "done" means and what success looks like.

"Interesting" projects are done when you've learned the thing. Don't graft a fictional product narrative onto them, don't feel bad about no users, and don't spend three more weeks polishing an onboarding flow for an audience of one.

The failure is the mismatch: treating a learning project like a product and then feeling like a failure when it has no users — or treating a product like a learning project and never doing the distribution work that would give it any.

5. Am I willing to maintain this for two years?

The question that stops most of my project ideas, and the most useful one on the list.

If people use your thing, you own it. Bugs, dependency updates, support emails, the API you built on changing its pricing. If the answer is "no, I want to build it and move on," then either build it as a learning exercise with that expectation set, or don't build it.

Shipping a tool and abandoning it six weeks later is worse than not shipping it — you've now cost users their switching effort and their trust.

When to Stop

Equally important and less discussed: knowing when to kill something you've already built. Reasonable stopping conditions:

You shipped it and nobody used it, and you've done real distribution work. Not "I posted it once." If you've genuinely tried to reach the people who'd want it and they don't want it, believe them.
You're maintaining it out of guilt. Zero-user projects don't deserve your weekends.
You've stopped using it yourself. The most damning signal available. If the problem was real enough to build for, why aren't you using the solution?
The maintenance exceeds the value. Three users and four hours a month is a bad trade, however much you like the three users.
You're finished learning and it was a learning project. Archive it. That's a completed project, not an abandoned one.

Killing a project well: archive the repo, note what you learned, tell any users with enough warning and an export path. Then don't think about it again. The sunk cost is sunk and it's smaller than it feels, because the learning stays with you.

What to Do Instead

If cheap building isn't best spent on volume, what's it actually good for? The three uses that have held up for me:

Prototype to decide, not to ship. Building the thing is now often faster than arguing about whether to build it. Spend a day, get a real artifact, show it to five people, and let their reaction settle the question. Then throw it away without ceremony. A prototype's job is to produce a decision.

Go deeper on fewer things. The time AI saves on construction is the time you now have for the parts that were always hard: talking to users, refining the thing that's already working, distribution, handling edge cases properly. One project with users, taken seriously, teaches you vastly more than eight abandoned repos — about product, about maintenance, about what people actually do with software.

Build small things for yourself, deliberately. Personal tools are genuinely one of the best uses of cheap building. A script that saves you ten minutes a day is worth an evening, has exactly one user whose needs you understand perfectly, and requires no distribution at all. Just call it what it is rather than imagining a market.

The Shape of the Advantage

Here's the part I find genuinely interesting about this moment. When building was expensive, it was the constraint — and being able to build was the differentiating skill. Now building is cheap, so the constraint moved, and it moved to judgment: knowing which problem is real, which user actually exists, which thing is worth maintaining, and when to stop.

That's a harder skill and a slower one to acquire, because the feedback loop is measured in months rather than compile cycles. But it's also where the leverage now is. The engineers who'll do the best work over the next few years won't be the ones who shipped the most projects. They'll be the ones who shipped the right ones — and who got comfortable with the deeply unfashionable act of deciding not to build something that they easily could have.

The question isn't "what can I build with AI?" You can build almost anything, and that's precisely why the question stopped being useful.

The question is: who is this for, and are they actually waiting for it?

Frequently asked questions

Is it wrong to build side projects that nobody uses?

Not at all, if the purpose is learning. A project built to understand a technology is complete when you understand it and needs no users. The trap is building something nobody uses while telling yourself you are building a product — the mismatch is what produces the feeling of failure, not the absence of users.

How do I decide whether an idea is worth building?

Five questions before you start: who specifically has this problem, what do they do about it today and is your version enough better to justify switching, how often does the problem occur, are you building it because it is needed or because it is interesting, and are you willing to maintain it for two years. Most ideas fail the first or the last question.

Why do so many AI products feel like solutions looking for problems?

Because many of them started as 'what could we build with an LLM?' rather than 'what problem do people have?'. AI made the build step nearly free while leaving the hard parts untouched — knowing what to build, finding users, maintenance, support, and trust. Cheap building made starting easy, and starting was never the bottleneck.

When should I abandon a side project?

When you have done real distribution work and nobody uses it, when you are maintaining it out of guilt, when you have stopped using it yourself, when maintenance exceeds the value it delivers, or when it was a learning project and you have finished learning. Archive the repo, note what you learned, and give any real users warning and an export path.

What is the best use of AI coding tools if not shipping more projects?

Three things: prototyping to make a decision rather than to ship, since a day of building often settles an argument faster than a week of discussion; going deeper on fewer projects, spending the saved construction time on users, distribution, and edge cases; and building small personal tools where you are the only user and no distribution is needed.

Related reading: AI coding assistance and the engineer's evolving role covers the same shift from the skills side, and AI agents in production covers what happens after you decide something is worth building.