From a Newspaper Article to Go-Live

A personal reflection by Stefan

Sometimes something great begins with a single sentence.

Not with a business plan.

Not with a presentation.

Not with a fully developed concept.

But with a sentence you read and never quite forget.

On 17 April 2026, an article about Sima appeared in Der Standard. In it, she spoke about her experiences, her work, and her vision of how mobility could become safer, more respectful, and more humane.

One sentence stayed with me:

"In the future, Sima dreams of her own app."

I read it once.

Then again.

And as I thought about it, I suddenly knew: perhaps I could help turn that dream into something real.

I didn't know Sima at the time. There was no shared history, no long conversations, no plans for a platform — and certainly no idea of how many hours, detours, setbacks and small victories lay ahead.

There was only that sentence.

And my message to her.

First Contact

I offered Sima my help.

Not with grand promises, and not with the pretence of already having all the answers. I simply wrote that I found her idea exciting and believed I could support her technically.

That first message became a conversation.

That conversation became more conversations.

And at some point it was clear this wasn't going to be just another app.

Sima didn't have a shallow product idea. FLINTAXI was driven by an attitude from the very beginning. It was about safety, trust, visibility, respect — and about giving people an alternative where they feel genuinely taken seriously.

My task was to build a technical solution from that.

What initially sounded fairly clear very quickly became very large.

Because an app is never just an app.

Behind every button are decisions. Behind every booking lie workflows, calculations, data, notifications and edge cases. Behind every seemingly simple feature is the question of what happens when things don't go as planned.

And software has the unpleasant habit of reliably finding those exact cases.

My Office Often Had Wheels

Those who know me know that my life isn't only servers, source code and screens.

I love being out and about. I love the water, the wind and surfing. I appreciate those moments when you're outdoors, your mind clears and for a while only what's directly in front of you matters.

An important part of that life is our motorhome.

We call her Liesl.

For Marion and me, Liesl is more than a vehicle. She's a retreat, a travel companion, a small kitchen, a sleeping space — and over the past months, repeatedly my office.

So a large part of FLINTAXI came to life not in a conventional development office, but on campsites, beside lakes, at the seaside and at small tables inside the motorhome.

The local development server ran on my laptop. Next to it lay notes, cables, sometimes a cup of coffee and occasionally the various things that tend to accumulate in a motorhome.

Outside you could hear people talking, dishes clattering or the wind moving through the trees.

Inside, the server was running.

Sometimes it wasn't.

Podersdorf

One of the most important afternoons in this story took place in Podersdorf am See.

Marion and I were at the campsite in Liesl. Sima came to visit with a friend.

It wasn't the kind of formal business meeting you might picture. No conference room, no sterile setting, no long table with name cards and bottles of mineral water.

Instead, we sat together at the campsite.

We talked, laughed, shared our ideas and got to know each other better. It was a very pleasant, lively and enjoyable afternoon — one of those afternoons that doesn't feel like work, even though something decisive happened.

That's also where we signed our contract.

Between motorhomes, holiday atmosphere and Lake Neusiedl, an idea became a shared project.

Looking back, that setting fits FLINTAXI remarkably well.

This project was never born in a polished corporate world. It grew from personal encounters, honest conversations and the will to build something that didn't yet exist.

The First Lines of Code

At the beginning, software is always quiet.

There are no users yet. No real bookings. No drivers responding to rides. No payments. No invoices. No push notifications.

There is only an empty structure and the hope that a working system will eventually emerge from it.

I started locally.

Step by step the technical foundation took shape. A backend, initial data models, user roles, booking flows and administration areas.

At the start, a lot goes quickly.

The first pages appear. Buttons work. Data gets saved. You see progress and briefly believe you've already done the hardest part.

That's usually the moment when the software begins to disagree.

When the Code Won't Cooperate

There were days when everything came together.

A feature I had worked on for a long time finally ran through. A booking was created correctly. Prices were calculated right. Notifications arrived exactly where they were supposed to.

And then there were the other days.

You change one small thing and suddenly something completely different stops working.

A value is calculated correctly but displayed wrongly.

A flow works with card payment but not with cash.

A voucher is deducted correctly, yet somewhere else the original price reappears.

A button responds.

Except sometimes.

And "sometimes" is one of the most dangerous words in software development.

I remember evenings in Liesl when I was convinced I had finally found a bug. I changed the code, restarted everything and tested again.

The bug was still there.

Then came the next attempt.

And the next.

At some point the coffee had long gone cold on the desk. Outside it had grown dark. The campsite was quiet. Only inside the motorhome the screen still glowed.

You read the same lines for the tenth time and wonder how something that looks completely logical can still behave incorrectly.

Then you find a small inconsistency.

A wrong value.

A condition that behaves differently in an edge case.

Something you considered insignificant that afternoon.

You fix it.

You test.

And suddenly it works.

These moments are hard to explain. After hours of doubt, there is suddenly just a green status, a correctly completed booking or an amount that is finally right.

For others it's a small thing.

For you, in that moment, it feels like a victory.

Between Wind and Error Messages

Working on the road had its own rhythm.

