How to build internal tools with Retool and Postgres

There's a familiar pattern at mid-market B2B SaaS companies. The engineering team is shipping product. The support team is asking for a tool to look up customer data. Finance wants a refund console. Sales wants a way to manually adjust a deal in the database. Ops wants a dashboard that pulls from three different systems. All of these requests get logged in Linear, all of them slip down the backlog, and most of them never ship.

Retool is the tool engineering leaders adopt to stop drowning in that queue. It plugs into your Postgres, your APIs, your Stripe, your HubSpot, and gives you a real UI in days instead of weeks. The first app gets built. Support stops pinging engineers ten times a day. Everyone breathes.

Then the platform sits there. The next ten obvious apps never get built, because nobody owns Retool past the initial install. That's the gap we keep walking into.

The Problem Most Retool Customers Have

When we audit a Retool instance, the symptoms are consistent:

• One or two apps in active use. A handful of half-built drafts no one will publish.
• No staging environment, no source control, no clear owner. Changes go straight into production whenever someone has a free hour.
• Permissions left wide open. Every employee can see every customer record, and the audit log has not been opened since the install.
• Retool Workflows untouched. The cron jobs and webhooks that should live there are still scattered across Heroku schedulers and one-off scripts.
• Retool AI features ignored. The team is paying for AppGen and Agents but is using neither, because no one has time to figure out how.

Retool gets used as a one-time pressure release valve when it should be the operating system for everything internal. The fix is not buying a second tool. It is treating Retool as a build surface and shipping the next four apps.

Automation Plays We Build with Retool

1. The Customer 360 Console

Trigger: a support rep or account manager opens the console and searches a customer.

Workflow: Retool queries your Postgres for product usage and entitlements, hits Stripe for billing status and MRR, calls HubSpot for the deal owner and lifecycle stage, and pulls open tickets from Zendesk or Intercom. All of it renders in one app with tabs and action buttons. From the same screen the rep can issue a refund, extend a trial, change the plan, or escalate to engineering.

Outcome: a customer call that used to require six open tabs takes one. Time-to-resolution drops, and the audit log captures every action.

2. The Refund and Credit Console with Approvals

Trigger: a CSM requests a refund or credit from inside the Customer 360 app.

Workflow: small refunds (under a threshold you set) go through immediately, with Stripe credited and the action logged. Above the threshold, the request triggers a Retool Workflow that posts a Slack message to the relevant manager with one-click approve or reject buttons. On approval, Stripe issues the refund, the deal is updated in HubSpot, and the customer gets an automated email. On rejection, the CSM is notified with the reason.

Outcome: finance gets a defensible audit trail. CSMs stop chasing managers in DMs. Refunds that used to take a day take ten minutes.

3. The AI Support Triage Agent

Trigger: a new ticket lands in Zendesk or Intercom.

Workflow: a Retool Agent reads the ticket, classifies it (billing, bug, feature request, onboarding), pulls the relevant customer record from Postgres for context, drafts a response using your knowledge base via RAG, and posts the draft back into the ticket for the agent to send or edit. For low-risk categories (password resets, plan questions) the response sends automatically. Edge cases route to a human with the agent's reasoning attached.

Outcome: first-response time drops to minutes. Agents spend their time on the cases that actually need judgement, not the ones that need a template.

4. The Data Quality Cockpit

Trigger: a daily Retool Workflow runs at 06:00 UTC against Postgres and your CRM.

Workflow: the cron job scans for duplicate accounts, orphaned records, broken HubSpot-to-Postgres syncs, customers with missing owner assignments, and Stripe subscriptions out of sync with your internal entitlement table. Anything that fails a check gets flagged in a Retool dashboard with one-click resolution actions (merge, reassign, force-resync). RevOps opens the dashboard, fixes ten things in fifteen minutes, and the database stays clean.

Outcome: the silent data rot that breaks reporting and forecasting gets caught at source. No more month-end surprises.

