v7dUrgent AI & software development · UK

Ship the software that cannot wait.

We build and run software for organisations that cannot wait. For an urgent problem that passes our checks, a first working version is in real use inside seven working days, and a proper pilot follows within thirty.

Discuss an urgent project Watch the build

Targets depend on agreed scope, technical feasibility, systems and data access, decision-maker availability, dedicated delivery capacity and budget. Dates are confirmed before work begins.

tg — build log · working days 1–7

What you are watching: a real seven-day build, day by day. First we check the job is doable, then we build one working piece of software, then we put it in front of your people. You do not need to read code to follow it.

0WD

to a working MVP for a qualifying brief

0DAYS

to a controlled first pilot in real work

0PRODUCTS

built and run by the same delivery teams

0SILENT

model outputs: every decision is reviewable

in plain terms · for people who do not write code

You bring the problem. We bring working software.

The rest of this page shows how we work in the language of engineers, because that is the proof. This is the same story in plain terms.

Tell us what cannot wait

A deadline, a stuck project, a process that is drowning, an AI idea your board is asking about.

Your time: one conversation.

We say yes or no in two days

We check whether it is genuinely doable fast: the right access, one clear goal, someone who can make decisions.

You get: an honest answer, not a sales pitch.

You see it working every day

Not a slide deck at the end. Something real on day two, better every day, your people using it by day seven.

You get: a first working version in a week.

You decide with evidence

After thirty days of real use you have numbers, feedback and safeguards, so the next decision is easy to defend.

You own: the software, the data and the plan.

✓

No jargon in decisionsEvery technical choice is explained in terms of cost, risk and time before you are asked to approve it.

✓

Nothing hidden behind a demoYou watch real software being used by real people, with the problems visible too.

✓

You own everythingCode, data, documentation and a named person who runs it. No lock-in, no hostage situation.

brief.yaml

workflow.ts

pilot.dashboard

deploy.pipeline

# brief.yaml — qualified on working day 1
client: "regulated service operator"
problem: "decision queue backlog blocks releases"
workflow: "triage → decision → audit trail"   # one, not five
access:
  systems: ["case api", "identity", "warehouse"]
  granted: true          # before the date is promised
decision_maker: "available daily 09:00"
acceptance:
  - "a caseworker completes a triage in < 3 min"
  - "every decision has an audit record"
  - "model output is reviewable, never silent"
budget: agreed
feasibility: pass
qualified: true   # mvp target: working day 7

yaml · gate passed

// workflow.ts — the one usable path
import { triage, decide, audit } from "./steps";
import { review } from "./safeguards";

export async function run(c: Case): Promise<Decision> {
  const t = await triage(c);              // model-assisted
  const d = await review(decide(t));      // human in the loop
  await audit({ c, t, d, by: d.reviewer });
  return d;
}

// acceptance.test.ts
it("completes a triage in under 3 minutes", ...)   // ✓
it("writes an audit record for every decision", ...) // ✓
it("never returns a silent model output", ...)      // ✓

typescript · 12 tests passed

active users

triages completed

median time

0min

acceptance criteria

0/ 3

reviewed decisions per day · pilot week 3

pilot · 0 silent outputs

build · workflow@1.0.012s

test · 12 acceptance, 84 unit41s

security · dependency + secret scan9s

deploy · controlled rollout 10% → 100%2m

observe · traces, alerts, on-call namedlive

pipeline · owned, not handed off

IN PLAIN TERMSThis is your brief, written down and checked. If it passes the four checks, we commit to a date.

01working days 1–2 · brief.yaml

A fast answer begins with a hard qualification.

Scope, access, feasibility, budget and decision speed are tested before any date is promised. The brief is a file we can check, not a hope.

Day 0qualified: true, or an honest no

02working day 7 · workflow.ts

Make the smallest release answer the biggest question.

One usable workflow, model-assisted with a human in the loop, and acceptance criteria written as tests before the build begins.

Day 7MVP in controlled use

03day 30 · pilot.dashboard

Put the software into controlled use, not another demo.

Real users, real numbers, safeguards on. The next deployment decision is made on evidence you can read off a dashboard.

Day 30controlled first pilot

04ongoing · deploy.pipeline

Harden, integrate, observe and own.

Build, test, security, controlled rollout and observability with a named owner. The interface is only one part of a deployable system.

Ownednot handed off

services · one accountable route

Four functions. One accountable team.

Consultancy, product design, engineering, AI, integration and governance move together around the work, not in a hand-off chain.

In plain terms: we rescue projects that are stuck, build the first version of new software (with AI where it genuinely helps), guide larger change one pilot at a time, and make sure anything we launch is safe, secure and looked after. Each card below says what you put in and what you get back.

rescue(deadline, blockedRelease)

Urgent software development

Recover a deadline, deliver a critical path or stabilise software when the work cannot wait for a conventional cycle.

returns a shipped critical path · from 7 working days

build(workflow, acceptance[])

AI MVP & product development

Concentrate product, engineering, AI and integration effort on one usable workflow with acceptance criteria agreed up front.

returns an MVP in controlled use · day 7, pilot by day 30

transform(operatingConstraint)

AI transformation projects

