Partner Integration Plan
The document every partner-built Splash integration ran on: pre-build agreement, design and build, and delivery, so the two companies scoped the same thing and shipped something supportable.
The integration questionnaire was the first version of this idea: get the partner and the product team to agree on the problem before anyone writes code. At Splash I rebuilt it for a platform where partners build against our API, and the plan grew a middle and an end.
Pre-build is the agreement. Who the partner’s users are, what problem the integration solves for them, the use cases in plain language, the user journey through both products, and a scope written at the level of “get a list of attendees so that…” rather than endpoints. Nothing gets built until this section is signed off by both sides, because every expensive integration failure I have seen was a scoping mismatch that surfaced after the build.
Design and build is where the engineering lives: assumptions and prerequisites, the proposed solution with the authentication flow drawn out, the API inventory and data-flow diagram, success criteria with the testing method, and an explicit out-of-scope list so the things a customer will assume are handled are either handled or named.
Delivery is the part most plans skip. What changed from the original scope and why, a recorded demonstration including setup, the final endpoint inventory, a getting-started guide a customer can follow, the goals the partner will measure, and the collateral marketing needs to tell anyone it exists. An integration that ships without those is one that support learns about from a ticket.