rabblepop.
Work / docuweave

What it cost to find out the market wasn’t there

A document-generation SaaS, taken from idea to a working, launched product. It didn’t find its market. This is what happened, and what we’d do differently.

Client
docuweave
Sector
SaaS · document automation
What we did
Product discovery · full-stack build · subscription billing · launch
Shape
Idea → build → launch → wind-down
Status
Shipped. Wound down.

The product was good. That was never the problem.

The build went well. It shipped, it worked, it did what it said. The subscription flow worked, the editor worked, the output was genuinely useful to the handful of people who used it properly.

What it never established was that enough people had the problem badly enough to change their behaviour and pay for a solution. We validated that the thing could be built long before we validated that it should be.

What went wrong

Honestly
  • We built the whole thing before testing the premiseThe riskiest assumption was commercial, not technical — and we spent the budget on the technical half.
  • “Would you use this?” is not evidenceEveryone says yes. The only real signal is whether someone changes what they currently do, and we didn’t test for that.
  • The problem was real but not painful enoughPeople had a workaround. It was worse than our product and it was already paid for, which is a very hard thing to displace.
  • We polished before we provedEffort went into subscription tiers and edge cases at a stage when the only question that mattered was whether anyone would come back a second time.

Why we publish this one.

Why this is on the site

This is the case study we point at when someone asks why we charge for scoping and why we start by trying to make the first build smaller. It is an expensive lesson, and it is one we would rather you had for the price of a sprint than the price of a product.

The results

Outcomes

The real risk

Naming the riskiest assumption out loud would have shown it was demand, not delivery — and demand is testable in two weeks.

The smaller cut

A tenth of the product, put in front of twenty real users, would have answered the question for a fraction of the cost.

The stopping rule

Agreeing in advance what “this isn’t working” looks like is the difference between learning cheaply and learning slowly.

Who built it

Credits
Product & build
Zeki Mirza
Back toAll workNext case studyBeyondCars
rabblepop.What we doHow we scopeWorkLabWritingAboutFAQContactLondon · © 2026