Design Partner or Paying Customer? How to Pick the Right Relationship From Both Sides of the Table

"We have three design partners."

I've heard that line in more pitch meetings than I can count. Founders say it the way they used to say "we have strong pipeline." And just like pipeline, it can mean almost anything.

Sometimes it means a CISO or a qualified Practitioner is actively shaping the product every week. Sometimes it means someone took one 30-minute meeting and said "keep me posted." Sometimes it means a customer who would have happily paid is getting the product for free because nobody had the nerve to ask for money.

Practitioners have noticed. Many have been burned by "partnerships" that turned out to be unpaid QA work for a Startup that disappeared six months later.

Here's the truth: design partners and paying customers are both valuable. They are just not the same thing. Treating one like the other hurts both sides of the table.

This post is for both sides. Startups, it will help you decide when to charge and when to co-build. Practitioners, it will help you decide when to lend your expertise and when to simply buy.

I: Know Which Relationship You're Actually In

Before we get into pros and cons, let's agree on terms.

A design partner helps build the product. They bring a real problem and a real environment, and they commit time to testing, giving feedback and telling you what's missing. In return, they get early access, influence over the roadmap, and usually a meaningful discount or free use for a defined period. The relationship has a goal, a scope and an end date.

A paying customer buys a working solution. They expect it to deploy, perform and be supported. Their feedback still matters, but they aren't there to finish your product for you. They're there because the product solves their problem today.

The trouble starts when nobody says out loud which column they're in.

II: A Design Partnership Done Right

When I was at Anomali, we had a customer we wanted badly, and the deal needed a significant discount to get done. A discount with no structure is just margin you give away. So we turned it into something more useful: a formal design partnership.

The discount wasn't a favor. It was the price of their time, their candor and access to their environment.

Here's what both sides got out of it.

What we got:

• Honest, detailed feedback from a team using the product in a real enterprise environment, not a demo lab.
• Clear direction on what to build next. That feedback helped us grow tremendously.
• A model for what became our customer advisory board. The way we worked with that one customer set the baseline for how we worked with every advisor after them.

What they got:

• Custom work built for their environment, not a generic roadmap promise.
• A real say in how the product evolved.
• Something harder to put in a contract: knowing we had their back throughout the process.

That last point matters more than most Founders realize. A Practitioner who trusts that you'll show up when things break will put up with an unfinished product. A Practitioner who doesn't trust you won't put up with a finished one.

III: For Startups: When to Co-Build and When to Charge

Take a design partner when:

• You haven't reached product-market fit, and you know it. (If you're not sure, our PMF readiness matrix will tell you.)
• You're building in a new category where nobody, including you, knows exactly what "good" looks like yet.
• You need proof in a specific environment, scale or compliance setting before the rest of the market will believe you.
• A strategic logo needs a discount to close, and you want something real in exchange for it.

Charge full price when:

• The product works, deploys reliably and solves the problem today.
• The "feedback" you're getting is mostly feature requests you'd build anyway.
• The customer has budget and urgency. A customer with an active project wants a vendor, not a science experiment.

Warning signs you're doing it wrong:

The free consultant. They take every call and send long feature wish lists, but never deploy anything. That's not a partner. It's an advisor you're paying with your roadmap.

• Design partner forever. There's no end date and no conversion point, so a "partnership" two years in is just a customer who doesn't pay.
• A roadmap of one. If one partner's requests make up most of your roadmap, you're building custom software, not a product.
• Discounts with nothing in return. If you can't name what the discount bought you, it bought you nothing.

IV: For Practitioners: When to Lend Your Expertise and When to Just Buy

Practitioners, a design partnership is a bigger commitment than a pilot. Go in with your eyes open.

Become a design partner when:

• You have a problem no current vendor solves well, or one that's too expensive to solve with what you already own.
• You want the product built around how your environment actually works, not adapted to it after the fact.
• You have the time and the internal support to give real feedback on a regular schedule.
• You'd like early access to emerging technology and a voice in where it goes. Plenty of Practitioners also find it rewarding to help a strong team succeed.

Just buy when:

• You need the problem solved this quarter, with support and SLAs.
• Your team has no capacity to test an unfinished product.
• The data involved is too sensitive to put in front of an early product without a full security review.

