Bubble vs Retool: Customer Portals and Internal Tools

Start by separating the customer task from the staff task. A customer might request a quote, upload a document and see progress. Staff might assign the request, change its status and prepare the quote. Those are different interfaces over the same business process.

Bubble is a reasonable candidate when the customer interface needs a distinctive layout and several linked journeys. Retool is a reasonable candidate when the staff interface needs to query existing systems and perform operational actions. Retool also supports external apps; treating it as strictly internal would rule out a valid option.

You can use one platform for both audiences, or a customer app alongside a staff tool. The deciding questions are who can see which records, where changes are committed, and who will maintain the result. The examples below are illustrative designs, rather than client results.

Consider a Melbourne maintenance business with a customer portal for service requests and a dashboard for dispatch. The customer supplies an address, photographs and access instructions. Dispatch checks the request, assigns a technician and updates the appointment. The customer sees the appointment and progress, without seeing staff notes or other customers' addresses.

A Bubble-led design keeps the customer journey and staff screens in one application. A Retool-led design uses operational screens and a controlled external experience. A combined design puts the customer journey in Bubble and the dispatch interface in Retool, connected through an authorised API.

In that combined design, nominate one system as the authority for requests and status changes. Do not maintain two independently editable copies of the job. Record who changed it, the previous status and the new status. Decide what a customer sees if a connected system is temporarily unavailable.

Before estimating the build, write down one complete request from submission through dispatch to completion. Include a rejected request and a cancelled visit. These exceptions often determine more of the work than the happy-path screen.

Yes. Retool documents external apps for customers, vendors and partners. Its external classic-app guide describes branding and external-user permission groups. That guide is explicitly for the classic editor, while Retool now recommends its newer app builder. Confirm the chosen editor supports the external experience you need before committing to a design.

Check the live pricing page for external-user access and the required plan. A staff-only prototype on a cheaper plan does not establish the cost or suitability of a customer portal. Include the login flow, invitation rules and access removal in the proof of concept.

For an external portal, test a customer account with real permission boundaries. An administrator preview can hide problems a customer will encounter.

A hidden admin button is not a data-access rule. The customer must be unable to obtain another customer's record by changing an ID, opening a file URL or calling an endpoint directly.

Bubble uses privacy rules to control access to data types. Configure them for each private type and test both records and uploaded files. Review backend workflows separately: a workflow that runs with broader privileges needs its own checks on the requested action.

For Retool, app and resource permissions govern access to those surfaces. Also define how each query or API restricts records to the authorised customer or staff member. Do not rely on a browser filter as the only boundary. Write permission tests in business terms: customer A cannot read customer B's request; dispatch can assign a job; a technician can see only the jobs their role permits.

Price the actual audience, workload and connections. For Retool, distinguish builders, internal users and external users, then check the applicable plan. For Bubble, review the plan and workload assumptions for the customer journey. Verify current vendor prices instead of comparing an old starting price with a different kind of licence.

The operating estimate should also cover storage, email or SMS, API access, failed-job monitoring and support. A portal that needs a manual fix every time a payment or document upload fails can cost more to run than its subscription suggests.

Assign an owner for each integration. Document how to change a status rule, revoke access, reconnect a resource and recover from an interrupted workflow. For a combined setup, add the responsibility for keeping the interface contract between platforms consistent.

Build the smallest complete workflow before building every screen. Include a customer login, one request, a staff action, a status update and a failed connection. Use separate accounts for each role.

Choose one platform if it can deliver both audiences' requirements without awkward duplication. Choose a combined design when the benefit of specialised interfaces outweighs the extra connection and maintenance work. If neither can enforce the permissions or integration requirements, consider a custom application.

The handover should contain the data model, role matrix, external accounts, connection inventory and recovery instructions. For related scheduling requirements, read our booking-system backend guide.