Products We Shipped: How Many Failed, Why, and the Boring Middle

Founders keep asking us for benchmarks. Here is the honest aggregate from Wavect's engagement history: roughly 10-15% of products we shipped scaled, about 50-60% landed in the boring middle (kept revenue, never broke out), around 20-25% were sunset within 18 months of launch, and roughly 5-10% never reached MVP. None of those numbers are unique to us. They are close to what every honest builder reports. Plan for the middle.

Exact counts are approximate. We treat each engagement as one product, even when we shipped multiple iterations. The distribution is what matters, not the headcount.

What does the outcome distribution actually look like?

Here is the rough breakdown across products Wavect has shipped for founders and operators since 2020. Bands, not exact counts, because outcomes shift over the years (a product steady today can scale next quarter, a scaler can crash).

The takeaway is not the 10-15% scaler band. The takeaway is the 50-60% boring middle. Most founders aim for the scaler outcome and budget as if the middle does not exist. That is how a healthy product gets shut down for not being VC-shaped.

Why the boring middle is the realistic plan

The boring middle is not failure. It is the default outcome for a competently shipped product in a real market. Founders who pre-plan for it (own equity, modest burn, distribution that fits the size of the business) keep their company. Founders who plan only for the scaler outcome get caught when month 14 arrives and the curve is linear, not exponential.

We have seen both. The ones who survived the boring middle were the ones who kept burn under monthly revenue from month 6 or 9 onwards, regardless of what the deck said.

"The boring middle is not a failure outcome. It is the outcome you build for, so the scaler outcome is the upside instead of the only survival path."

Why do shipped products actually fail?

Across the 20-25% that we shipped then sunset, the reasons cluster into six or seven recurring failure modes. Almost never is the cause "the code was bad". The code shipped. The product shipped. Something else broke.

1. No PMF. The market was smaller than the deck, or the willingness to pay was lower, or the alternative (spreadsheet, status quo, free tool) was good enough. Most common single cause.
2. Founder bandwidth collapsed. Solo founder, day job, second child, divorce, health. The product needs an owner full-time, and there is no owner full-time anymore.
3. Wrong distribution channel. Built a B2B SaaS, then tried to sell it via paid ads. Built a consumer app, then tried to sell via enterprise sales. The product was fine, the GTM was wrong.
4. Regulatory blow-up. Crypto, fintech, health. Rules changed (or were enforced) mid-build or post-launch. We have seen this in Web3 specifically, and in a couple of fintech adjacent products.
5. Capital ran out. Bridge round did not close. Cash zero before revenue. This is what happened with our case study Hyperstate AI: shipped, ran out of funding after launch, not a product or tech failure. The product was live and working.
6. Scope explosion. Built version 1, then version 2 ballooned. The product fragmented across too many user personas and verticals. By month 12, no single user segment was happy.
7. Co-founder split. Two founders, disagreement, equity dispute, one walks. Product stalls, then sunsets.
8. Wrong founder-market fit. The founder lost interest. Not a moral failure, just an honest one. Products without an obsessed owner die.

We have built products that hit several of these. Offlinery is a product in the middle of finding its segment. Scramble Pay and LivLive shipped and continue to operate. We have shipped real Web3 products through real cycles. Some are still running, some are not. The pattern above is what we see.

What does Wavect actually control?

Honest answer: code quality, ship velocity, architecture choices, SDLC discipline. That is roughly 30-40% of the outcome on a generous reading. Everything else (market, founder, capital, distribution, regulation, timing) is outside the engineering scope.

We tell every founder this in discovery. We can build the product right. We cannot make the market exist. When the market is borderline, we say so. Sometimes we still build it because the founder wants to find out, and that is fair. Just go in with eyes open.

How should founders use this benchmark?

• Budget for the boring middle. Plan a path where the company survives at modest revenue without follow-on capital. If you cannot, the product is fragile by design.
• Treat regulatory and capital risk as primary. Not secondary. They sunset more products than tech does.
• Decide who owns the product after launch. Day 1 of post-launch is when most products die quietly. Ownership is not just code, it is roadmap, support, distribution, retention.
• Be skeptical of agencies who only show scaler case studies. Anyone with a real portfolio has shipped products that died. If they will not show you the middle and the failures, the portfolio is curated, not honest.
• Consider a fractional cofounder or fractional CTO for the first 12-18 months. Cheaper than a wrong hire, faster than building an internal engineering org for an unproven product.

Does this distribution match the rest of the industry?

Roughly, yes. Industry-wide startup mortality numbers (CB Insights, Y Combinator alumni data, regional accelerator reports) cluster in similar bands. The big differences are filter (accelerators see fewer "never shipped" because they vet at entry) and survivorship (older datasets miss the products that sunset 18 months in). Our numbers are not better than the industry. They are not meaningfully worse either. They are what shipping software in a real market looks like.