§ 01Internal tools
The screens your staff work in all day: queues that show what needs doing, record views with exactly the fields each role needs, bulk actions for repetitive work, and admin dashboards that point at exceptions instead of decorating a wall.
| Return | Item | State | Age |
|---|---|---|---|
| Selected: RMA-3307 | Router, model R2 · damaged | Refund > limit | 3d |
| Selected: RMA-3302 | Desk lamp · wrong item | Inspecting | 2d |
| RMA-3295 | Monitor arm · missing parts | Supplier hold | 5d |
| Selected: RMA-3291 | Keyboard · unopened | Refunding | 2d |
What this page covers
§ 01Screens
Custom internal tools development is mostly about six kinds of screen. Each is designed around one role’s daily work, and all of them read and write the same records.
A filtered list of records that need action from the viewer’s role, sorted by urgency rather than by date of creation. Saved views replace the shared spreadsheet tab that everyone filters differently.
One screen per record type with its fields, current state, owner, related records, attachments, comments and history. Fields appear, become required or lock depending on the state and the viewer’s role.
Assign, change state, export or update many records at once, with the same validation and permissions as a single edit. Every bulk change appears in the audit trail record by record.
Screens for the people who run the tool: users and roles, reference data (sites, products, price lists), thresholds and notification rules. These changes no longer require a developer.
The first screen each role sees: their queue, their exceptions and the few counts that tell them whether the day is on track.
Find any record by ID, customer, product or free text. Exports respect field-level permissions, so restricted data does not leak out through a CSV.
§ 02Today
Internal business application development usually replaces something that already works, badly: a shared spreadsheet, a database console only one developer can use, and an inbox that serves as the approval system.
| BeforeToday: sheet, console and inbox | AfterIn the internal tool |
|---|---|
| shared spreadsheetReturns are tracked in a shared sheet; three people edit the same row and overwrite each other. | recordEach return is a record. Two people cannot overwrite the same field, and every edit has an author. |
| database consoleA developer runs SQL to change a status when the sheet and the system disagree. | ruleState changes go through the tool, with the same validation as every other change. |
| inboxThe inspection result arrives as an email with photos; the agent copies it into the sheet. | recordInspectors record the result and photos on the return itself, on a tablet at the bench. |
| manager approvalRefunds above the limit wait for the manager to read the right email. | decisionRefunds above the limit appear in the manager’s queue with the inspection attached. |
§ 03Record screen
Audit trail
The header answers the two questions people open a record to ask: where is it, and whose move is it.
The refund amount is editable during inspection and locked after approval. Required fields change as the record moves.
The order line and the customer are links, so the return never disagrees with the order it came from.
Every change and decision is listed with who and when, including bulk edits and changes made through integrations.
Illustrative record · example data
§ 04Access
The same returns queue looks different to an agent, an inspector and a team lead. Permissions decide which records appear, which fields can be edited and which actions are offered, and the server enforces them as well as the screen.
| Role | View returns | Record inspection | Approve refund | Override state | Export | Manage users |
|---|---|---|---|---|---|---|
| Agent | Yes | No | Approves ≤ $500 | No | No | No |
| InspectorPer site | Yes | Yes | No | No | No | No |
| Team lead | Yes | Yes | Approves > $500 | Yes | Yes | No |
| Finance | Yes | No | No | No | Yes | No |
| Tool adminIT or ops | Yes | No | No | No | No | Yes |
§ 05Dashboards
Admin dashboard development services often go wrong when they start from the chart library. We start from the questions each role asks at the start of a shift, and the dashboard answers them in a few seconds: what is waiting for me, what is late, and where it is stuck.
§ 06Decision
Internal tools development does not always mean custom code. This is how we advise teams to choose, including when we recommend not hiring us.
| Question | Spreadsheet + forms | Low-code tool builder | Custom internal tool |
|---|---|---|---|
| Users and records | A handful of people, hundreds of rows. | Teams, thousands of records. | Many roles, large volumes, many related record types. |
| Permissions | Sheet-level sharing. | Per app or per table. | Per role, per state and per field, including exports. |
| Business rules | Formulas that anyone can break. | Scripts inside the builder. | Tested rules in code, versioned with the system. |
| Integrations | Manual import and export. | Connectors for popular SaaS tools. | Any API, file exchange or database, with retries and logs. |
| Ownership | Yours, but fragile. | Tied to the builder’s pricing and limits. | Your code, your hosting, your roadmap. |
| Right choice when | The process is small and stable. | Screens are simple CRUD on one data source. | The tool is how the operation runs and must enforce rules. |
§ 07Delivery
We watch the current work: the spreadsheet tabs, the inbox rules, the SQL someone runs on Fridays. Then we write down records, states and roles.
Queue, record and admin screens built against a copy of your data, so people judge the tool by their actual work.
Validation, routing and permissions in code; connections to the systems the tool reads and writes; import of current records.
Training per role, a short period of support at the desk, then handover of code, admin guide and runbooks.
§ 08Questions
In an operational system, an admin dashboard is the first screen a role sees. It shows the records waiting for that role, the exceptions that need attention (overdue items, failed syncs, records on hold) and where work is piling up. It links straight into the records, so the dashboard is where work starts, not just a report.
When the tool is a set of simple forms and tables on one data source, used by one team, with permissions at the table level. Once you need rules that must not be bypassed, field-level permissions, several integrations or large volumes, a custom internal tool is usually cheaper to own than a low-code app full of workarounds.
Often, yes. An internal tool can read and write an existing database through a service layer that enforces the rules, so staff stop editing tables directly. If the database is part of a legacy system that has to be replaced, we plan that with the modernization work instead.
Screens used away from a desk (inspection, receiving, field checks) are designed for touch and small screens from the start. Back-office screens with dense tables are designed for desktop and stay usable on a tablet.
Portals for customers and partners are a separate Comtau service with different requirements, such as self-registration and public-facing security. This page covers tools used by your own staff. The two often share the same records and integrations.
Next step
The fastest way to scope an internal tool is to start from what people use today. Describe the records, the roles and the workarounds, and we will propose the screens.
brief.txt · what helps us most
