The Hardest Problems Live at the Seams: Leading Integration-Heavy Delivery

I'm Tom Lang — I've built and scaled engineering organizations for three decades, from startups to 250-plus engineers and through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

When I look at a massive, stalled software project, I don't look at the individual databases or the UI frameworks. I look at the network calls.

Every engineering team on earth can build a microservice that works perfectly in isolation on their own machine. Projects don't fail because a single API is broken. They fail because the assumptions between the APIs are incompatible. The hardest problems in software engineering don't live in the systems — they live at the seams. I've been solving seam problems my entire career, from wiring plant-floor controllers into mainframes at P&G, to connecting industrial scales and point-of-sale systems to clients' back ends, to making legacy and modern architectures talk to each other. Here's why integration is the true risk, and how I lead teams to engineer the seams first.

The core thesis: death by boundary

My thesis is simple: individual systems are highly testable, but the failure modes live in the gaps.

A seam is anywhere data crosses a boundary — between two of your microservices, between your app and Stripe, between a legacy mainframe and a modern cloud layer. Here's the crucial part: inside a boundary, a single team controls the physics. Across a boundary, no one controls the physics. The seam is where timing assumptions quietly collapse, where two data schemas disagree, and where error handling gets orphaned because each side assumes the other is responsible for it. Every system in the project can pass its own tests and the project can still fail — in the space between them, which nobody owns.

What actually goes wrong at the seams

When integrations fail, it's rarely a typo in the code. It's almost always one of three recurring architectural traps.

The semantic mismatch. Team A's system exports a "Customer" — meaning anyone who created a free account. Team B's system ingests a "Customer" — meaning someone with an active paid subscription. The JSON parses perfectly. The APIs return 200 OK. And the business logic silently corrupts, because the same word means two different things on either side of the wire. These are the worst bugs there are, because nothing errors — it just quietly produces wrong answers for months.

The synchronous death spiral. System A makes a synchronous call to System B and waits for the answer. System B gets slow. System A keeps opening new connections and waiting, until it runs out of memory and crashes. Tight coupling just turned two healthy, independent systems into one massive, fragile monolith — and took down the one that was working fine.

The orphaned error. The data payload is too large, so the receiving system silently drops it. The sending system assumes it was received. Neither one logs a critical error, because each team assumed the other team was monitoring the boundary. The failure isn't in either system; it's in the gap that has no owner.

How I lead integration-first delivery

Most teams build System A for three months, build System B for three months, and try to wire them together in month seven. That is a recipe for a blown deadline, because every problem above surfaces at once, at the worst possible time. I invert the model.

Contracts first. Before a single line of business logic is written, the two teams write and agree on the API contract — the OpenAPI or Swagger spec. The contract is the law. Everything is built against it, and neither side gets to change it unilaterally.

Integration is sprint one — the walking skeleton. In the first two weeks, we build a "dumb pipe." System A sends a hardcoded string — literally "Hello" — to System B, and System B saves it. It has zero business logic. But it proves the network, the authentication, and the deployment pipeline actually work end to end. We de-risk the seam first, while it's cheap to fix, instead of discovering it's broken in month seven.

Explicit boundary ownership. I assign a specific engineer — usually a tech lead — to own the integration layer itself. Their job isn't to build features; their job is to defensively code against the failure of the system on the other side of the boundary. The seam gets an owner, which is the single thing that prevents the orphaned error.

The scar: the physics of the seam

Years ago I led a project integrating highly precise industrial scales on a factory floor into a client's cloud inventory system. In isolation, everything was flawless. The scale broadcast its weight over the network perfectly. The client's cloud system ingested the JSON payload perfectly.

Then we turned it on, and the inventory numbers were completely, wildly wrong.

The seam we'd failed to account for was physical timing. When a 50-pound box dropped onto the scale, the metal physically bounced for about 400 milliseconds. The client's system was polling the scale during the bounce — reading 12 pounds, then 64 pounds, then 50 pounds — and recording whatever it happened to catch. The fix wasn't rewriting the database or buying a new scale. It was writing an integration layer that understood the physical reality of the boundary: ignore all data until the scale reports a "stabilized" flag for a full 500 milliseconds. The hardest problem in the entire project wasn't the software on either side. It was the physics of the seam between them. (It's the same lesson the factory floor taught me — the real world doesn't care that your code is correct in isolation.)

Why this is your moat

Why does this matter to a growth-stage founder? Because modern SaaS is no longer a single application — it's a distributed mesh of third-party APIs. Your product depends heavily on Stripe, Twilio, Snowflake, AWS, Auth0, and a dozen others. You are, whether you think of it this way or not, an integration company.

If you hire a CTO who optimizes individual systems instead of the seams between them, your platform will eventually collapse under its own complexity. When Stripe has a momentary outage — and it will — your entire checkout page goes down with it. I architect the seams first: circuit breakers and asynchronous queues at every boundary, so that when the inevitable integration failure happens, your platform degrades gracefully instead of taking your whole business down. The seam is where your product is most fragile, which is exactly why it's where I spend the most attention.

The honest goal

So when I evaluate a project, I look at the connections before I look at the components — because that's where the risk actually is. Engineer the contracts first, build the integration on day one, give every boundary an owner, and defend the seams as if they'll fail, because they will. Do that and a complex, integrated system becomes robust. Ignore it and you've built a house of cards held together by 200 OK responses.

If your product is a mesh of services and APIs — and these days, whose isn't — and you want someone who's spent a career making systems that were never meant to talk to each other work together reliably, that's exactly what I do. Book a call and we'll look at where your seams actually are.