Founding a SaaS on Someone Else’s Infrastructure: The Platform Dependency Trap

The fastest way to ship a SaaS product is often to build on top of someone else’s infrastructure. Connect to Stripe, sit on top of Shopify, extend HubSpot, pipe everything through Twilio. You get to skip months of plumbing and go straight to the thing that actually earns revenue. That trade-off is usually worth making – but only if you’ve thought clearly about what you’re giving up and where the trap is.

The mistake we see most often isn’t founders choosing the wrong platform. It’s founders who never explicitly decided to take on platform risk at all. They just started building, moved fast, and ended up with a product that’s 70% dependent on infrastructure they don’t control. That’s a different situation to one where you made a conscious call, understood the exposure, and planned for it.

This post is for founders in that second camp – or founders who want to be.

What platform dependency actually means

Platform dependency isn’t just about API calls. It’s about where the critical logic in your product lives. If your SaaS product does something genuinely valuable and that logic runs entirely inside a third-party system – inside Zapier, inside Shopify’s liquid templates, inside a no-code tool’s automations – then you don’t really own a product. You own a configuration.

That’s not always a problem. Some businesses are configurations, and they work. But it becomes a problem the moment you want to:

• Change how your core workflow runs in a way the platform doesn’t support
• Move upmarket to customers who have security, data residency, or compliance requirements
• Negotiate on pricing – either yours or the platform’s
• Survive a terms-of-service change, a deprecated endpoint, or an acquisition

We’ve had founders come to us after their Shopify app was effectively cloned by Shopify itself. We’ve seen a payments-adjacent SaaS get blindsided when Stripe changed its Connect fee structure and wiped out half the unit economics overnight. These aren’t edge cases. They’re the normal lifecycle of building on top of a platform that has its own commercial incentives.

The three layers where risk actually sits

When we assess a platform-dependent product for a build or rebuild, we think about risk across three distinct layers – not just “the API might break.”

Distribution risk. If you’re in someone else’s app marketplace, they control discoverability, ranking, and whether you show up at all. Shopify’s app store, Atlassian Marketplace, Salesforce AppExchange – these can be extraordinary growth channels, but the platform sets the rules. That includes rules about which categories they want to fill with their own native features next year.

Data risk. Where does your customer data actually live? If it’s in HubSpot or in Airtable or in a platform’s proprietary datastore, your ability to build sophisticated features on top of that data is constrained. Worse, your ability to migrate customers away – if you ever need to – is a project in itself. We’ve done those migrations. They’re expensive and messy.

Commercial risk. Pricing changes are the quietest killer. A platform moving from flat-fee to usage-based, or adding a new tier that suddenly captures your core use case, can change your unit economics faster than any technical problem. At least a server going down is visible. A margin compression that plays out over six months is not.

When you should absolutely build on a platform anyway

None of this means avoid platforms. The opposite, actually.

If you’re pre-revenue and trying to validate whether a problem is real and whether people will pay, building on top of existing infrastructure is almost always the right call. The speed advantage is enormous. You’re not competing with the platform – you’re riding it. A Shopify app built in six weeks that generates $8k MRR inside three months has proved something real. That’s worth the dependency.

The question we ask founders is: at what point does the dependency become the constraint? For most products, it’s not immediate. The constraint shows up when you hit a specific revenue level (rough rule of thumb: when the platform’s cut or rate changes could meaningfully threaten your margins), or when an enterprise customer asks about data residency and you can’t give them an answer you’re comfortable with.

One fintech we worked with had built a solid business on top of a major payments API. They’d done it well – clean abstraction layers in their own codebase, no business logic baked into the third-party SDK. When the API provider’s pricing changed, they were able to evaluate alternatives in a few weeks and migrate the critical path in a sprint. That’s what smart platform dependency looks like. They used the platform. They didn’t get used by it.

The architectural move that actually protects you

The practical answer is abstraction, and it needs to happen at the right level. Not over-engineered abstraction that costs six months of developer time – targeted abstraction around the parts that carry real switching cost.

When we build products that depend on a third-party platform, we follow a few specific rules:

1. Never let third-party data models leak into your domain model. If Stripe’s subscription object or Shopify’s order object is flowing through your core application logic unchanged, you’ve coupled your domain to theirs. Wrap it. Define your own internal representation and translate at the boundary.
2. Own your customer data. Even if the platform holds the authoritative record, you should be syncing critical data into your own database. This isn’t about distrust – it’s about optionality and performance. You can’t build sophisticated AI features or complex analytics on data you don’t control.
3. Keep your commercial logic in your system, not theirs. Pricing rules, access controls, trial logic – if this lives inside a platform’s configuration rather than your codebase, you have no history, no testing, and no easy migration path.
4. Document the integration surface. Sounds obvious. Rarely done. When the API changes, the team member who built it has often moved on. A maintained integration spec is worth real money when that moment arrives.

None of these steps are expensive. They add a few days of careful thinking up front, and they’re the difference between a product you can evolve and a product you’re stuck with.

The conversation founders avoid having

Here’s the real pattern we see: founders avoid this conversation because it feels like a distraction from building. And early on, it is. You’re trying to find product-market fit, not architect for a pivot that may never happen.

But the window where this is cheap to address is narrow. The first six to twelve months of a codebase is when you can set patterns that persist. Once you have three engineers and two years of committed integration work, untangling platform dependencies is a serious project – often $40k to $120k+ of rebuild time, depending on how deep it goes. We’ve scoped those engagements. They’re not fun conversations.

The question worth asking at the start isn’t “will this platform ever be a problem?” It’s “if this platform changed the rules tomorrow, where would we be?” If the honest answer is “we’d be in serious trouble,” that’s worth a few days of architectural thinking right now.

If you’re building something platform-dependent and you’re not sure whether you’ve got the right abstraction in place – or you’re staring down a migration you’ve been putting off – talk to Amora about your build. This is exactly the kind of problem we work through with founders, usually before it becomes expensive.

The mental model worth keeping

Platforms are partners until they’re competitors. That’s not cynicism – it’s just the commercial reality of how platforms grow. They start by enabling a ecosystem. They mature by internalising the most valuable parts of it.

Your job as a founder is to use the platform aggressively while it’s helping you, build your own moat in parallel, and make sure the architecture you’re putting in place today leaves you with options tomorrow. The founders who get burned aren’t the ones who built on platforms. They’re the ones who confused speed with safety.

Build fast. Build smart. Don’t let the scaffold become the structure.