Stack 03 · Product Engineering
An AI feature is still a product feature. Somebody has to sign in, find it, trust what it says and do something with the answer. This is the stack we build that part on — the same one behind ExamsDojo, which is the honest test of whether we would choose it again.
How we choose
The exciting part of an AI product should be the AI. Everything around it benefits from being deeply unsurprising.
We make conservative choices in the application layer on purpose. A framework with a decade of answers behind it, a type system that catches the mistake before review, a design system that stops every new screen being a fresh negotiation. The novelty budget gets spent on the model and the retrieval, where it earns something.
The other reason is handover. Most of what we build eventually belongs to a client's own team, and a stack they can hire for is worth more than a clever one they cannot. If you can staff it, you can keep it — and that is the difference between a project and a product.
Non-negotiables
The toolchain
Each row says what we actually use the tool for and links to the products, services and industries where it is already doing that job — so you can follow it through rather than take our word for it.
The language the AI and data work lives in, and increasingly the API layer around it too. One runtime for the model code, the pipeline code and the service that serves them.
Used across web, mobile web and Node services with the API types generated from one schema, so a breaking change surfaces in CI rather than in a user's browser.
Our default for anything stateful and interactive — review queues, scoring dashboards, exception consoles. Large ecosystem, easy to hire for, predictable to hand over.
Routing, rendering strategy and performance handled by the framework rather than by us. Server rendering where SEO or first paint matters, client rendering where interaction does.
Where an API sits in front of model calls and third-party systems, Node keeps the language boundary at one — the same types, the same validation, the same tooling as the client.
A substantial amount of the world's working software is PHP, and rewriting it is rarely the right call. Laravel is how we extend, API-enable and modernise those estates instead.
One codebase for iOS and Android where the app is the product rather than a companion. Used where a native-per-platform build would double the surface we have to maintain.
Tokens, components and documented states, with keyboard paths, focus management and reduced-motion handled once in the component layer rather than per screen.
Built on this stack
The useful question about a technology list is not what is on it but what has been shipped with it. These are the products and accelerators this stack carries today.
Two products on one engine — a learner app and an institute dashboard — built on exactly this stack, with the multi-tenancy and role model in place from the first release.
A caseworker console built to WCAG 2.2 AA, where every AI suggestion is reviewable, every draft is approved before it leaves, and the whole interaction is retained for audit.
Built to live inside the CRM agents already use rather than adding another screen — with a mobile path for the half of the job that happens away from a desk.
Note Products we run ourselves accelerators are production-grade starting points configured to your data and rules See the measured outcomes
Request a quote
Talk to an engineer about your architecture, or get a quote for the work.
In the field
Three sectors where this particular layer carries the most weight. Each page shows the five-step automation pattern in that sector's own vocabulary.
The sector where we run our own product and can show the numbers.
Explore Industry 09Enquiries qualified on arrival and transactions chased to completion.
Explore Industry 06Permit assessment and case work with a decision record built for appeal.
ExploreAlso All ten industries run on some combination of these four stacks
Connected
No system we build uses only one of these four layers. Here is the service line that leads the work, and the stacks that sit either side of this one.
Services that use this stack
Monoliths re-platformed into cloud-native services, business rules extracted with AI assistance, APIs published.
Explore Service 01Retrieval grounded in your own records, evaluation harnesses and the guardrails that keep answers on-policy.
Explore Service 07Process discovery, then bots and API workflows that reconcile, key in and chase — AI handling the judgement calls.
ExploreThe other stacks
Questions
Asked most often by founders and product teams.
Yes. We build web applications, internal tools and integration layers, and add AI features where they genuinely help the user.
Often, yes. We start with a review of the code, tests and deployment, then agree what to keep, stabilise or replace.
By agreeing the smallest version that proves the idea with real users, then expanding once it is working. Request a quote to start the conversation.
Ownership is set out in the statement of work and in our Terms & Conditions.
Request a quote
Tell us who has to use it and what they need to do with the answer. That conversation usually reshapes the model work more than the model work reshapes it.
