There is a particular kind of email no founder wants to open.
It is the one announcing that a tool your business quietly depends on is shutting down.
Not a price increase.
Not a feature being deprecated.
The whole thing, going away, on a deadline you did not choose.
If you have been in business long enough, you have probably received a version of this email.
And if you have not yet, you eventually will, because platform risk is one of the most underappreciated threats to a growing company.
This is a guide to thinking clearly about that risk: where it hides, why it is especially sharp for software and app businesses, and how to structure your company so that the disappearance of any single tool is a manageable inconvenience rather than a catastrophe.
Table of Contents
Every Business Is Built on Things It Does Not Control
Modern companies are assembled from other people’s software.
Your payments run through one provider.
Your email runs through another.
Your analytics, your hosting, your customer support, your marketing channels, all of it sits on platforms you rent rather than own.
This is not a mistake.
It is how businesses are supposed to be built now, and trying to own every layer yourself would be slow, expensive, and foolish.
But it does mean that every one of those dependencies is a small bet that the platform will still be there tomorrow, behaving the way it does today.
Most of the time that bet pays off.
Occasionally it does not, and the question that decides how badly you get hurt is one you should ask long before the shutdown email arrives.
How portable is what you have built on top of this platform?
Why Platform Risk Hits Software Founders Hardest
For a software or app founder, platform dependency is not a side issue.
It is often the core of the business.
App developers build on top of an app marketplace they do not own.
They acquire customers through channels they do not control.
And critically, they often run their growth engines, things like affiliate and partner programs, on third-party tools that sit between them and their own customers.
That last category is where platform risk gets genuinely dangerous.
Because when a tool sits in the middle of your customer or partner relationships, its disappearance does not just cost you a feature.
It can sever the relationships themselves.
A recent, concrete example makes this vivid.
A Case Study in Platform Risk
For years, the app developers who built serious affiliate programs largely built them on a platform called Mantle.
It worked well.
Developers tracked referral links, managed partner relationships, and ran their commission programs through it, and many of them came to depend on it as a real growth channel.
Then Mantle announced it was shutting down.
Consider what that actually threatened.
Not just a dashboard going dark, but thousands of working affiliate links, years of partner relationships, and complete histories of who had earned what.
For a developer who had spent years building a referral channel, that is not a minor disruption.
It is a growth engine going dark, with the very real possibility of taking the partner relationships down with it.
This is the nightmare scenario of platform risk.
A tool you trusted with something central to your growth disappears, and the value you built on top of it is suddenly at risk of vanishing too.
So what separates the founders who survive this kind of event from the ones who get badly hurt?
It comes down to portability, and portability is something you can design for in advance.
The Portability Question That Decides Everything
Here is the principle worth tattooing on the wall.
The more your critical assets route through infrastructure you do not control, the more catastrophic that infrastructure’s failure becomes.
The affiliate link example illustrates this perfectly.
Imagine an affiliate program where every partner’s referral link points at the platform’s own redirect service.
When that platform dies, every one of those links dies with it.
Every blog post, every email, every YouTube description your partners ever published now points at nothing.
To recover, you would have to ask every affiliate to replace every link they have ever shared, and many simply never would.
You would watch a referral channel you spent years building quietly evaporate.
Now imagine the opposite design.
The referral links point not at the platform’s servers, but at your own destination, your app’s listing, with the referral information carried as a simple parameter on the end.
In that design, the links do not depend on the platform staying alive.
They resolve to your listing regardless.
The platform behind them can be swapped out, and the links keep working.
Same link, different system reading it.
That single architectural choice is the difference between a survivable migration and a disaster, and it generalizes far beyond affiliate links.
Wherever you can, you want the durable, valuable assets, the customer relationships, the published links, the historical data, to live somewhere portable rather than locked inside a single vendor.
How to Evaluate Your Own Platform Risk
You do not need to panic about every tool you use.
You need to triage them.
Ask these questions about each significant platform your business runs on.
How central is it?
A tool that powers a core growth channel or holds key customer relationships is a high-stakes dependency.
A tool that formats your invoices is not.
Spend your worry where the stakes are real.
How portable is what I have built on it?
If this platform vanished tomorrow, could I take my data, my relationships, and my assets elsewhere?
Or are they trapped in a format only this vendor can read?
How replaceable is it?
Are there credible alternatives I could move to, or is this vendor the only one who does what I need?
A dependency with no alternatives is far riskier than one in a competitive category.
Do I control the relationship, or does the platform?
This is the subtle one.
If your customers or partners interact with you only through the platform, the platform owns those relationships, not you.
The more directly you can reach the people who matter to your business, the less any single tool can hold them hostage.
Run your stack through those four questions and your real exposure becomes clear.
The tools that are central, non-portable, hard to replace, and sit between you and your relationships are the ones that deserve a contingency plan.
What a Good Migration Actually Looks Like
Platform risk is not only about avoiding bad dependencies.
It is also about knowing that when a platform does fail, a clean exit is possible.
The Mantle situation is instructive here too, because it shows what a survivable migration looks like in practice.
Affilitrak for Apps was built specifically as a replacement path for developers caught in that shutdown, and the way it handles the transition is a useful template for what to look for in any migration.
It preserves the thing that matters most.
Because affiliate links in this model already point at the app’s listing with the referral code as a parameter, Affilitrak for Apps simply honors that same code, so every link partners have already published keeps working.
Nothing for affiliates to re-share, nothing to break.
It carries the history across.
Affiliates, their links, their original codes, and their past payout records migrate over so attribution stays intact and nobody loses the record of what they earned.
It makes the move safe rather than nerve-racking.
The migration can be previewed before anything is committed, and it is built to run again without creating duplicates, so it is a controlled process rather than a leap of faith.
And it keeps the partner relationships warm, inviting affiliates into pre-created accounts that already show their carried-over details, so the change reads as continuity rather than a cold restart.
The general lesson, independent of any one tool, is this.
A good migration preserves your assets, carries your history, and keeps your relationships intact.
When you evaluate a replacement for any failed platform, those are the three things to insist on.
Conclusion
Platform risk is the quiet tax of building a modern business on other people’s software.
You cannot eliminate it, and you should not try, because the alternative of owning every layer yourself is worse.
But you can manage it.
Know which of your dependencies are genuinely critical.
Favor designs where your important assets stay portable rather than locked inside a vendor.
Keep your customer and partner relationships as close to you as possible, so no single tool sits between you and the people who matter.
And when a platform does disappear, and eventually one will, judge its replacement by whether it preserves your assets, your history, and your relationships through the move.
The founders who get hurt by platform shutdowns are usually the ones who never thought about it until the email arrived.
The ones who sail through are the ones who built for portability long before they needed it.
Be the second kind.
