When a user pays us, it feels like a breakthrough. We’ve validated our MVP. We’re onto something real. Except… maybe not.
In early product development, revenue is often treated as the gold standard for validation. It’s easy to see a Stripe notification and assume we’ve crossed a meaningful threshold. It might feel like it’s time to go all in, hire, and raise. But money, especially in the early stages, is a noisy signal. It can mask deeper flaws in the model and lull us into a false sense of product-market fit. I learned this the hard way.
Mistaking Early Traction for a Business Model
My first startup was called Domainsmith. It was designed to help brand designers and entrepreneurs discover unique, high-quality domain names.
We launched with a Concierge MVP. I built custom scripts to generate ideas and ran live naming sessions with over 100 users, guiding them through the process by hand. Eventually, some of them began paying ¥10,000 (around £55) for the experience. It felt like early traction. Users told us existing tools like ChatGPT were too generic or repetitive, and our approach felt refreshingly tailored. We were solving a real problem.
Based on that feedback, we built a platform MVP that curated polished, brandable domains and offered them on a subscription. We had finally got paying users for the concierge MVP and clear signals that we were doing something different from the rest of the market. But beneath that surface was a deeper issue. Most users only needed a domain once. Our early adopters were solo founders and first-time creators, and once they had their name, they had no reason to come back. It was also hard to find new users and wasn’t clear if enough people had the same problem and were willing to pay for it.
We had validated that at least some people were willing to pay for help with naming for a brand. What we hadn’t validated was the size of the market and whether they needed that help often enough to support our business. The pain was clear, but the frequency was very low. We explored ways to create more ongoing value, such as becoming a domain registrar and handling renewals. But that path was out of reach given the cost, complexity, and regulatory barriers and didn’t solve the problem of finding new users. I took those early payments as a signal to move forward with the product. In hindsight, we had only proven that there was some demand for a one-time service. We had not shown that there was a sustainable business behind it.
What Early Revenue Really Tells You
Early payments can feel like a breakthrough. After so much uncertainty, someone is finally willing to pay. But I’ve learned that revenue on its own doesn’t mean we’ve found a business. It only shows that we solved a problem once.
It was easy to think early traction via concierge MVP meant we were ready to move forward. What it really meant was that we had solved a single-use problem. That matters, but it was not the same as validating a repeatable business.
Early revenue should lead to better questions:
- How often does this problem occur?
- Who experiences it repeatedly?
- What does the journey look like after the first payment?
- How many potential customers are out there?
- How realistic is it to make £10K MRR in 6 months?
Until those answers are clear, early revenue is just that: early.
The Limits of Early Support
Early revenue can be deceptive, not because it’s unimportant, but because it often comes from a small, non-representative group: friends, early adopters, and the startup-curious. Their willingness to pay doesn’t always map to future behaviour. We might be testing generosity, not demand.
I saw the same pattern again with a venue-booking platform I co-founded at Falmouth University’s incubator. We built a working MVP in 24 hours and quickly onboarded listings. Early bookings rolled in. It felt like another win. But many of those bookings came from friends who were experienced event organisers. Their support was helpful, but short-lived. They used the product once, gave feedback, and moved on.
These organisers weren’t struggling to find venues. Their real challenge was managing logistics more broadly, including catering, ticketing, vendor coordination, equipment, and scheduling. Our platform solved only one small part of that workflow. It wasn’t useful enough on its own to become part of their process.
Revenue is not a binary signal. It matters why someone paid, what problem they believed they were solving, and whether they would pay again without personal involvement or goodwill propping things up.
Think Like a Developer: Atomic Validation
Just as developers commit code atomically in small, testable units, I’ve found product ideas can also be developed in the same way.
Every shift in the experience, delivery model, or pricing approach can be a separate experiment. Move from manual to automated? Test it. Switch from a service to a product? Validate it. Change the customer type? Re-test the assumptions. It’s so tempting to try to leap straight into a big, scalable product. But validation is complicated, and it’s easy to draw the wrong conclusions from early success.
Each step in the journey can break what worked in the last one. What solves a niche user’s problem might not work for a mainstream audience. What’s profitable with ten users might fail at 1,000. Every assumption is up for revalidation.
Keep Validating, Always
Whether we’re testing the market with a Wizard-of-Oz prototype, stringing together no-code tools, or delivering services by hand, early revenue is just a signal. Money is important, but only if we understand what it means. And only if it keeps showing up when the magic curtain comes down.
The real startup magic isn’t building a product that people have paid for once. It’s building something that continues to deliver real value and keeps users paying as the business evolves.
Updated 16th July 2025
