How we work

The smallest
useful system first.

From the first signal to a working capability. Built, embedded and improved with the people who use it.

Signal

Find the opportunity worth building around.

Start with the ambition, the last real run and the people closest to the work. Find the constraint or opportunity that will make a meaningful difference.

We start with: A desired outcome and a recent example of the work.
You receive: A workflow map, a priority opportunity and a recommended scope.
Your involvement: Your process owner explains the work and helps establish a baseline.
Ready when: We agree what needs to change and whether there is enough evidence to scope a build.

System

Design the useful thing. Then make it work.

Define the output, data, decisions and ownership. Build the smallest useful version, then test it against representative work and the cases most likely to cause trouble.

We start with: An agreed opportunity, source access and representative work.
You receive: A working system with acceptance checks, run records and documented limits.
Your involvement: Your team confirms permissions, approves the design and reviews the output.
Ready when: The useful path and critical exception cases meet the agreed release criteria.

Shipped

Put the capability into the real work.

Connect the system to the live environment. Train the people involved and make operating, reviewing, recovering and changing it part of the handover.

We start with: An accepted build and the people who will own it.
You receive: A working capability, operating guidance and a clear handover.
Your involvement: Your team practises routine use, review and exception handling.
Ready when: An owner can run the workflow, recognise a failure and use the agreed escalation route.

Compound

Learn from use. Build the next advantage.

Review the result against the baseline. Improve the workflow, fix recurring failures and expand where evidence and operating capacity support the next step.

We start with: Run records, user feedback and agreed measures.
You receive: A prioritised improvement backlog and evidence for the next decision.
Your involvement: Your owner reviews value, usage and changing requirements.
Ready when: Changes have a reason, an owner and a way to verify that they helped.

Creative practitioners reviewing cobalt clothing and fabric samples in a contemporary fashion studio.

More than a
working demo.

The handover should explain how the system works and how to keep it useful.

Workflow and metric definitions
Acceptance checks and evaluation cases
Account, data and operating owners
Recovery and change guidance

Read the build guide ↗

The right shape
for the work.

Fit call

Clarify the outcome, urgency and whether Compound Lab is the right partner.

Diagnostic

A paid, time-boxed investigation when deeper mapping is needed before a responsible build can be scoped. You receive a concrete recommendation.

Build

A fixed-scope implementation with defined success criteria, ownership, checks and handover.

Embedded Lab

An ongoing partnership across the four capabilities for a roadmap of problems and opportunities.

Operate and improve

Agreed monitoring, incident response, evaluation and optimisation for systems that need continuing ownership.

Clear ownership.
Agreed boundaries.

Your environment, your decisions

Wherever practical, accounts, data, files and export paths remain with you. We agree the access needed for the work, who approves important actions and what is included in handover.

Support that is explicitly scoped

Monitoring, response arrangements and ongoing changes are agreed for each engagement. A build does not imply 24/7 coverage. New sources, channels and requirements enter an agreed change process.

Security and data ↗

Before we begin.

Do we need a diagnostic first?

Only when the work needs deeper mapping before implementation can be responsibly scoped. If the outcome, inputs and constraints are already clear, we can scope a build directly.

Do you work with our existing tools?

Where appropriate. We assess the available access, data quality and integration options during discovery. A tool appearing in the directory is an invitation to discuss it, not a promise that every workflow is supported.

Explore integrations ↗

How do we agree what success means?

We define acceptance criteria before building. They can include output quality, reliability, review effort and the decision the system supports. Business impact is evaluated against an agreed baseline rather than guaranteed in advance.

Who needs to be involved?

A person who owns the outcome, the people who do the work and whoever can approve the required access. Your team helps define the workflow, review representative outputs and establish operating ownership.

Can we operate the system ourselves?

That can be part of the engagement. We agree ownership, documentation, training and export requirements in the scope. Ongoing Lab support is available where the system and team need it.

Start with what
you want to make possible.

Bring the ambition and a recent example of the work. We will help find a useful place to begin.

Scale your advantage