How I Killed Three App Ideas Before Building Tick Tock Tracker

Most app ideas die slowly and expensively. They get built first and questioned later. I wanted the opposite: question hard, kill fast, and only build the one idea that survived. Before I committed a single line to Tick Tock Tracker, I ran three other ideas through the same gauntlet — and put all three in the ground.

Here's the framework I used, and why the watch idea was the one left standing.

The four questions every idea had to survive

I didn't trust my own excitement. Excitement is the cheapest thing a founder owns. Instead, each idea had to pass four questions, in order — and failing any one was fatal.

1. Is the pain real, recurring, and already costing someone money or time? Not "would be nice." A real, repeated, expensive problem.
2. Is the value I create leak-resistant? If I build it, can the customer extract the value once and then walk? Or do they need to keep coming back?
3. Does it get more valuable as it's used, not less? The best products compound. Every use should make the next use better — or make leaving harder.
4. Can I be the one to build and defend it? Domain knowledge, an unfair advantage, or a moat I can actually dig.

A good idea doesn't barely pass. It passes loudly.

The three I killed

Idea one — a scheduling tool for a service trade. Real pain, recurring, money on the line. It sailed through question one. Then it hit question two and sank: the value leaked. People would set up their schedule once and never need me again. No reason to return, nothing compounding. A feature, not a business.

Idea two — a marketplace. Marketplaces are seductive because the pain is obvious. But it failed question four. I had no unfair way to solve the cold-start problem — no existing audience, no supply advantage. A marketplace with no edge is just a very expensive way to learn about liquidity.

Idea three — a "tracker" with no memory. It logged things, then forgot them. Failed question three: it got less useful over time, not more. Once you'd logged the thing, the log was dead weight.

Three ideas, three clean kills. That sounds like failure. It was the opposite — it was three expensive mistakes I got to skip.

Why the watch idea survived all four

Then I looked at watches — at the gap between a watchmaker's bench and a collector's shelf — and ran the same gauntlet.

• Real, recurring, expensive pain? Yes. Watchmakers run on paper tickets and sticky notes; collectors have no trustworthy record of what they own, what it's worth, or what's been done to it. Both bleed time and money.
• Leak-resistant? Yes — the value lives in an accumulating record, not a one-time setup. You can't extract a watch's service history once and walk; the record only matters because it keeps growing.
• More valuable as it's used? Emphatically. Every signed service entry makes a watch's service history more complete, its provenance more provable, and its resale and insurance documentation stronger. The record compounds.
• Can I build and defend it? Yes — because the moat isn't the software. It's the verifiable, tamper-proof passport that travels with the watch, signed by the people who actually work on it. That's a record nobody else has, and it gets deeper every day the app is used.

That last point is the whole thing. A watch with a Tick Tock Tracker passport is worth more and easier to trust — and the proof can't be faked. The longer the app runs, the more valuable that record becomes, and the harder it is to replicate.

The takeaway

You don't need a fancy process to validate an idea. You need a few brutal questions and the discipline to actually act on the answers. Kill the weak ones early — they're far cheaper to kill than to build.

The watch idea was the only one that passed loudly. So I built it.

If you collect — or repair — watches, see what a verifiable service passport looks like. It's free to start.