Start a project

—Service

Internal Tools

Dashboards, reporting, workflow platforms, staff portals, and operational software.

01Overview

We build the internal software a business runs on — reporting, dashboards, portals, and workflow tools — designed for the people who use them daily rather than dressed up for a demo.

02How we approach it

Internal tools go wrong when they are specified from a distance. So we start with the work itself: who does it, where the data lives, which spreadsheets and workarounds currently hold the process together, and what it costs when something slips. That discovery feeds a definition stage with a firm scope — the workflows to replace, the systems to integrate, the roles involved, and what deliberately stays out of the first release.

Design for an internal tool is judged on the hundredth use, not the first. We lay screens out for the people who will live in them every day: dense where density helps, quick to scan, hard to break. Underneath sits the same engineering we apply to public products — typed contracts between frontend and backend, schema validation on every input, and role-based permissions so each person sees exactly what their job requires.

Most internal tools have to sit inside an existing landscape rather than replace it, so integration is engineered as a first-class part of the build — reading from and writing to the systems the business already runs, with failures handled and actions audited. Validation then happens with the people who will use the tool, against real data: permissions, edge cases, and the awkward records the spreadsheets have been quietly absorbing for years.

Rollout is staged rather than switched. The tool goes live through controlled environments, often running alongside the old process until the team trusts it, with monitoring in place from the first session. After that the system evolves on evidence: usage shows which workflows to extend next, and every change moves through staging first, so a tool the business depends on daily is never destabilised by an update.

See the full seven-stage process

03Suitable for

  • Teams relying on spreadsheets
  • Operations needing custom workflows
  • Businesses with internal reporting needs

04Problems solved

  • Manual, error-prone processes
  • Disconnected internal data
  • Tools nobody wants to use

05Deliverables

  • Operational dashboards
  • Workflow and reporting tools
  • Role-based access
  • Integration with existing systems

06Technical considerations

  • Designed for daily use
  • Permission-aware throughout
  • Auditable actions

07Common questions

What does a custom internal tool cost?

We don't publish prices, because the range is genuinely wide. Cost is driven by the number of workflows the tool covers, how many systems it must integrate with, the complexity of roles and permissions, and how much data needs migrating from spreadsheets or legacy software. Tell us what the process looks like today through the contact or brief form and we'll set out scope and cost in a written proposal.

Will it connect to the systems we already run?

Usually, yes — that is often the point. Most internal tools we build read from or write to existing systems: a CRM, an accounts package, a warehouse database, a third-party API. During Discover and Define we map every system involved, confirm what each one actually exposes, and design the integration around that reality. Where a system has no usable interface, we say so early and plan an alternative rather than finding the limit mid-build.

How do you make sure our team actually uses it?

Adoption is designed, not hoped for. The people who do the work are involved from discovery onwards, the interface is built around their real process rather than an idealised one, and validation happens with them on live data before launch. We also stage the rollout, often running the tool alongside the old spreadsheet until it has earned trust. A tool that saves its users time every day rarely needs persuading.

What happens after the tool goes live?

Deploy is the sixth stage of our process, not the last. Internal tools change as often as the business processes behind them, so ongoing care matters more here than on most builds. Our technical maintenance service exists for exactly this: the tool stays monitored, dependencies stay patched, and new workflows are added one controlled change at a time. The specific service commitments for any engagement are set out in the written agreement each project signs.

Could our own developers take it over later?

Yes — we build for that. The system is documented, typed, and version-controlled precisely so it outlives any single supplier, including us. Handover typically includes the repository, the database schema, deployment documentation, and a walkthrough with whoever inherits it. What is handed over, and who owns which deliverables, is defined in the written engagement agreement for each project, so there are no assumptions on either side.

08Related

Discuss a internal tools project.

Tell us what you need. We'll tell you how we'd build it.

Start a project
Internal Tools & Software Development UK — Sonar Development