Some of our thoughts on this:
Scenario 1: Client Owns the Retool Instance
This is the standard and most recommended approach for client work. The client subscribes to Retool, maintains ownership of their data and billing, and grants you a developer seat (a Standard User) to build and maintain the applications within their organisation.
For their employees, should you use End User seats or External User links?
You should absolutely use End User seats for the client's employees.
- End Users are intended for members within an organisation who need to use the apps you build but not edit them. They can log in to the company's Retool portal, see all the apps they have been given permission to access, and use them fully. This is the correct and compliant way to license internal staff.
- External Users are designed specifically for individuals outside the client's organisation, such as their own customers, suppliers, or partners. Using External User seats for internal employees to circumvent End User pricing would be a violation of Retool's terms of service.
Functionally, giving employees an External User link would also provide a worse experience. They wouldn't have a central portal to find their tools and would lose out on features tied to being an authenticated internal user.
Scenario 2: You Own the Retool Instance
In this model, you subscribe to a Retool Business (or Enterprise) plan, build applications in your own workspace, and share them with clients.
Are my clients External Users of my apps?
Yes, in this setup, your clients and their employees would access the apps you build for them as External Users.
Is this approach viable and what are the downsides?
While technically possible, this approach is fraught with significant challenges and is generally not recommended for building bespoke applications for individual clients.
Here are the major downsides:
- Data Isolation and Security: This is the most critical issue. All your clients' data would be processed through your Retool instance and connect to databases that you manage. You would be responsible for implementing a robust multi-tenant architecture to guarantee that Client A can never, under any circumstances, see data belonging to Client B. This is a massive technical and security liability for your business.
- Billing and Licensing Compliance: This model is not the intended use of the External User feature. Retool's pricing is designed for an organisation building tools for its own internal users. Using your instance to effectively resell internal tools to other companies via the External User feature is a grey area at best and likely contravenes the licensing agreement.
- Support and Ownership: The client has no direct relationship with Retool support. You become the single point of contact for any platform issues. If the client wants to take the app in-house, the migration process is not a simple click of a button.
- App Transfer Complexity: To transfer an app, you would need to export the application's JSON definition. The client would then need to import this JSON into their new Retool instance and painstakingly reconnect every query, component, and variable to their own data sources (databases, APIs, etc.). It is a manual process that can be prone to error.
In short, this model might seem attractive for centralising your work, but it introduces significant security, compliance, and operational risks. It is far safer and more professional to work within the client's own instance.
Answering Your Additional Questions
1. What’s the real difference between an End User and an External User?
| Feature |
End User |
External User |
| Intended Role |
An employee or member inside the organisation. |
A customer, partner, or individual outside the organisation. |
| Authentication |
Logs into your company's Retool instance (e.g., via Google SSO, email/password). |
Does not have a Retool account. Accesses via a public URL. |
| App Access |
Can access a central homepage to browse all apps they have permissions for. |
Can only access the specific app(s) shared via direct link. Cannot browse. |
| Licensing |
A paid, named seat on your Retool plan. |
Billed based on usage (e.g., monthly active users or page loads), depending on the plan. |
| Key Features |
Can use the full suite of Retool features they are permissioned for. |
Cannot use certain Retool features like Retool Database or Workflows in some contexts, and has limited interaction with the platform itself. |
An End User is a trusted, internal team member. An External User is a less-trusted, external person with limited, specific access.
2. Can you build multiple simpler apps as part of a single app?
Yes, absolutely. This is a very common and effective pattern. A single Retool "application" can contain many different views or pages. You can use components like a Tabbed Container to house different tools (CRM, inventory, orders) in one place, or use a Navigation component to allow users to move between different "pages" within that single app.
3. Is it better to ship several mini-apps or one hub app?
For a small business with related workflows, a single hub app is often better.
- User Experience: It's far slicker for a user to switch between tabs in one browser window than to have multiple bookmarks and browser tabs for different mini-apps. It feels like a single, cohesive piece of software.
- Licensing Efficiency: As you noted, it's more efficient. To access five different tools within one hub app, a user needs access to just that one app. To access five mini-apps, they would need permissions for all five, which is more to manage.
The time to consider mini-apps is when the tools are for entirely different teams or have vastly different security and data access requirements.
4. How do you package this as an agency?
Your calculation is correct, and you've hit on a key challenge: communicating the value against the cost. Here is how successful developers and agencies structure their pricing to make it attractive:
- Separate Your Fees from Retool's Fees: Be very clear in your proposal. The client pays Retool directly for their licensing. You are not a reseller. Your fees are for your professional services.
- Your Fees:
- One-off Build Fee: A fixed project price or a day rate for the initial discovery, design, development, and deployment of the application.
- Monthly Retainer (Optional but Recommended): An ongoing fee for maintenance, support, bug fixes, and a set number of hours for minor feature enhancements.
- Justifying the Cost (The Value Proposition):
- Focus on ROI, not Cost: Do not compare Retool's price to an off-the-shelf SaaS product. Compare it to the cost of the problem you are solving. If your inventory app saves 5 employees 2 hours per week each, that's 10 hours of labour saved weekly. Calculate that saving in monetary terms. The app will likely pay for itself very quickly.
- The Cost of Custom: A bespoke application that integrates perfectly with their existing spreadsheets, databases, and ways of working is immensely valuable. Off-the-shelf software often requires the business to change its processes to fit the software. With Retool, you build the software to fit their exact process.
- Start Small: Propose building one high-impact tool first. Once they see the value and the time saved, the cost of adding more users and more apps becomes a much easier conversation.
For the small shop example (€116/month), the conversation should be: "This €116 monthly fee enables a custom tool that will save you X hours and prevent Y costly mistakes, saving your business an estimated €XXX per month."
5. What business types benefit most from Retool?
Retool is most powerful for businesses that have unique operational workflows and rely on data from multiple sources. It is not for building a public-facing website like Wix.
Excellent candidates include:
- Operations-Heavy Businesses: Logistics, e-commerce, manufacturing, and service companies. They need custom dashboards for order tracking, inventory management, customer support, and fulfilment.
- Tech Startups and Scale-ups: They need admin panels, customer management tools, and data visualisation dashboards but want their core engineers to focus on the customer-facing product, not on internal tools.
- Financial Services and Fintech: For building underwriting dashboards, compliance checklists, and customer onboarding tools.
- Any company with "Spreadsheet Hell": Businesses running critical operations from complex, shared spreadsheets are prime candidates. A Retool app provides a robust, error-free, multi-user interface on top of their existing data, wherever it may live.