If you're weighing Webflow and Wized against a custom front end for an app, sort your screens into two lists before you compare anything else: pages a stranger must be able to find, and pages behind a login. Wized can build applications. The decision is which parts of your product need to be readable by something that isn't a logged-in human, and that split decides most of the architecture.
What Is a Webflow Web App Built With Wized?
Wized is a JavaScript layer that runs on a published Webflow site and makes its HTML react to data, auth state and API responses, while you keep designing in Webflow. Wized's own site calls it "the application layer on top of your Webflow project", which is honest positioning: it isn't a backend.
You attach Wized configuration to Webflow elements, define requests against a REST API or a backend service, and bind element state to what those requests return. Wized's documentation describes workflows for reacting to events. If you've written React, the mental model transfers: requests are your data layer, stored data is your state, workflows are your event handlers. What you give up is the compiler, the type system and a normal test runner. What you gain is that a designer can move a button without touching logic.
Finsweet acquired Wized and rebuilt it as V2, bringing in its original creator, Jonas Beisswenger. In its announcement, Finsweet says the goal of introducing pricing was to make Wized "a cash flow positive project, ensuring its continued development and improvement". That is reassuring for a tool you'll put product logic inside, and it also means one small company owns that layer.
Typical builds are gated dashboards, course platforms, job boards, booking flows and internal tools. If your site only needs a form post and an automation, you may not need Wized at all, and connecting Webflow to Zapier covers more than most people expect.
Is it really low-code?
Only in the sense that you skip typing the syntax. Conditionals, async sequencing, error branches and state that must be refreshed when something upstream changes all stay your responsibility. The typing goes away, the thinking doesn't, so plan for someone who can reason about application logic, whether or not they write code by hand.
Does Webflow Still Have Built-In User Login?
No. Webflow's deprecation notice says User Accounts stopped being available on 29 January 2026, and Logic on 27 June 2025, in favour of an ecosystem-first approach.
The notice names Outseta and Memberstack as top recommended partners for User Accounts, and Zapier and Make for Logic. Practically, authentication on a Webflow site is now another vendor's product. Memberstack, Outseta, Supabase Auth or Firebase Auth: you pick one, pay for it, and accept that it can change its terms.
That matters for scoping. A Wized build puts at least three vendors in the critical path before any business logic exists: Webflow for hosting and markup, Wized for the reactive layer, and an auth provider. Add a backend and it's four. Each prices differently, and each can change a feature or a plan.
The opposite end is the Pizzeria Bestek build, a React and Supabase ordering platform. Its case study states that the restaurant owns the codebase, the Supabase account, the Netlify deployment, the Resend account and the domain, and that it has run since September 2025 at five to ten orders a day. Ownership doesn't remove vendors, but it does mean no agency or tool sits between the owner and the site. It's the same question behind choosing WordPress or a custom website.
What should you ask an auth provider before choosing one?
Four questions cover most of the risk, and they're my checklist rather than a vendor standard. Can you export your users, including whatever credential data the provider allows, if you leave? How does pricing scale, per member, per active user or per domain? Can your backend verify the session on its own, or does every request depend on the provider's script running in the browser? And what is the migration path if the provider changes plans, as Webflow just did with its own accounts? Ask for those answers in writing before the design is signed, because the auth choice touches the data model, the login screens and every protected request.
How Much Does Wized Cost?
Wized bills per domain, with plans from free (staging only) to $169 a month, and the element allowance is the limit most likely to constrain a real project. Wized's pricing page lists, monthly, as checked on 30 September 2026:
| Plan | Price | Page views | Elements | Publishing |
|---|---|---|---|---|
| Free | $0 | Unlimited | Unlimited | Staging only |
| Lite | $12 | 100,000 | 20 | Single production domain |
| Small | $39 | 100,000 | 100 | Single production domain |
| Medium | $69 | 200,000 | 400 | Multiple domains, wildcard |
| Large | $169 | 300,000 | Unlimited | Multiple domains, wildcard |
Read the elements column as well as the price column. Count how many elements your largest screen needs and multiply by the number of screens before choosing a tier. The free plan being staging-only is fair, but know it before you demo on a staging URL and let a client assume the price carries through to launch.
For a sense of scale, Large at $169 a month is about $6,084 over three years, before the auth provider and backend. That's small against a full custom build and large against maintaining code you already own. The figure that's hard to model is a rebuild if the tool changes hands or pricing again, so carry it in the budget as a real liability.
When Should You Drop to Next.js Instead?
Drop to Next.js when public content must be readable by machines that don't run JavaScript, or when the data model outgrows what a no-code setup can express.
Why do client-rendered pages disappear from AI answers?
Because many AI crawlers download JavaScript files but don't run them. Vercel and MERJ's crawler analysis reports that GPTBot made 569 million fetches across Vercel's network in one month, and that ChatGPT's and Claude's crawlers fetched JavaScript files (11.50% and 23.84% of requests) without executing them. Content in the initial HTML response may still be read. Googlebot, by contrast, renders JavaScript.
The risk is the split. One 2026 write-up on Webflow JavaScript SEO calls it the "split visibility problem": a page can rank on Google and be an empty shell to ChatGPT, Claude and Perplexity. If Wized generates your public directory client-side, that page is exposed to it, and it's usually the page you reached for Wized to build. AI crawler behaviour changes, so re-test with a fetch that doesn't run JavaScript before you rely on this.
To check a page yourself, fetch it without running scripts and look for your real content in the raw response:
curl -s https://example.com/suppliers | grep -c "a supplier name from your directory"
A count of zero means a crawler that doesn't run JavaScript sees no content there.
My rule: anything a stranger must find should be real HTML, through the Webflow CMS or a framework. Anything behind a login can be as client-side as you like.
| Decision factor | Webflow + Wized | Next.js custom build |
|---|---|---|
| Public pages read by non-JS crawlers | Weak if client-rendered | Strong with server-rendered HTML |
| Marketer ships pages without a developer | Strong | Weak without a CMS layer |
| Auth and role management | Third-party, extra vendor | Yours, any provider |
| Complex relations and migrations | Reaches a ceiling earlier | No such ceiling |
| Time to first working version | Days | Weeks |
| Cost shape | Per domain, element and seat | Hosting plus your time |
| Who maintains it in year three | People who know Wized | Any React developer |
The last row decides many projects: the pool of Wized specialists is smaller than the React pool, which is my inference, not a measured figure. The two aren't exclusive. A common split keeps the marketing site and content in Webflow, where an in-house team edits without a deploy, and puts the product surface in code. The shortlist of CMS options is where I'd start on the content half, and if the product half is a real SaaS, the design and development process behind a SaaS web platform is a different discipline from configuring a site builder.
How do you scope a Webflow and Wized app?
Before anyone opens the Designer:
- List every screen and mark it "must be findable by strangers" or "behind a login". The first group is a Webflow CMS or server-rendering problem, and Wized shouldn't touch it.
- Count the elements the largest logged-in screen needs, multiply by the screens, and compare against the tiers above. If the honest answer is Large, put $169 a month over three years next to a developer's quote.
- Choose the auth provider before the design. It shapes the data model and it's the vendor most likely to change terms.
- Pick the backend by the shape of the data. Flat, spreadsheet-shaped records suit a spreadsheet-style backend. Real relations and query control point to a Postgres-based one such as Supabase, at the cost of needing someone who can write SQL.
- Build one vertical slice first: login, fetch, render, mutate, error state. Two days of work can settle arguments that would otherwise surface in month three.
- Write down what happens if Wized changes hands or its pricing moves. If the answer is "we rebuild", budget for that.
Open your sitemap and highlight every URL that brings you visitors today. If any of them would be rendered by Wized in the build you're considering, which ones are they?