Why a custom build stopped taking six months
Six months was an honest estimate for a custom build in 2021, and it is the main reason so many teams picked Webflow and Xano instead. That estimate has moved. How far it moved is harder to pin down than the vendor marketing suggests, so here is what the measured evidence actually says, including the parts that cut against the argument.
The numbers are messier than either side admits
METR ran a randomised controlled trial in early 2025 with 16 experienced open-source developers working on repositories averaging 22,000 stars and over a million lines of code. Across 246 real issues, the developers allowed to use AI took 19% longer. They believed AI had sped them up by 20%. That result travelled fast among people who wanted the whole thing to be hype.
METR then undercut its own headline. In February 2026 the team reported a follow-up study and said the data gives an unreliable signal, because between 30% and 50% of participants declined to submit tasks they did not want to attempt without AI. The raw follow-up figures showed an 18% speedup for returning developers, with a confidence interval running from 38% faster to 9% slower. METR's own reading is that selection bias pushes the estimate down, so the real effect is probably larger. A separate METR survey in May 2026 asked 349 technical workers directly and got a median self-reported change of 1.4x to 2x in the value of their work. METR flags self-report as weak evidence, and it is right to.
DORA's 2025 report surveyed close to 5,000 technology professionals and found 90% using AI at work, with more than 80% reporting a productivity gain. The finding that matters for a migration decision is different from the productivity one: for the first time since DORA started asking, AI adoption showed a positive relationship with software delivery throughput. The same report found 30% of respondents place little or no trust in AI-generated code, and that adoption still correlates with worse delivery stability.
What got faster is the part that was always most of the work
It is worth being precise about what METR measured, because it is close to the opposite of a rebuild. Their developers were fixing subtle issues in codebases they had maintained for years, where most of the cost is holding an enormous amount of context in your head. Very little of that resembles standing up a new system.
A migration off a no-code stack is mostly the work AI assistance is good at. Schema design, endpoint scaffolding, database migrations, admin CRUD screens, the ETL that moves the old data across, and the test suite that proves the new system matches the old one. When we moved Stay World Class off Webflow and Xano onto Next.js, NestJS and Supabase, the hardest engineering was a four-stage ETL that preserved every legacy record ID as a PostgreSQL UUID so nothing downstream broke. That is exacting, repetitive work with a clear specification, which is where the tooling earns its keep. The result was a Lighthouse score moving from 55.91 to 91 out of 100, and a 77% faster LCP.
None of this makes the build free. It shifts where the months go. The specification, the data model and the decision about what the software should do still take exactly as long as they always did.
The trade-off is priced differently now
Picking Xano in 2022 bought you months you did not have. That was a real purchase at a fair price, and anyone who made that call was reading their constraints correctly. What you paid for those months was a ceiling: pricing that scales with your success, a database you reach through someone else's API, and business logic you cannot put under test.
The months cost less now. That changes the arithmetic without changing the ceiling, which is why the decision deserves a fresh look rather than a reflex in either direction.
There is a second-order effect in DORA's stability finding that cuts in an awkward direction for platforms. AI raises throughput and degrades stability unless a team has automated testing, mature version control and fast feedback loops. Those are the controls a no-code platform is least able to give you. The tooling that closed the speed gap works best on a stack you can actually test.
When staying put is the right answer
If a non-technical marketer edits your site every week and ships campaigns without filing a ticket, Webflow is winning. A migration takes that away and hands it back as a deploy pipeline. Most teams underestimate how much they will resent that.
If your platform spend is under a few hundred dollars a month and your usage is flat, the payback period on a rebuild is measured in years. If you have no engineer on staff and no budget to hire one, custom code you cannot maintain is a worse position than a platform you can. And if you are still pre-product-market-fit and changing the product every week, speed is still your binding constraint. Keep it.
The case for migrating applies when the ceiling is the thing costing you money, not when the platform is merely imperfect. If you read all of the above and concluded you are fine where you are, that is a legitimate result.
Sources
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"
- METR, "We are Changing our Developer Productivity Experiment Design" (Feb 2026)
- METR, "Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity"
- Google Cloud, "Announcing the 2025 DORA Report: State of AI-Assisted Software Development"
- DORA, "State of AI-assisted Software Development 2025"
- Stack Overflow, "2025 Developer Survey: AI"
