Throwing away four months of my own work — and why it was right

Three attempts, two of them in the bin

October 2025. A first skeleton for an app. Then it was left lying.

February to March 2026. A real app called pongPartner. It kept score and had first tournament features. It also had a worked-out concept for how someone plays without an account and later takes their results into a real one. That was far enough to carry on.

June 2026. Instead of carrying on, I wrote six documents. What is there? What exists on the market? Where should it go? What must it do? How is it built? In what order?

What the analysis showed

Two findings turned the direction around.

First: apps that only keep score do not get far. Comparable apps have a few hundred downloads at most. That is not down to poor execution. You need an app like that once a year at a party, and then it gets deleted.

Second: what people need is help running a tournament. Whoever runs a tournament has a real problem that keeps coming back. Twenty people, a schedule, and someone is always asking for the score. Keeping score brings people back. It is not a product on its own.

That became the sentence that determined everything after it:

“The tournament runs itself, and nobody has to install anything.”

Why that sentence ruled out the app

The core is the shared link. A participant gets a message, taps it and is in the tournament. They download nothing and create no account. A spectator opens the same address on the TV in the room.

On the web that is a given. With an app it does not work without a hurdle. And every hurdle puts off exactly the people you want to reach.

That made the decision no longer a matter of taste. My written reasoning also lists the costs. In essence: around 90 files of the app are discarded. But the interface would have had to be redone anyway. There were no automated tests. And the part that calculates a tournament had to be rewritten in any case.

That list is what matters. It does not say “the old one was bad”. It states soberly what is lost. And that the larger part of the work would have come up anyway.

What survived from the predecessor

Not the program, but the thinking behind it. How the data is structured. Which rules apply in the game. And above all the way a player creates an account later and keeps their earlier matches. That was fully thought through in the old app. I carried it over unchanged.

So four months of work did not vanish. Only the execution vanished. That is the part that comes back fastest once the plan stands.

How the new platform is built

The part that calculates a tournament is separate from the rest. Only there can a bug destroy a running tournament. So that part is tested especially thoroughly and automatically.

To begin with, nobody may access the data. Every access has to be allowed one by one. That way nothing stays open by accident.

German and English have been equal from the start.

For the technically minded: the technology behind it

Next.js 16 with React 19 and TypeScript, Supabase (Postgres, Auth, Realtime). The tournament logic lives in its own package with no runtime dependencies and coverage thresholds enforced in the configuration. Database access is denied by default through row level security, writes that touch several rules go through functions with fixed privileges. Runs in Docker behind Caddy with automatic TLS, deployed through GitHub Actions. The predecessor was a Flutter app with 52 commits.

Why this is here

This report has the weakest user numbers of any on this site. It is still the one that matters most to me.

Clients rarely buy a finished feature. They buy someone who notices when the path does not lead to the goal. And who says so before the money is spent. I made this decision against my own work and wrote it down. Against someone else’s plan it comes easier.