Build vs. buy: how to actually decide on your next integration
The "should we build this ourselves" thread shows up every week, and it almost always gets answered with a build estimate. The build estimate is not the question. Here is the checklist that actually decides it.
A version of the same thread shows up in the platform subreddits every week: someone is scoping a new integration, and asking whether to build it in-house or bring in a platform or a vendor. Almost every reply answers a different question than the one that was asked. They estimate how long the build would take. That is the wrong number to anchor on, and it is why so many of these projects get re-litigated eighteen months later.
The most useful reply in one of those threads was not about the build at all. It was a question back: who is going to own this in a year, when the person who built it has moved teams? Almost nobody scoping a new integration answers that question before they start. They answer it by accident, six months after launch, when something breaks and three people get looped in to figure out who understands the flow.
The question people actually ask
"Can we build this ourselves" almost always gets answered as a skills-and-time question: do we have someone who knows this API, and how many sprints will it take. That is answerable, which is exactly why it is the question people default to. It is also the wrong scope. A cleaner version is: who maintains this after it ships, and what does it cost when it needs to change, break, or scale — not just what it costs to stand up.
What the build estimate leaves out
- Edge cases found after launch. Deletes, duplicates, schema drift and currency handling rarely make the original estimate, and they are most of the post-launch work.
- The on-call question. Someone owns the pager when the flow fails at 2am. On a small team, that is usually whoever built it, indefinitely.
- Change requests never stop. The business asks for a new field or a new rule every quarter. Each one is a new small project competing with whatever else that engineer is doing.
- Turnover risk. The person who built it eventually leaves or moves teams, and the flow becomes undocumented infrastructure nobody wants to touch.
- The opportunity cost. Every sprint spent on integration maintenance is a sprint not spent on the product your team is actually staffed to build.
A rough way to sort it
| Signal | Leans build it yourself | Leans have it built and run |
|---|---|---|
| Number of systems involved | One pair, simple objects | Several systems, real business logic |
| In-house platform skill | Someone already owns this stack | Nobody wants to be the integration expert |
| Change frequency | Set once, rarely touched | Rules and fields shift every quarter |
| On-call capacity | Team already carries a pager | No one wants 2am ownership of a sync job |
| What breaks if it fails | Low-stakes, easy to notice and fix | Revenue, orders, or compliance data |
The structural fix
None of this means build-it-yourself is wrong — plenty of integrations are simple enough that an afternoon and a native connector is the right call. The pattern above only bites on the integrations that touch real business logic, because those are the ones that keep changing and keep needing an owner. That is the exact shape of problem Weldforge is built for: you describe the outcome in plain English, senior architects plus AI build it, and we deploy and run it for a flat monthly fee. Edge cases get handled before launch, not discovered after it. We get paged when it breaks; you get a status update. The build was never really the hard part — we just also take the part that comes after.