How do I get design partners who deploy in production — and how do I convert them?

You are asking a stranger to run your code inside the systems they are paid to protect. That is what a design partnership means in security, and it is why the usual advice does not apply. The partner's yes costs them nothing. The deployment costs them a change to an environment they are measured on. Only the second one tells you anything.

Unpaid is fine. Unconverted is not.

You will be told to charge from the first day, and you will also be told to give it away in order to learn. Both miss it. What you are running is the first half of a sale, and the only measure that matters is whether it converts.

Charge where you can. A partner who pays has already cleared budget, procurement, and an internal sponsor, which are three of the four things that kill a first enterprise deal, so converting them later is paperwork rather than a new sale. We watched one company's original design partners renew early and expand while a competitor's drifted away, and the difference was not the product — that company charged from the first engagement. It is the strongest signal on offer and it is worth asking for. The number you name is your first price, not a discount, so set it so the business owner can sign within their own authority.

An unpaid partner is not a failure. In security it is often the only way in, because a large buyer may have no mechanism to pay a company your size quickly, and insisting can cost you the deployment as well as the partner. What is not acceptable is an unpaid partner with no agreed route to becoming a paid one. Before the first login, write down the price, the date, and what has to be true for the pilot to convert, then get the person who would sign to say it back to you. A free pilot with a conversion path is a sale in progress. A free pilot without one is a free option you are funding with your own engineering time.

Decide what the pilot is for.

You choose the purpose before the price, because each price buys a different thing. A paid proof of concept buys evidence that money can leave the building. A free pilot buys either the displacement of an incumbent or a reference you could not get any other way, but only if you decided in advance which one. A pilot with no price and no stated purpose buys nothing and spends the engineering attention you have the least of.

Two different instruments hide under one word. A design partnership trades influence over your roadmap for money and reference rights. A pilot is an evaluation inside a sales cycle. Open standard agreements exist for both, and starting from one is better than drafting your own.

Logos are a liability until they deploy.

You will watch the same logos on your board slides year after year, moving from design partner to prospect to in procurement without ever becoming revenue. We have watched that slide at more than one company, and the movement is the tell. For a technical buyer, agreeing to look at an early product is a free option with social upside and no cost. Nothing about that agreement tests budget, urgency, or authority. The logo stays on the slide because removing it would mean admitting the option was never exercised.

Design-partner logos are the standard proof of traction on a seed deck. They are the most misleading thing on it, precisely because the buyer's cost of saying yes is zero.

The bar is production. Your agent is on the fleet that matters, your connector is authorized against the real tenant, and your findings are routed into the system the buyer runs and is measured on. A partner who advises and never deploys has bought a seat at your roadmap and paid with your engineering time. One partner wired in is a signal. Six still evaluating are not.

Write the ending before the start.

You put five things on paper before the first login: the success criteria, the name of the business owner, the price and timeline for what happens if you pass, the deployment surface, and the way out.

Early pilots are kept deliberately loose to reduce friction and get in the door. The looseness is why they never end. A pilot that is easy to start is endlessly hard to finish, and the natural end of a pilot with no definition is a request for another pilot. Nobody writes the ending for you. Security buyers worry about integration and never about how the pilot ends, so name the surface yourself: what gets installed or connected, against which tenant, and when the change window is booked. The clock starts at the first production data, not at the signature.

Track conversion from the first pilot.

You track conversion as a hard ratio from pilot one, with the engineering hours it consumed in the denominator, and you stop the motion when the ratio is bad instead of adding pilots. Several marquee pilots that each produce good feedback and no contract is not a promising quarter. It is a signal about the category.

When pilots do not convert, the reflex is to run more pilots and run them better. The ratio is usually telling you about the buyer, not about your process. Change the buyer: the budget line, the person who signs, the segment. And count the quiet ones. A pilot that neither converts nor ends is a loss. Security deals go quiet rather than being declined, so a pipeline with no recorded losses is a warning, not a reassurance.

Stay out of the customer's change queue.

A slow pilot looks like a slow evaluation, and most of the time it is not. It is the customer's own change-management process, which is why shortening the evaluation never moves the date. A deployment path that is read-only, that works through an API, or that runs outside the customer's environment removes the delay rather than shortening it. Save the privileged agent and the inline position for the definitive agreement.

Confirm the deployment before the technical win. Security value gets agreed early and cheaply. Deployability gets discovered late and expensively, and an installation the customer will not approve is the objection that arrives last. Book the change window in the same conversation as the yes. If they will not schedule it, that is a disqualification, not a delay.

Partners who can convert, deploy, and be named.

You choose partners by three tests. Can they convert, meaning there is a named person who could sign within their own authority the day the pilot passes. Can they deploy, on a surface you can reach without their change queue. Can they be named, with reference rights written into the agreement at signing rather than requested as a favor afterward.

Qualify a design partner the way you would qualify any other deal, and expect to want to skip it. A partner who approached you feels like a gift, and gratitude is why founders run pilots they would have disqualified as prospects. Ask what you would ask a buyer: what happens if this works, who else has to agree, what is this competing with for their team's attention, and what would make them stop. Someone who cannot answer those is not a design partner. They are an interested engineer.

Start with mid-sized companies before large regulated ones. A smaller buyer decides within a quarter. A large one takes most of a year, and its yes is the start of a procurement process, not the end of one.