Building on Someone Else’s Land: The Platform Risk Nobody Prices In

A business rang us a few years back, one we’d never worked with, because their booking flow had stopped working overnight. Nothing had been deployed, nobody had touched the code, and the site was otherwise perfectly healthy. We were looking at a codebase we’d never seen, hunting for a change nobody had made: a service they relied on had changed how one of its functions behaved, given plenty of notice in a developer newsletter nobody at the business had ever subscribed to, and switched off the old way on a Tuesday.

The fix wasn’t dramatic. The realisation was. This is platform risk in its everyday form: their business had a dependency they’d never consciously agreed to, sitting underneath a part of the site that made them money, and they found out about it the way most businesses do.

What platform risk actually is

Platform risk is the exposure you carry when something your business depends on is controlled by somebody else, who can change it, price it, restrict it or retire it without asking you.

It’s worth being clear that this isn’t a problem to be eliminated. Every business runs on platforms it doesn’t own. Your payment provider, your email, your accounting software, the cloud your site sits on, the app stores, the search engine that sends you customers, the social platform your audience lives on. Building all of that yourself would be absurd, and far more expensive than the risk you’d be avoiding.

The useful comparison is a leased shopfront. Leasing is a perfectly sound decision, and almost every retailer makes it. What you wouldn’t do is spend two hundred thousand dollars on a fit-out without reading the lease, checking how long you’ve got, or knowing what happens at renewal. That’s the part businesses skip with software, routinely, because the lease isn’t a document anyone hands you.

The three ways it actually bites

The price changes. This is the common one, and it rarely arrives as a simple increase. It arrives as a restructure: the tier you’re on stops existing, usage is metered differently, or the feature you built around moves to an enterprise plan. Your costs don’t go up ten per cent, they go up in a way that’s hard to compare and hard to argue with.

The rules change. A platform tightens what it allows, and something you’d built becomes non-compliant. Access to data you were reading gets restricted. A permission that used to be granted routinely now needs a review process. This is the one that hurts campaigns and integrations most, because the change often lands with a deadline attached.

It goes away. Less frequent, more total. A product is discontinued, a company is acquired and folded into something else, an open-source project stops being maintained and quietly accumulates security problems nobody is fixing. You’re given a migration window, and it’s never as long as you’d like.

Which dependencies are actually risky?

Not all of them are, and treating them as equally dangerous will just make you slow. Four questions sort them fairly reliably.

How much of your value lives there? A tool that formats your invoices is a different proposition to the platform holding every customer record you’ve ever had. Depth of dependency matters more than number of dependencies.

Can you get your data out, in a form you could actually use? Not “is there an export button.” An export that produces a PDF of what a person would have seen on screen is not your data. A complete, structured export that another system could read is. This single question separates most recoverable situations from most painful ones.

How hard would it be to leave? Think in weeks, not in principle. If the honest answer is “everything we do is built around how this thing works,” you don’t have a supplier, you have a landlord.

Is your use case core to their business, or incidental? This is the one people miss. If you’re a paying customer doing exactly what a platform sells, you’re reasonably safe. If you’ve found a clever way to use something for a purpose it wasn’t designed for, and you’re not really the customer they’re building for, that cleverness is the thing most likely to be taken away. Free tiers deserve particular suspicion here. If you aren’t paying, you have no leverage and no contract, and the thing you’re depending on is a marketing expense to somebody.

The cheap insurance

Most of what protects you is inexpensive when it’s done during the build and expensive to retrofit afterwards. That timing is the whole point.

Keep your own copy of your own data. If customer records, orders or content only exist inside a third-party platform, you’re one account suspension away from a very bad month. A scheduled export into storage you control costs very little and answers the worst version of the question.

Put a thin layer between your system and theirs. Rather than scattering references to a specific provider through everything, we route them through one small piece of code that speaks to it. It’s a modest amount of extra work at the time. It’s the difference between swapping a provider in a fortnight and rewriting half a system.

Know who’s watching. Someone should be receiving the deprecation notices, and it shouldn’t be a developer who left in 2023. This is a genuine argument for an ongoing support arrangement, but even a shared mailbox that the right people can see is better than nothing.

Write down what you actually depend on. Most businesses can’t produce this list, which is why the risk stays invisible. It’s an hour’s work to produce and it turns a vague worry into something you can look at.

Take the risk, price the risk

None of this is an argument for building everything yourself, and I’d be suspicious of anyone who used it that way. Standing up your own version of a payment platform to avoid depending on one is a much worse trade than the dependency.

The argument is for making the decision consciously. When we recommend a platform, the reasoning should include what it would take to leave it, and that should be a sentence you’ve heard rather than a discovery you make in year three. A dependency you’ve chosen with your eyes open, with your data safe and an exit that’s merely annoying rather than existential, is a good business decision. The same dependency, unexamined, is a bill you haven’t been shown yet.

Your business is going to be built on someone else’s land. That’s fine. Read the lease.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He’s a great believer in depending on other people’s platforms, and in knowing exactly what it would cost to stop. Reach out to Simon to talk through where your business is exposed.