There is a category of product — legal, useful, and genuinely well-engineered — that is deliberately designed so that leaving it costs more than staying. Not because the product is bad. Because the product is good enough that by the time you realize the exit is expensive, you have already invested too much to leave cheaply.

The web development industry has built an entire generation of practitioners and an entire layer of client infrastructure on top of exactly this model. And the conversation about what that means — for the people who build websites, for the businesses that commission them, and for the next generation of developers deciding what skills to actually acquire — is almost never had plainly.

This article is an attempt to have it plainly. Not to attack any platform, not to dismiss the genuine craft of people who use them well, but to name the structure clearly and look at what it means over a five-year horizon. Because the math, once you run it, is not ambiguous.

There Is a Name for This Business Model

The pattern has a proper name in business strategy circles: the razor-and-blade model, updated for the subscription era. Give away (or deeply discount) access at the front end. Make the ongoing relationship — and the exit from it — the actual revenue mechanism. The more embedded your customer becomes, the less elastic your pricing needs to be.

This is not a scam. It is a legitimate, widely practiced, and often genuinely valuable commercial approach. Spotify works this way. Adobe works this way. Cloud infrastructure works this way. The model's defenders will note, correctly, that it aligns vendor success with customer success: if the product stops being useful, customers can leave. The price of admission is low. The value has to justify the ongoing cost.

What is worth naming, though, is the specific mechanism that makes it work in the no-code and low-code web platform space, because it has a feature the Spotify model does not: the exit cost is not proportional to what you paid in. It is proportional to what you built.

Walk away from Spotify and you lose your playlists. Walk away from a no-code website platform after three years of a client's content, CMS collections, integrations, form data, and design work, and the independent research firm Adalo put a number on it in 2026: migration costs run 2 to 4 times the original build budget. A website that cost $5,000 to build costs $10,000 to $20,000 to rebuild elsewhere. The original fee looked like a service. The lock-in is the actual product.

BCG research adds useful context to the psychology: 79% of companies say their platform's value justifies the cost. But 70% of the same respondents are actively scanning the market for alternatives. That is not a vote of confidence. That is the behavior of someone who knows the meter is running but can't find the off switch.

How the Pricing Cliff Actually Works

Framer is worth examining in detail here because it is among the most popular and genuinely well-designed of the current-generation no-code platforms, and because its pricing structure illustrates the pattern with unusual clarity. Nothing in what follows is a criticism of the platform's quality. It is an analysis of the economic structure the platform creates.

The free tier is genuinely generous. You get a full editor, AI design tools, and enough room to build and show a complete prototype without spending anything. The friction point is publishing with your own domain — that requires a paid plan. This is standard practice and entirely reasonable. The free tier is designed to make the product familiar before you commit. By the time you're ready to publish a real client site, you know the tool, you've built in it, and the switching cost has already begun to accumulate.

The 200% price jump from Basic to Pro is not an accident. Industry analysts who track Framer pricing specifically identify the Basic tier as deliberately constrained to push anyone with real content needs upward. One CMS collection is the hard limit — meaning a site with both a blog and a portfolio section cannot exist at the Basic tier. Add a team member and the economics of Basic collapse entirely: one editor seat adds $20 per month, putting you at Pro pricing for half the Pro feature set.

None of this is hidden. The pricing is published and, compared to some enterprise platforms, genuinely reasonable for what it delivers. The issue is not deception. It is that the cost structure at year three — when the client has a functioning CMS, a design system, form data, integrations, custom plugins, and staff trained on the interface — looks nothing like the cost structure at year one when the invoice was signed.

The Expertise Gap Nobody Names in the Pitch

Platform lock-in is a client problem. But there is a parallel problem that belongs specifically to the practitioner — and it is the one that affects the long-term trajectory of anyone building a career in web development right now.

A meaningful segment of new-generation web practitioners have built their entire professional identity inside a single platform ecosystem. They know one tool extremely well. They know its interface, its animation system, its CMS structure, its template marketplace. What they often do not know is what makes the tool work — the underlying DNS configuration, the email delivery stack, SMTP handshakes, server-side request handling, authentication flows, database structures, or the reason a particular design decision has to accommodate a constraint that isn't visible in the drag-and-drop canvas.

This is not a criticism of those individuals' intelligence or work ethic. Platform tools are designed to make this ignorance sustainable for most use cases. That is their entire value proposition. The problem surfaces in two specific situations:

The honest version of this is worth stating directly: platform proficiency and web expertise are not the same thing. They overlap substantially for simple use cases. They diverge sharply when a client grows past those use cases — and most clients who are worth building for eventually do. Knowing how to design inside Framer is a skill. Knowing why DNS propagation takes 48 hours, how SSL certificates are issued, what happens to form data when a platform goes down, or why flat-file JSON storage has different performance characteristics than MySQL — that is a different category of knowledge. One is tool fluency. The other is domain expertise.

What Clients Actually Buy When They Don't Know the Difference

From a client's perspective, this is where the structural problem bites hardest. A $2,000 website built on a no-code platform looks identical to a $2,000 website built on owned infrastructure. The invoice says "website." The deliverable looks like a website. The client has no way to evaluate what they actually purchased until they try to do something the platform wasn't designed for.

Consider what a client implicitly signs on to when they commission a site that lives on a third-party platform without being told the implications:

