WeWeb pricing for a portal with an existing backend

The prototype shows a client their open requests, and now you need a production URL and someone to maintain it. WeWeb pricing separates the workspace used to build the app from the hosting used to run it. If the portal already relies on an external database and authentication service, those costs belong in the budget too.

For two builders maintaining one portal on an existing backend, evaluate Pro with Front-end only hosting. Choose a plan with WeWeb’s backend if you want that service included and its limits suit the workload. Exporting may fit an established deployment team. Keep the current portal when it meets the access and operating requirements; changing builders creates implementation work that a subscription comparison cannot price.

Separate builder access from the live application

WeWeb’s pricing documentation distinguishes workspace plans from per-app Cloud plans. Workspace plans govern editor capabilities and developer seats. The Front-end only Cloud plan hosts the interface without WeWeb’s backend, while Launch+, Grow+, and Scale+ include backend resources with their own allowances. WeWeb is no longer accurately described as offering only a frontend.

Write down who changes the app, how many live apps you intend to publish, and which services hold the data. A client reading their request status has a different role from a developer changing the portal. The current pricing page says app users do not need builder seats, and seats cannot be shared between people. That does not make their database queries, stored files, or external services free.

Include the person who handles urgent fixes in the builder roster. If an outside agency owns the workspace, establish who pays for it and how the client takes control when the engagement ends. Access to the visual editor and access to the production database should each have a named owner.

A two-builder estimate using an external backend

Use this illustrative workload: two named builders, one live portal, 50 client accounts, an existing external backend, and 8 GB of frontend bandwidth per month. Both builders remain subscribed all year. The amounts below use USD annual billing rates checked October 23, 2026, exclude taxes and regional discounts, and come from documented research, not firsthand testing of the sample portal.

The hosting price table lists 10 GB of monthly bandwidth for Front-end only and $0.25 per additional GB. The example stays within that allowance. Treat the $1,356 as a subscription subtotal, not a complete portal budget; add the external backend and other excluded services before comparing it with a package that includes them.

For a self-hosted version of the same portal, keeping the two Pro builder subscriptions leaves $1,200 in annual WeWeb workspace charges. Replace the $156 hosting line with your own infrastructure and operating costs, which are unknown here. The difference is the vendor hosting charge removed from the estimate, not a demonstrated saving after operating the app yourself.

If another candidate charges for portal users, compare the same 50 clients, two builders, and workload. Softr pricing examines a portal budget where team and client allowances need separate attention. Check the included data services and access requirements before treating the totals as equivalent.

Prove that client records stay separated

A production decision needs more than a working request list. Build a fictional fixture with two clients, one request owned by each, and a staff account. Give the first client a permitted request and try to open the other request through a copied link. The expected result is access to their own record and a refusal for the other one, including its attachments.

Use WeWeb’s application security documentation alongside the access rules of the chosen backend. Put the record authorization at the boundary returning the data, then make the interface reflect that decision. Hiding a button or filtering an already-downloaded list cannot protect data that the browser has received.

Repeat the check after revoking membership and after changing the client association on a request. Inspect the actual response and exported files, not just the visible screen. These are proposed acceptance checks rather than firsthand results. If a requirement fails, price the work to fix it before committing to a launch date.

Code export leaves migration work to complete

WeWeb documents code export on Essential and higher workspace plans. Its export instructions require publishing the app before generating an export and allow repeated exports while the paid workspace subscription is active. An interface-only export can continue calling the existing backend, provided that service remains available.

For a full-stack export, the same documentation says table structures are included but stored records and uploaded files are not moved. API keys and secrets also need configuration at the destination. Inventory the data, storage, authentication, email delivery, and integrations before scheduling a cutover; the downloaded application files are only part of that move.

Rehearse with permitted sample records and a separate destination. Verify sign-in, request creation, file access, and the restricted-record test. Compare counts and identifiers after transferring data, and reconnect external services using the destination’s approved secret-management process. Preserve a rollback path until the person responsible for the portal accepts the results.

Include future updates in the rehearsal: change a label or validation rule, export again, and confirm that the deployment process replaces the intended version. A one-time successful upload does not establish who can maintain the app. Keep a release record so support can identify which version produced a reported problem.

The Bubble pricing example takes a different approach to capacity by budgeting measured application workload. Keep the same publishing requirements and business tasks when comparing it with a frontend and external backend.

Where Permute fits: consistent evidence behind the portal

Permute is the connected business data and custom application software we sell. We have a commercial interest in this category. When a client portal combines project requests with accounting or customer records, we can help reconcile the identifiers and retain the evidence behind the result. Your team defines which source establishes a status and how unresolved conflicts should appear.

We can reuse those definitions in a report or custom application, subject to verified source access and permissions. An account manager can inspect the records supporting an open-request total and see whether the data is current. The goal is a repeatable answer whose scope is understandable to the person using it.

Scope the connection and deployment responsibilities

We do not supply WeWeb subscriptions, and this article promises no native WeWeb connector or automatic migration. Source access, hosting, and any external actions need their own implementation scope. Enterprise app development covers planning a custom workflow around connected business data. Keep the chosen portal when it already meets the requirements.

Approve the production budget with its exclusions visible

For the two-builder example, $1,356 covers the stated WeWeb workspace and frontend hosting configuration for a year. Add the backend and operating costs before approving the portal budget. Choose self-hosting only after assigning an owner and rehearsing deployment and access checks. Keep the subscription decision tied to the production workflow you need to maintain.

Questions about paying for a WeWeb portal