There is one engineer at your company who knows how the integrations work. Salesforce to NetSuite, Stripe webhooks to the ledger, the partner SFTP that moves real money on Thursdays. All of it.
She goes on parental leave next month.
She leaves a Notion page behind. Twelve bullet points. Mostly correct.
Three weeks in, the first flow breaks in a way nobody else on the team can read. It’s running in a self-hosted n8n container that hasn’t been image-bumped in eighteen months. No version history. No tests. The last entry in the audit trail says “updated mapping.” When, why, against which version of the upstream schema? Nobody at the company can tell you.
You pay a contractor fourteen grand to rewrite it from scratch. That’s the cheap option.
This is the integration bus factor: the number of engineers in your company who can read, debug, and ship changes to your integration layer without paging the builder. For most mid-market engineering orgs, the number is one. Sometimes zero, and the company doesn’t know yet.
Why this bus factor is the worst bus factor
Every engineering org carries some single-point-of-failure risk. The auth service has its expert. So does the billing pipeline. So does the warehouse. That’s normal. It shows up on hiring docs and gets argued about in staff meetings.
The integration layer is worse, and it’s worse in a particular way: nobody hires for it.
Companies hire backend engineers and platform engineers and data engineers and SREs. They don’t hire integration engineers. So integration work falls to whichever engineer happens to be in the room when a vendor needs to get wired up, and it stays with that engineer indefinitely because nobody else volunteers to learn it. There’s no career path, no internal community of practice, no second person who knows.
The tools make it worse. A Zapier account is one login. A self-hosted n8n container has one admin. The mapping logic lives in a low-code canvas that the platform team doesn’t run and the SRE team can’t trace into. So the engineer who built it is the only person who can read it, and that means they’re the only one who can change it.
And the failure mode is silent. When the auth service goes down, every dashboard lights up. When the integration that posts orders to NetSuite stops working, accounting finds out on the 15th of the next month while reconciling.
So you end up with a class of production system that’s load-bearing, illegible, owned by one person, and only observable through invoice reconciliation. That’s the integration bus factor. It’s worse than any other bus factor your company is carrying.
How to audit your own stack in 30 minutes
The audit is short. It takes an afternoon and tells you everything.
Open a spreadsheet. Five columns: integration, what it does, where it runs, who built it, who else can debug it without asking the builder.
Now fill it in. Not from documentation. Documentation is a lagging indicator. Fill it in from memory and Slack search. Slack is the truth.
For each row, ask:
- If this broke on a Friday night, who gets paged?
- If that person is on PTO, who’s the backup?
- If the backup doesn’t exist, what would it take to make this readable to someone new?
For most companies the spreadsheet ends up looking like a binary tree where every leaf is the same name. One engineer owns the Salesforce stuff. The same engineer owns the NetSuite stuff. Probably also the homegrown EDI pipeline that customer #4 still uses.
Now do a second pass. For each row, write down what happens if the integration fails silently for 24 hours. Not loudly. Silently. The webhook delivers a 200 but the downstream system rejects the payload. The cron fires but the database connection times out. The retry loop never logs the original failure.
If you can’t answer that for a row, the integration isn’t in production. It’s running in production. There’s a difference, and the difference is whether you’ll find out at 9 AM Monday from a dashboard or at 4 PM Friday from a customer.
What you’ll find
There’s a cottage industry of Lambda functions sitting in two AWS accounts somewhere. Ten of them, maybe fifteen. They share no logging convention. A few of them post to a Slack channel that was archived in 2024. Nobody knows what most of them do, and removing any of them feels too risky to schedule.
There’s the one-flow-per-vendor sprawl. The self-hosted n8n instance has 47 active automations. Of those, maybe nine actually matter. Nobody has audited the other 38 in over a year because the tool doesn’t surface which ones have run recently or which executions succeeded.
And then there’s the load-bearing duct tape. One workflow, somewhere, that quietly moves real money or real customer data. It was built in a hurry. It has been working ever since. Nobody touches it. Nobody remembers the assumptions it makes about the upstream API. The engineer who built it left in 2023.
That last category is where the hidden integration cost lives. Not the license invoice. The latent rebuild cost on the day the duct tape gives way, plus whatever the business loses between when it breaks and when anyone notices.
The fix is one your stack already knows
Every other part of your production stack got out of the bus-factor-of-one regime the same way: source control, observability, and the discipline of making changes reviewable by people who didn’t write them. None of these are exotic. They’ve been table stakes for application code for fifteen years. Integration platforms mostly skipped the meeting.
Git turned tribal knowledge into history. You can git blame any line in your application code and find out who wrote it, when, and why. Integration platforms mostly haven’t shipped this. The ones that claim to usually mean “we export JSON snapshots to a directory,” which is to backup what git log is to archaeology. You want real branches, real diffs, real pull requests. If your integration platform doesn’t have them, your integration layer is the part of your stack still running like it’s 2014.
Observability did the same for runtime. Distributed tracing means any engineer can follow a request across services and read what happened without owning the code. Most integration platforms still treat traces as a premium feature, gated behind enterprise tiers, which is how you end up with workflows you can’t debug unless the original author is in the Slack thread — the same gap between “it ran” and “it worked” that makes integration stacks unobservable in general. OpenTelemetry on every workflow, on every tier, is what makes an integration legible to someone who didn’t build it.
Reviewable artifacts mean someone other than the author can sign off. A Decision Table is a reviewable artifact. A JSON Schema is a reviewable artifact. A click-and-save automation canvas is not. When the artifact isn’t reviewable, the person who built it is the only one who can change it safely. That’s the bus factor showing up as architecture.
When this doesn’t apply
If your integration surface is genuinely small — five flows, nothing load-bearing, all read-only — the bus factor doesn’t matter. Run the audit anyway because it takes 30 minutes, but stick the result on the fridge, not in the ops review.
If you’re a 20-person startup, the bus factor on every part of your stack is 1. That’s not an integration problem, that’s a startup. Worry about it when you cross 100 people, or when accounting starts asking pointed questions about reconciliation breaks.
Do the audit
If the integration bus factor in your company is 1, you already know. You don’t need a blog post to tell you.
What you need is to either grow the number on purpose, or move the integrations onto something that lets the rest of your engineering org read them without asking. Koodisi is one option for the second path. Git-versioned workflows, OpenTelemetry traces on every tier starting at $0, Decision Tables that look like reviewable artifacts because they are. The Community tier gives you 1,000 executions a month with no credit card. Move one flow over and see what happens when it becomes legible.
Or just run the audit. Either way, do it this week. The next engineer who takes PTO is the one you weren’t expecting to lose.