Bespoke AI software you own and control

Building AI into software that actually ships

Most firms come to us after a demo has impressed someone internally and now has to survive real users. We are a founder-led software development company in Droitwich, Worcestershire, trading for more than 20 years with over 100 projects delivered, and every client retains 100% ownership of the code and IP. That continuity suits AI work, where assumptions need correcting early and the person who scopes the project stays involved through delivery.

This page is about engineering rather than strategy, which our AI consulting services page covers separately. The typical stack uses Node.js with Angular on the front end, AWS for hosting, and managed connections to Salesforce, Bullhorn or FreeAgent where the data already lives. For AI builds, those integrations are often the source material the model draws on.

Calling an API is not the same as a product feature

It helps to separate three levels of effort. The first is calling an existing model’s API. You send a prompt, you receive text. Our minimum engagement for AI work starts at £5,000, but that floor is for a narrow internal helper and not a full product band. A usable feature often sits in the entry band of £10,000 to £50,000, assuming a single integration and light UI. It is the fastest route, but it leaves the model in charge.

The second level is building AI features into a product. This means a user interface, saved history, credential management, and an evaluation step to check the answers. Costs here commonly fall in the £50,000 to £150,000 middle range, and that mid band usually involves multiple data sources and a managed release cycle. The third level is training or heavily customising a model on private data, which belongs in the £150,000 to £1,000,000 plus top tier and includes ongoing training pipelines. UK agency rates for this kind of specialist build run from £75 to £150 per hour.

Where the real work sits: data, retrieval and permissions

The model is a small component. The lasting value sits in the plumbing. That includes secure data access, retrieval from the correct sources, strict permissions, and a repeatable evaluation routine. A common pattern is a business that needs answers drawn from records in Salesforce or recruitment data in Bullhorn. The task is to index that content, honour row level permissions, and pass only the permitted slice to the model.

FreeAgent integration can supply finance context where needed. Without this groundwork, the model fills gaps with guesswork. With it, the system becomes dependable. Because clients own 100% of the code, they can audit every connection and prove where information came from. We often spend more time on the retrieval layer than on the model call itself. A well structured index, clear permission mapping and a logging trail make the difference between a toy and a tool. The evaluation routine then scores answers against known facts, so drift is caught early. This is the part of the project that takes the most care, and it is where most of the budget is rightly spent.

Testing systems that do not give the same answer twice

Traditional software gives the same output for the same input. AI features do not. The same question can return a different phrasing on each call. Testing therefore moves from fixed assertions to evaluation sets and scoring. We build a fixed list of prompts with expected properties, then grade the responses for accuracy, tone and safety.

A human reviews a sample, and we track changes over time to catch regression. This is slower than unit testing but necessary. In payroll, where we built Octopaye, the deterministic logic has to be exact and provably so. Anything probabilistic layered onto a system like that needs the same standard of evidence before it goes anywhere near a live calculation. Our engineering team uses Node.js scripts to run these batches and record results. Because the system is non deterministic, we run each prompt several times and measure consistency. A drop in score alerts us before users notice.

Knowing when to keep a human in the loop

Where a wrong answer is expensive, a person should stay in the loop. Legal and financial contexts are the clearest cases. We built a legal AI chatbot for rradar, called Grace, where the cost of a wrong answer means a human must remain part of the process. The case study sits at Grace.

This stance differs from full automation. In a healthcare staffing back office for Infinitemp, or a health and safety platform like Saeker, the cost of error justifies review points. Our job is to place those checkpoints where they matter. If you need help judging readiness, our AI consulting services covers that question.

A worked example from our own build history

Grace shows what a production AI build involves. The chatbot needed to answer from a defined set of legal material, so the retrieval layer indexed only authorised sources and enforced strict permissions on what the model could see. The evaluation stage scored responses against those sources before anything reached a user.

That discipline, not the model call, is what makes an AI feature safe to ship. For legal contexts especially, a human review step remains part of the design. If you are planning a project, our cost estimator gives a grounded range.