Software that happens to run in a browser
How this is usually engaged
Typically phased: a first release covering the highest-value workflow, then extension. Fixed-scope for the first phase, then a rolling arrangement once priorities are informed by real usage.
Multi-user applications with real permissions, real workflow and real data volume — portals, dashboards, booking systems and operational tools.
A web application is where a spreadsheet goes when it has outgrown the person maintaining it. The symptoms are familiar: version conflicts, no audit of who changed what, permissions enforced by asking people not to look, and reporting that takes a day to assemble. The risk is not that the spreadsheet is inelegant; it is that a business process now depends on a file that one person understands.
Roles, permissions and record-level scoping defined as data and enforced server-side. Includes an audit trail of privileged actions.
Approval chains, status transitions and business rules modelled explicitly, so the system can explain why an action was refused.
Operational dashboards and scheduled exports built on queries designed for the data volume you will have in three years, not the volume you have today.
Getting existing spreadsheets and legacy records in, with validation, a dry-run mode and a reconciliation report.
Email and in-app notifications with per-user preferences, so the system is useful without becoming noise people filter away.
Where the work happens in warehouses, on sites or in transit: local persistence and conflict handling designed for the actual failure mode.
A process that runs the business but lives in a file with no permissions, no history and one person who understands it.
Giving external parties controlled access to their own data, which removes a large volume of routine email from your team.
Scheduling, dispatch, case management or compliance tracking that is currently spread across email and shared drives.
We model the domain and its rules explicitly — states, transitions, and who is allowed to cause them — then enforce those rules on the server. The interface is designed around the tasks people repeat most, at the density they need. Access control is defined as data rather than scattered through the code, so it can be audited and changed without a release.
The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.
The workflow as it is actually performed, including the workarounds people have invented.
Entities, states, transitions and who may cause each one.
Designed at real density for the tasks performed dozens of times a day.
Working software in an environment you can use, reviewed on a regular cadence.
Dry run, reconciliation, then a cutover with a rollback path.
Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.
These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.
Every request is authorised on the server against the acting user's role and their relationship to the record. Interface elements are hidden for clarity, never for security. Sessions are server-side and revocable, sensitive actions are written to an append-only audit log, and input is validated against a schema at the boundary.
By keeping the stack ordinary, the code reviewed, and the documentation part of the deliverable rather than a favour. You get the repository, the pipeline and the runbook. If you later take it in-house or hand it to another supplier, everything they need is in the repository.
Where those systems expose an API or a supported export, yes. Where they do not, we will say so early rather than discovering it in build. Integration scope is agreed explicitly, including what happens when the other system is down.
Migration is treated as a work stream in its own right, not an afterthought. We build an importer with validation and a dry-run mode, produce a reconciliation report showing exactly what came across and what did not, and agree the discrepancies with you before cutover.
You will have something running in an environment you can open within the first few weeks — incomplete, but real. We would rather you correct our understanding early against working software than approve a document that turns out to mean something different to each of us.
The project brief takes about five minutes and gives us enough to have a useful first conversation about Web Applications rather than a generic one. If you would rather just ask a question, the short form is there for that.
We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.