Start with the delivery problem, the operating constraint and the evidence the next decision needs, not a technology label.

returns evidence for the next decision · pilot by pilot

deploy(system, { safeguards, owner })

Responsible & secure deployment

Architecture, safeguards, integrations, operating ownership and feedback sit behind the visible product experience.

returns a system someone owns · designed in from day 1

use cases · the board moves while you read

Operational problems, not technology labels.

Workflow automation, knowledge operations, regulated delivery and service modernisation, framed before architecture or vendors are chosen. Each card is a real shape of engagement.

In plain terms: these are the kinds of problems people bring us. The board moves the way our work moves: from a list of problems, to one being built, to software your team is actually using.

Backlog0

Decision queue backlog is blocking releases

workflow automationrescue

Caseworkers cannot find current policy fast enough

knowledge opsAI MVP

Regulator wants an evidence pack in six weeks

regulated deliverygovernance

Legacy field scheduling must be replaced before winter

service modernisationintegration

Voice notes from care visits never reach the record

voice captureAI MVP

Previous supplier left with a half-built release

project rescuestabilise

In progress0

In controlled use0

qualification · what makes seven days realistic

Does your brief qualify?

A seven-day MVP needs one decisive workflow, immediate access, available decision-makers and acceptance criteria agreed before activity begins. We check those four gates on day one, and we say no when they fail.

In plain terms: four questions decide whether a week is realistic. Is it one clear job? Can we get into your systems straight away? Is someone available to make decisions? Do we agree what "done" looks like? The examples on the right show a yes, a no, and a rescue.

Send us a real brief

qualification model · example briefs, not customer data

type a brief…↵

engineering capability · the whole deployable system

The interface is one part of the system.

Product, AI systems, API, cloud, quality and observability disciplines turn a prototype into controlled working software. Watch the requests move.

Product & interfaceone usable workflow, tested with real users

AI systemsmodel calls with review, never silent

API & integrationcase, identity and warehouse connected

Quality & observabilityacceptance tests, traces, alerts, on-call

In plain terms: the screen your staff use is the small part. Behind it we connect your existing systems, add AI only where a person still checks the answer, test everything automatically, and watch it around the clock once it is live.

delivery cadence · small releases, every working day

Ship daily, not at the end.

A seven-day MVP is not one big drop on day seven. It is a working skeleton on day two and a visible increment every day after, so the decision-maker never waits for a reveal.

In plain terms: each square is a working day and the brighter it is, the more we released that day. You never wait for a big reveal. The list on the right is what a typical first month of releases looks like.

v0.1.0wd 2walking skeleton deployedend to end, does nothing useful yet, runs in the client environment

v0.4.0wd 3core triage workflowthe one usable path, reviewed against acceptance criteria

v0.7.0wd 4model wired, first end-to-end runhuman review step on every model output

v0.9.0wd 5user review, six fixes, safeguardssame-day changes from the caseworker session

v1.0.0wd 7MVP in controlled use12/12 acceptance tests, observability on, owner named

v1.3.0d 30pilot evidence packusage, quality and decision data for the next deployment call

products · built and run by the same delivery teams

Product thinking, tested in the work we build.

Six products in one monorepo. They show the operational detail we design around, not unverified customer outcomes.

In plain terms: we do not only build for clients, we build and run our own products for service operations, assessment, field teams and care. That is how we know what real operations need before we design yours.

📁 products/six shipped products · one delivery team

├── journey/The operating system for complex service delivery.operations │ └── meritura/Assessment and evidence for regulated programmes, by Journey.assessment ├── spectra/Intelligence across queues, decisions and signals.intelligence ├── fieldopspro/Field service scheduling and control.field service ├── care-voice-ai/Voice-led capture for care settings.care └── voiceops-ai/Voice automation for operations teams.voice

technical due diligence · before an urgent engagement begins

Everything a buyer should check, answered up front.

The evidence, security questions, delivery assumptions and commercial boundaries a buyer should establish before an urgent engagement begins. We hand this over on working day one, not after the contract.

Request the diligence pack

0/6

Security questionnaire answeredSEC-01

Data handling, residency and retention statedDATA-02

Delivery assumptions written downASSUME-03

Commercial boundaries and exit termsCOMM-04

Evidence of capability, not customer claimsPROOF-05

Ownership, source and operating handoverOWN-06

git log --oneline · urgency without shortcuts

In plain terms: three rules we never break, even under a deadline. Check first, build the smallest useful thing, then prove it with real users.

a1f7c0dfeat(qualify): gate before dateswd 1

A fast answer begins with a hard qualification.

We test the problem against scope, technical risk, access, budget and decision speed before promising a date.

c39e2b4feat(mvp): one workflow, acceptance as testswd 7

Make the smallest release answer the biggest question.

The MVP concentrates product, engineering, AI and integration effort on one usable workflow with visible acceptance criteria.

e8d51a9feat(pilot): controlled use with safeguardsd 30

Put the software into controlled use, not another demo.

Users, safeguards, feedback and operating ownership are designed into the pilot so the next deployment decision has evidence behind it.

What cannot afford to wait?

❯tell us the deadline, the blocked release or the AI opportunity

Start a conversation

We will test whether an urgent delivery path is credible before we promise one.