Your frontend can display customer requests, but the prototype still needs a backend you can run in production. Xano pricing starts the decision with a free development option and paid infrastructure. Choose a paid plan after checking the access controls and capacity your application needs. Keep an existing backend when it already passes those checks and moving would only change the subscription line.
For a first production evaluation, compare Essential with Pro using the same application and workload. A requirement to restrict what developers can see or change may settle the choice before traffic does. Kartik Deshpande prepared this comparison from official sources checked October 26, 2026. The examples below are proposed acceptance checks, not results from hands-on testing.
Start with the annual backend cost
Use three criteria before choosing a tier: the people maintaining the backend, the workload it must support, and the controls required for production. Xano’s published pricing lists the following USD rates and allowances. Reconfirm them at checkout, including add-ons and taxes.
| Plan | Annual base cost | Published allowance or constraint |
|---|---|---|
| Free | $0 | 1 workspace; 10 API requests per 20 seconds |
| Essential | $85 × 12 = $1,020 | 3 workspaces; 5 team seats; no API rate limit |
| Pro | $224 × 12 = $2,688 | 5 workspaces; 10 team seats; role and permissions manager |
| Custom | Quote required | Self-hosting options; contract-specific scope |
The paid figures use annual billing, rather than a month-to-month commitment. The listed rates establish a base cost; they do not establish how a particular query will perform. “No API rate limit” does not mean an application has infinite compute. Measure the request patterns you expect to run before deciding whether the base configuration is enough.
Free is a place to evaluate the implementation when its published request limit fits the exercise. For production, put access requirements ahead of the cheapest eligible price. Xano’s role documentation places its Permissions Center on Pro and Enterprise / Custom plans, with controls for workspace objects and access to live data. Confirm the exact role you need before buying Essential.
Price the same portal on both paid plans
Take a hypothetical portal maintained by two developers, used by 40 staff, with 20,000 request records and uploaded attachments. Staff open requests, change permitted fields, and download documents. Keep those inputs unchanged when evaluating either paid plan. These counts describe the sample application; they are not evidence that a particular configuration can serve it.
The annual base difference is $1,668. Buying Pro needs a reason such as the required developer permissions or a capacity requirement confirmed during evaluation. Do not multiply the backend team-seat count by every staff member using the portal; distinguish the application’s user accounts from the people maintaining its workspace, and confirm your roster with the vendor.
Your annual worksheet should have separate entries for the backend subscription, frontend building and hosting, email or messaging services, and implementation and maintenance. Leave any unquoted capacity add-on as unknown. A total with an unresolved item should remain a provisional budget, even when the base subscription is known.
Xano documents connections from frontends that make HTTP requests, including standard REST calls and generated OpenAPI documentation. Its pricing also includes static frontend hosting on Essential. Check whether that deployment suits your frontend before paying for another host; a visual builder subscription may still be needed to maintain the interface.
For a portal built in WeWeb, use the WeWeb pricing example to itemize builder and publishing charges. Substitute your actual frontend configuration into this worksheet. Adding two products’ starting prices without checking what each subscription covers can count hosting twice or leave maintenance out.
Measure a request that includes permissions and attachments
Create permitted sample data for two customer organizations. Include requests and attachments for each, plus an account limited to one organization. Configure the API to return the signed-in user’s permitted request, connect the frontend, and record the expected response. Xano’s frontend documentation describes the connection methods; the application owner still needs to define the allowed result.
Then request the other organization’s record by changing its identifier. The expected result is a refusal, including for attachment access. Repeat after revoking membership and while downloading an export. Xano’s shared responsibility model assigns application access configuration and testing to customers. A successful login alone does not establish permission to read every record.
For capacity, replay representative requests in an authorized test environment. Include a busy period with simultaneous reads and uploads, and record response times and failures. Run the same work on the configurations you are considering. Ask which capacity change addresses any observed bottleneck and obtain its price, rather than assuming a tier upgrade resolves the cause.
Budget for moving the running application
Xano’s pricing FAQ documents CSV and YAML data exports. An export is a starting point for moving records. Plan the destination schema, identifiers, file transfers, authentication, and replacement API behavior before treating the application as portable.
Rebuild the same request workflow in a separate destination and compare its outputs against the original. Reconnect services with approved credentials, and test failed uploads, duplicate submissions, and rejected access. Keep a written mapping from old identifiers to new ones so bookmarked requests and attached documents do not lose their relationships.
Assign someone to reconcile changes made during the move. Agree when writes stop, how remaining updates transfer, and which failures trigger rollback. If your current backend already meets the workload, include this migration effort when comparing renewal with replacement. The enterprise app development article covers scoping a workflow before committing to a broader rebuild.
Where Permute fits: business evidence behind the app
Permute is the connected business data and custom application software we sell, so we have a commercial interest in this decision. A backend purchase can host your request records while leaving a separate problem: matching those requests to customer and accounting records. We connect supported sources and reconcile identifiers so the application can use the agreed business record.
Your team declares which source establishes a status and how conflicting values should appear. We can reuse that definition with source evidence and current permissions. An operations manager checking a delayed request can inspect the supporting records and freshness, rather than receiving an unexplained status. Scope those requirements before deciding whether custom application work is needed.
Inspect the records behind an application status
Start with permitted business data and identify the evidence your users need to check a result.
Keep backend procurement and data integration in scope
We do not supply Xano licenses or promise a native Xano connector, automatic migration, or a cheaper equivalent of its plans. Source access and application hosting need an implementation review. Any external actions require supported operations, appropriate permissions, and approval. Keep Xano when it meets the application requirements; investigate connected-data work when inconsistent source records remain a separate obstacle.
Approve the budget after the production checks
Start with the annual backend base, then include the frontend configuration and unresolved operating costs. Choose the plan that supports the required developer controls and passes your workload checks. Keep capacity add-ons and migration effort visible until they are priced. A ready frontend becomes a production application when its backend behavior and maintenance responsibilities are accepted.
Review your application’s data requirements
Bring the prototype and source inventory to discuss definitions, access rules, and the work needed to support production.
Questions about budgeting for Xano
Should application users be included in the developer roster?
Keep the two rosters separate when requesting a quote. People who maintain the backend need workspace access, while staff using the application need the access rules defined for that application. Include both groups in requirements so capacity and permissions are evaluated against the intended use.
Should I commit annually while the frontend is still changing?
The annual calculation makes the year’s base commitment visible; it does not make an unfinished application ready for that commitment. Resolve the production access rules and deployment approach first. Compare the vendor’s current monthly terms if those decisions remain open.
Should a slow page trigger an immediate plan upgrade?
Inspect the requests behind the page and measure them with representative data. A slow response may need an implementation change or additional capacity, and the evaluation should identify which. Price the change after reproducing the problem.
When is staying with the existing backend reasonable?
Staying is reasonable when the current implementation meets the required access rules, workload, and operating responsibilities at an acceptable cost. Compare renewal against the full migration effort, including data checks and the cutover. A lower base subscription alone does not establish a less expensive move.