The Real Cost of Building on Top of a Platform vs. Owning Your Own Stack

A founder we talked to last year had built a solid scheduling tool on top of a popular workflow platform. Twelve thousand dollars a month in revenue, growing steadily, legitimate product-market fit in a niche vertical. Then the platform changed their API pricing. His margin went from 68% to 11% overnight. He had 90 days to either rebuild from scratch, eat the cost, or shut down. That's not a cautionary tale — that's just what platform dependency looks like when it matures.

The build-on-a-platform vs. own-your-stack decision gets framed as a cost conversation. It isn't. It's a control conversation. Cost is just the most visible symptom. When you build on top of Salesforce, Shopify, ServiceNow, or any other established platform, you are renting leverage. You get distribution, trust, and infrastructure at a discount. What you're paying with is optionality — and that bill comes due in ways most founders don't see until they're already committed.

We've built both ways at Phaseable. OpsFlow, our K-12 facility management platform, runs on a stack we own entirely — .NET, Blazor, SQL Server. We made that decision early and deliberately. For the W.L. Petrey wholesale ordering platform, we built on top of their existing ERP integrations rather than replacing the underlying system. Both were right for their context. But the factors that drove those decisions are rarely talked about with the specificity they deserve. That's what this post is about.

What 'Building on a Platform' Actually Means

There's a spectrum here and it matters to define your position on it before evaluating cost. At one end, you're building a native app inside another product's ecosystem — a Salesforce AppExchange listing, a Shopify app, a Microsoft Teams tab. You live inside their marketplace, follow their UI conventions, use their auth, and get discovered through their network. At the other end, you're using a platform as infrastructure glue — hitting their APIs to pull data, pushing updates, syncing records — but your product has its own identity, its own frontend, its own billing relationship with the customer.

The risk profile is completely different between these two positions, and most founders don't realize which one they're actually in. If your product cannot function without the platform — if removing it breaks the core loop — you're in the first category regardless of how your architecture looks. If the platform is one of several data sources your product orchestrates, you have more leverage. Understanding this distinction is the prerequisite to everything else in this analysis.

• Native ecosystem apps: Your go-to-market is the platform's marketplace. Your UX follows their design system. Your pricing is subject to their revenue share, often 20-30%.
• API-dependent products: Your product is independent, but critical functionality relies on third-party uptime, rate limits, and schema stability.
• Infrastructure platform dependency: You're running on AWS, Azure, or GCP. High lock-in at the infrastructure layer, but this is generally the most stable bet.
• Data platform dependency: Your product's value is derived from data that lives in someone else's system — an ERP, a CRM, a POS. When they change the schema or kill an endpoint, you feel it.

The Costs That Show Up on Day One

Let's start with the obvious stuff, because it actually matters more than people give it credit for. When you build on a platform, your initial velocity is real. You skip authentication infrastructure, you skip payment processing, you skip building trust with buyers who already trust the host platform. A Shopify app developer doesn't need to explain to a merchant why their credit card is safe. That trust transfer is worth something — sometimes a lot.

But the revenue share is an immediate structural cost that compounds. If you're in a marketplace that takes 20% and your net revenue retention is 110%, you're not really retaining 110% — you're retaining 88% after the platform takes its cut. That math doesn't break you early, but it absolutely shapes your ceiling. The platform's take is a fixed cost of revenue that doesn't go down as you scale in the way that, say, hosting costs do.

On the owned-stack side, your day-one costs are higher in time, not always in money. You're writing auth from scratch — or more accurately, integrating something like Auth0 or ASP.NET Identity, which is still engineering work. You're designing your own data model. You're building your own deployment pipeline. For OpsFlow, those early weeks felt slow compared to what we could have done with a low-code platform or by building inside an existing EdTech ecosystem. But we never had to ask permission to change how something worked. That's not a soft benefit — it's a structural one.

The Costs That Show Up at Scale

This is where the real accounting happens. Platform-dependent products have a scaling profile that looks great early and gets progressively worse. The pattern is almost always the same: the platform was built for a general use case, your use case is specific, and the more specific your requirements become, the more you're fighting the platform's assumptions instead of building product.