How Retool Should Integrate With Your Stack

• Postgres or your primary database: the source of truth. Retool should query it read-only by default, with write access scoped to specific roles.
• Stripe: billing actions (refunds, credits, plan changes, subscription pauses) belong inside Retool, not in the Stripe dashboard where mistakes have no rollback.
• HubSpot or Salesforce: contact and deal lookups from inside operational tools, with two-way sync so updates propagate back to the CRM.
• Slack: the approval layer. Use Slack as the human gate for any action that needs sign-off, and let Retool Workflows drive the threading.
• Snowflake or BigQuery: analytics views surfaced into Retool apps so operators see warehouse data without learning SQL.
• OpenAI, Anthropic, or Bedrock: bring-your-own model providers for AI Workflows and Agents. Pick the one that matches your data residency and security posture.

What ROI Actually Looks Like

These numbers are indicative, not promised. Every company's baseline is different, so treat them as the shape of the upside rather than a quote.

• Engineering time saved on internal tool requests: typically 60 to 80 percent. A queue of admin panel asks that used to cost two engineers a quarter each becomes a part-time job for one builder.
• Support handle time after a Customer 360 console: usually drops 20 to 40 percent, because reps stop hunting across tools.
• Refund processing latency: lands between a day and a few hours pre-build, and minutes once Slack approval routing is in place.
• First-response time on tickets with AI triage: routinely under five minutes for the categories the agent handles autonomously.
• Data quality incidents caught before they hit reporting: hard to count exactly, but the absence of month-end fire drills is the signal.

What Retool Costs in Practice

The license itself is not the expense most teams think it is. At mid-market scale you are looking at the Business tier, which starts at roughly $46 per builder per month and $14 per internal end user per month. A typical setup is two or three builders and 30 to 60 internal users, plus Workflow runs at $75 per 5,000 above the included 5,000. That puts most mid-market Retool spend somewhere between $700 and $2,500 a month. Enterprise is custom and usually unlocks SSO, source control, and dedicated environments, which is the threshold past which most regulated industries land.

The actual cost is the build. A single well-scoped Retool app (Customer 360, refund console, data quality cockpit) lands between 40 and 80 hours of build time depending on the data sources involved. The math that matters is comparing that to what your engineering team would have spent rolling the same thing in React, which is typically four to six times higher and a quarter as fast to iterate on once shipped.

Where Teams Go Wrong

Five patterns we see again and again, and what to do instead.

• Building one heroic mega-app instead of five small ones. A single 30-tab Retool app no one can maintain is worse than five focused tools. Ship narrow.
• Skipping the permission model. Default open access is a compliance issue waiting to happen. Configure Retool groups around roles (support, finance, engineering) before the second app gets built.
• Putting writes directly against production with no audit log or undo. Every destructive action should hit a logged endpoint, ideally via Retool Workflows, so you can replay or roll back.
• Treating Retool as a frontend-only tool. Workflows and Agents are where the real leverage lives. If you have not built a single Workflow, you are using a quarter of what you are paying for.
• Letting one engineer build everything in their head. Without source control, staging, and naming conventions, the platform turns into shadow IT. Treat Retool apps like code.

Where Moonira Comes In

Retool is a power tool. Most teams use it like a hammer when it can run the whole workshop. We come in as the team that owns Retool end to end: the apps, the workflows, the agents, the permissions, and the connection to your wider stack. Inside the first month we typically ship the Customer 360, the refund console, and the first AI triage agent. Inside the first quarter the engineering queue for internal tools is empty for the first time in a year.

Our builds come with the things most teams skip: documented permission groups, staging environments wired into source control, naming conventions that survive a team rotation, and a maintenance playbook your team can run without us. The point is not to lock you in. The point is to leave behind a Retool instance that does not turn into a liability the moment the person who built it leaves.

If your Retool instance has one app, three drafts, and zero workflows, you have a build problem, not a tool problem. We can fix the build.