Approach
How I get an integration from signed deal to real use.
Integrations rarely stall on code. They stall on promises nobody checked, work nobody owned and launches nobody measured. This is how I stop that happening.
Start with the outcome
Before anything else, I find out what problem the integration solves, why it matters now, what success looks like in numbers and how much usage the deal expects.
By the time requirements reach the people building it, they've usually been retold two or three times, and something gets lost each time. My first job is to get those four answers down in a line each. If nobody can say what happens when the date slips, the date isn't real yet. Better to know that before anyone plans a sprint.
Check what was promised
I check everything promised in the sales process against the current docs or a test.
For each thing the deal relies on, I write down how I know it works: I read it in the docs, I saw it in a test, or I'm inferring it and it still needs confirming. Anything I can't find goes on the risk list on day one, not when the customer's engineers hit it. I never assume the provider's test environment behaves like production.
Put a name on every dependency
Every piece of work the launch depends on gets an owner, a date and a note on what it holds up, whether it sits with you, your customer or a supplier.
Slips usually come from people and access, not code: a team that hasn't been freed up, frontend work nobody scheduled, a compliance question with no owner, credentials that take weeks to arrive. I map them in the first week. Anything launch can't do without goes on one list and everything else on another, so the extras never quietly move the date.
Launch on proof
Nothing on the go-live checklist gets ticked until there's a log, a test result or a setting to back it up.
Some things only show up in production. For those, I put one small, real transaction through and watch it all the way. Whoever makes the call to launch writes down why, including any risk they chose to accept, so nobody has to reconstruct it later.
Check it's being used
A month after launch, I check real usage against what the deal was sold on.
I look at how many users finish the flow, where they drop out, what errors they hit and what the integration doesn't cover yet. If usage is short, I find out why and get someone's name against the fix. New features or markets come after the current flow works, not instead of it.
None of this is paperwork for its own sake.
The point is to find the three or four things that would sink the launch while they're still cheap to fix. When a check comes up twice, I script it, and your engineers only hear from me when they're the only ones who can answer.
Getting started
What the first piece of work looks like
It starts with a half-hour call to see whether the problem fits. If it does, I begin by finding out what's really going on. I read the contract, the docs and the customer's plan, work out which systems are involved, and talk to whoever owns each part of them, on your side, the customer's side and any supplier's.
Then I write it up. You get a list of what's missing, a list of what could go wrong, and the questions nobody has answered yet, each with the name of the person who needs to answer it. It's useful on its own. Sometimes that's all a team needs to get moving.
If the work carries on, it's under one of the four ways of working, with the scope, the price and how we'll measure it agreed in writing before it starts.
Example first write-up
| Open question | Who answers it | Needed by |
|---|---|---|
| Which system decides that a payment has settled? | Your backend lead | Before the design is signed off |
| Who is requesting the live API keys? | The customer's IT team | This week |
| Does the customer need bulk refunds at launch? | Your account lead, with the customer | Before the build starts |
| What usage should the first month reach? | Your sales lead | Before launch |
Got something stuck?
Tell me where it's stuck and I'll give you an honest read on what's blocking it and what it would take to move.