Skip to content
Something
Start

How to build

How to build an internal tool or dashboard without code

Internal tools are the work that never reaches the top of an engineering backlog, because each one is individually small and collectively enormous. The operations team wants an admin panel; finance wants a tracker; someone is running payroll out of a spreadsheet with four tabs of formulas nobody dares touch. These are all the same shape of problem, and that shape is now describable rather than buildable.

Start building free~15 min to first version

What you’re building

An internal tool is any small app your team uses to get work done that you would never sell: an admin panel, a request queue, an approvals flow, an inventory tracker, a reporting dashboard. Built here it has a real database, real screens, and a URL behind sign-in.

Who this is a good fit for

  • Operations and finance teams whose requests sit permanently below the product roadmap
  • Anyone maintaining a spreadsheet that has quietly become load-bearing
  • Engineers who could build it but have better things to do with a week

How to build it

  1. Step 1

    Describe the tool and who uses it

    Say what the tool is for, who touches it, and what they do to a record. "Who touches it" matters more than people expect — a request queue where anyone can approve is a different app from one where only a manager can, and that distinction is easier to state now than to retrofit.

  2. Step 2

    Connect where the work already happens

    Internal tools die when they become a second place to check. Connecting Slack means new requests announce themselves in the channel people already watch; connecting Sheets means the finance export they rely on keeps working. The tool joins the existing workflow rather than competing with it.

  3. Step 3

    Watch it build the screens and the permissions

    It generates the submission form, the queue view, the detail screen with comments, and the manager dashboard — plus the role logic that decides who sees which. Permissions are built in from the description rather than bolted on, which is the part hand-rolled internal tools usually skip and regret.

  4. Step 4

    Ship it to the team and iterate on real use

    Publish, send the link, and let people use it badly for a week. What comes back — a missing field, a status nobody uses, a filter everyone wants — is the real spec, and each of those is one sentence to fix. This loop is the entire reason building it yourself is now reasonable.

What it does once it’s running

  • Forms, queues, detail views and dashboards generated from one description
  • Role-based permissions — who can submit, who can action, who can only watch
  • Notifications into Slack or email so the tool reaches people where they are
  • Reads and writes the Sheets and trackers your team already depends on
  • A URL behind sign-in, no deployment step to think about

Tools it connects to

SlackGoogle SheetsLinearJiraNotionAirtableGmail

What it won’t do

  • Built for internal use behind sign-in — not for a public, unauthenticated product surface
  • Very large datasets (millions of rows) want a real warehouse behind them rather than this as the store
  • Complex approval chains with legal sign-off requirements usually need review before they go live

Start from a template instead

Each of these opens with the prompt already written. Edit it before you build.

Project / Task Automation

Create, sweep, and sync tasks across Slack, Linear, and GitHub.

Slack Digest

Daily Stripe, PLG funnel, and product metrics pushed to Slack.

Common questions

What counts as an internal tool?
Anything your team uses to get work done that you would never sell: admin panels, request queues, trackers, approval flows, reporting dashboards, small CRUD apps over a dataset. If it currently lives in a spreadsheet with too many tabs, it is probably this.
Can I control who can do what?
Yes. Describe the roles when you describe the tool — who submits, who actions, who only watches — and the permissions are built in rather than added later. You can change them afterwards by asking.
Does it replace Retool or Airtable?
It overlaps. The practical difference is that you describe the tool instead of assembling it from components or configuring a base, and you get a real app with its own database rather than a layer over one. For simple tracked lists Airtable is often enough; this starts paying off when the logic gets specific to how you work.
What if we already have the data somewhere?
Connect it. Sheets, Airtable, Notion and the rest can be read and written directly, so the tool can sit on top of the data you already maintain instead of asking people to move it.

Related use case

AI agent for operations & project automation

Create, sweep, and sync tasks across chat, issue trackers, and code automatically.

Build it in the next ten minutes

Start with a sentence. Leave with a working app on its own URL.

Start building freeSign in