The compounding cost of staying on low-code one more year
Nobody leaves a low-code platform because of the invoice. Webflow's Premium site plan is $25 a month billed yearly, and Xano's Pro tier runs $224 a month. Together that is less than two days of one engineer's time. The number that actually grows is the one nobody bills you for: the workarounds you built to get around a platform limit, and the way each of those workarounds makes next year's migration bigger than this year's would have been.
The line item is cheap right up until it is not
Webflow's published site plans as of today run free for Starter, $15 a month for Basic, and $25 a month for Premium when billed yearly, priced per site. The next step up is the Team plan at $2,500 a month with an annual contract required. There is nothing between them. Publishing workflows, the site activity log and API, and the governance controls all sit on the far side of that gap, so a team that needs one of them is not upgrading, it is starting a procurement conversation about a hundredfold increase.
Bubble prices differently and the risk moves with it. The free tier includes 50,000 workload units a month, Starter is $59 a month for 175,000, Growth is $209 for 250,000, and Team is $549 for 500,000, all billed annually. Bubble emails you at 75 percent of your allowance and again at 100, after which overages apply unless you have disabled them. Your hosting bill tracks how much your app gets used, which means a strong quarter shows up as a cost increase rather than just revenue.
Airtable charges by seat. Team is $20 per seat per month billed annually, or $24 monthly. Business is $45 per seat billed annually, or $54 monthly. Twelve people on Business comes to $6,480 a year, and that figure climbs with headcount whether or not those people ever write a record. The record ceilings are 1,000 per base on Free, 50,000 on Team, and 125,000 on Business. Airtable's own pricing FAQ is clear about what happens at the ceiling: your data stays, but you cannot add new records or attachments until you move up a plan.
Workarounds outlive the reason anyone built them
Every platform limit produces a clever solution, and the clever solution has a way of becoming permanent. A field gets stuffed with comma separated values because the schema would not allow a second table. An automation fires a webhook at a third party service to do arithmetic the platform cannot do. A page gets a block of custom code to fix a layout the visual editor will not produce.
None of those decisions was wrong on the day it was made. Each one shipped something that needed shipping. The problem is that a year later they are load bearing, undocumented, and known to exactly one person, and none of them can be covered by a test because the platform has nowhere to put a test.
When we moved Stay World Class off Webflow and Xano onto Next.js, NestJS and Supabase, the visible result was performance. Lighthouse went from 55.91 to 91 out of 100 and largest contentful paint came down by 77 percent. The part that mattered more to the team was quieter. Behaviour that had lived in the platform's interface became code in a repository, which meant someone other than its original author could read it, change it, and prove it still worked.
Why next year's move costs more than this year's
Migration cost tracks the mess in your data, not the size of it. Moving 50,000 clean records is a script you write in an afternoon. Moving 50,000 records where a third of the relationships are encoded in text fields, and where four external systems hold the platform's internal record IDs as their own foreign keys, is a project.
That was the real work on Stay World Class. The ETL ran in four stages so that every legacy identifier from Xano mapped deterministically to a PostgreSQL UUID, which is what let integrations keep resolving to the right rows after the cutover. Building that mapping was straightforward because we did it once against a known schema. It would have grown harder with every quarter of extra records and every new integration pointed at the old IDs.
So the calculation is not what the platform costs you this year. It is what the platform costs you this year plus the increment it adds to a migration you will probably do eventually. That second number goes up on its own, without anyone deciding anything.
When staying put is the right answer
Plenty of teams should stay, and I would tell them so. If your site is marketing content with no custom logic, and a non technical colleague publishes to it every week without asking an engineer, Webflow at $25 a month is doing exactly what you hired it for. Replacing it with a repository and a deploy pipeline would take that colleague's independence away and give you a worse outcome for more money.
The same holds for an internal Airtable base that four people use to track a process nobody outside the team depends on. It holds for a Bubble app that is still finding out whether anyone wants it. Software whose requirements are not settled yet belongs somewhere cheap to change, and a visual builder is cheap to change.
The signal to watch is not cost, it is friction. When your engineers spend more time working around the platform than building inside it, when a feature gets scoped down because the tool cannot express it, or when nobody can say with confidence what a workflow does without opening it and reading the boxes, the platform has stopped being the fast option. That is worth measuring before the renewal, not after.
