Custom CRM/ERP systems and LLM integrations, built around the process you already have — not the other way round.
Talk to usThe problem
The work
Orders, production, stock, costing and reporting held in one model, so the numbers a manager acts on come from the same place the work is recorded — not from a monthly reconciliation between four tools. Built around the process the company already runs rather than replacing it with a vendor's.
Extraction from documents and photographs, classification and routing, drafting inside a workflow. Each one is fenced by the schema it writes into, evaluated against your own data before anyone depends on it, and cheap enough per call to leave switched on.
For in-house software the business has outgrown but still runs on. We map what it actually does, including the behaviour nobody documented, then move it across one workflow at a time while the old system keeps serving until it has nothing left to serve.
In production
Both systems run against the same data, so there is nothing to migrate and no restore to plan. The new one gets a second address rather than the old one's: key people learn it while everyone else keeps working as before, and once they have, the old address redirects to the new one — nobody is taught a route that is about to disappear. It stays alive behind that redirect as the fallback instead of being switched off. Rolling back at any point is changing a domain, not restoring a backup. And a record both sides happen to process in the same minute does not become two: a unique key and an upsert make whichever ran second a no-op rather than a second notification.
Extraction hands over what it read — a total and a quantity — and the code does the division and the unit conversion. Nothing a model produces reaches a record without passing the same validation a person's typing does. A refused write comes back with the reason named: the unit does not convert, the name matches nothing, more than one order fits. The assistant has to say which, rather than report a success that did not happen. That is what makes it safe to leave switched on all day — the failure mode is a visible refusal, not a quiet wrong number.
Training material is matched to a person's own weak points by semantic search, sitting on top of a taxonomy that stays deterministic and auditable. The vector store carries no operating cost of its own: it runs as a scan over stored vectors with no separate search index to provision, moves to a managed index by one setting without migrating what is already there, and returns nothing rather than a guess when the embedding service is unavailable. The semantic layer only ever adds to the tagged structure underneath — nothing depends on it. What it removes is the month a new person spends working out which part of the job they are weakest at.
Distribution, reminders and the end-of-day pass are schedules rather than habits, so an enquiry nobody picked up becomes a state the system acts on instead of a gap nobody sees. And the numbers a manager reads are not a separate reporting exercise — they are the same records the work is written into, which is why nobody has to check whether they are current before a meeting. Reviewing the day becomes reading what happened rather than reconstructing it.
In practice
A recipe, a bill of materials or a job card turned into something with numbers attached: yield, waste, cost per unit, and what a job actually earns rather than what it invoices. The work that otherwise lives in a notebook next to a spreadsheet.
A photo of a handwritten document or a supplier receipt goes in; recognised line items and current prices come out as structured records the rest of the system already runs on. The model is fenced in by that structure, which is why it holds up when people use it all day.
Calculations run on the device, so a site with no signal is still a site that works, and the back office sees it as soon as there is a connection.
Released into the app stores or onto the company's own infrastructure, localised where the users are, and maintained on a release cycle rather than handed over and forgotten.
The long run
None of this is a project with a hand-off at the end. A system a company runs on is a multi-year relationship: it arrives in stages, each usable before the next begins, and then it has to be kept alive as the business changes around it.
We do the work to know the work — sitting with the operation as it runs, including the parts nobody wrote down. What comes out is a data model the next five years compound on, not a feature list.
The first release covers a single real workflow completely and goes into daily use. From then on decisions are argued against how the business actually behaves rather than against a document.
A twenty-person operation and a two-hundred-person one need different systems. We build for where the business is now with room for the next stage, instead of for an org chart it does not have yet.
Models go where they remove manual entry. The schema constrains what they are allowed to write, and they are measured against real inputs before the business is permitted to depend on the output.
Old systems come out one workflow at a time, with both running until the new one has earned the traffic. Rewrites that flip a switch are how companies lose a year.
Releases, monitoring, and the changes asked for in year two and year three — including handing parts over to an in-house team as one grows. Most custom software dies in this phase, which is why it is the part we plan for first.
Tell us what the process looks like today and where it breaks.