What we can help with

We help organisations get found and understood online, replace manual work with software that fits, put AI to practical use and keep existing systems fit to change. If yours sits somewhere in between, tell us anyway.

Websites & digital experiences

A website has a job: help the right people find you, understand what you offer and take the next step. We design and build around that job, from a first site for a small organisation to a larger platform with its own workflows.

Problems it addresses

  • Visitors cannot tell quickly what you do or how to reach you.
  • The site is slow, awkward on a phone or hard to keep up to date.
  • Bookings, orders or enquiries are handled by hand because the site cannot take them.
  • You are starting out and need a first site done properly, without paying for more than you need.

What you might get

  • A structure and design based on what visitors need to do
  • A responsive, accessible, fast website or web application
  • Enquiry, booking or other custom workflows
  • Search fundamentals in place, and handover notes so you can run it

Typical outcomes. The actual list depends on the scope we agree.

What we look into before building a website
  • Your audience and what they come to do
  • Existing content, branding and any current site
  • Systems the site must connect to, such as booking, payment or email
  • Who will maintain it, and how comfortable they are doing so

How it starts

We begin with who the site is for and what it has to achieve. For a straightforward site, that conversation may be all the discovery needed. Larger platforms start with a scoped piece of work before any build is priced.

A question worth bringing

What should a visitor be able to do in their first minute on your site?

Talk to us about a website

Software, apps & integrations

When off-the-shelf software does not fit, or several systems refuse to cooperate, people end up doing the joining by hand. We build custom tools, mobile apps and integrations that bring information and processes together.

Before

  • Bookings
  • Invoices
  • Customer records

People carry the same details from one system to the next.

After

  • Bookings
  • Invoices
  • Customer records

Details are entered once and reach every system that needs them.

An illustration of what an integration changes, not a delivered project.

Problems it addresses

  • The same data is typed into more than one system.
  • A critical process runs on spreadsheets, email and memory.
  • Two systems should exchange data and do not, or do so unreliably.
  • You need a mobile app and are not yet sure what it should do first.

What you might get

  • A custom web, desktop or mobile application
  • Integrations through APIs, data feeds or scheduled synchronisation
  • Internal tools built around a specific process
  • Tests, documentation and a handover plan in proportion to the system

Typical outcomes. The actual list depends on the scope we agree.

What we look into before building software
  • The systems involved and what access or APIs they offer
  • Where the data lives, who owns it and how reliable it is
  • The people who will use the tool, and on which devices
  • Security, permissions and any regulatory constraints you work under

How it starts

We start by mapping how the work is done today: who does what, in which systems, and where it goes wrong. Small tools can often be scoped from that conversation. Integrations and larger applications usually begin with paid discovery, because the answer depends on what the systems involved can actually do.

A question worth bringing

Where do people re-enter, copy or chase information today?

Talk to us about software or an integration

AI & workflow automation

AI is useful when it takes on a well-defined part of a real process and its results can be checked. We build AI and conventional automation into the workflows you already have, with people reviewing the steps where a mistake would matter.

Problems it addresses

  • People spend hours reading, sorting or extracting details from documents.
  • Knowledge is spread across files and systems, and finding an answer takes too long.
  • Routine steps in a workflow are repeated by hand many times a day.
  • You want to use AI, or have tried a tool, and need to know where it can be relied on.

What you might get

  • An assessment of where automation or AI fits a process, and where it does not
  • AI-assisted features built into existing tools or workflows
  • Review and approval steps for people, placed where errors would matter
  • A way to measure quality, with guidance on running costs and limits

Typical outcomes. The actual list depends on the scope we agree.

Before building, we agree four things: how success is assessed, where people stay involved, what data the system may access and what it takes to run.

How we assess an AI feature: the four checks
How success is assessed
We agree what a good result looks like and test against real examples from your process, so quality is measured, not assumed.
Where people stay involved
Steps where a mistake would matter get human review or approval. Not every step needs it, and we help decide which do.
What data the system may access
We agree which data an AI service can see, where it is processed and what must stay out.
What it takes to run
Cost per use, speed, what happens when the service fails and who looks after it once it is live.

How it starts

We start with the process, not the technology: what goes in, what should come out and what happens when the output is wrong. That first conversation is free. Testing an approach on your real examples is paid work, scoped and agreed in advance.

A question worth bringing

What would have to be true for you to trust the result?

Talk to us about AI or automation

Legacy modernisation

Older systems often carry years of business knowledge, along with code nobody wants to touch. We start by understanding what the system does and why, keep what works and improve what holds it back. A full rewrite is one option among several, and rarely the first to reach for.

  1. Stage 1: The system as it is

    Running the business today, with everything it has learned.

  2. Stage 2: Assessment

    What it does, what it depends on, what is tested and what is at risk.

  3. Stage 3: A route that fits

    • Refactor in place
    • Migrate in stages
    • Replace

    Chosen on the evidence, and often a combination.

  4. Stage 4: Staged change

    Small steps, each tested, each with a way back.

An illustration of how a modernisation route is chosen, not a delivered project.

Problems it addresses

  • Small changes take a long time and break things in unexpected places.
  • The system depends on outdated technology, or on knowledge that has left the organisation.
  • It runs the business, so it cannot simply be switched off while it changes.
  • You have been told the only answer is to rewrite everything, and want a second opinion.

What you might get

  • An assessment of the system: structure, dependencies, risks and options
  • A reasoned recommendation between refactoring, incremental migration and replacement
  • Tests that capture current behaviour before it is changed
  • Staged improvements, each with a way to roll back, and documentation that makes the system easier to maintain and evolve

Typical outcomes. The actual list depends on the scope we agree.

What we assess before recommending a route
Dependencies
The libraries, platforms and integrations the system relies on, and which of them are out of support.
Behaviour
What the system actually does today, including the undocumented rules the business depends on.
Tests
What is covered, what is not and what must be covered before changes begin.
Migration risk
Data, interfaces and the order in which things can safely move.
Continuity
How the business keeps running while the work happens.
Rollback
How each step can be undone if it does not behave as expected.

How it starts

The first conversation is free. The work itself starts with a paid technical assessment, scoped and agreed beforehand: we need to read the code, see the system running and talk to the people who depend on it before recommending anything.

A question worth bringing

What must keep working, without interruption, while the system changes?

Talk to us about an existing system

Tell us what's getting in the way.

Starting something new or fixing what is already there, begin with a free initial evaluation. We'll work out whether, and how, we can help.

Let's figure it out