METHOD
More than 50% of startups fail. Not from bad ideas, but because they build them before validating them. Vibe Lab is our way of doing the opposite.
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.
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.
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.
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.
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.
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.
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.
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.
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.
AI ENTERPRISE
YoDa Health is our vertical AI Receptionist for private healthcare. Four months of operation, real numbers, what works and what doesn't when AI meets real users — not lab users.
Read the article →FLEET MANAGEMENT
Provisioning, drift, asymmetric routing, mass rollouts. Four years of lessons from the field, condensed for ISPs, WISPs and MSPs who still configure routers "by hand".
Read the article →About one article every two weeks. No spam, no fluff.
