When your Retool tool becomes the product

Why an internal Retool app struggles once customers log in

A Retool app built for your own team is designed around people you trust, a single organisation and no revenue of its own. Once customers log in, all three assumptions break, and fixing them is product work rather than a few extra screens.

Most Retool apps start the same way. Someone connects Retool to the company database so the team can look things up, update records and stop working out of spreadsheets. It does that job well. It doesn't have to be pretty, because the only people using it sit in the same office or the same Slack workspace.

The shift usually happens gradually. A customer asks to see their own data instead of emailing for updates, and gets a login. Then a few more ask. At some point the tool your staff use every day has become something customers rely on and would pay for, and it is still built like an internal tool. The rest of this guide goes through what changes when that happens, area by area, and what we would do about it.

The day customers log in, the trust model flips

Internal tools assume every user is a well-meaning colleague. Products have to assume some users are not. That one change ripples through everything else.

Retool handles staff logins neatly, usually through your company's Google account or single sign-on. Customers need something different: public sign-up or invitation by email, password resets, email verification, sessions that expire, and for larger customers, single sign-on with their own identity provider. Retool does support external users on some plans, billed separately from internal users, and for a modest portal that can be enough for a while. It gets awkward once the number of customer logins grows, once you want people to sign themselves up, or once the per-user cost starts influencing who you are willing to invite.

Watch for one symptom in particular: customers sharing logins with colleagues because adding a new person means asking your team to do it. That is a sign the access model was never built for them. A product lets each customer's own admin invite and remove their own staff, and lets you see who actually did what.

Permissions stop being about roles and start being about rows

Staff permissions are about what kind of person you are: ops can edit, finance can see invoices. Customer permissions are about which records are yours. Every query has to be limited to the customer who is signed in, and that limit has to be enforced on the server, not trusted from the screen.

Most Retool apps connect to the database through a single resource with broad credentials, because staff were allowed to see everything. Queries are often written directly in SQL in the editor, with filters that depend on values from the interface. That is fine for a trusted team. For customers, one missed condition in one query means a customer sees another customer's records, which is both a commercial disaster and a reportable data breach under UK GDPR.

The safer shape is a backend with an API between the interface and the database, its own database credentials with only the access it needs, and a check on every endpoint that the record belongs to the signed-in customer. Postgres row level security can enforce the same rule inside the database as a second line of defence, so a mistake in application code fails closed rather than leaking data.

One organisation becomes many

A product with many customers needs multi-tenancy designed in, rather than patched on. Internal tools rarely have the concept of an organisation, because there is only one: yours.

In practice that means an organisations table, every customer-owned record carrying an organisation ID, and users who belong to an organisation with a role inside it. It also means deciding early what happens when one person works with two of your customers, as agents, consultants and outsourced finance teams often do, and whether a customer's data can ever be deleted on request.

Retrofitting an organisation ID onto a database that Retool apps already depend on takes care. The internal apps still need to work while the schema changes underneath them, so each migration is checked against the Retool queries that read those tables before it runs. Adding a column is usually harmless; renaming one or making it required can break a Retool screen your team uses all day.

Someone has to pay for it

Retool has no way to bill your customers, so billing is new work, not a migration. Even a simple plan needs a payment provider such as Stripe, a subscription per organisation rather than per user, webhooks that turn access on and off when payments succeed or fail, invoices with VAT that a finance department will accept, and a way to handle the customer who wants to pay by bank transfer.

Pricing choices shape the data model too. Per-seat pricing needs a count of active users per organisation. Usage pricing, such as a fee per order processed or per record tracked, needs reliable usage records that can be reconciled against invoices. Decide the pricing model before building the billing, because changing it later touches every part of the app.

It has to look like yours

Customers judge your company by the screens they log in to, so the customer app needs your branding and a design built for occasional visitors, not daily operators. Retool's components are built for people who use the same screen all day: dense tables, forms and buttons. Customers visit now and then and need to understand a screen in seconds. They expect your branding, a clear first-run experience, sensible empty states, emails that look like they came from you, and a layout that works on a phone.

This is the part that cannot be carried across. Retool exports apps as JSON or Toolscript files that only Retool can run, which makes them excellent backups and a precise specification, but they cannot become a React app. The customer interface is designed and built fresh, usually in a framework such as Next.js.

What to do when your Retool app becomes a product

Split by audience, not by technology. Your team keeps Retool, because it is very good at exactly that job and rebuilding admin screens in code is rarely a good use of money. Customers get a proper web app, built on the same Postgres database, with its own backend and credentials.

Treat the Retool apps as the specification. Write down every query, JavaScript transformer and Retool Workflow behind the screens customers use, because the conditions hidden in them are easy to miss and they often quietly correct data. Scheduled workflows become backend jobs with retries and alerts. If any data lives in Retool Database, which is managed Postgres, it can be copied out with standard Postgres tools or exported as CSV.

Then run the new app in parallel. Move a handful of friendly customers across first while everyone else stays on Retool, compare results on real data, and only then move the remaining customers and remove their Retool access. For a focused customer-facing app, four to eight weeks is a realistic timeline, and keeping internal admin in Retool is what keeps it that short.