Most first-time founders, including me, start with a revenue model that looks clean on a spreadsheet and falls apart on contact with actual customers.
I am going to write honestly about the revenue model I am building — not the polished version I would present to an investor, but the working version with all its rough edges and the history of how I arrived at it. I think founders talk too much about their business models in the abstract and not enough about the specific failures that taught them what actually works.
My first model and why it failed
My original revenue model was a subscription. Monthly recurring revenue, three tiers, clean pricing page. I spent nearly three weeks designing the pricing architecture before I had a single serious conversation with a potential paying customer about whether they would actually pay.
This is a classic mistake, and I made it in full knowledge that it was a classic mistake. I told myself I would test the pricing assumptions quickly. I did not test them quickly enough.
When I did finally start asking founders directly — will you pay £49 a month for this? — the answer I got back was almost universally some version of: I would pay for it, but not every month. The explanation was consistent: founders in the pre-revenue stage manage their spending in project mode, not subscription mode. They are intensely active for a period of weeks or months, then they need to step back and focus on building or selling. A subscription that continues charging during the quiet periods felt like a penalty for not being constantly active.
I tried repositioning the subscription as low-commitment. I added a pause feature. I reduced the price. None of it addressed the fundamental issue, which was that the mental model of a subscription was wrong for this customer at this stage. The product was not a utility they used daily. It was a tool they reached for at specific moments of decision-making intensity.
My second model and what it revealed
I pivoted to a project-based model — a flat fee per validation project with no ongoing commitment. You pay when you run an analysis, you do not pay when you are not using it. This felt much more aligned with how founders actually used the product.
It worked better. Conversion improved significantly. But it created a new problem: the revenue was entirely unpredictable, and the unit economics were difficult to model at scale. A founder might run three validation projects in a month and then nothing for six weeks. For the customer, this was perfect. For the business, it was challenging.
The project model also revealed something important about customer behaviour that the subscription model had obscured: when founders paid per project, they thought very carefully about whether a given question was worth running through the full validation process. Some of the questions they chose not to analyse because of cost were exactly the questions that most needed rigorous examination. The cost of analysis was creating a selection bias toward the questions founders were already relatively comfortable with.
The model I am building toward
After working through both failures, I landed on a credits-based model with an optional low-cost base subscription.
Credits are consumed when founders run specific analyses — not time-based, but action-based. You buy a bundle of credits and use them when you have real work to do. The cost per credit is low enough that cost is not a barrier to running the analyses that matter most. But there is still a cost signal that encourages intentionality rather than treating the tool as a toy.
The optional base subscription is a small monthly fee — low enough not to feel like a burden even during quiet periods — that keeps founders connected to the platform, gives them access to their historical analysis data, and provides a small credit allocation each month so they always have some capacity without needing to make a purchasing decision.
This model is harder to explain on a pitch deck than a clean monthly SaaS subscription. It requires more sophisticated billing infrastructure. The revenue forecasting is more complex. But it matches the actual usage pattern and the actual psychology of the customer, which ultimately matters more than elegance in a spreadsheet.
The thing I am still figuring out
The credit pricing is still not right. I have the right model but not the right parameters. The questions I am actively working through are: at what credit price does the friction-to-usage ratio feel appropriate? How large should the base subscription credit allocation be to meaningfully reduce purchasing decisions without cannibalising the upside? How do I handle teams — is it credits per seat or credits per organisation?
I will write about this again when I have better answers. The honest version of a business model is always a work in progress.