Product engineering
The interfaces people actually use.
Internal tools that replace spreadsheets, review screens where staff check what a system proposes, and consoles where someone can see what happened and stop it. Built properly, accessible, and yours to run.
Why this matters now
It has never been faster to produce an interface, and the quality of what is being produced is going backwards. Code generated quickly ships with security flaws nobody reviewed and accessibility failures nobody tested. The tool works in the demo. It is not ready for the people who will depend on it.
What we build
Interfaces for the people running the system
Internal tools & operational web apps
Custom web apps that replace spreadsheets and patched-together SaaS for core operations. Proper sign-in, role-based access, an audit trail and tests, connected to your real systems of record. Built in React and Next.js, in repositories you own.
Where it applies: a back-office order management tool replacing a shared spreadsheet · a portal for field teams to submit and track jobs · a client portal showing the status of processed documents.
Human-in-the-loop review dashboards
Where staff review what the AI extracted or proposes to do. The source document sits beside the extracted fields, with low-confidence values highlighted. Reviewers approve, reject or correct, one at a time or in bulk. Every decision is logged and fed back into the evaluation set, so the system improves.
Where it applies: an accounts payable clerk approving extracted invoices before they post · operations approving refunds an agent has proposed · compliance reviewing flagged transactions.
Operator & oversight consoles
A control room for agents and automations running in production. A readable timeline of what the system did and why, an exceptions queue, and the controls to override, reverse or stop it. Every intervention recorded with its reason.
Where it applies: a team lead supervising several agents working a support queue · a risk team needing a stop button and audit trail for an automated decision system.
Interfaces for your customers and your prototypes
AI product interfaces
Customer-facing interfaces for AI features — assistants that stream answers and show their sources, and screens assembled from your approved components. Clear disclosure that people are dealing with AI, and labels on generated content.
Where it applies: a SaaS product adding an AI assistant for its customers · a bank or insurer adding AI-drafted answers to its customer portal.
Apps inside AI assistants
Interactive tools that run inside Claude, ChatGPT and VS Code, and inside Slack and Teams through their card formats. One server reaches several assistants. Dangerous operations are hidden from the model and can only be triggered by a person.
Where it applies: staff approving purchase orders from inside the assistant they already use · a SaaS company putting its product inside the assistants its customers use.
Prototype to production
For an app built with AI coding tools that has found real users. We harden sign-in and data access, remove exposed secrets, add tests, delivery pipelines, monitoring and accessibility, and move it onto infrastructure you own. We take on the whole app, not single bug fixes.
Where it applies: a startup's AI-built MVP preparing for an enterprise customer's security review · a business-built internal tool that IT must now take over.
Accessibility remediation
For web and mobile services in scope of the European Accessibility Act, UK accessibility regulations or US ADA Title II. We fix the design system and shared components first, then the user journeys, then retest with assistive technology. We implement requirements; we do not certify conformance.
Where it applies: an online shop or bank app that must meet the Accessibility Act · a government supplier facing ADA Title II deadlines.
What comes with it
- Role-based access and an audit trail in every tool that touches real data
- Tests, including the flows people actually use
- Accessibility built in — keyboard, screen reader, contrast and reduced motion — not retrofitted
- Code in repositories you own, on a stack your own team can hire for
- A readable record of every decision a reviewer or operator makes
Built secure and evidenced, as standard
Built for the people who will depend on it.
- Security and compliance are not a separate service we sell. They are how the work is built, on every engagement.
- For interfaces, that means three things in particular. Access is enforced on the server, never only in the interface — a hidden button is not a permission. Code generated with AI tools is held to the same review, scanning and testing as code written by hand, because it fails security tests at a rate nobody should ship unreviewed. And every screen is built to be usable by everyone who has to use it, which is also increasingly what the law requires.
- Everything we build in this area is delivered against our published engineering standard, and ships with the evidence to prove it: a security review record, test results, and signed build provenance.
How the work runs
- 01
Scoping — who uses it, what data it touches, what it may change.
- 02
Design — architecture, threat model and key screens, written down.
- 03
Build — against the published standard, every merge reviewed.
- 04
Handover — in repositories you own, with documentation and a runbook.
Typical duration: 3 to 12 weeks. A single review dashboard sits at the short end; a full internal platform or an accessibility remediation across a large estate at the long end.
How we workWhat we will tell you
When an app built with AI tools reaches us, we tell you whether to harden it, rebuild it, or stop — and where hardening would cost more than starting again, we say so and rebuild. Patching a foundation that will not hold is the most expensive option, even when it looks like the cheapest.
Tell us what you’re building.
Describe the problem in your own words. We will tell you honestly whether we are the right people for it.