AI Will Build Anything. It Won't Tell You What to Build

By Ken Vermeille. Senior mobile engineering, embedded in your team in 5 days. 15 years, 4 founder exits. The alternative to a 6 month, $200K hire.

Building software stopped being the hard part. That is exactly why most of what gets built now makes nothing, and why building the right thing is the only work that ever paid.

Read time: 5 minutes.

You've seen this graph. It has been on every feed for two weeks.

I post my take on Tuesdays, so I am late to it. I would rather be late and right than fast and wrong.

Here is what it shows. Since agentic AI arrived, iOS app releases nearly doubled. Apps with real usage stayed flat. Reviews fell.

Building exploded. Mattering didn't.

Most people read this wrong

The common read is "AI let anyone ship, so the stores filled with junk." That is true. It is not the lesson.

The lesson is that building was never the expensive part. We just learned it the hard way, at scale, in public.

Building is not free

This is the part that gets lost in the excitement. I learned it before AI existed, by building apps nobody wanted.

If you build something and it makes zero dollars, you did not move fast. You spent time and money to produce nothing. Fast nothing is still nothing.

The bill for the wrong thing did not shrink because the building got quicker. It moved. It shows up later, as the months you spent, the runway you burned, and the thing you have to now walk away from.

Building the right thing is the only kind of building that ever paid.

AI will build anything. It will not tell you what to build.

This is the line I would write across that whole graph.

AI will build anything you ask it to. It will not tell you what is worth asking for.

Here is how I know. Years ago we built a multiplayer tank game for phones. An agent could rebuild the whole thing today in an afternoon. It still would not have told us the only thing that mattered, which is that almost nobody wanted to play a tank game on their phone (at the time). We found that out after we shipped it. Not before.

It has never met your customer. It cannot tell you which five of your twenty features matter, or whether the problem you are solving is painful enough that someone pays to make it go away.

That was always the hard part. The building just stopped hiding it.

We built the wrong thing beautifully, more than once

Early in my career we built apps for other people. We used the best tooling, real designers, real testing. The apps were not buggy. They were not slow. They did exactly what the spec asked.

There was a snow day app that predicted whether school would be canceled. There was the tank game. There was a receptionist app for a dental office. Every one of them sounded great in the room.

One of them, the dental receptionist app, ran close to $100,000 over six months. We shipped it clean. Two years later the client shut the app down.

I was furious, because I thought we had done everything right. We had. Except the one thing that mattered. Nobody ever asked whether any of these things should exist. We never put them in front of a real person who would pay. We built the wrong thing beautifully, more than once, and once we did it for a hundred grand.

Then we built Foodeze the opposite way

The restaurants we knew were paying GrubHub around 30% on every order, and they hated it. So this time, before we wrote a line of code, we went and talked to them. And to the people ordering takeout three nights a week.

That sounds obvious. Almost nobody does it. It is the step that does not feel like progress, so founders skip it, especially now that building looks free.

Customer development is the part that does not get cheaper

The process has a name. Customer development. It is unglamorous, and it is the whole game.

We found the people who already had the problem, and we recorded the conversations. We did not ask them if they liked our idea. People lie to be nice. We asked what they actually did, what it cost them, and what they hated about it. Then we went back through the tape and looked for the pain that showed up over and over.

That is where the real product came from. We walked in with twenty features we were certain about. The interviews killed fifteen of them. The five that survived were the only ones anybody had asked for.

The interviews also moved the whole idea. The real pain was not ordering food. It was decision fatigue, and the guilt of how expensive takeout had become. So we built a flat fee model instead of the 30% cut, and we let restaurant owners talk straight to their customers through deals.

No native app. Just a web app that worked. We launched at a few colleges and crashed our own servers because people actually used it. The restaurants used GrubHub for discovery, then slipped a Foodeze coupon into the delivery bag so the next order came through us. We went from a few colleges to Ithaca, to hundreds of restaurants and tens of thousands of users.

None of that is promptable. An AI can summarize an interview you already ran. It cannot sit in the restaurant. It cannot read the owner's face when you bring up the 30%. That work is yours, and it is the work that decides whether anything you build makes a dollar.

What is actually scarce now

Not the code. The code is the cheap part now, and the graph is what happens when everyone optimizes the cheap part and skips the expensive one.

The same team built the tank game and built Foodeze. Same tools, same skill. AI can reproduce a Grubhub clone. It could never have told us to build Foodeze in a differentiated way instead. That single decision was the entire difference between a dead app and a real business.

What is scarce is knowing what to build before you build it. The painful problem worth solving. The five features out of twenty. The real person whose feedback does not live in any training set, because it just happened, in a room, to you.

The founders who come out of this stretch ahead are not the ones shipping the fastest. They are the ones slowing down at the exact step everyone else is now skipping.

It was never the code.

Building got faster. Knowing what to build did not. Which one is your company actually short on?

The Cold Start, by Ken Vermeille. We build embedded senior engineering for product companies.

Forward this to your favorite founder.