Most of the platforms that end up on our desk didn't start out fragile. They started out fine, for a while, doing exactly what they were built to do. What broke them was time. A payment processor changed its pricing. A vendor's system went undocumented and unsupported. The person who understood the original setup moved on, and whoever inherited it had to reverse-engineer decisions nobody wrote down. None of that traces back to a failure by the original team. Any website or application that stays in service long enough runs into this, unless it was built to expect that kind of change.
There's a way to build that avoids most of this, and it's worth understanding even if you never touch a line of code yourself, because it changes what a vendor swap costs your business.
The Problem, in Business Terms
Every website of real complexity connects to outside systems: a payment processor, an email service, a booking platform, a CRM. The easy way to build that connection is to wire the site's core logic directly to that one vendor's system. It works, it's fast to build, and for a while nothing about it looks like a problem.
The trouble shows up later. The vendor discontinues a feature the business depends on. A new compliance requirement rules out the current provider. The organization decides to standardize on a different platform company-wide. At that point, if the vendor's specific quirks were wired directly into dozens of places across the codebase, replacing that vendor means finding and carefully changing every one of those places, with real risk of breaking something that was working along the way. What should be a vendor decision turns into a development project, and the cost of that project is a direct function of how tangled the old vendor's logic became, not how good the new vendor is.
The Fix: A Buffer Between Your Business and Your Vendors
The pattern that avoids this is called ports and adapters, or hexagonal architecture. Software architect Alistair Cockburn first described it in 2005. The hexagon name trips people up, since it isn't about six of anything. It comes from how Cockburn originally drew the diagram, with the hexagon shape simply leaving enough room to sketch as many connection points as a given system happened to need. The name is a little odd. The substance underneath it isn't, and that's what actually matters here.
The idea itself is easier to picture than the name suggests. Think of a shipping port. A shipping port doesn't rebuild its cranes, rail lines, and loading docks every time a new carrier's vessel arrives. It's built around a standard shipping container. Any carrier that shows up with cargo in that standard container can be unloaded using the same infrastructure, regardless of whose ship it is or which country it sailed from. The carrier changes. The port's infrastructure doesn't.
Built correctly, a website works the same way. The core logic, the part that actually runs your business, only ever hands work off to a standard internal interface, never to a specific vendor's system directly. A separate, isolated piece of code handles the translation to whichever vendor is actually in use, the way a port's cranes are built to handle the standard container rather than any one carrier's ship. When it's time to switch vendors, that translation piece gets replaced. The core of the site never has to be touched, audited, or re-tested from scratch.
That difference shows up directly in how a vendor change actually plays out: a quick, contained update instead of a multi-week project with real risk attached.
How It Works, Technically
For the technical stakeholders in the room, here's the mechanism underneath the analogy. The pattern has three parts. A port is the interface itself, a contract stated in the business's own words, such as "send a notification" or "process a payment," with no vendor names or vendor-specific data structures anywhere in it. An adapter implements that port for one specific vendor and absorbs everything about how that vendor's system actually works. A registry, usually a small factory or configuration file, decides which adapter is active at runtime. Application code depends only on the port and never imports an adapter directly.
The trade-off is real and worth stating plainly: this approach costs more to build up front than a direct connection would. There's the interface itself, the vendor-specific piece that implements it, and the logic that decides which one is active, all of which need to be written and kept current, not just the single call a direct integration would require. It only pays for itself once there's a genuine second vendor in the picture, or a credible reason to expect one.
There's also a pattern we've noticed across projects that build this for the first time. The initial interface a team designs tends to carry the fingerprints of whichever vendor prompted the work, because it's genuinely difficult to design a clean abstraction without a second real case to measure it against. That's not a sign the approach isn't working. It typically gets resolved naturally once a second vendor actually gets connected and the interface gets adjusted to reflect what the business needs to say, rather than what happened to be convenient for the vendor that came first.
Why This Matters More the Longer a Site Is in Service
The value of building this way compounds with time, and that's exactly the kind of long-lived, business-critical platform we take on most often. We inherit sites that are years, sometimes decades, into their operating life. Roughly 85% of the platforms that come to us arrive in some state of technical distress, and a meaningful share of that traces back to exactly this problem: vendor-specific logic scattered across the codebase with no consistent structure, working fine until the day it has to change.
We saw a clear version of this on the Design Observer engagement. Design Observer is a media property covering design, equity, technology, leadership, democracy, and more, with an archive of roughly 6,000 blog posts and over 100 podcasts built up over more than two decades, that needed to move off an aging, non-WordPress platform. One piece of that migration connected to an external jobs listings feed with no documentation available for how it actually worked. Rather than let that one unreliable connection hold up the entire project, our team analyzed the feed's behavior directly and built a reliable integration layer around it, while separately preserving every podcast's original audio hosting on AWS intact. The migration took roughly half the total project timeline, and the rest of the rebuild moved forward on its own schedule instead of waiting on that one difficult piece. As Design Observer's Managing Editor, Sheena Medina, put it, it "was a significant technical undertaking, and while there were challenges along the way," our team "ultimately helped us build a stronger, more sustainable foundation for the future of Design Observer."
We've also lived this on the other side, with a vendor decision rather than a vendor problem. Horizon Services is a home services client we've maintained for more than six years, across a portfolio that grew to 34 websites. Horizon originally ran a custom-built appointment booking system before the organization made the business decision to standardize on ServiceTitan platform-wide. We built the integration that now pulls updated service-area zip codes from the ServiceTitan API on a weekly basis and automatically refreshes the location maps across Horizon's sites, eliminating manual updates and reducing routing errors.
Where Domain-Driven Design Fits
Ports and adapters solve one problem: how your core business logic talks to the outside world. A related but separate discipline, domain-driven design, solves a different problem: how that core business logic gets organized in the first place. We approach custom application development, particularly Laravel projects, through domain-driven design specifically because it forces the codebase to be structured around the actual business processes an organization runs, described in language both developers and business stakeholders can use in the same conversation, rather than around whatever technical shortcuts happened to be convenient at the time.
The two disciplines reinforce each other in a way that matters for anyone evaluating a development partner. A well-designed port speaks in domain language, such as "process a payment" or "look up a member record," never "call the Stripe endpoint." Designing a port that clean requires already having a clear model of the business domain, because a port that leaks vendor-specific vocabulary into its interface isn't really a port. It's a wrapper wearing a port's name, and it gives back none of the benefit. In practice, this is one of the clearer signals of whether a development team is building for the long term or just making the current request work.
Why This Should Matter to Marketing and Operations Leaders, Not Just Developers
A locked-in integration shows up as a business problem well before it shows up as a technical one, which makes it more than an engineering concern. It shows up as a marketing team that can't switch email platforms without a development sprint. It shows up as finance flagging a vendor's rising costs, only to learn the switch will take longer and cost more than the savings justify. It shows up as a leadership decision to consolidate systems after an acquisition, delayed because nobody can say with confidence how deeply the old vendor is wired into the site.
Asking a development partner whether a platform is built this way, before a vendor decision becomes urgent, is a reasonable question for anyone responsible for a company's digital operations, not just for the engineering team.
Where We Don't Recommend This
This approach costs more to build up front than wiring directly to a vendor, and we're direct about that rather than treating it as something every project needs. Our internal rule of thumb: one vendor with no real plan for a second doesn't need this treatment. Two vendors, or a genuine business conversation about adding a second, such as Horizon's move to ServiceTitan, is usually the point where the investment pays for itself.
The Actual Payoff
The real test comes on the day, months or years into a platform's life, when a vendor decision has to be made and the business needs to move quickly. A payment processor raises its rates. A vendor's system quietly stops being maintained. The organization decides to standardize on a new platform, the way Horizon Services did. On a site built with vendors wired in directly, that day means a development team reading and carefully changing every file the old vendor touched, with real risk to production along the way. On a site built with this buffer in place, that day means writing one new connection and flipping a switch.
