How to take an AI prototype to production without a six month project

On-Off Group

September 2026

Take the AI prototype to production one journey at a time. Write down the before number, cut the prototype back to the single task that worked, build it with the people who will run it, and put it live for a small group of real users before scoping anything wider.

This is for the person whose AI prototype worked and who now has to ship it. The demo went well. Someone senior said do it properly. The default answer in most banks and insurers is a six month project, a steering committee and a slide pack at the end.

There is a shorter route from AI prototype to production. Parts of it are still slow. It is mostly about cutting the scope down to one journey, writing down a before number, and building with the people who will actually run the thing.

Here is the order we work in when a prototype has to become live software.

The pilot worked, and nobody can say by how much

It usually goes like this. The prototype ran for a few weeks with a small group of users. Everyone liked it. Then the boss asks whether it worked, and the honest answer is a shrug, because nobody wrote down what the old way cost.

Without that number, the build stops being a build and turns into months of meetings. With no baseline, the business case has to be argued from opinion, so more people get invited to argue.

So before the pilot ends, go and get the before number. Turnaround time on the onboarding flow. Completion rate. Handling time per case. Number of rejected submissions in a week. Pull it from the system logs if you can, from a manual count of two weeks of cases if you cannot. Write down where it came from, so the after number can be measured the same way.

When the same number is measured before and after, there is much less to argue about.

Cut the prototype back to the one task that worked

Most prototypes do several things, and only one of them is the reason people liked it. In production, the other three carry all the risk and most of the cost.

Sit with the recordings or notes from the pilot and mark the moment users got value. Usually it is narrow. The AI drafts the reply. The AI reads the uploaded document and fills in the form. The AI flags the cases an assessor should look at first.

Ship that. Park the rest in a list and date it.

This is also where you decide what gets rebuilt. Screens, prompts and flows that people already tried can carry over. Anything touching real customer data, core systems or an audit trail usually gets built again properly. Make that call before the build starts, in writing, with the developer in the room. Deciding that halfway through the build is what adds months.

Build it with the people who will run it

A production build slows down when the people who know the rules are not in the room. Branch staff know which exceptions keep coming back, and ops knows the workaround everyone uses to get round them. Risk knows what will hold up the release.

Put them in the same room as the developer and the designer, on a regular slot, with the working software on the screen. Not a status update. A session where someone says that field is wrong and it is changed while they watch.

We build this way with client teams because it keeps decisions moving. The person who can answer is sitting there, so nothing waits in a queue.

If the team has never worked like this, one short workshop up front helps more than a process document. The UX training page at onoffgroup.com lists what it covers and which roles in a bank get the most out of it.

Ship one journey, to a small group of real users

Everyone will push for the full rollout. Hold it back until one customer journey is live and measured.

A large insurer ran a series of five-day design sprints on its customer-facing web journeys. Journeys that used to take six months or more were designed and tested with customers in two weeks, and live in four. Time to market dropped from 26 weeks to 4. Completion rates on the new journeys rose 80 percent and the old drop-off points disappeared. Those were the client's own figures.

That pace came from keeping the scope small. One customer journey, real customers on it early, and a number at both ends.

Start with a group small enough to fix by hand if something breaks. One branch, or one team of assessors. The odd cases show up early, and they are cheaper to fix at that size. A short write-up of how the sprint work runs is in our design sprint with Meralco.

Agree the data and review rules before you start

AI features in a regulated business need a few plain rules written down early, or the release stalls at the last gate.

What data can the model see. Where does it run. Who reviews the output before a customer sees it. What happens when the model is wrong, and who notices. What gets logged so an auditor can follow a case back.

Write them on one page, get the risk and data people to mark it up, and build to that page. That conversation is short at the start of the build and painful at the end of it.

Add one more rule: what would make you turn it off. If the after number does not move, say so and stop it. Better than a pilot nobody ever stops.

What to do this week

Write down the before number for the task your prototype touched, and where it came from.
Mark the one moment in the pilot where users got value, and cut the scope to that.
List what must be rebuilt for production and what carries over, with a developer in the room.
Book a weekly build session with branch or ops staff who will use the thing, with the software on screen.
Get the data, review and logging rules onto one page and have risk mark it up now.

Questions people ask

What is the first thing to do after a pilot works?
Write down the before number for the task the prototype touched, such as turnaround time or completion rate, and where it came from. Without that number, nobody can answer whether the production build worked.

How long should the first production release take?
Aim for one journey, not the whole product. In a series of five-day design sprints for a large insurer, journeys that used to take six months or more were designed, tested and live in four weeks.

Do we need to rebuild the prototype from scratch?
Usually you rebuild the parts that carry real customer data or connect to core systems, and keep the screens and prompts that people already tried. Decide that before the build starts, not halfway through.

Who should be in the room for the production build?
The people who will operate it. Branch staff, ops, risk and one developer who can change the thing the same day, so decisions get made in hours rather than in a change request queue.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with building software.