When Webflow is the
right constraint.

Most rebuild conversations start with a false choice: custom stack or simple page builder. I think the better question is what the client will actually maintain after launch, and whether the project has the time and budget for custom engineering around every update.

Webflow earns its keep when marketing needs regular publishing, the team is thin on engineering, and the work is mostly pages, CMS collections, forms, and repeatable sections. The constraint can help. It forces hierarchy, reusable components, and predictable spacing instead of one-off div soup.

Webflow becomes the wrong bet in predictable places: complex authentication, multi-tenant app logic, heavy relational data, or integrations that need server-side secrets you do not want in the browser. In those cases, I would rather pair a small front-end framework with an API you control. Keep Webflow for the marketing shell if it still wins for editors.

The proposal should answer a few practical questions. Who publishes, and how often? Which collections need drafts, references, and previews? What must never break, such as donations, bookings, or legal copy? Where does native CMS work stop, and where does custom code start? What is the exit path if traffic or logic outgrows the tool?

Pick constraints that reduce fear for the client. If Webflow is that constraint, name the boundaries early so scope stays honest and the site stays fast.