Personal · Engineering · Career

Webflow vs My Stack: The Honest Gap, and How I'd Close It in 90 Days

I build in Next.js, Docker, and Postgres on Hetzner. Most top AEO agencies build in Webflow. Here's the honest comparison from someone considering the move across.

By Lesli Rose · Published 2026-05-13 · 9 min read

Opening

I'm writing this on the way to applying for a role at a Webflow Enterprise Partner shop. Their work for Verifone, Headspace, Reddit, NBC, and Pentagram is the kind of craft I'd learn from. They specialize in Answer Engine Optimization, which is the work I already do.

But I build websites in Next.js + Docker + Postgres on Hetzner. They build in Webflow. The methodology that produces AI visibility outcomes is platform-agnostic. The day-to-day craft of shipping inside Webflow is not. So this is an honest answer to the question I'd be asked at interview anyway: what would your first 30, 60, 90 days look like, and is there a Webflow gap I'd need to close?

I also built an AI Visibility Scoring engine on top of my stack this week. The data it produces and the architecture decisions behind it sit at /aivs. That's the proof of the second half of this comparison. This article is the proof of the first half: that I know exactly where the gap is.

Where my stack wins

My current stack is Next.js 16, TypeScript, Postgres (or SQLite where the workload allows), Docker, Traefik, and Coolify on a self-hosted Hetzner box. I run 11 production properties off this stack. It wins in five places.

Custom backend logic. The AIVS Scoring engine could not run inside Webflow. It needs a long-running Node process, a SQLite WAL database, and outbound calls to three AI APIs on a weekly cron. That kind of work is the default on my stack and the exception on Webflow.

Multi-tenant SaaS architecture.The same engine reads multiple sites' data from a single DB with row-level isolation by site_slug. The admin UI and the client-facing UI render from the same source of truth. That's SaaS-shaped product work and a code stack is the right tool for it.

Deep API integration. Stripe webhooks, Anthropic + OpenAI + Perplexity SDKs, Google Search Console service accounts, Bento broadcasts, LinkedIn OAuth. All wired with versioned code, all testable in CI, all redeployable on a `git push`.

No platform fees.The Hetzner box runs 11 properties for roughly $50 a month. Webflow's comparable footprint at the CMS Hosting tier with 11 sites would be roughly $300 a month before any add-ons. At small scale that doesn't matter. At agency scale across paid clients it does.

Full GitHub ownership.Versioning, branching, code review, atomic rollback. Webflow's backup model is a snapshot list, not a commit graph. For engineering-heavy work the commit graph wins.

Where Webflow wins

Webflow wins in five places that matter for an agency's actual revenue.

Marketing teams ship without engineering. A content editor can publish a new landing page in Webflow on Tuesday afternoon. The same change on my stack is a pull request, a CI run, a Docker rebuild, and a deploy. For an agency selling to marketing departments, the editing surface is the product. Webflow wins that surface.

EPOTY-tier polish out of the box. The Webflow Designer enforces a level of typography, spacing, animation, and responsive behavior that takes effort to maintain in custom Tailwind. The default is high. The default in custom code is whatever the developer brings.

CMS UX for clients.The Webflow CMS Collection editor is a polished interface a marketing team can use. The equivalent on my stack is a custom-built admin panel per client. Custom admin works for me; it doesn't scale to handing the keys back to a Fortune 500 marketing team.

Hosting and CDN are bundled.No reverse proxy, no SSL renewal, no container restart on OOM. For a client that doesn't want to think about ops, this is a major feature, not an absence.

Faster iteration with non-technical stakeholders.A client review on Webflow staging is "click these links and tell me what to change." The change happens in the Designer while the client watches. A client review on my stack is "here's a preview URL, here's the slack channel for comments, here's when the next deploy lands." Different cadence, different relationship.

The honest gap

If I started in a Webflow shop on Monday, here's what I'd be slower at than the team I'd be joining.

The Designer as IDE.Webflow's Designer is the editing surface. It's also the place where styling, layout, animation, and CMS binding happen. I know the underlying HTML/CSS/JS. I don't yet have muscle memory for the Designer's panel structure, the "Style" vs "Settings" vs "Element" distinction, or the workflow for compound classes.

Webflow class conventions.The community standard is "Client-First" (Finsweet) or "Lumos" (Lumos Labs). These are organizational systems for class naming inside Webflow that make handoff between agencies survivable. They're not optional at agency scale. I would need to internalize one of them.

CMS Collections vs database schemas. A Webflow CMS Collection is not a SQL table. It has a different reference model (Multi-Reference fields), a different filtering model (Webflow filters, not WHERE clauses), and a different access model (live items vs draft items). The mental shift from SQL to Collections is real.

Interactions panel vs writing JS.The Designer's Interactions panel is a node-based animation builder. I'd default to writing the animation in JS because that's the muscle memory. Doing it through the panel is faster for the team and more maintainable for the next editor. I'd need to override muscle memory.

