An App Is Not a Business

I keep saying something that irritates software founders more than it probably should.

An app is not a business.

Neither is a website.

Neither is a course.

Neither is a consulting offer.

Neither is whatever you managed to build over the weekend after discovering that AI can now write most of the code for you.

Those are products.

Some might become very successful products.

But building a product and building a business are not the same achievement.

And as AI makes building ridiculously easy, understanding the difference is becoming more important, not less.

We confuse building, selling and building a business

Suppose you spend six months developing an app.

You launch it.

Congratulations.

You have a product.

Someone gives you $20 for it.

Even better.

You have a transaction.

Then 1,000 people buy it.

Now you have $20,000 in revenue.

Excellent.

You have evidence that people are willing to pay for what you created.

But I would still ask some annoying questions.

Who exactly are those customers?

Why did they buy?

Can you find another 1,000?

How much does finding them cost?

Can you reliably convert them?

Does enough money remain after acquiring and serving them?

Why will customers continue choosing you?

What happens when competitors copy you?

What happens when customer behaviour changes?

What happens when AI makes half your functionality available for free?

And perhaps the most uncomfortable question:

What happens when this product stops being relevant?

Because eventually it will.

Every product has a lifecycle.

A business needs the capacity to survive beyond it.

So what is a business?

For entrepreneurs, I use a deliberately simple definition:

A business is a repeatable and sustainable system for creating, delivering and capturing value.

The important word isn't app.

It isn't technology.

It isn't even product.

It's system.

A real business has several connected parts.

There is someone with a problem, need or aspiration.

There is something valuable enough for that person to act.

There is a way to reach them.

There is a reason for them to choose you.

There is a way to deliver what you promised.

There is an economic model that leaves enough money behind for the business to survive.

And there is the ability to learn and adapt when reality changes.

The product sits inside that system.

Sometimes it is the centre of it.

But it is still only one part.

That's where Business Architecture begins.

Most entrepreneurs architect backwards

The usual sequence looks something like this:

IDEA → BUILD → LAUNCH → NOW HOW THE HELL DO I SELL THIS THING?

That last question is doing quite a lot of work.

Who is it for?

What sufficiently important problem does it solve?

Why would somebody change what they're currently doing?

Where are these people?

How do you reach them?

What will they pay?

Why would they choose you?

Can you acquire them economically?

Can you deliver consistently?

Can the business make money after all the costs are counted?

These aren't marketing details to figure out after you've built the product.

They are the business.

And that's why Business Architecture should happen before, around and beyond product development.

You are not simply deciding what to build.

You are working out how the business itself should work.

A scalable product isn't necessarily a scalable business

Software founders particularly love this one.

"But my app is scalable."

Wonderful.

So is a stadium with 50,000 empty seats.

The seats aren't the problem.

The people are.

Your software might technically serve 100,000 customers without much additional infrastructure.

That's useful.

But can your business find those 100,000 people?

Can it persuade enough of them to buy?

Can it acquire them at a cost that makes sense?

Can it retain them?

Can it continue creating enough value for them?

Technical scalability is a characteristic of the product.

Business scalability is the ability of the whole system to grow economically.

Those are very different things.

AI is making this mistake easier

This is where the problem becomes particularly relevant now.

Building used to be expensive.

You needed developers.

Designers.

Infrastructure.

Money.

Time.

Today, one reasonably capable entrepreneur with AI-assisted coding and a collection of tools can build something surprisingly sophisticated in days.

I think that's extraordinary.

The distance between imagination and creation is collapsing.

But there is a catch.

When building becomes easier, building the wrong thing becomes easier too.

You prompt it.

You build it.

You deploy it.

You connect Stripe.

You announce your startup.

There is only one inconvenient participant missing from this beautifully efficient process.

The customer.

An app at the beginning is essentially an assumption written in code.

An assumption that somebody has the problem.

An assumption that the problem matters.

