Long design-in programs fail for a reason that never appears in a forecast: neither side is committed, and both sides call the program active.
A design-in program that is going to fail rarely announces it. There is a modelling review in March and a promised test vehicle in April. In June the customer reorganizes the architecture team. In September a new power map arrives and supersedes the old one. Two of your engineers have spent a quarter on it, the opportunity is still in the forecast, and no deliverable exists that either company could point to as evidence of progress.
Nobody lied. The failure has a specific shape, and it is symmetrical. The customer is interested but not budget-committed: an engineer wants the answer, and no cost centre owns getting it. And the supplier is interested but not schedule-committed: applications engineering will get to the test vehicle when the quarter allows. Both sides are genuinely engaged. Neither has put anything at risk. Programs in that state do not fail, they drift, which is worse, because a failure gets removed from the pipeline and a drift gets carried.
The fix is to tie both commitments to the same gates. Agree at the outset what each side funds and staffs at each stage of the design-in, write it down, and revisit it at every gate. Not a contract. A commitment schedule, of the kind both engineering organizations already use internally and neither thinks to use across the boundary.
Where the free line sits matters enormously. The early gates should stay free and joint: architecture access, problem definition, first-pass modelling. Low friction is the only way anyone gets into an architecture conversation at all, and attempting to charge for entry prices you out of the door you need. From the test vehicle onward it changes. A non-recurring engineering fee at that stage is entirely industry-normal — photomask and tooling NRE in semiconductors is exactly this arrangement, and it is routinely creditable against production volume, which disposes of the main objection before the customer raises it.
But the fee is not the point, and treating it as revenue is how this idea gets ruined. The fee is a diagnostic. A customer who cannot find a budget owner for a modest engineering line within a fortnight does not have a program; they have an interested engineer, which is a real asset and a different thing. Learning that in week two instead of month fourteen is worth far more than the fee. It also works internally in the same way: a funded engineering commitment gets scheduled, while an unfunded sales-support request gets deferred, so asking the customer for commitment is often the only reliable route to getting commitment from your own applications team.
What goes in the schedule is unglamorous and takes about a page. For each gate: what the customer supplies, what the supplier staffs, the exit criterion that says the gate is passed, and a date. The exit criterion is the line that does the work, and the best way to get it is to stop proposing one. Ask the customer what they would need to see for this to be worth a test vehicle. Whatever they answer is your exit criterion, stated in their words, owned by them, and defensible inside their own organization in a way that nothing you write ever will be. It is the single most useful question available in a design-in conversation and it converts a pleasant meeting into a definition of done.
Introducing it requires care, because the wrong framing sounds like a payment demand at the exact moment you are asking for trust. The frame that works is predictability, which is what both sides actually want out of a long program. Before proposing anything, ask the question: in their experience, do stalled design-ins stall on physics or on funding? If the answer is funding, you have permission and they have effectively asked you for this. If the answer is physics, do not raise it, and go and solve the physics.
The failure modes are worth naming. Do not put this in the first conversation. Do not use it as a substitute for discovery, because it is a qualification instrument and not a qualification shortcut. And do not let finance attach a target to it, because the moment the fee has a number to hit, the people collecting it stop reading what its absence tells them.
The argument against. The real argument against it is competitive. In a market where a rival will do the same work for nothing, asking for a fee can lose you the evaluation outright, and in an early-stage company fighting for its first reference customer that may be the correct trade. The answer is not to abandon the principle but to move the line: make the free tier genuinely generous and make the paid tier genuinely different, with a co-signed report, a committed turnaround and a named engineer against it. What you cannot do is charge for what everybody else gives away and call it commercial discipline.