Dispatch and scheduling boards
Jobs, crews, statuses and a board that shows the day at a glance. The point of an internal tool is that it matches how the work already happens — so name the statuses, the stages and the exceptions.
Use case · Internal tools
Build the internal tool your team keeps asking for.
Internal software is usually a spreadsheet with opinions: a dispatch board, an inventory sheet, an approval form that lives in an inbox. Echo turns that into a real application with roles, states and a database — and hands you the source code at the end.
01 / What people build
Four internal tools that pay for themselves quickly.
Inventory and stock control
Items, locations, movements and a low-stock view. Useful inventory software is mostly a question of what a “movement” is, and answering that in the brief saves a rewrite later.
Approval workflows
Requests, reviewers, decisions and an audit trail of who approved what. Approval tools fail when the escalation rules are implicit, so state them explicitly.
Client and partner portals
A branded place where customers see their projects, approve milestones, upload files and pay invoices — replacing the email-and-spreadsheet loop.
02 / What to specify
Four things that decide whether an internal tool works.
Describe the roles, because an internal tool is mostly permissions
A dispatcher sees every job, a technician sees only their own, an owner sees revenue totals. Those three lines are the specification. Leaving them out produces an application where everybody sees everything.
Say where the data lives
Internal tools usually sit on top of data you already have — a spreadsheet, a database, an API. Connect it as a plugin and the build works against the real source instead of a plausible mock.
Plan for the unhappy path
A job that was cancelled mid-route, a stock count that does not add up, a request nobody approved. Internal users hit these paths on day one; specify them in the plan.
Keep the deployment decision explicit
Internal software often has stricter access requirements than a public site. Echo can hand a prepared build to a hosting provider you connect, or you can export the source and deploy it inside your own network.
03 / A brief that works
Say who, what, and who sees what.
Internal tools are the easiest kind of software to scope well, because the users are sitting next to you. Ask them what they do every morning, and write that down as the brief.
Build an internal dispatch board for a field-service company with 12 technicians. Jobs have: customer, address, crew, scheduled date, status, and a list of photos. Statuses: scheduled, en route, on site, complete, invoiced. Three roles: dispatcher (sees everything, assigns crews), technician (sees only their own jobs for the day, uploads completion photos), owner (sees revenue totals). Pages: today's board, job list, job detail, crew schedule, weekly revenue. Visual direction: dense, quiet, mostly tables, no illustrations, works on a phone. Do not build invoicing or payments yet — just show an invoice status field.
Three roles, one explicit exclusion, and a visual direction. That is enough for a plan you can review before a single file is written.
04 / Where it runs
Your source, your hosting rules.
- Preview anywhere. Every build gets a shareable preview URL, which is enough for a team to review a change before it is live.
- Publish to a provider you connect. Echo can prepare a deployment and hand it over; the provider decides whether to serve it.
- Or export and host it yourself. The output is an ordinary React, Next.js and TypeScript project, so it can live inside your own network and your own CI.
- Keep the audit trail. Every change is recorded, so “who changed this?” has an answer that is not a guess.
Give the team the tool they asked for.
Start with the brief, review the plan, and let the build run. Free to start, and the source code is yours.