An assumption that your solution is better enough for them to change behaviour.

An assumption that they'll pay.

An assumption that you can reach enough of them.

An assumption that the economics work.

AI can dramatically accelerate execution.

It cannot magically turn those assumptions into evidence.

The first sale matters. A lot. But as I've written before, as assumptions start looking like evidence, what actually deserves to become a business needs architecture. There's an earlier piece on testing whether an idea has a real chance of becoming one.

Revenue is evidence. It isn't the whole architecture.

The first sale matters.

A lot.

It means reality has finally entered the conversation.

More sales create stronger evidence.

Repeatable acquisition creates stronger evidence again.

Healthy economics tell us something even more interesting.

But revenue alone still doesn't tell us whether we've built something durable.

If acquiring a $100 customer consistently costs $140, congratulations.

You've created a remarkably efficient machine for converting $140 into $100.

Scale carefully.

A functioning business needs more than revenue.

It needs demand.

Acquisition.

Conversion.

Delivery.

Economics.

Operations.

Capabilities.

Learning.

Adaptability.

And those pieces need to work together.

That's architecture.

Products have lifecycles

This is the part entrepreneurs often ignore while things are going well.

Every product changes.

Some products survive for decades.

Some disappear in eighteen months.

Some become irrelevant.

Some get copied.

Some are replaced by new technology.

Some are destroyed by changing customer behaviour.

And occasionally, a company deliberately kills its own successful product because it has something better coming next.

The question isn't whether your current product will change.

It will.

The better question is:

What remains when it does?

Imagine two companies selling almost identical successful apps.

Both have customers.

Both generate revenue.

Both are profitable.

Then the market changes and demand begins declining.

Company A understands its app.

Company B understands its customers.

It knows why they bought.

It understands their changing problems.

It has relationships.

Distribution.

Market knowledge.

Operational capability.

Trust.

Data.

A way to identify new opportunities.

And the ability to develop and commercialise another solution.

Company A asks:

How do we save the app?

Company B asks:

What do our customers need next?

Those are two fundamentally different businesses.

If your product disappeared tomorrow, what would be left?

I think this is one of the most useful questions you can ask an entrepreneur.

Take away your current product.

What's left?

Nothing?

That's worth thinking about.

Or do you still have:

Customers?

Market knowledge?

Distribution?

Relationships?

Trust?

Brand?

Data?

Capabilities?

Operational knowledge?

Understanding of a valuable problem?

A reliable way to create, test and commercialise something new?

Now we're getting somewhere.

Because those things can survive Product 1.

And they can help create Product 2.

Then Product 3.

The products move through their lifecycles.

The business continues creating value.

That's what Business Architecture is for

Business Architecture is not drawing complicated diagrams about a company.

At least not the way I practice it with entrepreneurs.

It answers something much more practical:

How should this business actually work?

Who are we creating value for?

What problem are we solving?

What are we selling?

Why does it matter?

How do customers find us?

Why do they buy?

How do we deliver?

How does money move through the business?

What needs to exist operationally?

What capabilities do we need?

What could break?

What needs to happen first?

And how does the business continue adapting as reality changes?

The product is part of those answers.

It isn't all of them.

That's why building an app doesn't mean you've built a business.

For a closer look at what this actually means, there's a detailed answer to the question "What is Business Architecture?"

Build the business around the product

So yes.

Build your app.

Launch it.

Sell it.

Celebrate every customer.

Make money.

Please make money.

I'd much rather see an entrepreneur with an ugly product generating real revenue than another founder calling themselves CEO because Canva gave them a nice logo.

But don't stop architecting when the product works.

Ask what needs to exist around it.

Demand.

Customers.

Acquisition.

Delivery.

Economics.

Operations.

Capabilities.

Learning.

Adaptation.

Build those things deliberately.

Because the thing you're selling today will eventually change.

Products have lifecycles.

Businesses have the opportunity to survive them.

And the difference between the two is architecture.