The starting problem
The founder had a strong background in operations consulting. He had identified a gap in the market for a B2B marketplace connecting specialist contractors with mid-sized logistics businesses. The problem was real — he had validated it through years of his own consulting work. The potential customers existed. The market was underserved.
He had assembled a team of four: a lead developer, a product designer, a junior developer, and himself operating as product owner. They had been building for twenty-two months.
The product had approximately sixty per cent of what had been scoped. It did not have a single paying customer. It had three "pilot" users who had been on the platform since month eight, none of whom had paid anything and one of whom had not logged in for four months.
The founder reached out after a board meeting where the question of whether to continue had been raised explicitly. The board's position: if there are no paying customers in ninety days, the plug gets pulled.
My role
I came in as SaaS coach. The founder's instinct was that the problem was technical — the product was not ready. My job was to test that assumption.
I spent the first two weeks doing three things: reviewing the product, reviewing the roadmap, and talking to the three pilot users about what they actually needed.
What the audit found
The product itself was functional. It was not sixty per cent complete in the sense of being unusable — it was sixty per cent complete in the sense that sixty per cent of the original roadmap had been built. The core marketplace loop — contractor lists a service, logistics company discovers and contacts them, agreement is reached — worked end to end.
The remaining forty per cent of the roadmap was a mix of reporting dashboards, a messaging system with read receipts and threading, a review and rating module, an enterprise SSO integration, a mobile application, and an analytics module for contractors.
None of the three pilot users had asked for any of these features. When I asked the pilot users what would make them willing to pay, the answers were: faster search results, a clearer way to see contractor availability, and pricing transparency on the contractor side. Three small improvements to the core loop.
The real problem was not technical completeness. It was that the team had been optimising for a feature roadmap rather than for a paying customer. The roadmap had been defined at the start of the project, before any real user data existed. It had barely changed in twenty-two months.
The decisions
The first decision was to freeze the roadmap. Completely. Nothing new would be built until there was a paying customer. This was not popular with the development team, but it was non-negotiable.
The second decision was to cut scope. We ran a formal scope audit: every feature in the backlog was evaluated against one question — "does a paying customer need this to get value from the core product?" If the answer was not clearly yes, it was moved to a separate "post-revenue" backlog. This removed approximately forty per cent of the remaining planned work from active scope.
The third decision was the hardest one: the three improvements the pilot users had mentioned — search speed, availability display, and pricing transparency — would be built in two weeks, and then the founder would personally ask each of the three pilots to pay.
The fourth decision was to stop calling them pilots. A pilot is a way of giving someone the product for free while implying that payment comes later. It had been twenty-two months. The founder had to have the pricing conversation.
The outcome
The three improvements were shipped in twelve days. The founder had the pricing conversations in week three.
Two of the three pilots converted to paid accounts. The third declined — they had internally built a workaround over the previous four months and no longer had an immediate need. That information alone was valuable.
By the end of month three, the platform had seven paying customers at an average of £380 per month. MRR was approximately £2,660.
The board meeting at the ninety-day mark was a very different conversation.
The founder lesson
There are two traps that technically-minded founders and founding teams fall into. The first is building for an imagined user rather than a real one. The second is using building as a way of avoiding the discomfort of selling.
This founder was doing both. He genuinely believed the product was not ready. But "not ready" had been the answer for twenty-two months. At some point, "not ready" becomes a belief that protects you from finding out whether the product will actually sell.
A SaaS coach's job in this situation is not to validate the founder's assessment. It is to ask the question that has not been asked: what would it take for a user to pay? Then build exactly that. Not the roadmap. Not the vision. The minimum that earns the first payment.
The other lesson: pilots are a mechanism for learning, not a mechanism for building a customer base. If you have been running pilots for more than three months without a conversion conversation, the pilot is not a pilot anymore. It is a way of avoiding a no.