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.

Describe the problem to us

Book a free 15 minute call and tell us what is going wrong and which systems are involved.

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

  1. 01Discovery
  2. 02Design
  3. 03Build
  4. 04Deploy
  5. 05Support

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

Can this be built into an existing website or CMS?

Simple forms, often yes. Once people need accounts and their own records, a separate application connected to the website is usually easier to secure and maintain.

What is the difference between a website and a web application?

A website mainly publishes information. A web application lets people complete a process such as applying, booking, paying, uploading documents or checking their own records, with accounts, permissions and connections to other systems.

What kinds of web application do you build?

Customer and staff portals, workflow applications, administrative interfaces and specialised applications that sit around a system of record.

Can you build around a system we already have?

Yes. Many web applications are an interface around a system of record that cannot or should not be replaced, connected through its API or database.

How are logins and permissions handled?

With authentication and authorisation designed around the roles involved, so customers, staff and administrators each see and change only what their role allows.

Does it work on phones?

Yes. The interfaces are built to work in the browser on phones and desktops, and the design starts from what people need to finish on each.

Can it take payments and handle documents?

Where the process needs them, yes. Payments, document handling and notifications are built and tested as part of the workflow.

Who hosts and maintains the application?

Deployment and a release process are part of the delivery. Hosting can be run by the organisation, by another provider or by Ryoss under Managed Hosting.

How is the application tested?

With automated tests around the important paths, and with the people who will use it on the awkward cases found during discovery.

How do we get started?

Book a free 15 minute discovery call and describe the process people need to complete and the systems behind it. We will say whether an application, an integration or a product is the better answer.

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.