In K-12 facility management specifically, the workflow for tracking a maintenance request through an approval chain is not generic. It involves principals, district operations directors, state compliance checkboxes, and budget codes that change every fiscal year. If we had tried to build OpsFlow on top of a general-purpose work order platform, we would have spent half our engineering time mapping their data model to our domain instead of solving problems that actually matter to school districts. That's a hidden cost that doesn't show up in any pricing page.

Platform dependencies also create a specific kind of technical debt we call 'schema debt.' Every time the host platform updates their data model — and they will, especially if they're growing — you have a maintenance burden. For the Petrey ordering platform, one of our primary engineering challenges was ensuring that our custom ordering logic stayed synchronized with their ERP's evolving product catalog structure. That's ongoing engineering cost that disappears entirely when you own the data model yourself.

• Revenue share compounds: 20% off the top at $10K MRR is $2K. At $100K MRR it's $20K — that's a salary.
• API rate limits cap your product's performance: If your core feature requires real-time data sync and the platform limits you to 1,000 API calls per hour, that's not your product's limitation — it's theirs.
• Roadmap misalignment increases over time: The feature you need to win a key account is a low priority for the platform. Now you're either waiting or hacking around it.
• Enterprise deals hit a ceiling: Large buyers often won't sign contracts that route their data through a third platform they haven't vetted. This is especially true in healthcare, education, and government.
• Exit valuation takes a haircut: Acquirers apply a discount to platform-dependent revenue because they're buying platform risk alongside your product.

The Specific Risk Nobody Talks About: Platform Pivots

Platforms pivot. They decide to build the thing you built. They kill API access for competitive products. They change their pricing model. They get acquired and the acquirer has a different strategy. None of this is hypothetical — it has happened to builders in nearly every major ecosystem. Twitter's API changes wiped out entire categories of social media management tools. Intuit has a history of acquiring successful QuickBooks apps and then replicating their functionality natively. This isn't malicious — it's just how platform economics work.

The question to ask is: if this platform changes its terms or kills the API I depend on, how long does my business have to respond? If the answer is less than six months, you're in a fragile position. If the answer is 'we'd be gone,' that's not a business you own — it's a business you're borrowing.

Owned stacks don't have this problem in the same way. Your infrastructure provider — AWS, Azure, whatever — can raise prices, but they're not going to replicate your K-12 facility management workflow and undercut you. The competitive moat in vertical SaaS comes from domain depth, not from being first in a marketplace. And domain depth is only possible when you control the product surface area completely.

When Building on a Platform Is the Right Call

This isn't a blanket argument against platforms. There are specific scenarios where building on top of an existing ecosystem is the correct strategic move, and being honest about them matters.

The clearest case is when the platform's distribution is the product. If you're building a Shopify app where the value to the merchant is that it's inside Shopify — same login, native-feeling UI, App Store discovery — then fighting that integration would be fighting your go-to-market. The platform isn't a dependency risk there; it's a feature. Similarly, if you're building an extension for a product like Notion or Figma where the entire value is being contextual to the host product, you're not a victim of the platform — you're a participant in an ecosystem.

Another legitimate case is validation speed. If you're testing a hypothesis about whether anyone will pay for a thing, building on a low-code platform or using a robust third-party API to fake the infrastructure can buy you signal in weeks instead of months. The failure mode is when founders validate on the platform and then never migrate — they confuse 'this works for 10 customers' with 'this architecture works for 100 customers.'

• The platform's distribution is genuinely your go-to-market, not just convenient
• You're in a pure validation phase and willing to rebuild after achieving signal
• The platform has contractual commitments to API stability (rare, but they exist)
• Your target buyer already lives inside the platform and switching costs are high
• The platform is infrastructure, not a product layer — cloud providers, payment processors, email delivery

How to Actually Calculate the Tradeoff

Here's the framework we use when evaluating a new product opportunity. It's not fancy, but it forces the honest accounting that most founders skip when they're excited about building.

First, map every capability your product requires and categorize it as owned, rented, or borrowed. Owned means you built it and control it. Rented means you're paying for infrastructure you don't control but that has stable, contractual terms — Stripe, Twilio, SendGrid. Borrowed means you're using an API or integration that can change without notice and without compensation. Your goal is to understand the ratio. Heavy borrowed dependencies in your core product loop is a red flag.

