Skip to content
StealThis.dev

You're building an internal tool or dashboard

The situation

The ops team tracks refunds in a spreadsheet and asks for “a small tool”. Or support needs to look up users and toggle flags. It’s real software — but the users sit two desks away, there are eleven of them, and nobody will ever see it outside the company. The team instinctively reaches for the same stack, review bar, and polish as the public product… and the “small tool” is suddenly a two-month project.

Diagnosis: why it happens

Internal tools live under inverted constraints, and applying public-product defaults to them is optimizing for users you don’t have:

  • Users are known and reachable. No SEO, no onboarding funnel, no first-impression risk. Training is a Slack message. Browser support is “whatever IT installed”.
  • The bottleneck is change speed. Internal tools change constantly — every process tweak lands here. Value = how fast a request becomes a shipped change, not how pretty the empty states are.
  • The real features are unglamorous: auth (SSO, roles), tables (filter, sort, export), forms with validation, and an audit trail of who changed what. That’s ~90% of every internal tool ever built.
  • The real risk isn’t churn — it’s damage. Nobody uninstalls the refunds tool; but a permissions bug there costs actual money. Access control deserves the rigor the animations don’t.

Platform-wise the answer is boring: it’s a web app behind your company login. Desktop browsers, controlled environment, no stores. The actual decision is how much you build vs assemble.

Recommendation: the boring web stack, assembled for change speed

Pick the least custom thing that covers the need, in this order:

  1. Does an admin framework / internal-tool builder cover it? (Retool, Appsmith, Django admin, AdminJS…) CRUD over a database with roles is a solved problem — assembling beats building by 5–10× on time.
  2. If you build: server-rendered pages or a plain SPA with a component library — tables, forms, SSO middleware. No custom design system, no pixel work. Boring choices are a feature: any teammate can fix it in a year.

Whatever you pick, three things are non-negotiable because it’s internal:

✔ SSO / company auth — never a shared password in a wiki
✔ Roles: viewer vs operator vs admin (support reads; leads refund)
✔ Audit log on mutations: who, what, when — one DB table, saves an incident

And the corresponding freedom — actively don’t spend on: custom branding, animation polish, mobile-first layouts (unless the users are literally in the field), cross- browser archaeology, marketing pages.

Walk the build-vs-assemble decision for your tool:

When does it matter? The trade-off flips with headcount-hours: a tool 3 people use weekly should be assembled in days; a tool 200 support agents live in 8h/day justifies product-grade investment — at that point it is a product, with an internal market.

Discarded alternatives (and when they ARE the right call)

Admin framework / low-code platform as the permanent answer

  • What it solves: CRUD + roles + tables in hours; non-engineers can tweak flows; it is the recommendation’s step 1.
  • Why it can stop being right: at some complexity (custom workflows, external integrations, gnarly business logic) you fight the platform more than the problem; per-seat pricing scales badly; and logic trapped in a vendor UI resists code review and versioning.
  • When it IS the right call: the first version of almost every internal tool — and the final version of most. Migrate off only when concrete friction (not aesthetics) demands it.

Spreadsheet + scripts (the tool you already have)

  • What it solves: zero build time, the ops team already knows it, flexible reporting for free.
  • Why it’s not the first option here: the case starts where this breaks — no concurrent editing discipline, no validation, no permissions granularity, silent formula corruption, and scripts nobody owns.
  • When it IS the right call: genuinely small scale — one owner, low stakes, read-mostly. A spreadsheet used by two people beats a web app used by two people. Don’t build software to feel like a software team.

Product-grade SPA (same stack and bar as the public product)

  • What it solves: consistency with the main codebase, shared components, familiar CI. And engineers enjoy it more.
  • Why it’s not the first option here: it imports the public product’s cost structure — design reviews, responsive breakpoints, e2e suites — for users who measure the tool in “does it save me time today”. Two months instead of two weeks for the same eleven users.
  • When it IS the right call: the “internal” tool is drifting toward customer-facing (a partner portal), or usage justifies it (the 200-agent case), or it must embed inside the product’s own UI anyway.

Native or hybrid app

  • What it solves: field teams — offline forms in warehouses, barcode scanning, photos on site.
  • Why it’s not the first option here: for desk-based back-office use it adds a distribution pipeline (MDM/TestFlight) and slows every iteration, which was the one thing that mattered.
  • When it IS the right call: the users are physically mobile and the browser is awkward (scanning-heavy warehouse flows, offline field inspections → It must work offline).

How to measure before and after

Internal tools have unusually honest metrics — the users are on your payroll:

  • Time saved: minutes per task × frequency, before vs after. “Refund handling went from 6 minutes in three tabs to 40 seconds” is the whole ROI statement.
  • Request-to-ship latency: how long from “can it also filter by region?” to deployed. If this exceeds ~a week for small changes, the stack is too heavy for its job — which is this playbook’s core claim.
  • Adoption without enforcement: if people keep using the old spreadsheet next to your tool, the tool lost. Ask them why; the answer is your backlog.
  • Skip: Lighthouse scores, conversion funnels, anything about users you don’t have.

Signals you need something else

  • External users (partners, customers) start logging in → it’s a product now; re-enter the tree at Web, PWA, hybrid or native? and raise the security bar.
  • The dashboard’s tables are slow with real data volumes → Your huge list renders slowly and Your endpoint is slow.
  • The tool mostly displays data others own → maybe it should be a read model / BI dashboard, not an app — check what your data warehouse tooling already offers.