Almost anyone can build software today. We deliver it production-stable.

What we offer, we do ourselves. There is no layer between you and the people building it — and nobody who sells and then hands it on.

Build

We build software with agents and own the result the way we would own hand-written code. Often it isn’t a greenfield build but an increment to a system that already exists and has to keep running. And when an agent gets stuck on the last ten per cent, we finish that part instead of handing it back.

What we work with
TypeScript, Python, Java, C#. Web and mobile. Azure, GitLab, GitHub Actions, Cloudflare. Claude Code day to day, in client projects since 2025.
When to bring us in
When something has to be built and you don’t want to spend half the time afterwards working out whether it really runs — or reading it back in an endless stream of bug tickets.
What you end up with
Working code in your repository, with tests that were agreed before the building started — and without a tool you have to licence afterwards.

Automate

Automating operations, connecting systems, building data flows — and agents that take over part of the process themselves. Not as a demo, but as something that runs in the morning while nobody is watching.

What we work with
Process and system automation, interfaces between systems never meant to have one, CI/CD and release pipelines, operations and monitoring.
When to bring us in
When somebody clicks through the same screens before every release — or two people retype data from one system into another and nobody notices when something gets lost on the way.
What you end up with
A process that runs without being asked, and an alert when it doesn’t. The hours it costs today stop costing anything — and your own team can change it, the documentation comes with it.

Test management

The work we come from. Setting up test processes, building a test team, making approvals hold — often in companies where nobody had tested before, and inside approval processes a regulator prescribes.

What we work with
Jira and Xray, Azure Test Plans, TestRail, HP ALM. Test strategies, test phases and acceptance processes. Training for departments that have never tested anything.
When to bring us in
When a release is up for sign-off and the honest answer to “has this been tested enough?” is a shrug.
What you end up with
A test strategy that makes it through your approval, a test team that carries on without us, and a tooling setup that fits your organisation rather than ours.

Verify

The part most people skip: quality assurance for AI features. An agent that writes code also writes the tests for it — and inherits the same blind spots doing so. Green tests are therefore not evidence. We build the counter-check an agent cannot write for itself.

What we work with
Evaluation and metrics for AI features, guardrails, regression gates in CI, test automation at every level, acceptance criteria written out before anything is built.
When to bring us in
When the demo convinced everyone and nobody knows what happens across ten thousand real cases.
What you end up with
A shared understanding of what is good enough and when something may ship — and the automation that checks exactly that on every run instead of commenting on it.

From a requirement to a QA pipeline

Almost every requirement starts as a sentence that cannot be checked. It is meant well — only nobody can say when it is met. That is exactly where we start: the sentence becomes a step in your CI/CD pipeline that checks on every run, repairs itself where it can, and grows with every new case.

  1. “Orders should go through the shop reliably.”

    What cannot be checked about it
    “Reliably” has no threshold, and there is no such thing as “the order”: guest checkout, voucher, partial cancellation, three payment methods, delivery abroad. Three people in the room mean three different journeys — and nobody notices, because everybody nods.
    What it gets measured against, automatically
    The order journeys that actually occur in your shop, each with the expected end state in shop, ERP and warehouse. If one of them fails, the deploy stops — and the case lands in the board that same moment: which journey, which step, which data, with log and recording attached, assigned to the team that owns the step. Nobody has to reproduce it first, and nobody finds out on Monday through a customer.

  2. “The agent should only do what it is allowed to do.”

    What cannot be checked about it
    A prohibition without a list is an intention. On top of that: the agent writing the code also writes its test — and inherits the very assumption the fault came from. Green then only means the same thought happened twice.
    What it gets measured against, automatically
    The forbidden cases are written by a person, not by the agent. They run against the real permission layer, not against a stand-in. When one slips through, it becomes a case — before the fix, not after it.

  3. “After the rebuild everything has to work like before.”

    What cannot be checked about it
    “Like before” is written down nowhere. Without a recording of the starting state, sign-off is an act of memory — and memory loses against a release date.
    What it gets measured against, automatically
    Before the first change we record the old state: responses, timings, page images. From then on the suite compares against that recording rather than against an opinion. Whoever changes it sees in the diff what they are changing.

We are not allowed to show our clients’ criteria. The form is the same: the sentence comes from you, the gate is written before the build — not afterwards, where it gets written around whatever happened to get finished.

How we work

A defined scope and a defined result.

We say up front how you will know it is finished. That is not a courtesy, that is the craft.

Remote, with a fixed overlap.

We have worked as a distributed team for years — with fixed hours when we are reachable, and inside the tools your team already follows.

Bookable together or separately.

Whether one of us works on it or both: you have one contact who knows the project — and nobody who transfers your call.

Regulated environments are not a special case.

We have worked inside a federal development bank under BAIT, MaRisk and DORA, and in defence. If there is an approval process attached to your work, that is our normal.

What that looked like under banking supervision

Reinforcement — or someone to take the whole thing?

One of us inside your team — or the two of us as a unit that takes a project from build to sign-off.

Get in touch