I built a restaurant app nobody used. It's why PMFtracker exists.

It was 2015. I was finishing my degree in Wroclaw, working part-time at McKinsey, and running a student club on the side. Like a lot of people who eventually start companies, I'd always been eager to build something of my own. So when a friend and I landed on an idea, a membership app connecting busy professionals with restaurant concierge perks, priority reservations, exclusive deals, we didn't waste time thinking it over.

We hired a software house. We built the platform. We signed more than ten restaurant and bar partners across the city. On paper, we were doing everything right: shipping fast, closing partnerships, moving quickly.

And then almost nobody used it.

We hadn't validated a single assumption before writing the first line of code. We didn't know if entrepreneurs and corporate employees actually wanted a concierge app for restaurant deals. We just believed they would, the same way every founder believes their idea before they've tested it. A few months in, with a growing list of unused partnerships and some co-founder friction on top, we shut it down.

Here's the part that actually matters. Eminatio was small and the failure was quiet. Nobody wrote a post-mortem about it. But the exact same mistake happens to organizations of every size, from first-time founders to funded startups to corporate innovation teams, and it happens constantly.

What I skipped, and what almost every failed product skips

I didn't talk to a single target user before we started building. I didn't test the idea. I didn't run one experiment. I had an idea, found a co-founder, and we started building, because building felt like progress and talking to people felt like a delay.

That's the trap. It doesn't feel like risk while you're inside it. It feels like momentum. Every week you ship something is a week that looks like proof you're moving in the right direction, right up until the moment you find out the direction was wrong the whole time.

What we skipped has a name now, though I didn't know it then: validating demand before you build, not after. We never even got as far as problem-solution fit. We went straight from an idea we liked to a live product, and the market simply didn't answer.

The data behind what it cost us

I didn't have this number in 2015, but Nielsen Norman Group later put hard evidence behind exactly what we skipped. In a study of UX projects, teams that performed real discovery work before building saw dramatically better outcomes than teams that didn't.

Read that twice. That's not a marginal effect. That's the difference between a coin flip and a stacked deck, and which way the deck is stacked depends entirely on whether you do the unglamorous work first.

Why "no market need" isn't a rare disease

If you've read why 42% of startups fail this exact way, you already know the CB Insights numbers. What I can add is what it looks like from the inside, because I lived it before I ever wrote about it. It doesn't feel like failure while you're building. It feels like progress, right up until the users don't show up.

The pattern is always the same. An idea feels obviously good to the people who thought of it. Building feels more productive than interviewing. Signing partners feels like traction. None of those things are evidence that anyone wants what you're building. They're just activity, and activity is not the same thing as demand.

What I'd do differently, and what I built instead

In the years after Eminatio, I went on to lead product and run discovery work for a string of startups, and I kept seeing the same story repeat: teams shipping fast, skipping validation, finding out the hard way. By the time I started training founders on this directly, I'd watched it happen enough times to know it wasn't bad luck. It was a missing step, the same one, over and over.

Three things I'd do differently, and that I now tell every founder I work with:

• Talk to the actual people before you build. Not your co-founder, not your friends who'll be polite. The people who'd actually pay for it.
• Treat the idea as a hypothesis, not a plan. Decide upfront what evidence would prove you wrong, then go look for it.
• Measure demand directly, don't infer it. Partnerships, signups, and press are activity. The only real signal is whether people would be genuinely upset to lose what you built.

That third one is the whole reason PMFtracker exists. I don't want any founder to find out the way I did, at month three, with a list of unused partnerships and a co-founder relationship in tatters. I want you to find out in weeks, with an actual number, while there's still runway left to act on it.

The one thing worth taking from this

Building was never the bottleneck, not in 2015 and not now that it's gotten dramatically cheaper. Knowing what to build always was. Eminatio didn't fail because we built badly. It failed because we built the wrong thing quickly and confidently, which is somehow worse than building it slowly.

If there's one number I wish I'd had before we started, it's the one Sean Ellis eventually gave the world: the share of your engaged users who'd be genuinely disappointed to lose you. Not a survey you run once out of curiosity. A number you track, the way you'd track revenue, because it tells you the truth before the market tells you the hard way.