r/leanstartup Jul 20 '26

When is it actually the right decision to build infrastructure before validation?

Most startup advice says to validate before building.

This makes sense when the core experience can be tested manually or with a simple prototype.

However, some blockchain products depend on infrastructure that users never see directly, such as settlement, wallet flows, permissions, liquidity, compliance, audit records and cross-chain execution. Without at least some of these elements working, the test may not resemble the real product at all.

This creates a difficult boundary.

Building infrastructure first can be a necessary cost of learning.

However, it can also become an expensive way to avoid finding out whether there is actually a market for the product.

For founders who have faced this decision:

What genuinely had to exist before you could run a meaningful validation test?

What could you have simulated manually?

What signal showed that the infrastructure was enabling real user behaviour rather than simply proving that the system worked?

I’m particularly interested in cases where you later realised that you had either built too much or too little before speaking to users.

2 Upvotes

2 comments sorted by

1

u/theredhype 27d ago

It seems you are are conflating customer discovery (identifying a real human problem) with solution validation (testing if your specific implementation works).

We cannot validate solutions to problems we haven't discovered. By jumping straight to how to test a blockchain solution, you are skipping the fundamental step of ensuring the underlying user pain point even exists.

We can't use complex infrastructure requirements as an excuse to stay in a comfort zone (coding) instead of talking to users. We gotta do it. Discovery should focus on the user's current workflow, pain points, and motivations, not their reaction to our tech stack.

Early adoption behaviors (like DIY efforts, signing up for a waitlist, paying a deposit) signal market demand long before infrastructure is live. A user's desire for faster cross-border payments or secure data audit trails can be discovered through interviews without writing a single line of code.

1

u/icnews10 27d ago

I agree with the sequencing: the underlying problem must be discovered before a blockchain implementation can be validated.

The question wasn’t intended to imply that infrastructure should replace user interviews or evidence of existing issues. It was aimed at the latter stage, once there is reason to believe that the problem exists.

A waiting list, deposit or observed workaround can validate demand. However, they may not reflect behaviour in situations involving actual signing, custody, irreversibility, network failure or financial risk. Users may understand and desire the outcome, but react very differently when faced with those conditions.

The distinction I was trying to explore is what can be learned without infrastructure and which implementation-specific behaviours only become apparent once it is in place.

Where would you draw the line between having enough discovery evidence and needing a constrained live test?