Custom AI solutions for business: a practical guide
A buyer's guide to custom AI solutions for business: what custom means, when it beats a packaged tool, how a build runs, and what to ask a vendor.
What "custom" means, and what it does not
When an operations director asks for a custom AI solution, the picture in their head is often a model trained on the company's own data. That is rarely what gets built, and rarely what should be. Training a model is slow, expensive to repeat, and produces something that knows your business as of the day the run finished. The models from the major providers already read and write well. What they lack is access: to your ERP, your storefronts, your inbox, your approval rules, and your definition of a correct outcome.
So "custom" in practice means a system built around a model. The model is one component, rented by the call. The custom work is everything else: the connectors that read from your systems of record, the logic that decides what the model may see and do, the approval steps that put a person between a draft and an action, the logging that lets you reconstruct what happened, and the deployment that keeps it running in your infrastructure. That surrounding system is where the value and the risk both live, and the model inside it should be replaceable. A bespoke AI system tied to one model vendor has been designed backwards.
When custom pays off, and when a tool is the right answer
Custom AI development is not the default answer. If the need is general and the data is not entangled with your systems of record, an off-the-shelf tool is cheaper, faster, and better supported. Routine email, document summaries, meeting transcription: buy these.
Custom pays off under three conditions, and they usually arrive together.
The work is specific to how your business runs. A purchase planner that has to respect your supplier lead times, minimum order quantities, and warehouse rules cannot be configured into a generic product. The rules are the product.
The work touches your systems of record. If the output has to become a purchase order in the ERP, or a confirmed sales order with real inventory deducted, you need an integration written for those records and control over exactly what it may write.
The work carries consequences that need an approval path. A tool that drafts freely is fine. A tool that acts on your ledger has to act under rules you set, with a person in the loop wherever a wrong action is costly. Generic products give you their approval model; custom gives you yours.
The combination that usually wins is a hybrid: an off-the-shelf model with a custom integration and approval layer around it. We work through that decision in custom AI versus off-the-shelf AI.
The four shapes custom AI takes in operations
Almost every custom AI system in operations is one of four things, or a combination. Each has its own risk profile and cost driver, so name the shape early.
Automations on a schedule
Runs without being asked. Reads the systems, computes a result, produces a draft: a purchase proposal, an end-of-day report, a shipping batch. The arithmetic is deterministic code; a model may classify or summarize, but it never decides the numbers.
Copilots that draft for a human
The model drafts a support reply, a quote, or a supplier email with the relevant records pulled in. A person edits and sends. The value is speed and consistency; the risk is low, because every output passes through someone first.
Agents that act under approval
The system proposes an action with the before-and-after visible, a named person approves it, and ordinary code executes the write. The hard part is the approval design, not the model.
Integrations that move data between systems
The plumbing. A partner API that accepts orders into your ERP, a sync that keeps stock honest, a connector to the shipping platform. A model may not be involved at all, and this is often where most of the budget goes, because the writes are here.
The integration rule that matters most: read widely, write narrowly
In a live commerce stack the same fact exists in several places. A price is a record in the ERP, a listing on each storefront, a row in the shipping platform, and every one of those systems will accept a write. The tempting design lets the AI write wherever the change is needed. It looks correct for about a day. Then the ERP exports its own version of the price, and the business holds two truths with no way to say which is real.
The rule that prevents this: the system may read from anywhere useful, and it may write each fact to exactly one place, its system of record. Every other system gets the change downstream through connectors that already exist. The list of things the system may read can be as long as you like. The list of things it may change is the design, and it should fit on one page.
For a buyer, the payoff is that there is one place to look when something is wrong, rollback is an edit to one record, and a security review is a review of a short list of write paths. The trade-offs are in Read widely, write narrowly.
In practice. Butler, at PPC International (a Brdy Holdings portfolio company, so our own deployment rather than a client's), never writes a storefront directly. Every price and every listing goes into Odoo, and Odoo's existing Shopify connector exports it. Butler reads from the ERP, storefronts, shipping platform, and messaging workspace, and writes into one of them.
What a sound build process looks like
Four stages, each with an output you can hold. If a vendor cannot say what you receive at the end of each, there is no process.
Scope
Inventory the workflows and the systems they touch. Enumerate every write the system may make and name the system of record for each. Decide who approves what, and in which tool. Agree on how the result will be measured before anything is built; a baseline taken afterwards is not one. The output is a written scope with an explicit out-of-scope list. A vendor who will not say what is out of scope has not scoped. This is what our AI strategy and opportunity assessment service does.
Build
Working software, early and often, against a development environment that mirrors production with its own credentials. Schema changes arrive as migrations that can be applied repeatedly without harm. Tests cover the write paths first. You should see a running system early, not a deck describing one. What gets built is on the custom AI software development page.
Security review
Before the system may write to production, someone reviews it as an adversary would: every write path, every approval gate and what happens when it times out, where credentials live, whether environments are separated, what data crosses to the model provider, and whether the logs could reconstruct an incident. The output is written findings, each with a severity and a fix, then a retest. The recurring patterns are in what audits of AI systems keep finding; the service is described at AI security review.
Ship and run
Go live with approvals switched on, not off for convenience. Agree who watches the system, what the runbook says when a connector fails, and how changes are made afterwards: through migrations and deployments, never by hand-editing the database. Handover means documentation an outsider can follow, and the credentials in your hands.
What running looks like. In Butler, at PPC International (a Brdy Holdings portfolio company; our own system, not a client's), a staging stack that had retained production Slack credentials posted duplicate end-of-day drafts into real channels every day from July 7 to July 15, 2026. Nothing reached the ERP, but a message channel is still a write path, and staging holding production secrets is a deployment defect, not a model defect. More of these are in three ways an operations agent fails.
What drives cost and duration
This page quotes neither a price nor a timeline, because the honest answer depends on five things scoping establishes. A buyer who understands them can tell when a proposal has underestimated the work.
Number of systems touched
Each system is a connector with its own authentication, rate limits, data shapes, and failure modes. Five cost more than two, though reading stays cheap compared with writing.
Write actions
Every write is a path that has to be designed, tested, made safe to retry, reviewed, and logged. This is the largest driver. Two writes are a project; twenty are a program.
Approval design
Who approves, in which tool, with what in front of them, what happens on timeout, and what record is left behind. Approval screens and audit trails are real software.
Data quality
If the product master has blanks in the fields the automation depends on, such as lead time, supplier, or cost, the first weeks go to fixing data rather than building. Proposals most often miss this one.
Hosting choice
Your infrastructure or the vendor's, single-tenant or shared, a hosted model API with or without a local fallback. The choice decides who holds the keys and shapes both the deployment work and the security review.
A first automation scoped to one workflow with one or two write actions is a matter of weeks, not quarters. Adding systems and write paths turns weeks into months, and should be a deliberate choice made once the first one is running. Before scoping, the AI readiness checklist will show where the data and credential gaps are.
The security questions to ask any vendor
A vendor who has built this kind of system can answer each in a sentence.
- What can the system write, and where is that list? "It depends on the task" means the write surface has not been designed.
- Where do credentials live, and are development, staging, and production separated? Shared secrets are how a test stack acts on real data.
- What leaves our infrastructure, and to whom? Which fields go to the model provider, under what terms, and whether a local model can take over.
- What happens when a write fails halfway? The right answer is that the call fails and is retried safely. The wrong answer is a local record replayed later, because a record the system of record never saw is a second truth.
- Who approved each action, and can you show me the record? Not the screen. The record, with a name and timestamp, for an action that already happened.
- Which certifications do you hold, and which do you not? A plain list. "Aligned with" and "working toward" are not answers.
Our own answers, including the certifications we do not hold, are on the security practices page, written to be read adversarially.
How to judge whether a vendor has actually shipped
A demo proves a model can produce an answer. It does not prove a system has run inside a business long enough to have broken and been fixed. Four requests separate the two.
Ask to see the system running. The dashboard, the scheduler, the log of what it did this morning. Production has a history a prototype does not.
Ask to see the migration history. A system in use accumulates dated schema changes, each a response to something learned. A long, ordinary migration list is hard to fake.
Ask to see the approval records. Who approved what, when, and what was executed. If approvals exist only on a roadmap, the system has been acting without them or not at all.
Ask whose business it ran in. A deployment in a company the vendor owns is still real, but they should say so before you ask. Our position is exactly that: Brdy AI's one deployment is Butler, at PPC International, a Brdy Holdings portfolio company. It is listed under founding engagements, not clients, because it is not one.
How Brdy AI approaches this
We build the system around the model, not the model. Four services map onto the process above; an engagement can start at any of them.
AI strategy and assessment
A fixed-scope review of workflows, data, and systems, producing a ranked list of where custom AI pays off and the integration and risk for each.
Custom AI software development
Agents, copilots, automations, and the software around them, built in your infrastructure and handed over with documentation. We do not train foundation models or resell anyone's product.
AI automation for ERP and ecommerce
Scheduled automations and approval-gated writes for operations running Odoo, Shopify, and the systems around them, one workflow at a time.
AI security review
A review of an AI system's write paths, approvals, credentials, environment separation, and model-provider boundary, with written findings and a retest. Not a certification.
The systems we build integrate with the hosted Anthropic Claude API, with Ollama as a local fallback, so the model-provider boundary is configuration, not a rebuild. Integration is not partnership; no vendor has reviewed or endorsed this work. The full list is at AI consulting and development services.
Common questions about custom AI solutions
Does a custom AI solution mean training our own model?
Almost never. A custom AI solution for a business is usually a system built around a model rented by the call: connectors to your systems of record, rules for what the model may see and do, approval steps, logging, and a deployment in your infrastructure.
How long does a custom AI project take?
It depends on how many systems are touched, how many write actions are needed, how approvals are designed, the state of the data, and where the system is hosted. A first automation scoped to one workflow with one or two writes is a matter of weeks, not quarters.
Will our data leave our systems?
That is a design decision, not a given. The system can run in your own infrastructure as a single-tenant instance. The boundary to examine is the model provider: which fields are sent to the hosted model API, under what terms, and whether a local model can take over. Get those three answers in writing before the build starts.
What is the difference between an AI automation and an AI agent?
An automation runs on a schedule, reads the systems, computes a result with deterministic code, and produces a draft for a person to act on. An agent proposes an action, waits for a named person to approve it, and then has ordinary code execute the write. In both cases the model drafts, classifies, or summarizes; it does not perform the write.
Start with a scoping call
Tell us what you run and where the manual work is, and we will tell you whether custom is the right answer at all.