Progress is evidence: how we plan capability milestones in hard tech
Key takeaways
- In hard tech, progress means retiring technical uncertainty with objective evidence, not hours worked or features built.
- We define each capability with a metric and a customer-relevant threshold; meeting a set of thresholds is an inflection point.
- Atomic inflection points prove one threshold cheaply; composite ones prove an integrated system and unlock pilots and capital.
- Sequencing atomic proofs first is how small teams escape the demonstration catch-22.
A hard-tech startup does not create value by building technology. It creates value by reducing technical uncertainty, one piece of objective evidence at a time. That idea shapes how our studio plans every development program, how we decide what to fund next, and how we talk to customers and co-investors about progress.
Why effort is the wrong measure of progress
Hardware teams are busy by nature. There is always another board revision, another test rig, another feature on the list. Busy is not the same as progressing. A month of work that leaves the team knowing nothing new about whether the system will meet its targets is expensive, and it can mislead everyone into thinking the risk is lower than it is.
We hold every milestone to a simple test: did it change what the team knows? If not, it was activity, not progress.
The core questions in Phase 1 are blunt. Will the core technology work outside the lab? Will it hit the performance numbers customers care about? Will it do so at a cost and reliability that make a business? Every experiment should be designed to answer one of those, as quickly and cheaply as possible.
How do we define a capability milestone?
We use a four-level hierarchy, and we write it down before the work starts:
- Capability: what the system must do, such as stay aloft, detect a defect or locate itself.
- Metric: how that is measured, such as minutes, precision or centimeters of error.
- Threshold: the specific number that matters to a paying customer, not a number that sounds good.
- Inflection point: the milestone reached when the required thresholds are met. Risk drops, and the next stage opens.
Here is the example we use with founders, an autonomous drone built for infrastructure inspection:
| Capability | Metric | Threshold |
|---|---|---|
| Flight endurance | Minutes aloft | 45 or more |
| Defect detection | Precision | 95% or better |
| Localization | Position error | 20 cm or less |
| Image resolution | Ground sample distance | 3 mm per pixel or finer |
The inflection point is a prototype ready for a commercial inspection pilot, and it counts only when all four thresholds are met together. Three out of four does not earn the milestone.
Atomic vs. composite inflection points
Some inflection points are atomic: one threshold, one proof. Top speed above a target, or endurance above a target. These are cheap to demonstrate with a small team and a modest budget, and they build early credibility.
Others are composite: several thresholds proven at the same time in one system. They are harder and more expensive, but they retire far more risk. A composite proof is usually what customers and larger investors need before they commit real money, because it shows an integrated system working in realistic conditions.
Good sequencing uses atomic proofs early to buy credibility and capital, then spends that capital on the composite proof.
How do you break the demonstration catch-22?
The most common trap we see is a team that believes it must show a finished system to raise money, while needing money to finish the system. The loop stalls good ventures for years.
The way out is to stop organizing work around features and organize it around inflection points. Break a big capability into slices that can be proven on their own. Prove one slice, show the evidence, raise or sell against it, then fund the next slice. Each proof makes the next conversation easier.
To choose which slice to prove next, we use a light version of the RICE framework: how much of the roadmap it unlocks (reach), how much uncertainty it removes (impact), how likely we are to hit the threshold (confidence), and what the evidence will cost (effort). It is a thinking aid, not a spreadsheet to obsess over. After every inflection point, we review whether the thresholds were truly met, what we learned, and what has to change.
What it means for founders
Write your capability table before your next raise. Put real numbers on it, tie each threshold to what a customer told you they need, and mark which proofs are atomic and which are composite. Then align your capital plan with it, so each tranche of money buys a specific inflection point. Investors who understand hardware will trust that plan far more than a feature roadmap.
What it means for investors
Ask for the table. A team that can name its thresholds and its next inflection point understands its own risk. A team that can only describe features may still be strong, but the diligence work is yours. In our studio, capital is released against evidence, which keeps everyone honest and keeps the company alive long enough to reach a pilot.
This is how we build durable companies in aerospace, autonomy, maritime and energy. Learn more about Fluxa First or browse all topics.
Frequently asked questions
What is a technical inflection point?
It is the milestone reached when one or more capability thresholds are demonstrably met, so the team knows something new and the venture’s risk drops. It is defined in advance with numbers, such as minimum flight time or detection precision, and it unlocks the next stage, like a pilot or a raise.
What is the demonstration catch-22?
Many hardware teams believe they need a complete working system to raise money, but need money to build that system. Breaking the system into separately provable capabilities lets a team show credible evidence early, raise against it, and fund the next proof.