How to Keep Building Before the Evidence Arrives

The answer to building without evidence is to stop looking for the harvest while you are still clearing the field. In the early and middle stages of a startup, external evidence—revenue growth, user retention, and market praise—is a lagging indicator. If you wait for these signals to decide whether to keep going, you will likely quit exactly when the work is beginning to take root. To survive this period, you must substitute lagging evidence with proximal evidence: internal signals of structural integrity, complexity reduction, and learning velocity.

Building a product is often described as a series of breakthroughs, but the reality is a long, quiet stretch of invisible work. This is the period where the first product is rarely the real product, and the founder often feels like they are breaking while the product is merely idling. Navigating this requires a framework that values the movement of the needle inside the building, even when the needle outside hasn't moved an inch.

The Proximal Evidence Framework

Proximal evidence consists of the markers that indicate your product is becoming more mature, even if it isn't yet more popular. When you are in the middle of the long build, you must track these three categories of internal signals.

1. The Shift from Support to Research

In the beginning, support is a fire drill. You are fixing bugs and explaining basic UI. Evidence of progress arrives when support interactions shift from "This is broken" to "How do I do this complex thing?" As noted in the manuscript, support is product research in disguise. When your customers start asking for deeper functionality rather than complaining about surface-level failures, you have evidence of product-market resonance, even if your user count is flat.

2. The Reduction of Complexity

Growth brings complexity, but maturity brings simplicity. If you are successfully refining your product, you should find yourself saying no to more features and stripping away the ones that don't serve the core mission. If the product is getting simpler to explain and easier to maintain, that is evidence of progress. A small team with a large surface area cannot survive without this simplification. If you are successfully reducing the "leadership tax" required to keep the lights on, you are building the capacity for future growth.

3. The Quality of the User Base

It is easy to be fooled by false momentum from free users or lifetime deal hunters who do not represent your long-term customer. Proximal evidence is found when you begin to attract users who value the product's core utility over its price point. Even if you only have ten such users, their presence is more significant evidence than a thousand users who signed up because of a discount.

Distinguishing Structural Progress from False Momentum

The danger of the long build is that it is easy to mistake activity for progress. The following table helps differentiate between the external metrics that might be lying to you and the structural progress that actually matters.

The Invisible SaaS Work

Much of what constitutes "building" before evidence arrives is what we call invisible SaaS work. This includes database migrations, refactoring code, improving security, and refining the onboarding flow. None of these actions produce a celebratory tweet or a spike in the dashboard. However, they are the prerequisites for scale.

If you neglect this work because you are chasing external evidence, you will find that when the growth finally arrives, the product will break under the weight. The middle is the time to pay down technical and emotional debt. This is why simplicity is a strategy; by keeping the surface area manageable, a small team can maintain a high standard of quality while waiting for the market to catch up.

When Persistence Becomes Stubbornness

A critical limitation of building without evidence is knowing when the lack of signal is actually a signal of failure. There is a fine line here: persistence and stubbornness are not the same.

• Persistence is continuing to iterate on a core thesis while the external world is quiet.
• Stubbornness is refusing to change the product even when customers (your teachers) are telling you it doesn't solve their problem.

If you have no proximal evidence—if support is still just fire drills, if the code is getting more tangled, and if you can't find even five users who would miss the product if it vanished—then the lack of evidence is the evidence. In that case, the first product was a probe, and it is time to use what you've learned to build the real product.

Field Notes for the Long Build

If you are currently building in the dark, take these steps to reorient your perspective:

• Audit your support tickets: Are the questions getting harder? If yes, your product is maturing.
• Measure your "Time to Ship": Is it taking longer to ship simple things because of technical debt? If so, stop building features and start building infrastructure.
• Talk to your best five users: Ignore the masses for a moment. Ask the five people who use the tool daily why they stay. Their answer is your real product.
• Acknowledge the Leadership Tax: Recognize that as a founder, your emotional state is a resource. If you are breaking, the product cannot thrive. Adjust the pace to ensure endurance.

The evidence eventually arrives, but it rarely arrives all at once. It shows up in the quiet moments: a week without a critical bug, a customer who recommends the tool without being asked, or a day when you feel like you are finally in control of the machine you built. For more on navigating these stages, continue with The Long Build and GrowthDiary essays.

Follow via RSS: latest articles · full article archive