Custom AI software development for business

Who this is for

This service is for a company with a specific job in mind. The job is usually unglamorous: turn supplier emails into draft purchase orders, reconcile what three storefronts say against what the ERP says, draft the reply to a support ticket with the order history already pulled. The off-the-shelf tools either do not know your data or want to become the system of record themselves. The guide to custom AI solutions for business covers how to tell which situation you are in.

It fits best when an operations director or a CFO owns the outcome, the company trusts its system of record, and it is willing to start with one workflow rather than a platform. It fits badly when the brief is "add AI" with no workflow attached. In that case the opportunity assessment is the right first step.

What gets built

"Custom AI" almost never means a custom model. It means custom software around a model from a provider. Three shapes cover most of what operations teams need, and the software underneath all three is the same.

The software around them is what takes the time: connectors to each system, a scheduler, an approval queue, an audit log of what was read, what was proposed and who released it, migrations, tests and a dashboard for the people who run it. A model call is a few lines. The rest is the product.

How it is integrated with your systems of record

The integration rule is the one we published in Read widely, write narrowly. The software may read from every system where reading is useful. It writes to exactly one destination per fact, and that destination is the system of record. A price goes into the ERP; the storefront receives it through the ERP's own export. Nothing we build writes a storefront directly.

Within that rule, three properties are fixed. Writes are deterministic: the model may decide an order should be created, but the code that creates it has a fixed shape. Writes are idempotent where a caller might retry, so a timeout cannot become a duplicate order. Writes fail closed: if the system of record cannot be reached, the call errors rather than keeping a local copy the ERP never sees.

Before anything writes to a live record, its write paths, approvals and credentials go through the same security review we offer standalone. Staging and production are separated from day one, with their own credentials.

What you receive

What is out of scope

We do not train foundation models. The models come from a provider through an API, with a locally hosted model as a fallback where that matters. If your problem genuinely needs a model trained from scratch, we are the wrong vendor.

We do not resell someone else's SaaS. If an existing product does the job, the right advice is to buy it. What we build is the layer no product ships: the integration into your records and the approval flow around it.

We do not build unsupervised writers. A system that writes to live financial or customer records with no approval step and no audit trail is not something we will ship, however much faster it would be.

Process

Scope. One workflow. We list every system it will read, the one place it will write, who approves each action, and the baseline we will measure before anything ships so that "it worked" has a number behind it.

Build. In your infrastructure from the first commit, against a staging copy of your systems. The approval queue and the audit log are built first, because they are what make the rest safe to test.

Review. The write paths, approvals, credentials and environment separation are audited and the findings fixed before the system touches a live record.

Ship and run. Every action approved by a person at first; as the audit log shows the proposals are right, approval narrows to the exceptions. Documentation, handover and training close the engagement, and the software keeps running without us. The aim is a first system live in weeks, not quarters.

Common questions

Which model providers do you build on?

We build against a provider's API and design the software so the provider is a configuration choice rather than a dependency. Where a local model is useful as a fallback, or for data that should not leave your network, we include one. Which provider suits you is a scoping question.

Can the software run without an internet connection to a model provider?

The deterministic parts can, and that is the point of keeping them separate. The scheduler, the writes and the approval queue do not depend on a model. If the provider is unavailable, drafts stop being produced until it returns, and nothing is written in the meantime.

Can you extend software we already have rather than build new?

Often, yes. If you have an internal tool with a sensible database and API, adding an automation or a copilot to it is usually better than standing up a new service beside it. We review its write paths first, as we do with our own work.

Who maintains it after handover?

Your team can, because you have the source, tests, migrations and documentation. If you would rather we kept running it, that is a separate conversation, and never a condition of the software working.