On most projects the riskiest component is one we did not build. A payment gateway, a courier's tracking API, a government identity check, a maps provider, an SMS service. Our own code we can fix at midnight. A vendor's sandbox that behaves differently from production, or a go-live approval queue that takes three weeks, we cannot. So every third-party integration on my projects gets treated as a risk item from the first week, with its own owner and its own fallback.
Why do third parties bite so often?
Because a third-party service sits outside the plan's control and inside its critical path. The same failure modes repeat: documentation for a version the vendor no longer runs, a permissive sandbox followed by a strict production endpoint, unread rate limits, a vendor-side compliance review, and a deprecation email nobody opened.
None of these are exotic. All of them are invisible on a Gantt chart, because "integrate payment gateway, five days" looks like any other task. The compliance review is the one that hurts most, because it starts only after you submit the finished integration, which is to say after the point where the plan assumed you were done.
What do I check in week one?
Five questions, answered before the integration is scheduled: do we hold sandbox credentials today, how long does production approval actually take, what are the rate limits and the price at real volume, what does the user see when the service is down, and who at the vendor answers the phone.
- Do we have sandbox credentials in our hands today, or has someone promised them?
- How long does the vendor's production approval take, measured from someone who has done it recently rather than from the vendor's own page?
- What are the rate limits and the price at our real volume, and at three times that?
- What happens to the user when the service is down, and has anyone designed that screen?
- Who at the vendor answers the phone, by name, when it breaks?
I do not let the work be scheduled until all five have answers. The approval question is the one that moves dates. Payment providers and identity services in particular have review steps that can add weeks, and those weeks belong at the start of the plan, running in parallel with the build, rather than at the end where they usually get discovered.
Isn't buying an integration supposed to reduce risk?
It trades one risk for another. Buying moves the engineering work onto a vendor who has solved the problem many times, which is worth paying for. It also moves your timeline onto that vendor's approval queue and your uptime onto their status page, neither of which you control.
I keep an eye on how the build-versus-buy line has moved, because for a growing set of small integrations, building a thin version ourselves is now faster than getting through a vendor's onboarding, and it leaves the client owning something they can change. That is a delivery decision as much as an engineering one. If the vendor's approval takes longer than the build of the feature it enables, that belongs on the risk register with a date, and the client should hear about it in week one.
What does the fallback look like?
Three habits. Build against a stub in the first sprint, so the rest of the product does not wait. Integrate for real the day credentials land, never in the final sprint. And design a degraded mode for every integration, so the product still does something useful when the service is down.
| Integration | What can hold the date | The fallback we build |
|---|---|---|
| Payment gateway | Vendor-side compliance review before go-live | Stubbed checkout so the rest of the flow ships |
| Courier tracking | Rate limits discovered at real volume | Order saves, label prints later, user is told |
| Identity check | An approval queue measured in weeks | A manual review path for the first cohort |
| SMS or maps | An outage on the provider's status page | A visible message instead of a dead screen |
Integrating early matters more than it sounds, because a real integration always teaches you something the documentation did not. The degraded mode is a design task rather than an error handler: if the courier API is down, the order still saves and the label prints later, with a message that says so.
At Shanti Infosoft the integration list is reviewed in every weekly status report until each item has cleared production approval. It is the dullest recurring line on a web development project and the one I refuse to drop, because dull is what keeps the launch date attached to reality.
Which third-party service on your project could hold your launch date hostage, and does anyone own the relationship?
Sonal Jain runs project delivery at Shanti Infosoft, a CMMI Level 5 team that has delivered for 700+ companies.
Top comments (0)