Business and public sector

How we work
with your organisation.

Before development, we define what the software needs to do, which data it can use and how to check that it works. The approach depends on the organisation, its responsibilities and the service being built.

For businesses

Start with a task
that slows things down.

A procedure that is hard to find, data entered into several systems or multiple locations to coordinate. Our first conversation helps identify where a change could be useful.

  • Information and procedures that teams need to find.
  • Requests and documents with too many manual steps.
  • Existing tools to connect or missing features to build.

For public organisations

Define the service
and the responsibilities.

Documents, staff workflows and access to information need a clear scope. We approach these issues through the organisation’s requirements and the people involved.

  • Assisted access to the organisation’s archives and documents.
  • Support for staff, with clear sources and limitations.
  • Prototypes to test user journeys before extending a service.

Work through it together

The questions
that matter.

These points become part of the project’s requirements and checks.

Which data can the system use?
Sources, purposes, roles and access must be defined before integration begins. Data retention and logging are also part of the project.
Where is a human decision needed?
We establish which tasks to automate and where approval is required. An exception needs a defined way to be handled; it should not be left to the model’s behaviour.
How do we check that it works?
Test cases, answer quality, usability and accessibility requirements must become acceptance criteria. Verification is planned alongside each feature.
Who will look after it after launch?
We define responsibilities, documentation, updates and recovery procedures. Interfaces and data exports help the system evolve over time.

The working process

At every step,
something to assess.

  1. Scope of work

    We document users, objectives, available data and constraints, then choose a first use case and the result to verify.

  2. Technical proposal

    We compare options and define features, integrations, tasks and acceptance criteria, with an estimate of the work involved.

  3. A prototype to try

    A focused version built around representative cases lets us assess usefulness and limitations before extending development.

  4. Delivery plan

    We agree on subsequent releases, operational handover and maintenance, based on the findings and priorities that emerge.

Contact

Tell us how you work.

The task you want to improve, the people doing it and the tools they already use: that’s a useful place to start.

Message sent.

Thank you for getting in touch. We’ll reply to the email address you provided.

Please do not include health data, passwords or other confidential information.

We’ll use your details to respond to your enquiry. Read the privacy notice.