Some mornings began with a view of the lake. If the wind was right, we'd head out on the water. Then back to Liesl, open the laptop, start the server and carry on.

Other days, the surf gear stayed packed because a problem needed solving.

Sometimes I thought I'd just quickly check something.

Three hours later I was still at it.

There were days when the campsite around me gradually slipped into evening while I was working through booking logic, price calculations or payment flows.

It was an unusual mix.

Outside, holiday.

Inside, development.

Outside, people with bicycles, swimwear and barbecues.

Inside, error messages, databases and test bookings.

And yet it felt right.

Perhaps precisely because of that.

From an App to a Platform

Over time, the original idea grew into a comprehensive system.

An application for riders took shape.

A dedicated interface for drivers.

An administration area.

Then came companies, documents, invoices, payment flows, vouchers, notifications, location tracking, pricing logic and many other areas.

Every new feature brought new questions.

What does a rider see?

What information does a driver need?

What needs to be traceable in the admin area?

What happens with a cancellation?

How do card payment and cash payment differ?

How is a voucher calculated?

What happens when a ride has multiple stops?

The further development progressed, the clearer it became: the real work is not in getting a feature to work somehow.

It lies in making it work reliably.

For everyone involved.

In every intended flow.

And ideally even when someone does something nobody anticipated.

Conversations, Changes and New Ideas

FLINTAXI didn't come together alone in front of my screen.

Many solutions only took shape in conversations with Sima.

We discussed workflows, changed terminology, discarded ideas and rebuilt others from scratch. Things that sounded good in theory sometimes turned out to be too complicated in practice.

Then we started again.

That's part of it.

Good software doesn't come from clinging to an early idea. It comes from being willing to look more carefully.

Sometimes that also meant changing parts that were already finished.

That can be painful.

Especially when many hours of work are invested in them.

But in the end it doesn't matter how long something took to build.

What matters is whether it works for the people who will use it.

The Hardening Phase

The closer go-live approached, the less it was about new features.

The big question was no longer:

What else could we add?

But:

What could still go wrong?

We tested booking flows, payments, price calculations and user interfaces. Riders, drivers and administration had to see the same values. Vouchers had to be applied correctly. Surcharges had to be transparent. Cash payments couldn't behave differently than expected.

Some bugs were obvious.

Others hid deep in flows that looked completely correct at first glance.

Those are the ones that cost time.

They only appear when several conditions occur simultaneously. They can't always be reproduced immediately. And sometimes they disappear during testing, only to return later.

This phase teaches humility.

At some point you stop believing something works just because it worked once.

You test again.

And again.

No New Toys

Shortly before launch, the moment almost inevitably arrives when new ideas appear.

That's understandable.

When a product becomes more visible, you see more and more possibilities. Something could be added here. An extra feature would be useful there. Surely one small change is still possible.

But just before a go-live, "small" is a dangerous word.

Every change can have new consequences. Every new feature needs to be tested. Every intervention can alter something elsewhere.

So the decision was clear:

No new features.

The current state should go live stably.

Only fix remaining bugs, secure flows and prepare the platform for real operation.

Sometimes good development isn't about building more and more.

Sometimes it's about stopping at the right moment.

Just Before Go-Live

As I write these lines, FLINTAXI is on the verge of launching.

From a sentence in a newspaper article, a platform has emerged.

From a first message, a collaboration has grown.

From an afternoon in Podersdorf came months of conversations, decisions, code, tests and long evenings.

When I look at the project today, I see more than features and databases.

I see Liesl at the campsite.

I see the table where the laptop stood.

I see Marion beside me while I "quickly" wanted to finish something.

I see Sima and her friend in Podersdorf, that pleasant afternoon and the moment we signed the contract.

I see error messages that nearly drove me to despair.

And I see the small moments when everything suddenly worked.

More Than Code

I'm proud of what has come to be.

Not because every line of code is perfect.

Not because development always went in a straight line.

And not because there were no difficult days.

I'm proud because an idea has become something tangible.

Because a dream has turned into a system that real people will soon use.

Software appears from the outside as pages, buttons and features.

But behind them, projects like this one are made of trust, patience, decisions, doubts, perseverance and very many hours that nobody will ever see.

Perhaps that's as it should be.

Because in the end, nobody should need to think about how many evenings were required for a booking to work.

It should simply work.

The Beginning of a New Chapter

With go-live, development doesn't end.

But something changes.

Until now, we have been building FLINTAXI.

Soon, people will be experiencing FLINTAXI.

Riders will book rides.

Drivers will accept those rides.

Encounters will happen, experiences will be gathered and stories will be written that we don't yet know.

Perhaps those very stories will appear here on the blog in the future.

Stories from riders.

Stories from drivers.

Stories about special journeys and personal moments.

And occasionally perhaps stories from the technology behind it all.

About a feature that refused to work at first.

About a problem that was only solved late at night.

Or about a developer sitting somewhere at a campsite in his Liesl, listening to the wind outside and running one last test.

Because FLINTAXI didn't emerge from code alone.

It emerged from people.

And right now begins the part of the story we've been working towards for so long.