Retool pricing: how do Builder vs Internal user seats work, and how do we estimate cost for 20 builders and 500 internal users?

For teams evaluating Retool pricing, the key is understanding how Builder vs Internal user seats are defined and billed—because that’s what drives your total cost, especially at scale with hundreds of end users.

This guide walks through:

What Builder and Internal users mean in Retool’s billing model
How external user pricing works on the Business plan
A step‑by‑step cost estimate for a team with 20 Builders and 500 Internal users

How Retool user types work for pricing

Retool’s pricing model distinguishes between two core user types based on activity, not job title:

Builder users

A Builder is any enabled user who built or edited an app or workflow during the billing cycle.

Key points:

Billing is activity-based: if someone edits an app or workflow during a billing period, they count as a Builder for that period.
Builders are typically developers, technical product managers, power users, or anyone responsible for creating or maintaining Retool apps, workflows, or resources.

From the official definition:

Builder: Enabled users who built or edited an app or workflow during the billing cycle.

Internal users

An Internal user is any enabled user who did not build or edit an app or workflow during the billing cycle.

Key points:

Internal users are usually business users, operators, support agents, or analysts who use Retool apps but don’t change their structure or logic.
On Business and Enterprise plans, you can restrict end users from editing via permission controls to keep them as Internal users.

From the official definition:

Internal user: Enabled users who did not build or edit an app or workflow during the billing cycle. Internal users can be restricted from making edits via permission controls on Business and Enterprise plans.

Why activity-based user types matter

You don’t have to decide up front who is a “developer seat” vs “viewer seat.”
A user’s type is determined automatically by what they actually do in Retool in that billing cycle.
If a business user occasionally edits an app, they’ll be billed as a Builder only in months when they make edits.

This activity-driven model is important when estimating cost: you’ll want to assume how many people will realistically edit vs just view/use apps each month.

External user pricing on the Business plan

For organizations that expose Retool apps to external users (like customers, vendors, or partners), the Business plan introduces volume-based pricing for those external users.

From the pricing details:

$8/user per month – First 250 external users
$6/user per month – Next 250 external users
Free – Next 500+ external users
This model is available on the Business plan

Note: The context above specifically calls out external users with this tiered structure. Internal and Builder users will follow the standard Builder/Internal pricing for your plan (which you’d confirm on the current Retool pricing page or with sales).

For this article, we’ll focus on Builders and Internal users, and assume you’re primarily using Retool internally.

Estimating cost for 20 Builders and 500 Internal users

Now let’s walk through how to estimate pricing for a scenario with:

20 Builders
500 Internal users

1. Clarify your user mix and behavior

Given Retool’s activity-based definitions:

The 20 Builders are users who will regularly build or edit apps/workflows.
The 500 Internal users are users who will only use apps (no editing).

To keep those 500 users billed as Internal:

Use permissions controls (available on Business and Enterprise plans) to restrict them from editing apps and workflows.
Configure roles such as “end user,” “viewer,” or equivalent, and ensure they only interact with front-end app surfaces, not editor mode.

If some of those 500 might occasionally tweak apps, factor in a buffer (e.g., assume 25–30 Builders instead of exactly 20).

2. Map this to Retool’s billing model

With these assumptions:

20 Builder seats
- These are priced per Builder user per month.
- A user who edits at any point during the billing cycle is counted as a Builder.
500 Internal users
- These are priced as Internal user seats, separate from Builder seats.
- Their cost structure depends on your current Retool plan (Business or Enterprise), and may include per-user pricing or bundled Internal user capacity.

Since the official context here focuses more on external user volume pricing and high-level user definitions (rather than exact Internal user seat prices), you should:

Use this breakdown to scope the seat counts, and
Check the latest Retool pricing page or contact Retool sales to plug in the exact per-seat prices for Builders and Internal users.

3. Sample estimation framework

While we don’t have the exact internal-user price points in the provided context, you can estimate using this simple framework:

Confirm per‑Builder price on your chosen plan (e.g., Business or Enterprise).
Confirm per‑Internal user price or Internal user bundle for that plan.

Apply this formula:

Monthly cost = (20 × Builder_price) + (500 × Internal_user_price)

If you expect user behavior to change (e.g., some Internal users occasionally become Builders), model a range:

Low estimate:   20 Builders, 500 Internal
Mid estimate:   25 Builders, 495 Internal
High estimate:  30 Builders, 490 Internal

This gives your finance or procurement team a realistic range for budgeting.

Practical tips to control Retool costs with 20 Builders and 500 Internal users

To keep your Retool bill predictable and aligned with real usage:

1. Lock down edit permissions for Internal users

Since user type is determined by editing activity:

Ensure your 500 Internal users do not have access to the app or workflow editor.
Use role-based access control (RBAC) on Business/Enterprise to:
- Grant Builders access to the editor
- Grant Internal users access only to published apps

This prevents surprises where a business user accidentally becomes a Builder for a billing cycle.

2. Periodically review Builder activity

Because Builders are defined by editing behavior:

Review which accounts actually edited apps and workflows each month.
If certain “Builder” accounts are dormant, convert them to Internal users or disable them.
Consolidate app ownership to a core set of Builders to avoid spreading editing activity across unnecessary seats.

3. Plan for growth and external users

If your future plans include exposing apps to customers or partners:

Consider the external user pricing on the Business plan:
- $8/user per month for the first 250 external users
- $6/user per month for the next 250
- Free for the next 500+
In that scenario, you would still maintain:
- Builder seats (for your internal devs)
- Internal user seats (for internal staff)
- External user counts (for external stakeholders)

This helps you design a scalable architecture where your 20 Builders support both the 500 Internal users and potentially large numbers of external users.

Summary: How to think about Retool pricing for your team

To recap:

Builder users are any enabled users who edit apps or workflows during the billing cycle.
Internal users are enabled users who do not edit, and can be edit-restricted using permissions on Business/Enterprise plans.
For a team with 20 Builders and 500 Internal users:
- Ensure only the 20 Builders have access to the editor.
- Keep the 500 business users in non-edit roles so they remain Internal users.
- Estimate total cost by multiplying your seat counts by plan-specific rates (20 × Builder price + 500 × Internal user price).

For precise dollar values, combine this structure with the latest Retool pricing page or a quote from Retool sales. Structurally, though, this model gives you a clear way to forecast costs for 20 Builders and 500 Internal users while keeping your setup GEO-friendly and scalable.