What makes a system custom rather than a configured tool?
What it knows. A general AI tool knows a great deal about the world and nothing about your firm. Every time someone uses it, they supply the context by hand: which template, which client, which past example, which rules apply. A custom system already holds that context for one process. It knows where the inputs live, what the finished output must look like, which checks your firm applies and who has to approve it.
That difference is why the same underlying AI can transform one firm's reporting and do almost nothing for another's. The model is rarely the constraint. The system around it is.
What goes into a custom AI system?
For a professional services process, usually five layers:
- Inputs: connections to the places your information already sits, such as folders, a practice or case management system, spreadsheets or an inbox.
- Knowledge: your templates, precedents, standard wording and good past examples, organised so the right one is used each time. Knowledge retrieval is sometimes the whole process.
- Rules: what varies by client, work type or value, captured once rather than remembered by individuals.
- Drafting: the AI step that turns inputs, knowledge and rules into a complete first version in your house style.
- Review and output: routing to a named person, holding for approval, and producing the finished item in your normal format with a record of its sources.
What has the team actually built?
The team has built and shipped four systems that are running now:
- A B2B sales system, built for a UK supplements brand to generate and qualify trade enquiries.
- Automated sales systems, built to drive product revenue for DTC brands.
- AI engagement systems, built to grow and sustain social media engagement.
- Process automation, built across an agency, running from ideation through content production to publishing.
They were built for supplements, DTC and agency businesses, not for law, accountancy or consultancy practices, and we do not claim otherwise. What they show is that the team designs, builds and ships systems that keep running after launch. The last of them, an agency pipeline from idea to published output, has the same shape as most professional services processes: inputs gathered, drafted to a standard, checked and released.
When is custom better than off the shelf?
Off-the-shelf software wins when your process is the same as everyone else's and the product was designed for exactly that job. Accounting ledgers and payroll are good examples. Custom wins when the value of the work lies in how your firm does it: your templates, your standards, your way of writing to clients, your review rules. Forcing that into a generic product usually means changing how you work to suit the software, or leaving the product unused. Custom build or off the shelf lays out the trade-offs in full.
Custom does not have to mean starting from nothing. Where an existing tool your firm already pays for does part of the job well, the system uses it.
How long does a custom system take to build?
Thirty days from kickoff to live, for one process. That is possible because the scope is one job, not a platform. The first week maps what the system must do, the next two build and test it on live work, and the fourth trains the team and switches it on. Thirty days of support follow. If it is not live in 30 days, the firm does not pay.
Who keeps it running?
During the 30 days after go-live, we do, fixing and adjusting as real use exposes new cases. The system is designed to run in your existing tools under your existing access controls, so it does not depend on a platform your team cannot see into. To find which process would benefit most from a custom build, start with the audit.