Partnership due diligence: what to check before you commit engineering
Partnership due diligence for B2B SaaS: API health, program maturity, legal terms, customer overlap, and security posture, plus a short checklist before you build.
A partner manager is enthusiastic, the logo is familiar, and a customer mentioned the tool last month. Engineering asks how many weeks to block. This is the moment most teams skip due diligence and start a build they will still be apologizing for a year later.
Due diligence for a technology partnership is not a full legal audit and not a six-month science project. It is a short, named set of checks you run before you spend engineering weeks: whether the technical surface is healthy, whether the partner's program can actually carry you, whether the paper is safe enough, whether customers overlap, and whether security and legal will let you ship. Skip a check and you find it in production, which is the expensive place to find it.
This post is that set of checks. Use it after a partner discovery call has shown real interest, and before you write the scope. It sits next to your partner ICP: the ICP says whether they are the kind of partner you want, due diligence says whether this specific partnership is safe to build. If the ICP score is low, do not due-diligence your way into a yes.
The 60-second version
If you only read one section, read this one:
- Run due diligence before you commit engineering, not after the kickoff. The build is the expensive step.
- Check five areas: technical surface health, program maturity, legal and commercial terms, customer overlap, security posture.
- Technical health means you can build against what they ship today, with docs, a sandbox, and a deprecation path you can live with. A dead or hostile surface is a walk-away.
- Program maturity means there is a way to get listed, enabled, and supported, not only a friendly manager.
- Legal is a few terms, not the whole stack: IP, data, deprecation notice, termination, exclusivity. See partnership agreements for the deeper read.
- Overlap is named customers or a clear shared job, not "we play in the same space."
- Security is whether you can pass their review and they can pass yours at the level your buyers care about. Do not guess.
- A two-week checklist is enough for most startup partnerships. If you cannot get answers in two weeks, that is itself a finding.
Why this comes before engineering
Engineering time is the scarce asset in a partnership program. A bad partner selection does not cost you a logo. It costs you a quarter of roadmap and a customer who installed something you then have to sunset.
Due diligence is how you avoid paying that price for reasons you could have seen. Not every risk is visible. The ones below are. Teams skip them because the partner is nice, the quarter needs a "win," or the first call felt like momentum. Momentum is not a check.
Treat the output as go, go with conditions, or no. Conditions are real: "we build only if they give us sandbox access and a written deprecation window," not "we will hope their API improves." A conditional go without an owner on their side to meet the condition is a no.
Brief counsel and security with a one-page findings note. A lawyer who gets forty pages with no business memo wastes hours. A security review that starts after the integration is half-built will stall the launch.
If build vs buy vs partner still has "build it ourselves" on the table, finish that decision first.
Technical surface: health, not a feature tour
You are not reviewing their product as a customer. You are reviewing the surface you will build on.
Can you get docs without an NDA theater? Is there a current, public or partner-gated reference that matches what the product actually does? Are there obvious gaps between the marketing of the partnership program and the endpoints or events you would need for the workflow you care about?
Can you get a sandbox or equivalent? If the only way to test is a production account, you will ship late and break something. How do they handle versions and deprecation? A surface that changes without notice is a maintenance trap. You do not need their entire lifecycle policy. You need a number of months you can live with and a channel where changes are announced.
Who owns the surface internally? If partner-facing engineering is a side project, your tickets will sit. A mature surface has a way to file bugs and a person who answers. An enthusiastic manager with no engineering counterpart is a red flag you will feel in week six.
You are not writing their platform for them. If the workflow you need is not possible on the current surface, that is a no, or a much smaller partnership, not a custom project you will regret. Unpaid custom work to make their product partner-ready is how due diligence was supposed to save you.
| Check | Healthy signal | Walk-away signal |
|---|---|---|
| Docs | Current, match the product, you can build from them | Out of date, gated behind theater, contradict the product |
| Test environment | Sandbox or a safe equivalent | Production-only testing |
| Change and deprecation | Announced, with a window you can plan around | Silent breaks, or "we don't really version" |
| Engineering counterpart | A named path for partner issues | Manager only, no one who can change the surface |
| Fit to the workflow | The job is possible on what ships today | Requires uncommitted roadmap or custom work |
Program maturity, overlap, legal, and security
Program maturity. Is there a real path to list, to get a listing reviewed, to reach their sellers or their marketplace, and to get support when the pairing breaks? Or is there one person collecting logos this quarter? A strategic alliance on a slide is not a program. Ask what the last partner who looks like you actually received: listing, intro, silence. If they cannot name it, you are the experiment.
Customer overlap. Name accounts or describe a job both customer bases already run. "Complementary in the stack" is not overlap. If you cannot get even a handful of named or clearly implied shared customers, the integration may still be worth it for retention, but it is not a distribution partnership. Score this the way your ICP already tells you to: overlap is the heavy weight.
Legal and commercial. You will not rewrite their paper. You will read the clauses that protect the build: who owns the integration IP, what they can do with customer data, how much notice before the surface changes, what happens on termination, and whether they are asking for exclusivity. Unlimited liability, broad IP assignment, data resale, and exclusivity with no commitment are walk-aways. The rest is negotiation capital. Run this in parallel with scoping, not after.
Security posture. Two directions. Can you pass what they require to list or to connect (questionnaires, reviews, minimum practices)? Can they pass what your buyers and your own review require (how they hold data, subprocessors, incident process)? You do not need to become their auditor. You need to know whether the pairing will die in a security review six months from now. If your customer is enterprise and they cannot complete a standard questionnaire, believe that.
| Area | Question to answer | If you cannot answer |
|---|---|---|
| Program | What does a partner like us actually get? | Assume listing-only, or walk away |
| Overlap | Who already uses both, or will in the next year? | Do not plan on distribution |
| Legal | Are IP, data, notice, termination, exclusivity acceptable? | Do not start the build |
| Security | Will both sides pass the reviews that matter to buyers? | Delay or no |
| Commercial | Is the GTM model explicit (referral, co-sell, nothing)? | You will invent it under pressure later |
Sourcing can dump a lot of candidates on you. Due diligence is how you thin them. If you are still filling the top of the funnel, go back to sourcing technology partners and stop doing deep checks on logos that fail the ICP.
A two-week checklist
You do not need a war room. You need a named owner and ten working days.
Days 1–3: pack. ICP score already written. Notes from the discovery call. The workflow you would actually build. A list of docs, sandbox, and program pages you can access without waiting. If you cannot find docs, that is the first finding.
Days 4–7: technical and security. Read the docs against the workflow. Request sandbox. Send or request the security questionnaire at the level you actually need. Note gaps. Talk to one engineer on your side who would have to build it. Their "this is messy but possible" is a go with conditions. Their "this is not a real surface" is a no.
Days 4–7 in parallel: commercial and legal. Get the paper, or the standard developer and partner terms if that is all they use. Mark the five clauses. Ask about GTM: listing only, referral, co-sell. Ask who the owner is after this manager. Confirm overlap with one internal list of customers who use (or asked for) the other product.
Days 8–10: decide. One page: findings, go / go with conditions / no, and the conditions with owners. Share it with whoever would sponsor the engineering time. Do not bury a no in a hopeful paragraph.
If the partner cannot respond in that window, extend once, then treat silence as data. A partner who cannot answer due diligence questions will not answer build questions.
| Day range | Your job | Their job |
|---|---|---|
| 1–3 | Pack facts, name the workflow | Provide docs and program links |
| 4–7 | Technical, security, legal read | Sandbox, paper, questionnaire |
| 8–10 | Decision memo | Confirm owner and GTM |
After a go, the lifecycle continues: scope, build, launch, maintain. Due diligence is not the partnership. It is the gate. The rest of the loop is in the SaaS partnership lifecycle.
Common mistakes, and the fix
Treating a good first call as diligence. The fix: run the five areas on paper. Warmth is not a finding.
Starting the build while legal and security are "in parallel" with no gate. The fix: conditions with owners. No sandbox, no start. No answer on exclusivity, no start.
Checking only the logo and the API marketing page. The fix: docs versus the actual workflow, plus program, overlap, legal, security. Technical fit is necessary and not sufficient.
Asking for a custom surface when the current one cannot do the job. The fix: that is a no, or a paid project with a scope. It is not a partnership due-diligence pass.
Spending six weeks on diligence for a small listing. The fix: match depth to stake. Two weeks is the default. A one-day pass is fine for a tiny, reversible connector. A deeper pass is for exclusivity, heavy engineering, or data-sensitive pairings.
Ignoring a missing owner. The fix: no named owner after the sale is a no. You will not have anyone to escalate to when the surface breaks.
FAQ
When should we run partnership due diligence? After fit looks real on a discovery call and before you commit engineering. Not after kickoff, and not as a way to delay a no.
How is this different from a partner ICP? The ICP is the profile of a good partner for you. Due diligence is a check on this specific partner's surface, program, paper, overlap, and security. High ICP, failed diligence, still a no.
How long should it take? About two weeks for a normal startup partnership. Faster if the stake is small and reversible. Longer only if security reviews or legal are inherently slow, and then the build waits.
What if they will not share docs without an NDA? Sign a mutual NDA if that is truly the bar. If docs still do not appear, treat that as a technical-health failure.
Do we need a lawyer for every partner? No. You need a lawyer when the paper has unusual risk, exclusivity, IP assignment, or data rights you do not understand. For standard developer terms, a trained read of the five clauses plus counsel on the flags is enough.
What if overlap is weak but the logo is strong? Do not build for the logo. Weak overlap means you may still do a small, reversible connector for a few customers. Do not staff a flagship partnership.
What does a "go with conditions" look like? A written list: sandbox by a date, written deprecation window, named engineering counterpart, no exclusivity. If conditions slip, the decision reverts to no.
Further reading
- The first partner call for qualifying before you invest in diligence.
- How to define your partner ICP for the profile diligence is checking against.
- How to negotiate SaaS partnership agreements for the clauses to read.
- Sourcing technology partners so you are not diligencing the wrong funnel.
- Build vs buy vs partner if the alternative is still on the table.
- The full lifecycle of a SaaS tech partnership for what happens after a go.
- Due diligence.
- Strategic alliance.
The short version
Due diligence is a short gate before engineering, not a vibe from the first call. Check the surface you will build on, the program that will carry you, the few legal terms that protect the integration, the overlap that funds the work, and the security reviews that can still kill the launch. Write go, go with conditions, or no.
Two weeks is enough if you pack the workflow, read docs, request a sandbox, mark the clauses, and name an owner. Silence, a dead surface, exclusivity without commitment, or a manager with no mandate are answers. Do not start the build to keep the conversation warm. Warm conversations are cheap. Engineering weeks are not.
If you want a due-diligence pass on a live partner candidate, that is what a Partner Audit is for. We review fit, surface, and risk, then tell you whether to commit engineering or walk.