The App Is Not the Product

One of the easiest mistakes to make as a founder is to confuse building an app with building a product.

I understand why.

Apps are visible. You can open them, swipe through screens, show them to investors, put them in an app store and point to something you have built.

A problem is less exciting to show.

So is a process.

So is a WhatsApp group.

But I have come to believe that some of the most important work in building a product happens before there is much software to look at.

The app is not the product.

The product is the solution you have created for a problem people actually have.

Software can make that solution faster, smarter, easier to use and capable of reaching millions of people.

But software cannot make an irrelevant solution useful.

We had Fitness Space before we had the app

Fitness Space taught me this.

We didn't begin by sitting down to design screens for a fitness application.

We began with people who wanted to lose weight.

That distinction shaped almost everything that followed.

We worked with people through WhatsApp. We gave them structure around food, exercise and daily habits. We watched where they struggled. We saw what they understood immediately and what required explanation. We saw people start strongly and lose momentum. We saw the difference accountability could make.

None of this required sophisticated software.

But something important was already happening.

People were using Fitness Space.

There was a problem.

There were users.

There was a system for addressing the problem.

There were behaviours we could observe.

There was feedback.

There were things that worked and things that didn't.

In other words, there was already a product.

It just wasn't an app yet.

That period taught us things I don't think we could have learned by spending months designing what we imagined the perfect health app should look like.

We were learning from reality rather than from our assumptions about reality.

Founders can build too early

Technology founders naturally want to build.

There is something satisfying about turning an idea into software. Once you can see the interface, the idea suddenly feels real.

But that excitement can create a dangerous sequence:

Idea → Features → Design → Code → Launch → Find users

I prefer a different sequence:

Problem → People → Solution → Behaviour → Learning → Technology

The difference looks small, but it changes what gets built.

In the first sequence, the founder spends significant time deciding what users will probably need.

In the second, the founder tries to understand what people actually need before committing heavily to how the solution will be delivered.

That doesn't mean every startup should spend a year running manually before writing code.

Sometimes the technology itself is the experiment. Some products cannot meaningfully exist without software.

The principle is simpler:

Don't build more technology than you currently need to answer the most important question about your idea.

If a WhatsApp group can answer it, use WhatsApp.

If a spreadsheet can answer it, use a spreadsheet.

If a landing page can answer it, build the landing page.

If ten phone calls can expose a bad assumption before ten weeks of engineering, make the calls.

Code when code becomes necessary.

A prototype can look terrible and still teach you something important

Founders sometimes think an early product needs to resemble the company they eventually want to build.

I don't think it does.

An early version has a different job.

Its job is to help you learn.

Can we solve this problem?

Will people use the solution?

Will they return?

What confuses them?

What do they ignore?

What are we doing manually that happens repeatedly?

Which part of the experience creates the most value?

What did we think mattered that users barely notice?

These questions are more valuable to me than whether version one looks impressive.

With Fitness Space, WhatsApp gave us an environment where the distance between us and the people using what we were building was very small.

If something wasn't working, we could see it.

If people repeatedly asked the same question, that told us something.

If a process required too much human intervention, that told us something else.

Those observations eventually become product decisions.

And then software becomes incredibly powerful.

Code should scale learning, not assumptions

The point of delaying certain engineering decisions isn't that code is bad or expensive.

I build technology companies. I want software.

But I want software to encode things we understand.

Every repeated manual process is potentially telling you what to automate.

Every recurring user question may be telling you where intelligence is needed.

Every point where people consistently drop off may be showing you where the product is failing.

Every behaviour users repeat without being forced may be showing you where the value actually is.

This is how I think about the transition Fitness Space made.

We didn't build Bibi because "AI" became something every company was expected to put into its product.

We had already spent time interacting with people.

People needed guidance.

They needed help making decisions around food.

They needed accountability.

Different people had different circumstances.

The experience needed to become more personalised without requiring a human being to manually handle every interaction as the number of users grew.

Now technology had a job.

Bibi could help carry forward parts of what we had learned from working directly with people.

The Health Score could make daily consistency visible and measurable.

The app could organise activities that had previously been spread across conversations and manual processes.

Software wasn't replacing the product.

Software was allowing the product to become something larger than the system we could operate manually.

Manual work is not always inefficiency

This is another thing I think founders can misunderstand.

At scale, excessive manual work is usually a problem.

At the beginning, it can be an advantage.

Doing something manually forces you to encounter details that software would otherwise hide from you.

You answer the questions yourself.

You see the complaints.

You watch people misunderstand instructions you thought were obvious.

You discover exceptions.

You notice behaviours you never included in your original assumptions.

Eventually, you should automate many of those things.

But automating something before understanding it can simply help you make the wrong decision faster.

There is a stage in product building where inefficiency is information.

The founder's job is to recognise when that information has become sufficiently clear that technology can take over.

Start with the cheapest useful experiment

This principle now influences how I approach other products too.

When someone brings me an idea, one of my first instincts isn't to ask:

What should the app look like?

I want to know:

What are we trying to prove?

Those are very different questions.

If we think people have a particular problem, how can we establish that?

If we think they will behave in a particular way, how can we observe it?

If we think they will pay, can we get someone to pay before building an elaborate payment system?

If the business depends on ten people coordinating around something, can we coordinate ten people manually first?

The cheapest useful experiment isn't necessarily the cheapest thing you can build.

It is the simplest experiment capable of teaching you something important.

And sometimes the result of that experiment should be that you don't build the app at all.

That is not failure.

Finding out cheaply that an assumption is wrong is one of the best outcomes an early-stage founder can get.

The expensive version is discovering the same thing after six months of engineering.

Product building is a process of removing assumptions

At the beginning of a company, almost everything is an assumption.

We think the problem matters.

We think we understand why it happens.

We think people want our solution.

We think they will use it in a particular way.

We think they will pay.

We think a certain feature matters.

We think we know what should be automated.

Some of those assumptions will be right.

Many won't.

For me, early product building is largely the process of replacing those assumptions with evidence.

That is why I don't think the first objective should always be to produce impressive software.

The objective should be to learn enough about the problem that, when you finally invest heavily in technology, you are building with greater clarity.

The app can come later.

The engineering can become more sophisticated.

The interface can become beautiful.

AI can make the experience more intelligent.

Infrastructure can allow millions of people to use what once required a handful of people operating manually.

But underneath all of that, something more basic still has to be true:

The product has to solve a problem.

An app is a container.

Technology is an amplifier.

Code is a tool.

The product is what happens when someone comes to you with a problem and leaves better off because of what you built.

Figure that out first.

Then write as much code as it deserves.