Questions to ask before you say yes:

• What specifically do you need from my team, and how many hours a month is that?
• What happens to my data and any custom work if the company is acquired or shuts down?
• When does this end, and what does pricing look like after it does?
• Who on your team is my point of contact when something breaks?

If you do say yes, how you run the pilot matters as much as the decision itself. Our playbook on how to pilot early-stage cyber Startups without exposing your tech stack covers sandboxing, data purge and exit plans step by step.

V: Four Scenarios, Four Answers

These are hypothetical, but if you've spent time in this industry, you've lived some version of each.

1. The Seed-stage Startup with a new idea. A Startup is building detection for AI agents running inside enterprise networks. The product works in their lab, but nobody knows what real agent traffic looks like at scale.

Answer: design partner. They need a real environment far more than they need revenue. Two or three well-chosen partners with clear goals will teach them more than twenty discounted deals.

2. The Series A Startup asked for a free pilot. A Startup has a stable product and a handful of happy customers. A large enterprise says it will "partner" if the product is free for a year.

Answer: paying customer, maybe with a short, paid proof of value. If the product already works, giving it away teaches the market it's worth nothing. If the enterprise offers real co-design work in return, put that in writing and keep a price on it.

3. The Practitioner with a gap nobody covers. A security leader has a niche problem that no vendor on the market handles well. They have a small team and some time to spare this quarter.

Answer: design partner, with a defined scope. They're the ideal partner, because the problem is real and they care how it gets solved. Their job is to set the boundaries: hours per month, data allowed, and an end date.

4. The strategic logo that needs a discount. This is my Anomali story. The deal only closes with a significant discount, and the customer is someone you'd love to learn from.

Answer: design partner, structured. Don't hand over the discount quietly. Turn it into a partnership with feedback sessions, roadmap input and a reference, and make sure they know you have their back.

VI: Put It in Writing

The best design partnerships I've been part of had one thing in common: both sides knew exactly what they'd signed up for. A one-page agreement does more for trust than a dozen friendly calls.

Every design partner agreement should cover:

• Goals. What problem you're solving together, and what "done" looks like.
• Time commitment. How many hours a month the Practitioner's team will give, and how often you'll meet.
• Feedback format. How feedback is captured, who receives it, and how quickly the Startup responds.
• Data and access. What data the product can see, where it lives, and how it's removed at the end.
• Custom work. What the Startup will build for the partner's environment, and who owns it.
• Pricing. The discount during the partnership, and the price once it ends.
• The end point. A date or milestone when the partnership either converts to a paid contract or closes cleanly.
• What each side gets publicly. Whether the partner will serve as a reference, appear in a case study, or join an advisory board.

If you can't fill in number 7, you don't have a design partnership. You have an open-ended favor.

VII: The 60-Second Scorecard

Still not sure? Answer these five questions honestly. Startups and Practitioners can both use it.

How to read your score:

0 to 2: This is a customer relationship. Charge for it, support it, and earn the renewal.

3 to 4: A design partnership could work. Write it down before you start.

5: You've found a real design partner. Treat them like gold.

Finding the Right Partner with Prospectorz

Great design partnerships start with the right match, and the right match is hard to find through cold outreach.

That's why we built the Design Partner Interest Flag into Prospectorz. Practitioners can signal that they're open to shaping an early product, and Startups can see who wants to co-build rather than simply evaluate. Nobody has to guess which column the relationship belongs in.

Every 30-minute meeting on Prospectorz ends with structured feedback, so Startups learn where they stand even when the answer is "not yet." Practitioners stay anonymous until they decide to opt in, on their own terms. And both sides are verified before the first conversation, which matters when a partnership means sharing an environment.

Whether you end up with a design partner or a paying customer, you'll know which one it is from the first meeting.

The Bottom Line

Design partners and paying customers aren't a ranking. One isn't a step below the other. They are different relationships with different promises, and the best Startups have both at the right time.

Startups: a design partner should buy you clarity, not just a logo. If the product already works, charge for it.

Practitioners: a design partnership should get you a product built for your world, and a team that has your back. If you need it working tomorrow, just buy it.

And both sides: say out loud which relationship you're in, write it down, and agree on how it ends. Everything gets easier after that.

Build something great together!

-Nick Vann

Founder & CEO