The App Is Not the Product

There is a mistake I think founders make too easily.

We have an idea and immediately begin imagining the app.

What should the home screen look like?
What features should it have?
Should we build for Android or iOS first?
What should the dashboard show?
Who should design it?
Who should build it?

These sound like product questions.

Often, they aren't.

They are software questions.

And software is not necessarily the product.

That distinction has shaped the way I build.

A product can exist before the software does

I learned this while building Fitness Space.

Fitness Space did not begin with an app.

It began with people trying to lose weight.

We worked with them through WhatsApp groups. We created structure around food, exercise, physical activity and daily habits. People checked in. They asked questions. We answered them. We watched where they struggled and where they succeeded.

There was no sophisticated technology behind it.

But something important already existed.

There was a problem.

There were people experiencing that problem.

There was a system designed to help them.

There was behaviour.

There was feedback.

And people were using what we had created.

We had a product before we had an app.

That experience changed the way I think about building technology.

Start with the problem, not the interface

When a founder starts with an app, there is a danger of answering questions that aren't yet important.

You can spend weeks deciding how onboarding should work before knowing whether anyone wants what happens after onboarding.

You can build a beautiful dashboard for information nobody cares about.

You can automate a process that hasn't proved useful manually.

You can spend months making assumptions look like software.

I prefer a different sequence:

Problem → People → Solution → Behaviour → Learning → Technology

Start with the problem.

Find the people experiencing it.

Try to solve it.

Watch what happens.

Learn.

Then decide what technology deserves to exist.

That doesn't mean technology is unimportant.

It means technology becomes much more powerful when you know what you're asking it to do.

Build the cheapest useful experiment

Not every early idea needs software.

Sometimes a WhatsApp group is enough.

Sometimes it's a spreadsheet.

Sometimes it's a landing page.

Sometimes it's a form.

Sometimes it's a founder manually doing something behind the scenes that will eventually be automated.

The question isn't:

What's the cheapest thing I can build?

The better question is:

What's the simplest experiment capable of teaching me something important?

I call that the cheapest useful experiment.

It doesn't have to be elegant.

It doesn't have to scale.

It doesn't even have to survive.

A prototype can look terrible and still teach you something important.

At an early stage, learning is often more valuable than polish.

There is a stage where inefficiency is information

Founders naturally want to automate.

I understand why.

Manual processes feel primitive when you're trying to build a technology company.

But there is a stage in product building where inefficiency is information.

When you're manually helping ten people, you notice things.

You hear the same question five times.

You see where people become confused.

You discover what they actually care about compared with what you assumed they would care about.

You find yourself repeating the same action every day.

You notice which part of the process consumes your time.

Those repetitions are telling you something.

They are beginning to show you what software should eventually do.

Automate too early and you risk hiding those lessons inside code.

Code should scale learning, not assumptions

This is one of the principles I keep returning to.

Code should scale learning, not assumptions.

The fact that something can be built doesn't mean it should be built yet.

Before committing engineering resources, I want to know what question the technology is answering.

What have we already learned?
What behaviour are we trying to support?
What are people repeatedly asking us to do?
What has become difficult to operate manually?
What becomes possible with technology that wasn't possible before?

When those answers become clearer, building software stops being an act of speculation.

It becomes a response to evidence.

That is what happened with Fitness Space

As Fitness Space grew, WhatsApp was no longer enough for everything we wanted the product to become.

But by then, we weren't starting from a blank screen.

We had spent time around the problem.

We had watched people try to make healthier food decisions.

We had seen the importance of accountability.

We had watched people struggle with consistency.

We knew that people needed guidance that could respond to their circumstances rather than simply hand everyone the same rigid plan.

Those experiences began determining what we built.

Bibi emerged because guidance and personalisation needed to happen at a scale that would become increasingly difficult to provide manually.

Health Score emerged from our interest in making daily healthy behaviours and consistency visible rather than asking people to focus only on the final number on the scale.

The app gave structure to activities that had previously been spread across conversations and manual processes.

Technology wasn't creating the product from nothing.

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

That's an important difference.

The first version is allowed to be ugly

I think founders sometimes feel embarrassed by simple beginnings.

We see polished companies and forget that we're looking at them after years of iteration.

So we try to make version one look like version fifty.

I don't think that's necessary.

Your first version has a different job.

Its job is to teach you.

If ten people are willing to use an ugly manual version of something because it solves an important problem, that can tell you more than a beautiful app nobody returns to.

The early version isn't supposed to prove how good you are at building software.

It should help you discover whether you're building the right thing.

Product building is replacing assumptions with evidence

At the beginning of almost every company, there are more assumptions than facts.

We think we know the problem.

We think we know who has it.

We think we know what they want.

We think they'll pay.

We think they'll behave in a particular way.

Then reality begins correcting us.

Good product building, to me, is the process of allowing that correction to happen as cheaply and quickly as possible.

Every conversation replaces an assumption.

Every experiment replaces another.

Every unexpected behaviour teaches you something.

Every failed idea removes a possibility.

Eventually, you understand enough to build with greater confidence.

Not certainty.

You never get that.

But evidence is considerably better than imagination.

Build when building becomes necessary

None of this is an argument against apps.

I build technology.

Fitness Space has a dedicated mobile product today because we eventually reached problems that required dedicated technology.

There are things software can do that WhatsApp groups, spreadsheets and manual processes simply cannot do well at scale.

The point is not to avoid building.

The point is to earn the complexity you're about to create.

Don't build technology merely because you're building a startup.

Build it because you've reached a problem that technology can solve better.

Start with the cheapest useful experiment.

Get close to the people.

Watch what they do.

Pay attention to what breaks.

Learn.

Then build.

Because 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.