I am especially interested in partnering with people who know an industry from the inside. They have sold into it, worked in it or run part of it, and they can see a problem that outsiders miss. What they often do not have is someone to design and build the product.

That is the kind of partnership I look for as a build partner. The usual way to describe it is simple: one person sells, the other builds. I think that description leaves out the most important job.

The strongest partnership is not simply one person builds and one person sells. Both need to help decide what deserves to exist.

Here is what I think the two partners should validate together, before either of them commits to a long build.

Who can actually reach customers?

Not a market. Names. Who are the first people who might buy this, and can one of us get a real conversation with them in the next few weeks?

This is usually where the domain expert carries the most weight. But "I know everyone in this industry" needs testing like any other assumption. It also helps to separate who uses the product, who pays for it and who can say no, because in many industries those are three different people.

If neither partner can reach the people who would buy, that is the first finding, and it is far better to learn it before the build than after.

Is the problem frequent and expensive enough?

A problem worth building for usually happens often, costs real time or money, and already has someone putting up with a clumsy workaround: a spreadsheet, a manual process, a tool bought for something else.

The domain expert knows which problems are real and which only sound real. The technical partner knows which are tractable, what AI changes and what it does not. Neither view is enough alone. Watching people do the work today, in walk-throughs rather than descriptions, is usually where those two views meet.

What can be sold or tested before a large build?

Most ideas can be tested well before the full product exists: a clickable prototype of the core flow, a spec reviewed by the people who would buy it, a manual version of the service run by hand for a few customers, or a pilot agreement. I wrote about designing those experiments in how I would test a product idea before building.

In a partnership, the split matters as much as the test. The technical partner's job is to find the cheapest thing that answers the next question. The domain expert's job is to put it in front of the right people and read their reaction honestly, including the reactions neither partner wanted. This is also why a Scoping Sprint is a good place for a partnership to start: it ends with a prototype tested with users and a plan, before anyone commits to a long build.

Who owns what after launch?

"You sell, I build" stops being clear the moment a customer signs. Somebody has to own:

  • Ongoing customer discovery, so the product keeps learning.
  • Implementation and onboarding, which can be where business products succeed or stall.
  • Support, including the questions that turn out to be product problems.
  • The roadmap, and how disagreements between the partners get resolved.

These are worth writing down early, along with everything else in the partnership. I cover what I put in writing in cash, equity or both.

What evidence would make you both stop?

This is the question that is easiest to skip, and the one I care about most.

Before the work starts, agree what would make you stop or change direction. For example: the people you agreed to talk to will not commit to a pilot, the problem turns out to be rare, or the buyer and the user want incompatible things. Agreeing in advance means neither partner has to argue against sunk cost later. It also makes stopping a shared decision rather than a betrayal.

Don't build what neither of you can distribute

A good product with no path to customers is still a failed product. Before the build, both partners should be able to answer a few plain questions. How will the first customers hear about it? How will they buy it? Who will help them adopt it? How will the next customers find it?

The domain expert's network is often the first channel. It is worth checking whether that network actually leads to purchases, or only to friendly conversations.

A partnership works when both people own the question of what deserves to exist, not just their half of the work.

How I would split the work

As a starting point:

  • The domain expert brings access, credibility, the language of the industry and a sense of what buyers will pay for, and usually leads sales.
  • I bring product direction, design, the build and the AI work, along with an honest view of what is feasible and what it will take.
  • Together we decide what to build, review the evidence and decide when to stop or change course.

That last line is the one that makes it a partnership rather than a contract.

If you know an industry well and want to talk about building something in it together, email me at kevin@kevinhorek.com with what you see and who you can reach.