Web Applications
Purpose-built browser applications for customers and staff who need to complete a process online, connected to the systems that hold the records.
A website can stay simple while it only publishes information. Once people need to apply, book, pay, upload documents or check their own records, the work is an application: accounts, permissions and a reliable connection to the systems that hold the data.
Software engineering, not commodity website production
A web application normally has meaningful business behaviour, identity, data, integrations or operational requirements. The work may be a new system, or an interface around software that cannot or should not be replaced.
Usability and completion are design objectives. People should be able to finish the important processes in the browser, including the awkward cases. That is not a guarantee that nobody will ever need help. A custom application should not be built where a suitable existing product already solves the requirement.
When this comes up
A process that starts online and finishes by phone
Customers or staff begin something in the browser and then have to phone or email to complete it.
A spreadsheet kept beside the official portal
Staff maintain their own record because a step is missing from the system they are meant to use.
A system of record with a poor front end
The core system cannot be replaced, and the people who use it are working around its screens.
A product that does most of the job
An off-the-shelf product covers most of the need, and a purpose-built application is required beside it.
Typical work
Process and roles
Investigate the workflow, user roles and exception cases before screens are designed.
Application and services
Build the browser interface, backend services and APIs, with authentication, authorisation and validation.
Integration and operation
Connect to existing systems of record, and deploy the application with a release process that can be operated after handover.
What you end up with
An application people can finish the process in
Including the awkward cases found during discovery, not just the main path.
Accounts and permissions that match the roles
Customers, staff and administrators each see and change what their role allows.
A release process and documentation
The application can be deployed, monitored and changed by whoever runs it after handover.
How a typical engagement works
01Discovery
Investigate the process and the roles
We follow the workflow with the people who use it, including exception cases, before any screen is designed.
02Design
Design the workflow
Roles, permissions, data and integrations are agreed, with the riskiest parts identified first.
03Build
Build in working stages
The application is delivered in stages so people can use part of it early and correct our understanding.
04Deploy
Deploy and hand over
Deployment, monitoring, documentation and support are arranged to suit the people who will run it.
05Support
Support after launch
After launch, support can continue with fixes, changes and new features.
Frequently Asked Questions
Start with a conversation
Book a free 15 minute call. Describe the problem, the systems involved and what you already know, and we will tell you plainly whether we can help and what a sensible next step looks like. There is no obligation.