AI made building cheap. Turning a product into a business is still hard
AI made building apps nearly free. Here is why AI-built apps stall after launch, and what it takes to turn a product into a business.
AI-built apps tend to stall after launch because the work that comes next is spread across tools and people that do not share data or context. We call that work the operating layer.
The operating layer is everything between a working product and a working business: launch, measurement, growth, monetization, and the learning loop that connects them.
Is building still the hard part?
For a growing range of web apps, no. AI app builders can now produce the pages, data, sign-in and checkout of a working first version from a description. Getting to something real used to take months of engineering. Now it takes a few conversations.
The constraint has moved somewhere else. When products are cheaper to build, more of them get built, and they all compete for the same customers. Being easy to build does not make a product easy to find.
Where do products stall after launch?
A product goes through seven stages, and AI has compressed the first two. Momentum is usually lost somewhere in the other five.
Idea
Someone sees a problem worth solving.
Build
A working product exists. AI has made this stage fast and cheap.
Launch
The product goes live on a domain and meets its first visitors.
Measure
Visits, sign-ups and payments are counted, the same way everywhere.
Grow
Channels that bring the right customers get more budget, and the others get less.
Monetize
A price, a checkout and a clear view of who pays and who stays.
Optimize
What was learned goes back into the product and the next campaign.
It is rarely one big mistake. More often it is a handful of gaps between stages:
| Gap | What it looks like | What it costs |
|---|---|---|
| Tool fragmentation | The app, launch page, analytics, ads and payments sit in different products | Every change touches several tools |
| Data silos | Ad clicks cannot be joined to sign-ups or revenue | You optimize clicks instead of customers |
| No shared method | Nobody owns how launch, growth and pricing affect each other | Decisions run on habit |
| Revenue kept apart | Payments live outside the product's data | You cannot see which feature or channel pays |
| Learning stops | Results are reported but never reach the next build | The product ships, then stands still |
Any one of these is survivable. Together they produce a familiar pattern: a launch, a burst of sign-ups and no clear idea of what to do next.
Why don't better models make distribution cheaper?
Because distribution is mostly decisions, and those decisions need data that a model does not have.
A model can write the ad and build the landing page. Without your numbers, it cannot tell you whether a 4% conversion rate at US$20 beats 2% at US$45. Per visitor, the second brings in more: US$0.90 against US$0.80. Whether it is actually better depends on what each customer costs to win and to serve, and whether they come back. Budget allocation, bidding and attribution work the same way. The right answer is specific to the business, and it changes as the business does.
So cheaper building tends to make distribution harder. More products chase the same channels, and the advantage goes to whoever learns fastest from their own data.
What gets lost between tools and teams?
A common setup after launch is a site builder, an analytics tool, one or two ad platforms, a payment provider and a spreadsheet to tie them together. Each boundary costs something.
- The reasoning behind a change rarely survives the trip. The next person sees what was done, not why.
- Setup eats the first weeks. Time that should go into learning from customers goes into connecting tools.
- Definitions drift. A "customer" in the ad platform, the product and the finance sheet can be three different counts.
Who runs into this most?
People and small teams who are strong at one part of the job and new to the rest. Someone with a clear idea and no engineers can now get a first version built, but may never have run a launch. A developer who can ship a demo in a weekend may have no feel for paid acquisition or pricing. A small team with a product people like may still be guessing which channel works and what to charge.
For all of them, the question is no longer whether the app can be built. It is whether launch, measurement, growth and revenue can be handled without hiring someone for each.
What does it take to turn a product into a business?
Three capabilities working from the same data. You need to reach customers and know which channel brought the ones who stayed. You need a price, a checkout and a clear view of who pays. And what you learn has to flow back into the product and the next campaign.
None of that is new. What is new is that it can be run from the same place the product was built, by the same person. That is the job ExaSpark takes on, and What is ExaSpark?, the next post in this series, describes how.
To see the product, the checkout and the numbers in one place:
Build my app with a launch page, analytics and Stripe checkout, then show me visitors, sign-ups and revenue in one place.
Frequently asked questions
- Why do apps stall after launch?
- Usually because launch, measurement, growth and monetization are split across tools and people that do not share context or metric definitions. The app keeps running, but nobody can see which channel brings paying customers, so the product stops improving.
- What is the operating layer of a business?
- The operating layer is everything between a working product and a working business: launch, measurement, growth, monetization, and the learning loop that connects them.
- What is the difference between an app and a business?
- An app is software that works. A business is an app that reaches customers, earns money and keeps improving, which takes distribution, payments and a way to learn from results.
- What should you do after building an app?
- Launch it on a real domain, count visits, sign-ups and payments the same way everywhere, spend on the channels that bring paying customers, and feed what you learn back into the product. Keeping those steps in one place stops context from getting lost between tools.
