Internal tools and dashboards

A custom internal tool makes sense when the workaround has become part of how the business runs.

That might be a spreadsheet that only one person trusts, a shared inbox full of approvals, a report rebuilt by hand every week, or a SaaS product that almost fits but leaves the awkward step in the middle. The aim is not to rebuild everything. It is to give the team a clearer place to enter data, review status, fix exceptions, and trust the numbers they use.

The best first version is usually narrow: one admin screen, one review queue, one dashboard, one import flow, or one approval process that removes a real operational drag.

Not every spreadsheet needs replacing. Some are cheap, flexible, and good enough.

The warning signs are different: only one person understands the file, reports are rebuilt by hand, approvals happen in inboxes, data is copied between systems, mistakes are hard to trace, or managers cannot see what is stuck until they ask around.

That is when a focused internal tool can help. It gives the process a proper home: permissions, history, validation, search, exports, exception handling, and a clearer source of truth.

Yes, but the dashboard needs to start with the decision.

A useful dashboard tells someone what needs attention, what changed, what is blocked, and what action they can take next. If it only displays charts, it may look better than the old report while leaving the same operational problem in place.

For internal tools, I usually think about the screen around the dashboard too: filters, drill-downs, exports, permissions, notes, audit history, and exception queues. The goal is fewer status meetings and less guesswork, not prettier reporting for its own sake.

I try to understand the business job before choosing the technical shape.

For a new build, that means mapping the users, rules, data, permissions, integrations, reporting needs, and manual fallbacks. For an existing app, it means reviewing the code, deployments, logs, queues, schedules, environments, known weak spots, and the workflows people are afraid to break.

The output should be a sensible first slice of work, not a huge speculative plan. I would rather start with a useful release that reduces risk or removes a real bottleneck than spend weeks designing a perfect version nobody has tested against the business.

I treat sensitive data, payments, and compliance-heavy workflows as product risks, not just technical details.

That usually means thinking about access control, audit logs, encryption, retention, data minimisation, validation, error handling, and who needs to see what when something goes wrong. For payment and operational workflows, I also care about reconciliation, traceable calculations, and support screens that explain the answer.

On the City Taxis NHS booking automation, the system needed encryption, audit logging, access control, retention policies, and careful reporting. On Rushpay, payment calculations needed audit trails and reconciliation because upstream data could change.

No. Laravel is my speciality, but most useful business software is not just one framework.

I often work across the surrounding stack: JavaScript, TypeScript, React, Vue, Blade, Alpine, APIs, queues, databases, hosting, integrations, and the admin or customer-facing screens that sit on top of the Laravel application.

The reason I lead with Laravel is focus. It is the framework I know best, and it is a strong fit for the operational systems, portals, payment workflows, and internal tools I usually build. When another technology is the right supporting piece, I use it.

Yes. I can work independently on a defined part of the system, or alongside your in-house team, agency, designer, product owner, or infrastructure supplier.

The important part is agreeing ownership early. I want to know who reviews code, who approves releases, how environments work, where decisions are documented, and what needs to be handed back when the work is done.

I am UK-based and remote-first. In practice that usually means focused calls when decisions need discussion, async updates when progress needs visibility, and planned handovers so the work does not become another mystery dependency.