Design partners: free development department or your first real customer?

The partner who loved everything and bought nothing

A robotics startup I advised had five design partners. Five! Logos on the deck, engineers on weekly calls, feedback flowing in both directions. Eighteen months in, I asked a rude question: how much money had the five of them paid, in total? The answer was zero. Worse: of the five, two had requirements pointing in opposite directions, one had quietly shelved the project when a budget cycle ended, and one turned out to have a competing internal program the whole time.

This is the design partner trap in its purest form. The concept is sound: you build with a real customer instead of in a vacuum. The execution is usually broken, because startups collect design partners the way they collect LOIs, as proof of interest, without ever asking the question that separates a partner from a trap: what does this relationship commit them to?

What a design partner actually is

Strip the romance away and a design partner is a commercial instrument with one job: to be the fastest possible path from your prototype to a purchase order. Everything else, the feedback, the co-development, the logo, is instrumental to that goal or it is decoration.

That definition has teeth. It means a design partner who will never buy your product is not a design partner. They are a research collaborator, which is fine, as long as you know it and budget it as research. The damage happens when a startup mistakes a research collaborator for a commercial pipeline, and builds its fundraising story, its roadmap and its calendar on the confusion.

The five-question test

Before signing any design partnership, I make founders answer five questions about the candidate. They are simple, and most candidates fail at least two.

One: do they have the problem today, measurably, in money? Not "this is interesting for our roadmap". Today, on a line, costing someone a bonus. Two: is the person sponsoring this inside the company the person who owns that problem's budget, or one floor away from them? An innovation scout with no P&L connection cannot deliver a purchase order, only opinions. Three: have they ever bought from a startup before, and how did that go? First-time buyers of startup technology need education you may not have time to give. Four: what happens, specifically, if the collaboration succeeds? If the answer is vague, write the answer down together before starting, or accept that success has no destination. Five: what are they paying, in money or in committed resources with names on them?

That fifth question is where founders get uncomfortable, so let me spend a paragraph on it.

When they should pay, and why it protects you

The instinct is to make design partnerships free, to lower the barrier. The instinct is wrong, and not for revenue reasons. Payment is a selection mechanism. A company that pays fifty thousand for co-development has a budget line, and a budget line has an owner, and an owner reports to someone. Your project now exists inside their accountability system, which is the only place projects survive contact with a reorganization.

Money is not the only acceptable currency. Committed engineering hours with named people, guaranteed line time for trials, exclusive data access, a written intent to negotiate a supply agreement at defined volumes: all of these create internal accountability. What does not count: enthusiasm, meeting attendance, and the phrase "strategic interest". If a candidate offers only the second list, they have just told you what you are to them. Believe them.

How many, and which ones

Two design partners is usually right. One is fragility: their reorganization becomes your pivot. Three or more is a roadmap riot, because each partner pulls the product toward their plant, their interfaces, their certification regime, and you cannot serve three masters at prototype stage without shipping mush.

Choose the two on diversity of condition, not diversity of industry. One large, slow, demanding corporate whose approval would mean something to every future buyer. One smaller, faster company whose pain is acute enough to move at startup speed. The first teaches you to survive procurement and qualification. The second gets you to a working installation before your runway ends. You need both lessons, and no single partner teaches both.

The exit is the point

Here is the sentence that should be in every design partnership agreement, and almost never is: if the joint work meets criteria X and Y by date Z, the parties will negotiate a supply agreement with volumes in the range of A to B. Without it, you have built a road that ends at a cliff. I wrote about this pattern in the pilot context, and it is the same disease: a successful collaboration with no defined commercial aftermath ends in congratulations, a case study request, and silence.

Set the exit terms when enthusiasm is highest, which is at the start. Six months in, when your roadmap has bent toward their requirements and your leverage has quietly shifted, is the wrong time to discover that they never intended to buy anything.

What good looks like

The best design partnership I have seen up close involved a sensor startup and a mid-sized food processing company. Fifty thousand in co-development funding, a named process engineer at twenty percent allocation, weekly line access, and a one-page letter stating the intended supply volumes if the trials hit three written criteria. Fourteen months later the trials passed, the negotiation took six weeks because the destination had been agreed before the journey started, and the startup's second customer came from the partner's own introduction at an industry event.

That is the whole game. A design partner is not a trophy. It is a machine for converting development risk into a first order, and like any machine, you can tell a working one from a broken one before you turn it on.

Common questions

Should design partners pay?

Yes, in money or in committed named resources. Payment creates an internal budget owner at the partner, which is what survives reorganizations and budget cuts. Enthusiasm without commitment predicts a partnership that produces feedback and no order.

How many design partners should a hardware startup have?

Usually two: one large corporate whose approval signals credibility, one smaller fast-moving company with acute pain. One partner is fragile; three or more pull the roadmap apart.

What should a design partnership agreement include?

Scope, named resources on both sides, payment or committed equivalents, success criteria in the partner's metrics, and a written statement of what happens commercially if the work succeeds, including intended volumes and price bands.

If you are collecting design partners and none of them has a budget line attached, you already know what this article was about. Let us look at the list together.