--- title: "Cool demo. Now what? Building production-ready internal tools" description: "From a prototype that works on your machine to a tool IT will sign off." canonical: "https://stackdrop.co/blog/production-ready-internal-tools-low-code" published: "2025-07-18T09:00:00.000Z" updated: "2025-07-18T09:00:00.000Z" authors: ["John Miniadis"] topics: ["Production", "Retool"] readers: ["builders", "operators"] --- # Cool demo. Now what? Building production-ready internal tools The prototype works on your machine, and the team now runs month-end through it. IT has just asked who can change an invoice amount, and where that change is recorded. The builder is on holiday next week. A production-ready internal tool is one that holds up under real usage, real access rules, and change. It handles many users at once, controls who can do what, records what happened, has documented logic, and has a named owner. The test is a Tuesday morning. Forty people are using the tool, one of them started yesterday, and the person who built it is away. Is it still correct, secure, and supportable? A demo answers "can this be built?" A production-ready tool answers that harder question. ## The five markers Each marker maps to a way the business depends on the tool. Once the tool carries real work, none of them is optional. - **Reliability under load.** The tool behaves the same for one user as for the whole team at month-end. A query that returns in a second for one person should not time out for 30. - **Access control.** The tool knows who the user is and limits each role. A finance approver signs off an invoice. A junior analyst can view it but cannot change the amount. - **Auditability.** Who changed what, and when, comes from a log. Nobody has to remember it or search a Slack thread. - **Documented logic.** A rounding rule, or an approval that skips a step under a threshold, is written where a new hire can find it. - **A named owner.** One person or team decides what changes, keeps it running, and answers when it breaks. The steps below work through them in order, with what you can copy. ## Step 1: separate the environments Give the tool a development environment and a production environment, each with its own database and configuration. Changes get tested where they cannot touch live records. A staging copy in between is worth it when several people change the tool at once. ## Step 2: give access by role Sign people in through the company's identity provider, so leaving the company removes access. Define roles from the directory, then decide two things for each one: what it can view, and what it can change. Keep those two lists apart, because they rarely match. ## Step 3: log every write Record the actor, the timestamp, and the value before and after, for every change to data. If the tool writes to a Postgres database you control, a table like this is enough to start. ```sql title="audit_log.sql" create table audit_log ( id bigserial primary key, actor text not null, -- the signed-in user, from SSO action text not null, -- insert | update | delete record_table text not null, record_id text not null, before jsonb, after jsonb, created_at timestamptz not null default now() ); create index audit_log_record_idx on audit_log (record_table, record_id); ``` Write to it in the same transaction as the change itself, so a change cannot land without its record. Encrypt data in transit and at rest, and set retention from your policy, or from the regulator if there is one. [The security and compliance checklist](https://stackdrop.co/blog/retool-security-compliance-checklist) has the full list your IT team will ask for. ## Step 4: keep heavy work out of the screen Monitor query response times, database load, and API traffic from the first release. Use pagination for large tables and caching for data that rarely changes. When an operation gets heavy, move the computation to the database or a backend service, and return the result. If a dashboard needs a summary of 100,000 rows, compute the summary where the rows live and send the screen the totals. [Keeping internal tools fast as they grow](https://stackdrop.co/blog/performance-architecture-internal-tools) covers this in detail. ## Step 5: own the data and the rules Teams worry about lock-in, and the answer is to decide where things live. Keep the data in the system where it already lives, whether that is Postgres, Salesforce, or SAP. Keep the business rules that matter, such as validation and pricing, in queries or services you control. The interface then sits on top, and can change without rewriting the core. Retool supports that split well. Its new app builder produces React apps, written in Retool's own chat and code views or from a coding agent such as Claude Code. They deploy to Retool, which supplies hosting, version history, source control, permissions on each data connection, SSO, audit logs, and approval gates on writes. The code lives in your repository, and the data stays where it was. ## Step 6: write down the logic and name the owner Write the rules the tool enforces somewhere readable: thresholds, rounding, who approves what. Then name the owner. Usually that is a pairing: operations decides who needs what and what the tool must do, and a technical owner keeps the controls, integrations, and deployments working. A tool with no owner gets no maintenance until it fails. [The tool was free to build. Maintaining it is not.](https://stackdrop.co/blog/in-house-internal-tools-maintenance-problem) covers what happens next. ## What it looks like in practice [Pico Clinics](https://stackdrop.co/customer-stories/pico-clinics) ran clinics on separate systems in each region, staff relied on spreadsheets, and audits meant compiling records by hand. One platform brought patient records, scheduling, compliance dashboards, and inventory together, with separate regional databases and strict role-based access. Administrative workload dropped by about 40%, and compliance reporting stopped being a manual job. A luxury e-commerce partner ran support across Zendesk, order and shipping systems, and internal databases. One support console in Retool brought them together, and AI now drafts replies for an agent to approve. Handle time went from 3 to 4 minutes to 30 seconds, across more than 20,000 tickets. The full story is in [how a global enterprise automated customer support with AI](https://stackdrop.co/customer-stories/enterprise-ai-customer-support). ## How to tell it is working Four measures show whether the tool is earning its place: - the backlog of requests it has cleared - the features shipped per sprint - how many of the intended users open it every day - the hours of manual work saved, or the errors no longer made The last one is the clearest, because it is the cost the tool was built to remove. ## The checklist Copy this into the tool's repository and fill it in before go-live. ```yaml title="production-ready.yaml" tool: invoice_approvals environments: [development, production] # add staging if several people ship changes access: sign_in: company identity provider (SSO) roles: - role: finance approver can_view: [invoices] can_change: [invoice status] - role: analyst can_view: [invoices] can_change: [] audit: log: [actor, timestamp, before, after] retention: "" # from policy or regulation load: tested_with_users: 0 # the month-end peak, not one person heavy_work_runs_in: database # never in the screen logic_documented_at: "" # link to the rules: thresholds, rounding, approvals owner: operations: "" technical: "" data_lives_in: "" # the system that already holds it ``` ## Our view We recommend working through the five markers before a second team starts using the tool, because adding them later means reworking logic people depend on. Later rarely arrives anyway: by then the tool is busy. The builder who made the prototype stays the product owner and makes the final call. We bring the architecture, the production engineering, and the running of it. Cool demo. Now ship it properly.