Custom AI development

Off-the-shelf AI serves the average company. If your edge is pricing, underwriting, scheduling, or a domain analysis nobody else runs the same way, a generic copilot will average that edge away. Custom AI development is software built around how you actually operate, with the model designed in where it earns its keep, not bolted on after the demo.

This is not a license and a hope. It is an application, a retrieval path, or a decision model in your cloud and your repos. The commercial version of that work is custom AI development. This post is when to choose it, what has to be in the first slice, and how to tell a production system from a POC that will not survive real users.

Do not start here if you cannot name the workflow. Rank it first. Do not start here if a bought tool already fits the desk. Build versus buy still applies.

Build custom when the workflow is how you make money

Buy the commodity. Build the process a competitor cannot purchase next quarter.

Custom earns its keep when:

• The workflow is specific enough that three vendors already failed to fit the desk.
• The data and the permissions are yours, and a SaaS tenant cannot express them.
• The output writes back into a system of record you already trust.
• Exit matters. If a regulator or a customer can force you to move, the logic should live in a repo you control.

Custom is the wrong spend when:

• The job is generic drafting, meeting notes, or search over a clean public corpus.
• You do not have an owner for the process.
• You have not counted hours. Run labor-hours ROI before you staff a team.
• The only artifact you want is a slide.

SaaS AI will keep getting better at the average. It will not learn your exception list unless you put that list in software you own.

A production slice is not a demo with a nicer UI

A proof of concept answers a planted question. Production software survives real tickets, real permissions, and a number you can defend. POC versus production is the same test, whether you built the demo or a vendor did.

The first slice should include:

• One workflow, one owner, one success number written before kickoff.
• The system of record and the identity model you already use.
• Eval on ugly cases, not only the happy path.
• Logging, a rollback, and a human on high-risk writes.
• Code in your repositories and a cloud account you control.

What "good" looks like on our delivery page is directional, not a contract: first working software in staging inside 30 days, you own the IP, scope and price locked after a one-week discovery. Those are targets for a slice, not a promise that every estate ships in a month. If a shop will not put the first slice in your environment, you are buying a demo host.

If you already have a promising POC, the work is usually not "more model." It is evaluation, data foundations, security, and load. That is productionizing, and it is ordinary work.

What you are actually buying

Four shapes show up over and over. Do not buy all four. Buy the one the workflow needs.

AI-native applications: a full-stack product with the model designed in. Commonly cloud-native and API-first. The UI is not a chat overlay on a system that still makes people copy-paste.

RAG and knowledge systems: retrieval over your proprietary data, with evaluation from day one. If you cannot say which document was used, you do not have a knowledge system. You have a chat.

ML and decision systems: forecasting, scoring, optimization, sitting inside tools people already open. The model is not the product. The decision in the existing screen is.

Data foundations: pipelines, warehousing, quality. If the source of record is a zip of exports, fix that before you tune a prompt. Custom AI on bad data is a faster way to be wrong.

We do not publish package prices. A one-week discovery should end with a fixed-scope, fixed-price plan, not an open-ended time-and-materials drift. If they will not lock scope, you do not have a plan.

Delivery that can be handed over

The people who scoped it should be able to write it. Senior engineers in the call, not a bait-and-switch bench. Two-week cycles with demos, evals, and usage data driving the next cut. You should be able to stop after the first slice.

Handover means:

• Repos, cloud, secrets, and runbooks you hold.
• Eval sets and the last score in the inventory.
• A choice to run it yourselves or keep a team under an SLA. Either way, no lock-in on the code.

If the only copy of the prompt lives in a vendor UI, you bought a department. Custom development that you cannot exit is just a slower SaaS.

Month-to-month or a capped statement of work. No license kickbacks, so there is no incentive to bolt on a platform you do not need.

Integration is part of the build, not a phase after

Custom AI that cannot talk to the ticket system, the CRM, or the warehouse is a side tool. People will paste around it. The first slice should write or propose a write in a system you already use, or it is still a demo.

That means identity, permissions, and audit from day one. A service account that can see every file is not "moving fast." It is a leak. The data governance rules still apply: the model does not get more access than the source.

If the differentiating workflow is a multi-step action in those systems (lookup, decide, act, confirm), you may want an agent rather than a document UI. Agents are a shape of custom software, not a separate religion. Same repos. Same eval. Same owner.

How to start without a science project

Name the workflow. Count the hours. Decide build versus buy on that one process. If you build:

• Scope in a short discovery with a price on the other side.
• Ship a thin slice in your staging environment.
• Measure the number you wrote down.
• Iterate or stop.

Do not start with a platform. Do not start with a six-month data lake. Do not start with "AI strategy." Start with the desk.

If that desk is a process no vendor will ever ship, the next step is a scoped read on whether a slice is even justified. See custom AI development.