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—that now it’s time to scale, hire, or 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.
Domainsmith: A Signal Without a System
My first startup was Domainsmith—a tool to help brand designers and entrepreneurs find unique domain names.
We started with a Concierge MVP. I wrote custom scripts to generate ideas and ran live workshops with over 100 users, manually guiding them through the naming process. Eventually, some began paying ¥10,000 (about £55) for the experience. It felt like early validation. Users told us existing tools like ChatGPT were too generic or repetitive—we were clearly solving a real pain.
The concept seemed solid: curate polished, brandable domains and offer them on a subscription basis. We had paying users and feedback confirming we were doing something differentiated. But underneath that traction was a structural flaw. Most people only need one domain, and our early adopters—solo founders and first-timers—had no reason to return. There was no recurring problem to solve, no retention loop, and no real path to scale.
In hindsight, we’d validated a moment of need, not an ongoing one. Acquisition was expensive, churn was inevitable, and monetisation beyond that first transaction was near-impossible. What I mistook for product-market fit was actually a novelty use case with a ceiling baked in. Once the payments started, I shifted from validation to scaling—too early, and without enough data to justify the leap.
Early Revenue ≠ Product-Market Fit
It’s tempting to treat early revenue as proof of demand. But in reality, it can be a vanity metric if it’s not attached to a repeatable customer journey or a scalable distribution path.
I’ve found that money changes how users behave. Early adopters are often forgiving, curious, or just willing to experiment. They might pay for novelty, to support us, or because they don’t have a better alternative yet. That doesn’t mean we’ve built something they’ll stick with—or that the next 1,000 customers will behave the same. Early success should raise new questions, not silence them:
- Will users come back without hand-holding?
- Can this scale without manual intervention?
- Are payments driven by true utility, or just early excitement?
Small Signals, Big Assumptions
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 SpaceforU, a venue-booking platform. We built a working MVP in 24 hours and quickly onboarded listings. Early bookings rolled in—another win, it seemed. But most of those bookings came from friends. Their support was generous, not scalable. The real customers—the ones we hadn’t validated—already knew the venues and didn’t want to pay for access through a third-party tool. When that early goodwill dried up, so did the traffic.
Revenue wasn’t binary. It matters why someone paid, what they believed they were buying, and whether they’d do it again—without handholding. Even more importantly: does that revenue still show up when the next version ships?
Think Like a Developer: Atomic Validation
Just as developers commit code atomically—in small, testable units—I’ve found product ideas are best developed the same way.
Every shift in the experience, delivery model, or pricing approach is 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.
So yes, I’ll follow the money. But I’ve learned to keep following it, treating every signal—every payment, feature, and workflow—as its own experiment. Build atomically. Test obsessively. Validate continuously.
The real startup magic isn’t just building a product that people will pay for. It’s building something that continues to deliver real value—and keeps doing so as we evolve.
Updated 27th May 2025
