Back to blog

Essay

We Make Them Listen

published

Integration is a contract problem wearing a code costume. Here is how we design the failure mode out on day one.

Most founders we work with have been through a "digital transformation" before, and they didn't enjoy it. They ended up with a consultancy-grade slide deck, a CRM their sales team refuses to use, a billing system that doesn't quite match the contracts they sign, and an internal data team whose full-time job is pulling CSV exports out of three SaaS tools and stitching them together in Excel. That's the failure mode we design out of every engagement. The phrase itself — systems integration — has earned a bad reputation because it's been sold badly, often by people whose definition of "integration" is "we'll write a Zapier for you." Zapier's fine for a six-person startup; it's not fine for a company carrying twenty million in revenue and an operations team that needs reliable, observable data flows. Integration projects fail the same way, and it isn't the data formats. It's that no one agreed who owned the contract. The "integration" in Systems Integration isn't about code — it's a conversation between two teams with a long shared history, who don't yet trust each other. Until we can write down who owns what, we're not ready to write middleware. Integration is a contract problem wearing a code costume. We do the same thing on every integration. We inventory the contract surface on both sides before we write a line of code. That means a one-page diagram of which system's the source of truth for each data element, who's responsible for retries on the wire, and what the SLA looks like in the unhappy path. The diagram isn't for the engineers — it's for the two business owners who'll be arguing about the data at 11 pm on the second Tuesday after go-live. Once the diagram's signed, the code's the easy part. We have one non-negotiable: every integration layer has to work when one side goes dark. This isn't engineering theater — it's how the two teams stop blaming each other. If we can't agree on what happens when the upstream's down for an hour, we're not integrated. We're connected, which is a different thing. A regional manufacturing client ran a 20-year-old ERP that handled costing and inventory, and they were adding shop-floor IoT sensors that produced 10,000 events per minute. We didn't attempt a two-way, real-time sync. We drew the contract surface together, signed it, and built a one-direction fan-out: the new system pushes events into a queue that the ERP polls on a 5-minute schedule, and the queue has its own contract. The next ERP upgrade will be a 5-minute cutover, not a multi-quarter program. The two systems listen to each other; they don't overhear. The person who felt that wasn't in the server room. It was the operations lead who used to spend the second Tuesday of every month on the phone with a plant supervisor arguing about which system had the "real" inventory count. They stopped having the argument. We're not selling a single platform that replaces your SaaS stack. We're not selling an AI agent that'll figure out your business for you. We're not selling a long-running managed service at a recurring percentage of your revenue. We sell a fixed-scope engagement — six to twelve weeks — that produces a working integration, owned by your team, with the diagrams, the test data, the runbooks, and the playbook for the next integration your team will do without us. The work ships. Your team drives it. We move on. That's the discipline we hold ourselves to — and the one you should hold your current integrator to. Here's a test you can run this week. Ask whoever's building your integrations three questions. Which system's the source of truth for each data element, on one page, in plain English? What happens when the upstream goes dark for an hour — who owns the retry, and what does the user see? And who's the business owner who'll be arguing about the data at 11 pm on the second Tuesday after go-live, and have they signed the diagram? If the answers are a shrug, a slide, or "we'll figure that out in production," you've found the gap. That's the gap we design out on day one — so the person who has to live with the system on day 31 gets their Tuesday nights back too.