A prospect emailed me in July asking whether a Webflow and Wized reactive app could replace the custom front end I had quoted for them. Reasonable question. The build was a members area with a public supplier directory attached, and on paper that is exactly the shape of product Wized exists for.
I spent an afternoon pricing both options properly. The answer came back yes for half the product and a firm no for the other half, and the line between those halves sits somewhere no comparison post I could find had put it.
Most writing about Wized argues over whether no-code can "really" build applications. Wrong axis. Wized builds applications fine. The argument worth having is about which parts of your product need to be legible to something that is not a logged-in human being.
What Is a Webflow + Wized Reactive App?
Wized is a visual JavaScript layer that sits on a published Webflow site and makes its static HTML react to data, auth state and API responses. You still design in Webflow. Wized describes itself as the application layer on top of your Webflow project, which is unusually honest positioning for a tool in this category, because it is not a backend and never claims to be.
The mechanics are straightforward. You attach Wized configuration to Webflow elements, define requests against a REST API or a backend-as-a-service, and bind element state to whatever those requests return. Wized's documentation describes workflows as sets of actions and conditionals triggered by element or page events. If you have written React, the mental model transfers immediately: requests are your data layer, the data store is your state, workflows are your event handlers. What you give up is the compiler, the type system and the test runner. What you get back is that a designer can move the button and nothing breaks.
Wized was acquired by Finsweet, who rebuilt it as V2 and brought the original creator, Jonas Beisswenger, on to lead development. Finsweet's stated reason for introducing pricing was making it "a cash flow positive project, ensuring its continued development". That matters more than it sounds, because you are about to put your product's logic inside it.
The builds people ship with it: gated dashboards, course platforms, job boards, booking flows, internal tools, multi-step forms writing into Airtable or Supabase. Anywhere a marketing site would normally need a developer to add behaviour, Wized lets whoever already owns the Webflow project add it instead. That is the real value proposition. If your site never needs behaviour beyond a form post and an automation, you do not need Wized at all, and connecting Webflow to Zapier covers more ground than most people expect it to.
Webflow Killed Its Own Auth, and Wized Inherited the Problem
On 29 January 2026 Webflow permanently removed native User Accounts, taking access groups and everything built against them along with it.
Webflow announced that sunset alongside Logic, which went first on 27 June 2025, and framed both as an ecosystem-first decision: vetted partners handle memberships, Webflow handles the site. Its own named replacements are Outseta and Memberstack. Whatever you make of the reasoning, the practical outcome is that authentication on a Webflow site is now permanently somebody else's product. Memberstack, Outseta, Supabase Auth, Firebase Auth. Pick one, pay for it, and accept that your login depends on a vendor who is free to make exactly the decision Webflow just made.
This is the part I want a client sitting with before anyone signs anything. A Wized build has three vendors in the critical path before a single line of business logic exists: Webflow for hosting and markup, Wized for the reactive layer, an auth provider for identity. Add a backend and it is four. Each one prices per seat or per domain or per row. Each one can sunset a feature on a Thursday.
Set that against the Pizzeria Bestek build, which sits at the opposite end. React and Supabase, three edge functions, and the restaurant holds every credential: Supabase, Netlify, Resend, the domain, the codebase. It has been running since September 2025 at five to ten orders a day, seven days a week. There is no vendor in a position to sunset it. The ownership question underneath that is the same one that decides whether to use WordPress or a custom website, and it does not get easier at larger scale.
Wized Pricing Is Per Domain, and Elements Are the Cap
Wized bills per domain, and the limit that actually stops projects is the element count rather than the page-view allowance.
Wized's published pricing, monthly:
| Plan | Price | Page views | Wized elements | Domains |
|---|---|---|---|---|
| Free | $0 | Unlimited | Unlimited | Staging only |
| Lite | $12 | 100,000 | 20 | One production domain |
| Small | $39 | 100,000 | 100 | One production domain |
| Medium | $69 | 200,000 | 400 | Multiple, wildcard supported |
| Large | $169 | 300,000 | Unlimited | Multiple, wildcard supported |
Read the elements column, not the price column. An element here is any Webflow element Wized is configured against, and a moderately complex dashboard consumes them faster than the plan names suggest. A filter bar with eight inputs, a results list, an empty state, a loading state, a pagination control and a detail modal is not an ambitious feature, and it is not landing inside twenty.
Twenty elements is a proof of concept. A hundred is one real feature done properly. Four hundred is a product. The free tier being staging-only is a fair model rather than a trap, but it is worth knowing before you demo on a webflow.io URL and let a client assume that price carries through to launch.
Is It Actually Low-Code?
Not in the sense the marketing implies: you skip JavaScript syntax entirely and still write JavaScript logic, so the skill requirement barely moves. Conditionals, async sequencing, error branches, state that has to be invalidated when something upstream changes. All of it stays your problem. What goes away is the typing, not the thinking. Hire accordingly.
The SEO Trap Nobody Prices Into a Wized Build
Wized renders client-side, which is harmless behind a login and quietly fatal for any public page that was supposed to be an acquisition asset.
The specific failure runs like this. You build the members dashboard in Wized and it works well. Then you build the public supplier directory in Wized too, because it is the same filtering logic and reusing it is obviously correct. That directory was the entire organic acquisition plan.
Googlebot renders JavaScript, so the directory ranks. The AI answer engines do not render it at all. Vercel and MERJ's 2024 crawler study analysed 569 million GPTBot fetches and found zero JavaScript execution: GPTBot downloaded JavaScript files 11.5% of the time and never ran one. ClaudeBot downloads them 23.84% of the time to the same effect.
So the page sits at position one on Google and hands an empty shell to ChatGPT, Claude and Perplexity on the same afternoon. A 2026 write-up on Webflow JavaScript SEO calls this the split visibility problem, and the name earns its keep, because the two systems genuinely disagree about whether your content exists.
Actually, that overstates it a little. Webflow's own CMS output is static HTML and indexes everywhere without help. The gap opens only where Wized generates content client-side, which happens to be precisely the page you reached for Wized to build. The dynamism is the reason you picked the tool and the reason the tool costs you the traffic.
The rule I use now: anything a stranger must be able to find gets rendered as real HTML, through the Webflow CMS or through a framework. Anything behind a login can be as client-side as you like, because no crawler was getting in there anyway.
When Should You Drop to Next.js Instead?
Drop to Next.js when the public content has to be readable by machines that do not run JavaScript, or when the data model outgrows what a no-code backend can express.
| Decision factor | Webflow + Wized | Next.js custom build |
|---|---|---|
| Public pages cited in AI answers | Poor, client-rendered | Strong, 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, joins, migrations | Hits a ceiling early | No ceiling |
| Time to first working version | Days | Weeks |
| Cost shape | Per domain, per element, per seat | Hosting plus your time |
| Who maintains it in year three | Whoever knows Wized | Any React developer |
The row that decides most projects is the last one. A Wized app is maintainable by people who know Wized, and that hiring pool is smaller than the React one by a wide margin. Worth pricing honestly if the thing being built is meant to outlive the agency that built it.
These are not exclusive options, and the strongest version of a Webflow app is usually a split. Marketing site and content stay in Webflow where an in-house team can edit them without a deploy. The product surface goes into code. Which system carries the content half is its own decision, and the shortlist of CMS options for a marketing site is where I would start it. If the product half is a genuine SaaS product rather than a dashboard, the design and development process behind a SaaS web platform is a different discipline from configuring a site builder, and pretending otherwise is how six-week projects become six-month ones.
How to Scope a Webflow Wized Reactive App Without Getting Stuck
Before anyone opens the Designer:
- List every screen and mark each one either "must be findable by strangers" or "behind a login". Everything in the first column is a Webflow CMS or server-rendering problem, and Wized should not touch it.
- Count the Wized elements the largest screen in the second column needs, then multiply by the number of screens. Compare that against the tiers above. If the honest answer is Large, put $169 a month over three years next to a developer's quote and look at both numbers.
- Choose the auth provider before the design rather than after it. It shapes the data model, and it is the vendor most likely to change its terms on you.
- Pick the backend by the shape of the data. Airtable is fine for flat, spreadsheet-shaped records and stops being fine as row counts climb. Supabase gives you Postgres, real SQL and row-level security, at the cost of needing somebody who can write them.
- Build one complete vertical slice first: login, fetch, render, mutate, error state. Two days of work settles arguments that would otherwise get settled in month three, expensively.
- Write down what happens if Wized changes hands again or the pricing moves. If the answer is "we rebuild it", carry that rebuild as a real liability in the budget instead of pretending it is zero.
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 are considering, that is the conversation to have this week, while the design is still unsigned and the answer is still free. What is on your list?
