Skip to main content
Skip to content
Ways of working

Nothing here starts from zero.

Discovery, build, test, release, then again. The rounds stay short because the method, the standards and the skin are already standing when we meet you, so the first week goes on your problem and what we learn comes from the people doing the job.

CH.01 · The mindset

A change of mindset, before any of the tooling.

Most delivery is organised around being right at the end. This is organised around being wrong early, cheaply, and in front of the people who will have to live with the result.

  • Scope it fully, then build to the scope.Scope the first round only, and let what it teaches write the next one.
  • Show the work when it is finished.Show it while it is still cheap to be wrong about.
  • Ask the manager how the job is done.Watch the job being done, by the person who does it.
  • Hand over at the end and leave.Hand over in the open, and stay until it runs without us.
CH.02 · The loop

Four steps, and the fourth starts the first again.

Short rounds beat long ones. Nothing here waits for a phase gate that arrives in March.

then again

DiscoveryBuildTestReleaseevery projectevery round
  1. 01

    Discovery

    sit with the work

    We watch the task being done and write down what actually happens on the day. The exceptions people have learned to handle by hand are usually the project.

  2. 02

    Build

    on real data

    A working thing on your systems and your data, early enough to be wrong cheaply. Never a slide of what it would look like.

  3. 03

    Test

    before anyone trusts it

    The failure cases are written down before release, not discovered after it, and checked by someone who did not build the thing.

  4. 04

    Release

    and watch it run

    It ships behind your permissions with a trail of what changed. Then we watch it in use, and what that shows starts the next round.

CH.03 · Why it is fast

We arrive already set up.

Speed here is not people working harder. It is the part of every project that is normally rebuilt from nothing being in place before the first call, so the quality bar and the pace stop competing with each other.

  • 01

    The AI Skin is already standing

    Rules, gateway and the connections to real systems exist before you are a customer. We are not choosing a stack in your first week; we are pointing an existing one at your work, operational or delivery side.

  • 02

    The structure carries the quality

    Planning, review, tests and release are the same on every project and enforced by the tooling. Nobody is remembering the standard under deadline, which is the usual place quality goes when speed arrives.

  • 03

    Short rounds compound

    A wrong turn costs a week. That is what makes it safe to start before everything is known, and starting early is most of where the time is won.

CH.04 · We run on it

We use the AI Skin to build the AI Skin.

Two of the projects on this site are not client work. They are ours, we run them every day, and that is how most of what is wrong with them is found before a customer ever meets it.

CH.05 · The feedback loop

Everything points at the person with the problem.

We are after a job that got better. So the loop is built to carry what people tell us back into the work quickly, and to keep asking after release rather than closing the project.

Automation designed in a meeting automates the version of the job that exists in the meeting.
People at work, where a task is actually done
  • 01

    The people who do it every day

    They know which cases are rare, which are constant, and which ones the system will get wrong. None of that is written down anywhere, and it is the difference between a demo and a tool.

  • 02

    Our customers, after release

    What changed in the work once it had been running a month. That conversation starts the next round rather than ending the project.

  • 03

    Ourselves

    We run two of these in-house, so some of the feedback arrives before a customer is exposed to it at all.

CH.06 · What we hand over

What lands, lands finished.

The same standard whether it is a model, a portal or a deck. These are the few rules a good project quietly enforces, and we hold each other to them.

  • Designed

    It looks like something you would put in front of your board. Look and feel is not a later phase.

  • Secure

    Every door has a lock. Log what changed and never the value.

  • Detailed

    The failure cases, the limits and the things we chose not to build are written down where you can read them.

  • Structured

    Organised so the next person can find their way in, including the next person on your side after we leave.

CH.07 · What we need from you

We need four things from you before we start.

Every ask on this list is something only you can bring. The boxes are drawn empty on purpose.

A planning session with a client
  1. A sponsor who can say go or no-go

    One person who can decide, for two hours a week during discovery.

  2. Read access to the systems in play

    Read-only access to the ERP, the CRM and the mailbox. Nothing is written until production.

  3. One process you already suspect

    The job your team does by hand, a different way each time. That is where we start.

  4. The numbers you already track

    We measure against them, not against new ones invented for the report.

CH.09 · Questions

How an engagement actually runs.

The engineers who scoped it. There is no delivery team behind the people you meet, and no commercial layer between you and them. We are six, and three are AI and ML engineers.

Access to the systems in scope, someone who can decide, and time from the people who do the work today. The package pages list this per engagement, because every item on it is something only you can bring.

You get the code, the models, the documentation and a trained team. If you want us to keep running it, that is a separate agreement with its own scope and its own end. Nothing renews by default.

Privacy by design, and GDPR is part of the build rather than a review at the end. Where the AI Act applies we say which obligations land on your system and which do not. We publish what the Act actually requires rather than selling a certification.

The pilot has a gate: an accuracy or outcome target agreed before it starts. If it misses, you have a written answer about why and a decision to make, not an invoice for a rollout of something that did not work.

Start

Bring us the problem nobody has cracked yet.

We are a small team of senior specialists. We pick the right model and the right layer, and we build the least machinery that does the job. You get a call with an engineer, not a sales deck.