Our developer says they can build the integration themselves with AI coding tools. Should we let them?
For a first version, often yes. Writing the code is no longer the hard part. The hard part is the two years afterward: credential rotation, retry logic, monitoring, backfills, and someone available when a vendor changes an endpoint. Ask who is on call, what happens when that person leaves, and whether anyone else can explain the field mapping.
Coding tools compress the smallest part of the work
Getting data from one API into another on a good day is maybe a fifth of an integration. The rest is everything that happens on a bad day: partial failures, duplicate prevention, deduplication, rate limits, schema changes, time zone handling, pagination edge cases, expired tokens, and knowing which of those occurred at six in the morning.
A capable developer with modern tooling will produce a working prototype fast, and it will look finished. It will not have any of the above, because none of it is visible until real data arrives at real volume.
The questions that decide it
- Who is paged when it fails? If the answer is the person who wrote it, on their phone, forever, that is the real staffing plan.
- What happens when they leave? Is the mapping documented well enough for a successor, or does it live in one person's head?
- Who handles vendor changes? Someone has to read deprecation notices and act on them months ahead.
- Where does it run, and who owns that account? Personal cloud accounts are more common than anyone admits.
- Is this the highest-value use of your only developer? Usually the answer is no.
Where in-house genuinely wins
Build internally when the logic encodes something specific to how you compete - a proprietary scheduling rule, a pricing method, a workflow nobody else runs. That knowledge is hard to transfer and valuable to own, and an outside party will always be a step behind it.
Buy or outsource the plumbing: authentication, sync, retry, monitoring, normalization. That work is identical across companies, deeply unglamorous, and its value comes from having already hit the failure modes rather than from cleverness.
A split that usually works
Let the outside integration layer own connectivity and reliability, and let your internal people own the business logic on top of it. Your developer spends their time on things only your company needs, and nobody is on call for a token refresh.
That division is essentially the shape of our two offerings: a configurable platform that handles the connective work, and custom development for the part that is specific to you. When the platform covers most of a problem, we customize the remainder rather than rebuild the foundation - see how the layers fit together.
Topics: build vs buy · in-house · maintenance · staffing
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.