AI Delivery Is the New Competitive Advantage: Getting AI Into Production

Most companies have an AI plan by now. Far fewer have AI running in the business every day. The plan is the easy bit. Getting something into production and keeping it there is where projects stall.

At Revitt we build AI systems for businesses with a lot of operations work, and we have watched this happen more than once. The firms that get value out of AI treat it as an engineering job with a deadline. The ones that treat it as a strategy exercise tend to end up with a good slide deck.

The demo trap

A demo is cheap. You can put a chatbot together in an afternoon, or show a model summarising documents in a meeting, and people get excited. None of that is production software.

Production is everything the demo skipped. The odd cases the sample data didn't include. Real load on real data. Finding out something has gone wrong before a customer tells you. Security your legal team will sign off. And the old systems your business actually runs on, which never connect as neatly as the demo suggested.

The gap between "look what it can do" and "this runs our invoicing every night without anyone touching it" is where most AI projects die. The model usually works fine. The job was never finished.

Buying an off-the-shelf AI product

The reflex is to buy something. Pay the subscription and tick the box. For common problems that's fine. For anything close to how you make money, it tends to go wrong in two ways.

First, your workflow sits in someone else's backlog. The vendor builds for its whole customer base, so the feature you need waits behind requests from bigger accounts. "Connects to everything" usually means it connects to everything badly, because your data formats and odd cases are yours.

Second, you learn nothing. When things move, and in AI they move monthly, you start again from scratch.

Building everything yourself is overkill too. What works is a small team that knows AI and production systems, fits something to how you run and hands you the code at the end.

Where AI projects go wrong

Starting too big

A company decides AI will overhaul a whole department. It scopes six months, hires a data team and spends three of those months on data plumbing before anyone builds something a user can touch. By month four the business has moved on and finance is asking questions.

Start with one workflow instead. Pick the most repetitive, most annoying job in the operation. Build a small version that is safe to run for real, put it live, learn from it, then widen it.

Research that never ships

Research has its place. Research with no deployment date is a hobby. We have seen teams spend months comparing models and writing reports when they could have had something in front of users.

We lean towards shipping. We pick an approach that is good enough to put live, measure it closely and improve it with real data. A model you ship today and improve next week will beat a perfect one that arrives in six months.

Skipping the last mile

The last mile is everything between a model that works and a system that works. Error handling. Retries. What happens when the model isn't sure. Screens that show people the AI's output without burying them. Monitoring that notices when results start to drift.

None of it is glamorous and none of it makes a good conference talk. Most of the value is in it.

How we do it

Small and quick

Halo Traffic went live with its own fleet control system under five months after our first proposal, with a first release in four weeks. There was no clever strategy behind that. We cut scope hard, built it properly from the first day and got it in front of the people using it as fast as we could.

We run client work the same way. Tight scope, quick builds, then changes based on how people actually use it.

Quick doesn't mean sloppy

Everything we ship has structured logging so you can see what it is doing. Errors stop the job instead of quietly corrupting data. There are automated tests at the integration level, and the infrastructure won't need a rewrite when usage grows.

We use Go, TypeScript, React and PostgreSQL because they are proven and we know them well. We deploy with Docker and set up CI/CD in the first week. That is the least you need for a system the business is going to rely on.

AI in a few places, ordinary engineering everywhere else

Most problems don't need AI. With a client, we find the specific points where it earns its place, usually summarising, sorting, predicting or drafting, and put it there. The rest is plain, well-tested code.

That keeps things maintainable. When a better model comes out, you swap the model and the rest carries on. When a business rule changes, you change the rule. The AI parts sit in their own boxes.

If you're starting AI delivery yourself

1. Start with a job

Don't start with "we should use GPT-4" or "we need a vector database". Start with "our accounts team spends 12 hours a week matching invoices to purchase orders". Pick the tool after that.

2. Decide what done looks like first

Which number will change? Fewer errors, faster turnaround, more orders handled per person? If you can't say, you won't be able to tell whether it worked.

3. Build it properly from the first line

"We'll productionise the prototype later" almost never happens, or it takes three times as long as doing it right first time. Use real infrastructure, a real environment, tests and monitoring from the start.

4. Measure everything

AI behaves differently once real people use it. Inputs change and results drift. Log inputs, outputs, confidence scores, response times and errors. Put them on a dashboard with alerts, or you won't know when it starts going wrong.

5. Keep a person in the loop

Most AI systems work best with someone checking, at least at first. Design it so a person can review, override and correct the output. That is how the business learns to trust it, and how mistakes get caught before they pile up.

6. Own what you build

Whether you build in-house or with a firm like ours, make sure you own the code, the infrastructure and the know-how. Lock-in is worse with AI because things change so fast. What works today may be out of date in a year, and if you own it you can change it.

Where this leaves you

Most businesses are still talking about AI, running pilots and comparing vendors. The ones getting real systems running in their operations now are building a lead that will be hard to close.

Our own record is the evidence we have. Halo Traffic went live under five months after our first proposal. We helped Everything Boxed keep a key customer by delivering compliant digital ordering before the deadline. We automated Miranda's invoicing and it kept its contract. In each case the AI mattered less than getting the thing built and live on time.

If you have the engineers to do this in-house, do it. Start small and measure everything.

If you'd rather have a team that has done it before, this is what we do. Get in touch and we can talk through where it would pay in your business.