Proof before revenue

The situation

I spoke recently with a founder building a premium digital camera.

The founder shared this story because they thought other hardware founders in the network might relate to the challenge.

The company started by trying to answer a simple question: if this camera existed, would people buy it?

They launched a landing page, collected signups, and spent time talking directly with potential customers. The goal was to understand what specifications mattered, what people expected from a product like this, and whether the pricing could support the business.

The response was encouraging.

Interest came quickly, and the customer conversations helped clarify what outcomes people cared about most. Over time, the founder became confident there was a viable business opportunity.

The next challenge was figuring out how to build it.

The plan

The founder started talking to camera manufacturers and development partners. The assumption was that there would be different approaches, different costs, and different opinions about how the product should be developed.

Instead, the conversations started sounding similar. Most of the companies believed the camera could be built. Nobody was questioning the concept or whether the product was technically unrealistic.

The issue was what it would take to get there.

The founder kept hearing roughly the same thing. Getting to a working prototype was going to require a larger investment and development timeline than the team had planned for.

After hearing that enough times, the founder started looking at the problem differently.

Where uncertainty remained

One of the more interesting parts of the conversation was that demand no longer felt like the biggest risk.

The founder felt confident there was a market for the product. Customer interviews had been completed and the team had spent time validating pricing assumptions. The team had a fairly good understanding of what customers expected.

What remained unclear was how much of the development effort the company should take on. The original approach - developing the product from the ground up - was a possible path.

Before the company could start manufacturing, and before customers ever touched the product, a significant amount of capital would need to be committed to create a functional prototype.

What needed to be proven first

Around that time, the founder started talking with a different type of partner.

Most of the earlier conversations had focused on building the entire platform specifically for this product. This new partner was already developing technology that was moving in a similar direction.

Instead of asking what it would cost to build everything from the ground up, the founder started asking what could be built on top of work that already existed.

The more they explored it, the more attractive it became.

The economics looked different. The amount of capital required to reach a functional prototype dropped significantly. The product would still require engineering work and custom development, but it no longer felt like the company had to carry the entire burden by itself.

The tradeoff for the 5x reduction in development costs was time. The founder would need to wait for the partner's platform to mature before moving forward.

Like many founders, the instinct was to move faster. The original path offered more control and a clearer timeline. This new path meant relying on someone else's schedule and giving up some flexibility.

After months of conversations with manufacturers and development partners, the question changed.

Instead of asking how to build the product, the founder started asking how much capital should be committed before revenue had been proven.

The answer was the path that allowed the company to keep validating the opportunity without committing so much capital upfront.

The pattern

This kind of situation comes up fairly often in hardware.

Founders often want to build the product the right way from the beginning. That can make custom development feel like the most direct path.

A prototype often needs to answer a simpler question first: are we building the right product?

Sometimes that means adapting what already exists before committing to a fully custom path.

The hard part is knowing when custom development creates value, and when it creates cost before the business has enough proof.

If you're in a similar spot

If you're evaluating development options, it may be worth asking whether you're optimizing for the product you want to build or the path that gives the business the best chance of getting there.

Those aren't always the same thing.