Why we build the signal first, then the product

The statistic has been going around for years: more than 50% of startups fail in their first three years. Half of these fail for the same reason: "market need". They built a product nobody needed. Not because the idea was stupid — almost never is — but because they chose to build first and ask the market later. By the time the market answers, it is too late.

Vibe Lab is how evoseed builds its internal startups, and the service we use to help external founders do the same. It is grounded on a boring but effective principle: first measure the signal, then build the product. In that order, on purpose.

The early-code trap

A technical founder has a natural temptation: the idea becomes code in three days. Code does things. Things can be shown. The feeling of progress is immediate. The problem is that perceived progress is not real progress: you are piling up a codebase around a hypothesis you have not tested yet. The more the codebase grows, the more expensive a pivot becomes. The more expensive a pivot becomes, the less you want to hear that the market says no.

OptiWize, our first product, is a textbook case. When we started — over four years ago now — the first version was a monolithic Python script. It configured five MikroTik types. It was ugly, slow, and worked. That code died after six months: we had built it around the cases we thought were important. When we started running the system with real users (one kind NOC), we discovered the cases that mattered were others. Three of the five templates ended up in the trash. We added twelve new ones.

The Vibe Lab framework in 5 steps

Step 1: idea → market hypothesis (1 week)

We write no code in this phase. We define the hypothesis we want to test so that it is falsifiable: a concrete claim about a concrete market. No "we want to improve customer experience". Yes "NOC operators at small Italian ISPs spend at least 10 hours per week on tier-1 MikroTik troubleshooting and would pay 200 euros/month to cut that time in half". The hypothesis is specific, measurable, and — most importantly — can be proven wrong.

Step 2: signal test (1-2 weeks)

Here we use pretotyping in Alberto Savoia's classic sense: before the prototype, build a tool that measures whether interest is real. A landing page with "book a call" CTA. A LinkedIn campaign with a clear offer. A sequence of personalised outreach to 50 ICP contacts. The signal is binary: either people bother (book, reply, click, talk) or they don't. If no, the hypothesis is wrong and we go back to Step 1 — without having written code.

Step 3: focused MVP (4-8 weeks)

Only at this point do we write code. The term MVP is abused: to us, it means the smallest possible version that delivers real value to the 5+ users who said yes. No accounts, no settings, no dashboard before the value. If the value is "cut troubleshooting time", the MVP is a tool that cuts troubleshooting time, even if it runs over SSH and has three commands. No frills.

Step 4: real market (2-4 weeks)

The MVP runs with the first real users. We measure three things: do they actually use the product, how often, and what happens when they stop. Qualitative interviews here are gold. A question we always ask: "if we disappeared tomorrow, what would you do?". The answer "I'd go back to doing it all by hand" is worth ten times "I'd find an alternative". The first is potential product-market fit; the second is commodity.

Step 5: decision (1 week)

Three explicit options. Scale: increase investment, add team, set up serious GTM. Stop: the PMF metric is not there, and no reasonable adjustment will move it. Spin-off: there is value but not for us — the product goes to another team, open-sourced, or sold. The point is that the decision is explicit, dated, and based on numbers we agreed upon at the start.

Concrete case: how OptiWize became ARIA

ARIA, our AI NOC Engineer, started as an internal spin-off of OptiWize. The question was: is it worth building a conversational interface on top of OptiWize's template engine, or should we stick to dashboards and APIs? The hypothesis was specific: the NOCs of our customers spend at least 40% of their time on operations that map to 20 troubleshooting macro-patterns, and a conversational interface can cut that time by 70%.

Signal test: we showed a live mockup to the NOCs of three customers, in interviews guided by a script. All three asked "when can I have it?". Two of the three offered to join a paid pilot programme immediately. That signal is what unlocked the 4-month development investment. If it hadn't come, we would not have built ARIA — or we would have built it very differently.

MVP built in 6 weeks. Template-driven agentic architecture with a playbook catalogue. No fancy UI, just a chat. Run for 8 weeks with the pilot NOCs. Result: mean first-diagnosis time down from 47 to under 5 minutes for the cases covered. The final-step decision was easy: scale. Today ARIA is a separate product (runaria.ai), with its own team, pricing and commercial pipeline.

Five questions we ask at the start of every Vibe Lab

1. Who exactly is the user? Not "companies", not "CIOs". A real person, in a real context, with a hypothetical name and a typical calendar. If you can't describe them in two lines, the hypothesis is too abstract.
2. What do they do today instead of you? Every new idea competes with a status quo. Understanding the status quo is understanding why someone should change. If the answer is "nothing, they don't have this problem", you may be in the wrong place.
3. What is the binary signal that will test the hypothesis? Not "we will gauge interest". Yes "if at least 5 out of 50 people book a call within 10 days, it is a yes". Agree the number upfront, before starting. It is hard to gaslight your own numbers when they are written on a dated Notion page.
4. How much are you willing to lose? Vibe Lab is an investment. If it is 8 weeks of a part-time founder, fine. If it is a 500k seed round, fine. What doesn't work is not knowing. The answer must be a number, stated upfront.
5. What triggers the stop? Define kill criteria before you start. "If at 4 weeks we don't have 5 real interviews, we stop." Without kill criteria, the hypothesis dies slowly by inertia — the worst kind of death.

Who it is for (and who it is not for)

Vibe Lab works best for those with an idea, a specific hypothesis and a bounded time budget. It doesn't work for those who want to "validate in general whether my idea makes sense": it's an attitude that would burn four weeks talking about everything and nothing. It also doesn't work for those who have already written 30,000 lines of code: at that point the sunk cost is too high to apply the framework honestly.

It works very well for: technical founders with intuition on a vertical sector who want to test it, internal teams of mid-market companies that want to validate a new product/feature before committing 6 months of development, managers with limited budgets and a specific vision. For them, we built Vibe Lab.

If you recognise yourself, the first call is an assessment, lasts 45 minutes, is free, and we leave with a concrete direction — even if we don't end up working together.