No native git.Webflow has a backup list and a publish history. It does not have branches, commits, or PR review. The workflow shift is from "feature branch, PR, merge, deploy" to "edit in staging, review, publish." This is a culture change, not just a tool change.

Pricing model. Webflow charges per site, per seat, per workspace. I price by Docker container. Internalizing the Webflow cost model is required to scope client engagements correctly.

The 90-day close plan

None of the gaps above are insurmountable. They are training, not paradigm change. Here's how I'd close them with structure.

Days 1 to 14 - Webflow University, end to end.The free curriculum. All of it. Including the CMS, the Designer fundamentals, the Interactions 2.0 module, and the Webflow Ecommerce track even though I'd rarely ship Ecommerce. Goal: pass the Webflow Certified Expert exam by day 14.

Days 15 to 30 - Five clone rebuilds.Pick five Webflow templates or community clonables and rebuild each from scratch. Not copy, rebuild. By the fifth one I'd know the Designer the way I know VS Code today. I'd also internalize one of the Client-First or Lumos conventions during this phase by enforcing it on every rebuild.

Days 31 to 45 - Pair on two paid projects. Pair-program with a senior Webflow developer on the team for two complete client builds. Both ends: the discovery and scope phase on the front end, the QA and publish phase on the back end. Get reviewed on every PR-equivalent (page commit).

Days 46 to 75 - Ship a hybrid case study. Build a single hybrid project that uses Webflow for the marketing surface and Next.js for an embedded calculator or comparator tool. This is the play that aligns the existing AIVS engine with the Webflow editing surface. Ship it on a real client if one fits; ship it as a portfolio piece if not.

Days 76 to 90 - Bring AI Visibility depth to the methodology. Apply the 5-layer AI Visibility Stack methodology against three live Webflow client engagements. Document the result in the same format as the AIVS comparator at /aivs. By day 90, the AEO + Webflow craft combination should be the agency's default rather than a separate offer.

The hybrid stack thesis

The reason I'm comfortable making this move: the top AEO shops are already hybrid. The agency I'm applying to ships Webflow marketing surfaces alongside custom development for clients who need it. N4 Studio, who built webflow.com itself, lists "Webflow + custom development" as a service. The split between Webflow shops and code shops is collapsing.

What lasts is methodology. The AI Visibility Stack methodology I built (5 layers: Technical SEO foundation, Schema and Structured Data, Content Architecture, E-E-A-T signals, AI Discoverability) doesn't care whether the page is rendered by Webflow or Next.js. The schema gets injected either way. The /llms.txt gets uploaded either way. The buyer-intent content silos get built either way.

What changes is the editing surface. The Webflow Designer is a better editing surface for marketing teams. A code-rendered Next.js app is a better editing surface for engineering teams. A good agency runs both. A great agency knows which one to put in front of which client.

I bring the methodology, the engineering depth, and the willingness to close the Designer gap on a 90-day clock. That's the offer.

Questions a hiring committee would ask

Why apply to a Webflow shop if you don't ship Webflow daily?

Two reasons. The role I'm applying for, AI visibility, is platform-agnostic. The Stack methodology that produces the result lives above the rendering layer. Second, the top AEO shops are Webflow shops, so closing the Webflow gap is the natural next move. Pretending I already have it would be the wrong move; sharing the gap and the plan is the right one.

What's the actual technical gap between a Next.js developer and a Webflow developer?

Three things. First, the Webflow Designer is a visual-first IDE with its own class naming conventions, animation panel, and CMS Collection model. Code-first developers know the underlying CSS/JS, but not the conventions Webflow expects. Second, no native git. Versioning lives inside Webflow as backups, not commits. Third, the deploy boundary moves. Hosting + CDN + form handling are bundled by Webflow rather than configured per service.

Could you just learn Webflow on the job in week 1?

I could ship a Webflow page in week 1. I could not ship a Verifone-quality Webflow page in week 1. The gap between functional and EPOTY-tier is craft, and craft compounds. The 90-day plan below is designed to close that craft gap with structure rather than improvisation.

What does a hybrid Next.js + Webflow stack actually look like in production?

Common pattern at agencies: Webflow renders the marketing surface (homepage, pricing, blog, case studies) where editors update content visually. Next.js renders the app surface (logged-in dashboard, custom calculators, search tools, integrations) where engineering needs to own the runtime. Identity is shared via OAuth or a session cookie. SEO sitemaps are merged. The boundary is usually a subdomain (marketing on www, app on app.).

Where does AI visibility work happen in a Webflow stack?

Three layers, all editable in Webflow. Schema markup is injected via the Page Settings custom code field. /llms.txt and robots.txt are uploaded as static assets. FAQPage and HowTo schema can be templated as CMS Collection items. The work is the same in concept as on any stack. The execution path is different because the editing surface is different.