What we do

AI adoption, and architecture. Two services, the same two practicing software architects. We advise your team on the decisions behind its work, starting with one bounded question.

How it starts

Together, we agree the question, the scope, and the written output before the work starts. At the end, you have findings and our recommended next step. You decide whether to continue, change the shape, or stop - with no obligation to a next stage.

Most of our work is one engagement with both of us on it. Whoever is closer to the problem leads; the other one pressure-tests.

How we work together →
One bounded piece of work - question, scope, and written output agreed - leads to findings and a recommended next step, then a decision point: continue, change shape, or stop
One bounded piece of work - question, scope, and written output agreed - leads to findings and a recommended next step, then a decision point: continue, change shape, or stop

The first step, three shapes

An architecture decision that needs resolving

A re-platform, a split, or an integration. We compare the options with your team and test the assumptions behind them.

You get: a written decision record with the options, what each one costs and forecloses, our recommendation and the reasoning behind it, and the questions still open. The decision stays yours.

An architecture review

We agree upfront which parts of the system and which questions to review - usually two or three areas where decisions are still open. We examine the evidence within that scope and agree any change to it with you.

You get: written findings, the evidence behind them, and prioritized recommendations - including what to leave alone or stop pursuing.

Where your AI rollout stands, and what comes next

We use The Harness Model to assess your team's use of AI coding agents, using examples the team brings and a working session together. Repository access is not required. Direct reading of repositories and pipelines is optional depth, on your access terms, to sharpen the evidence.

You get: a written assessment showing the evidence, gaps, and recommended next step - including what it changes for the people doing the work and for what they hand to an agent.

Two services

AI Adoption

A work harness your engineers write, run, and maintain.

AI coding agents come with an agent harness - the prompts, orchestration, and guardrails your model vendor ships. The work harness is the conventions, linters, and tests your team builds on top, specific to your codebase and your definition of done.

We work through it with your engineers in working sessions, read their code, and review the result. The architectural boundaries and verification needed for that work are part of the advice.

Read The Harness Model →
Diagnose, Enable, Blueprint: assess where the team sits on The Harness Model, run working sessions building conventions, linters, and tests into the team's own repository, then deliver a written model of the harness the team now owns
Diagnose, Enable, Blueprint: assess where the team sits on The Harness Model, run working sessions building conventions, linters, and tests into the team's own repository, then deliver a written model of the harness the team now owns
Architecture

The architecture judgment that decides what's worth building.

We do architecture decisions and scoped reviews, SDLC and delivery-process design, and team and role structure - the same craft we have practiced for 15+ years each, on distributed systems, services architectures, and platform teams.

We compare options, identify what each one costs and forecloses, and give you our recommendation with the reasoning intact. We read the relevant code and documentation with your team and review the result within the agreed scope. The decision stays yours, with a record the people building and operating the system can revisit.

Read how we use architecture decision records →
Compare, Decide, Record: lay out the options with the team and test the assumptions each one rests on, give the recommendation, its reasoning and what each option costs and forecloses, then deliver a written decision record the team can revisit
Compare, Decide, Record: lay out the options with the team and test the assumptions each one rests on, give the recommendation, its reasoning and what each option costs and forecloses, then deliver a written decision record the team can revisit

When an engagement includes practical coding exercises led by us, we agree and deliver that work as training or a workshop under a separate agreement, not as implementation delivery.

Who this is for

Small, task-based engagements where the decisions are still open and the team has the autonomy to act on them. It's not company size that matters, it's how the work is run.

The work needs your people in it: someone who can decide, rather than only report upward, and the engineers who will live with the result. They bring the product and domain knowledge that makes the findings useful.

What we don't do

  • No full-time roles, no slow-moving, low-autonomy work.
  • No staff augmentation. We don't join your team as extra hands; we work with your team on a bounded question.
  • No product or domain decisions. Those stay with you.
  • No tool reselling. We don't sell licenses, and nobody pays us to recommend one.

Get in touch

Tell us what you're deciding - an architecture call, a review, a delivery-process or AI-adoption question - and we'll tell you plainly whether we're the right fit.

Get in touch →