You can build anything. That's exactly the problem.
Before AI, your roadmap was filtered by a simple constraint: time. You had forty ideas and the budget for three. The constraint picked for you. Badly, often. But it picked.
That constraint is gone. Today you describe a feature on Friday night, it runs on Saturday morning. Three more follow over the weekend.
That's excellent news. And it's a trap, because the guardrail that protected you from yourself disappeared at the same time.
Building a feature became almost free. Keeping it did not.
The real price of a feature isn't writing it
A feature is like a dog. The purchase price is the easy part. What costs you is the fifteen years that follow.
Every feature you keep in your product:
- takes up space on screen, and makes the others harder to find
- adds to what has to be re-checked on every change, even in an unrelated corner
- adds to what you have to explain to every new user
- adds to what can break on a Sunday night
- adds to what your contractor must understand before daring to touch anything
The time spent writing a feature is a small share of what it will cost you over its life. The rest is support, fixes, and the way it complicates everything around it. I broke that bill down in the hidden cost of vibe coding.
And that bill is the one AI did not divide.
What AI changed, and what it didn't
| Before AI | With AI | |
|---|---|---|
| Writing the feature | Slow and expensive | Fast and cheap |
| Maintaining it | Expensive | Expensive |
| Explaining it to your users | Expensive | Expensive |
| Living with a more complex product | Expensive | Expensive |
| Deciding whether it deserves to exist | Free | Free |
AI divided exactly one line of that table.
The consequence: the bottleneck moved. It's no longer in your hands, it's in your head. The rare skill today isn't knowing how to build. It's knowing what to build, and above all what not to build.
The trap: mistaking speed for progress
You shipped seven screens this weekend. The feeling is great. It's the feeling of moving forward, not the proof that you did.
The symptoms are always the same:
- Your menu has twelve entries and you couldn't say which one actually gets used.
- Your homepage lists eight arguments, so none of them lands.
- Your onboarding keeps growing, because there's more and more to explain.
- A bug in one corner wakes up two others. Every fix takes a bit more care, until even the AI gets lost in it.
- You still have no paying customer, but you have a complete back office.
That last one is the most common, and the most human. Building is comfortable: you're in control, you see the result, nobody tells you no. Talking to your users isn't. AI makes the comfortable option even easier to reach than before.
How to spot the right feature
Four tests. They take ten minutes and they save you weeks.
1. The "who asked for it" test
Open a file, and for every request write down three things: who, how many times, in what context.
An idea that came to you in the shower doesn't carry the same weight as three customers describing the same blocker in different words. If the line is empty, it's not their need, it's your urge. Building your own urge isn't forbidden. But be honest with yourself about it.
2. The written bet test
Before you start building, write one sentence:
If I build X, then Y will move by this much, within this many weeks.
If you don't know what to put in Y, or you have no way to measure it, you're not building a feature. You're building a hunch. Write the bet down somewhere, and go read it a month later. It's the fastest way to learn how to choose.
3. The removal test
Imagine you delete it on Monday morning. Who complains?
If the answer is "nobody but me", you have your answer. Run this on what you've already built, not just on what you're considering. It usually stings, and that's the point.
4. The one-sentence demo test
Explain what your product does in one sentence, without ever saying "and also".
If you can't, you don't have a rich product. You have several half-finished products sharing one app.
Point AI at the right question
The speed of AI is a real advantage. It just has to be aimed well.
Build three versions of one feature, not one version of three features. Build the same flow three different ways, show them to five users, throw two away. Code got cheap: use that to discard, not to accumulate.
Test the door before building the room. Add the menu entry, put up a "coming soon" page, count the clicks for two weeks. Twenty minutes of work instead of three weeks, and you know whether the demand is real.
Use AI on the parts that aren't code. Feed it your support threads, your user feedback, your call transcripts, and ask what keeps coming back. That's where the right feature hides, not in your idea list.
And keep this in mind if you work with agents: an agent amplifies whatever you ask of it. Ask for the wrong thing and it will do it very well, and very fast.
Delete as fast as you add
Once a month, look at what nobody uses, and take it out.
"What if someone relies on it?" Hide the feature before deleting it. If nobody complains in two weeks, the question is settled. If someone does complain, you just learned something useful for almost nothing.
A product is shaped as much by what you remove as by what you add. That's true on the product side, and it's true on the technical side: the best architecture is the one that does exactly what you need, not the one that impresses.
The one case where piling up makes sense
Let's be honest: there is a moment when shipping a lot, fast, is the right strategy.
It's the very beginning, when you don't yet know what your users want. There, multiplying attempts is a way of searching, and AI is a fantastic accelerator for that.
But there are two conditions. You throw away what doesn't stick. And you actually look at the numbers, not just at the feeling.
Exploring isn't accumulating. The difference between the two is what you're willing to delete.
Key takeaways
- AI made building almost free. Maintenance, support and complexity still cost what they always did.
- The bottleneck moved from "knowing how to build" to "knowing what to build".
- Four tests before building: who asked, the written bet, the removal, the one-sentence demo.
- Delete at least as much as you add.
The question is no longer "can I build it?". The answer is yes, almost always. The question became: "does this deserve to exist in my product?"
Want to move fast without spreading yourself thin?
That's half of my job: building fast with AI, and saying no to the features that will cost you a lot for nothing. If you're looking for someone to build or take over your product, check out my custom development offer.
Has your app already grown in every direction and you don't know what to keep? Book an audit: in 3 days, you know what's solid, what's risky, and what to fix first.
And to get more articles like this one, sign up for the newsletter. No spam, just what you need to know.
