# Strategy, design & AI systems, on engineering that holds.#

First-principles thinking in design and software engineering is needed more now, not less. Sixteen years of building products grounds the AI hype in pragmatism. AI does the acceleration; people drive the judgement.

## Agentic systems for your team, your customers, *and the teams that build on you.*#

### Internal agents Agents your own team works with — in chat, in admin tools, and inside the systems that already hold your process.#

### Customer-facing agents Agents that act inside your product, where the person on the other end is your customer and a wrong answer is public.#

### Developer platform agents Agents and primitives other teams build on — exposed as tools, servers and packaged procedure rather than a product surface.#

Explore the frameworks, system layers and production practices behind our Agentic AI work.

### Start on a working foundation. *Move to yours when the product is proven.*#

We bring the production-tested, multi-tenant foundation behind our own products, so the MVP effort goes into your agent, your workflows and the experience around them — not rebuilding the same platform plumbing.

Designed for transition from day one: agent logic, typed tool contracts, schemas, evaluation sets and product interfaces travel with the product.

## Readiness, training, *and a way of working that survives the handover.*#

### Advisory & Readiness#

Where AI actually fits in how your organisation works today, and what has to change before it holds.

### Workshops & Training#

Sessions that leave your team with a decision they can defend, and the working language to keep making them.

### Installation & Maintenance#

The way of working installed in the systems and agent environments your team already uses, and kept running after we hand it over.

## The product your customers see and the one your team lives in, *built from the same foundations.*#

### Customer-facing products The app your users log into, where the state is complicated, the permissions matter, and somebody downstream depends on the screen being right.#

### Internal tools & admin The console your team runs the product from — review queues, support views, and the operations nobody outside ever sees.#

### Design systems & foundations The shared layer both sides are built from, so a change lands once rather than in every screen that copied it.#

See how we hold accessibility, performance, design systems and browser behaviour through production.

## This layer should be invisible. *Keeping it that way is the work.*#

### APIs & data models The contract everything else depends on — versioned, documented, and hard to use wrongly. We have run our own multi-vertical SaaS platform since 2018, so this is a layer we maintain rather than just ship.#

### Pipelines & integrations The work that happens after the request returns — jobs, events, and the third-party systems you do not control.#

### Security, DevOps & operations Correctness, auditability and recovery are the product here rather than the plumbing — through how it ships and how it runs. We build for the on-call rotation, not the demo.#

Inspect the contracts, data boundaries, deployment paths and operational evidence behind the invisible layer.

## Native where it matters, *cross-platform where it doesn’t.*#

### Apps & interfaces A personal device, used on the move — which changes what the app has to survive, and how it is built. Sharing its design system with the web product rather than forking from it.#

### Device & platform capabilities What a phone can do that a browser cannot, and the states an app has to survive — offline, backgrounded and interrupted.#

### Release & quality Getting it into the stores and keeping it healthy there, where a bad build is not a rollback but a review queue.#

Explore the native, cross-platform, device and release decisions that keep an app healthy after launch.

## Deciding what to build, *by building enough to find out.*#

### Research & strategy Understanding the people who use the product and the decisions the business has to make, before anything gets built. Usually the first engagement, and the reason the ones after it are shorter.#

### Design & prototyping Making the decision concrete enough to test — prototypes built to answer a question rather than decorate one.#

See how research, prototypes and delivery evidence turn an uncertain decision into a product that can be judged.

## Join at any stage.#

Some engagements start with a discovery question and run through to an operating system. Others start with a system that already exists and a decision inside it that has to become dependable.

AI accelerates our process, but it does not replace judgment. We use it to explore, simulate, document and test — the team stays accountable for the decisions.