Product Maturity in Slow Motion

I'm writing these lines sitting outside our motorhome.

Or rather, outside our Liesl.

Marion is still asleep. The morning sun is slowly rising over Lake Neusiedl, the first windsurfers are rigging their sails, and somewhere nearby, a mast is gently clinking in the wind. In a little while we'll have breakfast. Maybe there'll be enough wind for a kite session later. Maybe just enough for windsurfing. Or maybe there won't be any wind at all.

I like that uncertainty.

It's exactly why we're here.

Not to spend three weeks doing absolutely nothing, but to live the way I've imagined for many years: work when it makes sense, and enjoy life when the opportunity is there.

My Mac is always within reach inside the Liesl. If the lake is calm, I continue working on the first native FLINTAXI apps. The moment the wind picks up, the laptop closes and the kite or windsurf board comes out.

Ten or fifteen years ago, I could never have imagined living and working like this.

Today, it feels exactly right.

Just about a week ago, FLINTAXI officially went live.

Many people probably imagine a product launch as the finish line.

Countdown.

Push the button.

The product is online.

Done.

I've always seen it differently.

Maybe that's because I've been developing software for many years and have had the opportunity to work on a number of large projects—news apps, weather platforms, research applications, and digital products used by hundreds of thousands of people.

They all have one thing in common:

The real work begins after the launch.

Not because the software wasn't ready.

But because that's the moment when something happens that no amount of testing can ever fully reproduce.

People start using it.

Real people.

With their own phones.

Their own habits.

Their own expectations.

And sometimes with wonderfully creative ways of using an application that no developer would ever think of.

That's exactly what makes software so fascinating.

And that's why I knew, even before launch day, that the first week would probably be more demanding than the final week before release.

I was right.

On the very first day, the first Riders registered.

Shortly afterwards came the first bookings.

The first airport transfer.

Three Drivers completed their onboarding.

And suddenly FLINTAXI was no longer just our project.

It had become a system that real people were actually using.

From that moment on, our work changed.

Before launch, we were looking for bugs.

After launch...

The bugs found us.

Or more accurately:

Reality found them.

One situation, in particular, has stayed with me.

One of our newly trained Drivers completed her very first real ride.

The trip itself went perfectly.

The passenger arrived safely at her destination.

Exactly what we wanted.

And yet, the ride didn't end quite as planned.

Not because the software crashed.

Not because Stripe failed.

But because, quite understandably, the Driver simply forgot to complete the ride in the app.

As a result, the Rider could no longer pay online.

They solved the situation the simplest possible way: with a cash payment.

As a developer, your first instinct is always to look at the code.

Where's the bug?

What needs to be fixed?

A few minutes later it became obvious:

The software wasn't the real issue.

Our onboarding process was.

We had explained how to accept rides.

How to navigate.

How to communicate.

But clearly we needed to place much more emphasis on how to properly complete a ride.

That wasn't a software bug.

It was a lesson.

And probably a more valuable one than many technical issues we've fixed.

Sima also had her hands full throughout the week.

Alongside media interviews, social media, driver training, and the first real bookings, new feedback kept arriving almost constantly.

"This text could be clearer."

"Maybe this email should be sent earlier."

"This information would be helpful here."

"Why does it work like this?"

Almost every one of those observations landed on my desk just a few minutes later.

Sometimes I had barely finished fixing one issue before the next screenshot appeared.

Or a voice message.

Or simply:

"Stephan, I think we've found something else."

I often smiled.

Not because there were so many little issues.

But because this is exactly what happens when software stops being tested by developers and starts being used by people who simply want to book a taxi—or drive one.

What made me particularly happy was that most of the improvements weren't spectacular new features.

They were small refinements.

A clearer message.

An additional email.

A better explanation.

A more intuitive status indicator.

A workflow that simply feels more natural.

From the outside, they're almost invisible.

But together, they make an enormous difference.

During this week I found a phrase that perfectly describes what we've been experiencing.

Product maturity in slow motion.

No dramatic breakthrough.

Just dozens of small decisions.

Each one making the product a little bit better.

Each one making Riders and Drivers think just a little bit less the next time they use it.

And that's what good software really is.

Not software that impresses people.

Software that simply works.

As I write these lines, FLINTAXI is no longer just a development project.

There are Riders.

There are Drivers.

There are real bookings.

There are real journeys.

And there are people trusting the system to work when they need it.

That's a responsibility.

But it's also an incredible source of motivation.

In a few minutes I'll close my Mac again.

Maybe today will bring enough wind for kiting.

Maybe just enough for windsurfing.

And if the lake stays calm this afternoon, I'll continue working on the first native apps.

This time with a very different feeling.

Because I'm no longer building software for an idea.

I'm building software for a product that is already alive.

And I already know one thing.

The native apps won't be perfect on day one either.

Just like FLINTAXI itself...

They'll mature in slow motion.