Cheap to build is not a reason to build

You know the exact moment I'm talking about. Someone shows you an app they built with AI, and for the first minute it's genuinely impressive: a clean landing page, a flow that actually works, real speed. Then you click into the second tab. Three toggles, two of them dead. A "reports" section stuck on an empty state. A half-wired integration. The whole impression flips in about ten seconds, and it doesn't flip back.

Here is the part people miss: that half-built feature did the same damage a broken checkout would have done. Not less. A customer does not grade you on the feature they came for versus the one they stumbled into. They read the whole surface as a single signal about whether you finish what you start. A dead toggle and a broken payment both say the same thing: this team ships things they don't stand behind. The empty "reports" tab is not neutral. It quietly tells every customer you left something unfinished.

We got here because building a feature became nearly free, and a lot of builders quietly stopped treating "add a feature" as a decision. It used to be one. When a feature cost you two weeks you couldn't get back, you were forced to ask the old questions: why this, why now, what is the smallest version that proves it, how will we know if it worked, what do we cut if it doesn't. Cost imposed discipline. Remove the cost and, if you are not careful, you remove the discipline with it. You get prolific output and prolific half-things, and every one of them is a claim you failed to back.

I see it at both ends of the spectrum. I've talked to vibe coders who never wrote a line of code in their life and have spent a month building something that looks incredible: more features than you can imagine, and not a single user. And I've talked to companies with eight figures in revenue who are shipping features out the door they can't tell you the reason for, and now they have to maintain and support all of them. Different scale, same failure. Cheap building didn't repeal the need for a reason. It just removed the thing that used to force you to have one.

So the old startup rules still hold, unchanged. You need a reason to build. You build the smallest real version. Real meaning finished, not merely present. You measure. You cut what doesn't earn its place, without sentiment. None of that got repealed because the compiler got faster.

But there's a second half, and it's the part that's easy to miss. Because building is cheap now, you should aggressively reclaim the good scope you were once forced to cut for time. Every builder carries a list of the right things they never shipped: the empty state that should have been helpful, the export that should have handled the edge case, the second onboarding path for the user who arrives differently. Those weren't bad ideas. They were good ideas priced out by the clock. That price just dropped. The move is not "build everything now that it's free." It is "revisit the ledger, and pull back the things that were always worth doing." Same judgment, aimed at a scope you couldn't afford before.

When someone hands me a feature idea (a customer, a product lead, an engineer, or the LLM the product lead just asked), I run it through one question before anything else: where is the client truly getting value? Not "can this be built." Almost everything can be built now, and quickly. The question is whether there's a real problem underneath it, with a use case and a workflow that follows. A feature without a problem attached is not a feature. It's maintenance you signed up for by accident.

And here's the trap in the cheap-to-build era: the cheapness itself starts to feel like a reason. It isn't. There's always a trade-off, because there's always a better feature you could build if you actually understood the problem. So the cost of the wrong feature isn't just the wrong feature. It's the right one you didn't build instead.

I'm building an operating system for interior design studios. It's deliberately lean, and each capability in it had to earn its way in against that question. At its core it does one thing exceptionally: it replaces the spreadsheet a designer lives in to find, curate, and track products, and then propagates those selections out to every place the designer's job requires. That's the perimeter. The moment a feature pulls me outside it, I get suspicious of it, even when it's easy.

Live trade pricing is inside the perimeter. It's there because designers were quoting from retail numbers and eating the margin. It runs by driving the designer's own logged-in browser, because the real trade price frequently only exists in their authenticated session. With some vendors it doesn't even appear until an item is in the cart. A signed-out cloud scraper would only ever see retail, which is the wrong number. That's not a feature I added because I could. It's one I added because the alternative was confidently wrong.

What I left out matters as much as what I kept. I dreamed up an AI chat interface over all the documents in the design flow, and I even built the screen. At a glance it looks great: talk to your system, ask it anything. But I ruled it out, because I couldn't tell you what problem it solves. It's very limited, and nobody's getting an insight from it they couldn't get faster from ChatGPT. There's no moat, and more to the point, there's no workflow underneath it. It was easy. I could stand up a convincing version in under an hour, looking like every other AI tool on the market. Easy was exactly why I distrusted it. Meanwhile the genuinely painful problem, knowing whether an item just went out of stock across the thirty vendor sites a designer is tracking, isn't showy at all, and it's worth ten of that chatbot. I'd rather build the boring thing that solves a real problem than the impressive thing that solves none.

I hold the same line on requests I can't yet justify. Designers ask for visualization, and one day it may be the must-have. But there are deep, dedicated tools that already do it well, the designer is usually already doing it some other way, and it sits outside my perimeter. I'm not going to have the whole product judged by a quick-and-dirty version of something that isn't the core problem. When it becomes the thing that truly drives value, I'll build the real version or integrate the right one. Not before.

AI is genuinely good at the first version. It drafts fast, and it is a real accelerant. It does not decide what is worth building, it does not know when a feature is actually finished versus merely present, and it will happily generate the whole pile if you let it. That judgment is still yours. Discipline didn't go away when building got cheap. The measurement just changed: not "can we afford to build it," but "can we attach it to real value." The scarce thing, the thing worth having near your roadmap, is judgment exercised from a foundation of speed: the discipline to still make the decision, and the range to reclaim the good scope you thought you couldn't afford.

Build less than you can. Finish what you build. And go back for the good ideas the old constraints made you leave behind.

I write about this most weeks: building with AI, and the judgment that separates real work from the pile. If something here landed, reply and tell me what you're wrestling with on your own roadmap. I read every one.

Alex Bibighaus
Headmark Group. Helping ambitious companies apply AI where it matters most.