When you should stay on no-code
We make money migrating companies off no-code platforms, so read this with the skepticism it deserves: most of the sites and apps people ask us to rebuild should stay exactly where they are. A migration costs real money and buys you nothing if you were never going to hit the ceiling in the first place. The rest of this series argues that the speed advantage no-code used to offer has closed. That argument has limits, and the limits are worth writing down honestly.
A marketing site on Webflow has no ceiling to hit
Webflow's Basic site plan runs $15 a month billed yearly, and Premium, which adds the CMS, runs $25 (checked on their pricing page, 12 September 2026). For a company site with a blog, a careers page and a contact form, that is a rounding error against one afternoon of engineering time. There is no data model to outgrow and no business logic to test. The thing renders HTML, and Webflow renders decent HTML.
The argument for leaving a visual builder gets its force from what happens above the platform, not from the platform itself. Bad Core Web Vitals, a database you cannot query properly, workflows nobody can review. A brochure site touches none of that. If your marketing team edits pages without filing a ticket, and they are happy, you have already extracted the value the tool was designed to give you.
The number that should worry you is $2,500 a month, which is what Webflow now charges for its Team platform plan on an annual contract. That is the cliff. If your organisation is being pushed toward it for governance features and publishing workflows rather than for anything a visitor to the site would notice, the pricing has stopped tracking the value. Until then, stay.
You cannot migrate a product you have not validated
Bubble's Starter plan for a web app is $29 a month billed annually, or $32 month to month. Growth is $119, Team is $349 (from Bubble's own pricing docs, 12 September 2026). Those are the prices for the whole app, not per seat. A founder testing whether anyone wants the thing can run for a year on less than the cost of two engineering days.
The expensive part of migrating is not writing the code. It is deciding what the software should do, and a product with forty users has not answered that question yet. You would be paying to freeze assumptions you are still changing weekly. Every rebuild we have done started from a spec the client had already validated against paying customers, because that spec is what makes the estimate honest.
Bubble's costs stop being trivial when workload units enter the picture, which is a different post. But the trigger for that conversation is usage you actually have, not usage you hope for.
An internal tool with twelve users is not a platform risk
Airtable's free tier gives you 1,000 records per base and five editors. The Team plan, at $20 per seat per month billed annually ($24 monthly), raises that to 50,000 records per base and 25,000 automation runs (from Airtable's pricing page, 12 September 2026). An operations tracker with a dozen people in it and four thousand rows sits comfortably inside that, and will for years.
Ops teams build these things themselves, which is the whole point. Hand that tracker to an engineering team and you get a proper database, plus a queue of feature requests that now has to compete with customer-facing work. The person who understood the workflow best has been removed from the ability to change it. That is a real cost and it rarely shows up in the migration proposal.
Seat pricing is what eventually breaks the arrangement. At $20 a seat, a tool used by twelve people costs $240 a month; at eighty people it costs $1,600, and you are paying full editor price for staff who only read. Watch the seat count, not the record count.
What actually moves the decision
Stay World Class came to us because their Webflow and Xano stack had a Lighthouse score of 55.91 and page loads their customers complained about. We rebuilt on Next.js, NestJS and Supabase, with a four stage ETL that mapped every legacy ID onto PostgreSQL UUIDs so no record lost its history. Lighthouse went to 91 out of 100 and LCP came down 77%. That project made sense because the ceiling was measurable and someone was losing money against it.
The signals that justify the spend are boring and specific. Your platform bill grows faster than your revenue. A performance problem gets diagnosed and you find you cannot fix it from inside the builder. Two people editing the same workflow break each other's work and there is no diff to read. A customer asks where their data lives and you cannot give a straight answer. One of those is a nuisance. Three at once is a business problem.
If none of them describe you, the right move is to do nothing and check again in six months. We would rather tell you that now than three weeks into a rebuild you did not need.