This is not an argument that clients should never use platform-built sites. For many use cases — a portfolio, a landing page, a small content site with limited growth ambitions — the platform's advantages (speed, polish, ease of maintenance, the ability to make updates without a developer) are real and the constraints are acceptable. The problem is when the pitch omits the constraints entirely, as if the platform is the natural way websites work rather than one architectural choice with specific tradeoffs.

Transparent practitioners name the tradeoffs. Less transparent ones sell the platform's benefits and let the client discover the ceiling on their own — usually at the worst possible time, when they're trying to grow.

The Vendor's Incentive Structure Is Not Your Client's

Here is the piece of the analysis that platforms themselves will not volunteer: once a client's site is live and accumulating content, users, integrations, and SEO equity, the vendor's pricing power over that client is essentially uncapped. The switching cost grows every month. And the vendor knows this.

The October 2025 Framer pricing overhaul is instructive here — not because the new pricing is unreasonable, but because it happened at all. A platform can reprice, restructure tiers, reduce what a plan includes, or change which features are gated behind which levels at any point. Customers on old plans were grandfathered, a genuinely generous move that drew credit from practitioners who observed it. But the grandfathering is not permanent, and new projects start on the current structure regardless. The point is not that this is malicious — it is that a vendor's pricing decisions are made in service of the vendor's business model, not the client's.

The practitioner who sold the platform-built site is also, at that point, somewhat insulated from the consequence. They were paid once. The client pays monthly. If the pricing becomes uncomfortable, the client's complaint is directed at the platform, not the original builder. The builder's interests and the client's long-term interests were never fully aligned from the moment the build was scoped.

The chart above illustrates the divergence that tends to emerge between year one and year three. A self-hosted build with owned infrastructure has higher upfront cost and minimal ongoing platform fees — the cost curve is relatively flat after launch. A platform build has low upfront cost but a compounding cost structure: tier upgrades as the site grows, per-seat fees as the team expands, add-on costs for features that were free at a simpler scale, and the ever-present optionality cost of a rebuild that grows more expensive with each passing month.

What Genuine Expertise Looks Like in This Environment

None of the above should be read as a claim that platform tools are without value for practitioners. They are fast. They produce high-quality design output. For a solo practitioner building landing pages, they are a legitimate and defensible choice. The question is not whether to use platform tools — it is what else you know.

The developers and designers who are genuinely difficult to replace in this market are not the ones who are fastest inside a single tool. They are the ones who understand enough about how the web actually works to make deliberate architectural choices. That means knowing the tool and knowing its alternative — and being able to explain to a client, in plain language, what they are getting and what they are giving up.

It means understanding colour theory, typography, and visual hierarchy as concepts that exist outside any specific canvas. It means knowing what DNS is, what SMTP is, why HTTPS matters and how it's provisioned. It means being able to look at a platform's pricing structure and tell a client: at your current growth rate, here is when you hit the next tier, here is what that costs, and here is what your options are at that point.

It means, above all, being curious about what's under the hood — not just what the hood looks like.

This distinction matters especially right now, because AI is making the tool layer of web development increasingly commoditized. The gap between "I can use this platform" and "anyone can ask an AI to approximate what this platform does" is narrowing faster than the gap between "I understand web architecture" and what any AI can do autonomously. The practitioners who will be hardest to displace are not the ones with the most polished no-code output. They are the ones whose value lives at the level of judgment, not execution.

The Architecture Decision That Changes the Math

The alternative to platform dependency is not complexity for its own sake. It is making a deliberate architectural choice at the start of a project — one that you can explain, defend, and revisit — rather than defaulting to the most familiar tool.

Owned infrastructure looks different from client to client. For some, it means a static site with a self-hosted backend. For others it means a lightweight PHP platform with JSON file storage — portable, database-free, deployable anywhere, with no vendor standing between the client and their own data. For others still it means a framework-built site deployed on a server the client controls, with the design system documented and portable.

What these approaches share is not a technical stack. They share a philosophical stance: the client owns the output. The practitioner's fee covers the work, not a perpetual license to continue accessing the work. And the exit — if it ever becomes necessary — costs as much as a migration, not as much as a rebuild.

The practitioner who understands both options is more valuable than the practitioner who only knows one. Not because owned infrastructure is always the right answer — it is not — but because the ability to make the recommendation clearly, with the client's actual interests in view rather than just the path of least resistance, is what separates a consultant from an operator.

Where This Goes From Here

The no-code platform market is not going away, and it shouldn't. These tools have genuinely democratized a portion of web creation that was previously inaccessible to non-developers. They have enabled faster iteration, better design quality at lower budgets, and real productivity gains for the right use cases. The platforms that have achieved meaningful scale — Framer, Webflow, and their counterparts — earned that scale by solving real problems elegantly.

What is changing is the competitive landscape around them. AI-assisted development is compressing the cost advantage that platform tools held over custom builds. A developer working with an AI coding tool can now approximate a polished platform output in a fraction of the time it used to take — and produce something the client owns outright, with no subscription attached. That gap will continue to narrow. The practitioners who built their entire value proposition on platform speed are going to encounter that narrowing in the market.

Meanwhile, a parallel shift is happening at the infrastructure level: the rise of self-hosted, ownership-preserving architectures that aim to deliver platform-like deployment simplicity without platform-like dependency. The goal is not to make self-hosting as difficult as it used to be, but to make it as frictionless as possible while keeping the client in full control of the output. That is a solvable engineering problem, and it is being worked on.

The platform is not the skill. It is the environment in which a skill is expressed — and one of the most important professional skills available right now is knowing the difference.