Second, estimate the 'migration tax' for each major dependency. If this API disappeared tomorrow, how many engineering weeks would it cost to rebuild that capability from scratch or find an alternative? If the answer is more than four weeks for any single dependency, that's a business risk that should be on your radar. This isn't about being paranoid — it's about knowing what you're holding.

Third, look at your 36-month revenue projection and model two scenarios: one where the platform costs and terms stay constant, and one where the platform raises API pricing by 3x or introduces a new revenue share. What does your unit economics look like in scenario two? If it's ugly, you need a mitigation plan before you need it urgently.

1. 1Map every product capability as owned, rented, or borrowed
2. 2Estimate migration tax for each major dependency in engineering weeks
3. 3Model your 36-month unit economics under current platform terms and under a 3x pricing change
4. 4Identify which dependencies sit in your core product loop vs. your periphery
5. 5Ask: if this platform built what I built, would my business survive? If not, reconsider the architecture.

What Owning Your Stack Actually Costs — Be Honest

Owning your stack is not free, and anyone who tells you otherwise is selling something. The upfront cost is real engineering time on infrastructure that doesn't ship features. Auth, role management, multi-tenancy, deployment pipelines, monitoring, database backups — these aren't optional and they're not quick. For OpsFlow, we invested significant early engineering cycles into getting multi-tenant data isolation right before we wrote a single line of facility-management-specific code. That was the right call, but it was a real cost.

The ongoing cost is maintenance and operational responsibility. When you own the stack, you own the 3am PagerDuty alert. You own the compliance conversation with the school district's IT director who wants to know where data is stored and who has access. You own the penetration test the enterprise prospect asks for before signing. These aren't reasons not to own your stack — they're costs to factor in honestly. For a serious vertical SaaS, they're worth it. For a side project you're using to test an idea, they might not be yet.

The calculus shifts meaningfully based on team composition. If you're a solo non-technical founder, owned stack costs are higher because you're paying engineers to build the infrastructure layer. If you have technical co-founders who have built this kind of infrastructure before, the cost drops considerably — not because the work disappears, but because experienced engineers move through it faster and make fewer expensive mistakes.

The Compounding Advantage of Owning Your Data Model

There's one benefit of owning your stack that doesn't get talked about enough in the context of where software is going: your data model is your AI training ground. When you own your schema, you own the context. You can query it any way you want, build ML features against it, fine-tune models on domain-specific patterns, and expose it to AI tooling on your own terms.

Platform-dependent products don't have this. Their data lives in someone else's schema, behind someone else's API, with rate limits and access controls they don't control. As AI capabilities become a competitive differentiator in vertical SaaS — and they already are — this becomes a meaningful structural advantage for owned stacks. We're already seeing this with OpsFlow: because we own the maintenance request data, the work order history, the asset lifecycle records across multiple school districts, we can build predictive features that a platform-dependent competitor simply cannot.

The companies that will win in vertical SaaS over the next decade are the ones whose data assets compound over time. That compounding only happens when you own the asset. Platforms own the data generated inside their ecosystem. When you build on a platform, you're helping them compound their data advantage, not yours.

The Decision, Simplified

If you're building a vertical SaaS that you intend to own as a long-term business — one where the product will get deeper and more specific over time, one where you're accumulating domain-specific data, one where you'll eventually sell to enterprise buyers who care about where their data lives — build on your own stack. Accept the upfront cost. Own the infrastructure. It will feel slower at the start and dramatically better at year three.

If you're building an integration layer, a workflow tool that extends an existing platform, or a validation experiment — use the platform. Move fast. Get signal. But be explicit with yourself about when the experiment ends and when migration begins. The worst outcome isn't choosing wrong initially — it's choosing wrong initially and then never revisiting the decision because the business got comfortable.

The founder with the scheduling tool we mentioned at the start eventually rebuilt his product. It took eight months and cost him two of his four engineers. He came out the other side with a product he owned, better margins, and no single point of failure he didn't control. He told us afterward that the platform felt like a shortcut that turned into the long way around. That's a clean summary of the tradeoff. The owned stack isn't the easy path — it's the path where the difficulty is front-loaded instead of back-loaded. For founders who are serious about building something durable, that's usually the better deal.