What the cost to build an AI feature really covers, and how long it takes
Most of the cost to build an AI feature is people's time, not licences. A rough working version someone can try usually takes about two weeks. Production hardening, integration and approvals take longer, and access to systems and a decision maker drive the timeline more than the code.
If you are working out the cost to build an AI feature, this page is about the shape of the work: what the money actually pays for, how long each stage takes, and what your side has to bring for it to run.
It is written for product, digital and operations teams in banks and insurers who have an idea on a slide and a boss asking when it will be live.
We cannot put a price on this page without knowing what you already have in place. Cost depends too much on what you already have. What follows is what drives it up and down.
Most of the cost is people's time, not the AI
Model usage is rarely the big number. On a small internal feature, the model usage is usually far less than what the people working on it cost for a month. The spend sits in people: someone designing the interaction, someone building it, someone testing it with real users, and the hours from your side to explain how the work is done today.
That is why two features that sound identical can cost very different amounts. An AI summary sitting on top of an exported spreadsheet is about two weeks of work. The same summary inside a claims system, pulling live policy data, with logging that audit will accept, is a different job.
This happens a lot: the budget for "AI" is approved and nobody knows if it covers connecting to the core system. Ask early which of the two builds you are buying. One question usually settles it. On day one, does this feature need to read or write data in a live system?
A rough working version first, about two weeks
The fastest way to get the cost honest is to build a rough working version of the feature and watch someone try to use it. Two weeks is a realistic shape for that: a few days agreeing the one task it handles, a week building, a few days putting it in front of people who do the work.
What comes back is a list of things the PowerPoint left out. It is the list of things the PowerPoint left out. The three input fields nobody can fill in. The customer case that breaks the prompt. The branch staff who would never open a second screen mid conversation.
Design sprints on customer-facing web journeys at a large insurer worked this way. Journeys that had previously taken six months or more were designed and tested with customers in two weeks and live in four. Completion rates on the new journeys rose 80 per cent, and the old drop-off points disappeared. The time was saved by testing with customers early, not by rushing the work.
The baseline costs almost nothing and saves the project
This is the part most pilots skip, and then nobody can say whether the pilot worked. If you cannot say what turnaround time is today, you cannot say the feature helped. A month after launch someone asks whether it worked, and the honest answer is a shrug.
Before a build starts, write down one number for the task the feature touches. Average days from application to decision. Handling time per case. Number of files a person opens to answer one question. Take it from a real sample, even 30 cases counted by hand.
It takes an afternoon. It costs nothing next to the build. And it is the only thing that makes the second phase easy to fund, because you can put the before and after side by side instead of describing a feeling. If the improvement turns out to be small, better that you found it in your own number than that your boss guessed it.
What actually slows a build down
Not the code. In practice the delays are access and decisions.
Access: sandbox credentials, sample data with the sensitive fields stripped, and someone in IT who answers a question in a day, not in two weeks. A build waiting on an access request burns the same money as a build that is moving.
Decisions: one person who can say what the feature does and what it will not do in version one. Where three departments each hold a veto, scope grows through the build and the estimate stops meaning anything.
One more thing slows builds down: legal and risk coming in late. Bring them in during week one with the rough version in front of them. Reviewing a working thing is far quicker for them than reviewing a written proposal, because the questions become specific. Which data leaves the building. What gets logged. What a customer is told. Those answers change the build, so you want them before the production work starts, not after.
What your side needs to bring
A build with an outside team works when you supply four things. One task worth fixing, chosen because it is slow or error-prone today, not because it demos well. A current number for that task. Access to a sandbox or realistic sample data. And two or three hours a week from a person who does the work, not only from the manager who owns it.
Missing the person who actually does the work is the most common failure. Features built from a manager's description of the process get the process slightly wrong, and the correction arrives after launch.
If your team has never run a build like this, the design sprint format used on the insurer work above is explained at onoffgroup.com. What a custom workshop is and how we build one with your team explains how those are put together, and the design sprint page covers the two-week format used on the insurer work above.
What to do this week
- Pick one task the AI feature would handle, and write it in a single sentence.
- Count that task by hand for 30 real cases and write down the number.
- Raise the sandbox or sample data request now, before any build is scoped.
- Name the one person who can decide what version one does not include.
- Put a 30 minute slot in with risk or legal and bring the task, not a proposal.
More on Building software
- What it means when On-Off Group builds software with your team
- Prototype or production build: which to commission next
- Software development for banks and insurers in the Philippines: how we build with your team
- How to take an AI prototype to production without a six month project
- Instead of a platform project: ship one customer journey, measure it, then widen
- Everything on Building software
Questions people ask
How long before we can put an AI feature in front of real users?
A rough working version that someone can try on a real task can usually be built in about two weeks. Putting it in front of a handful of real users needs a little longer for recruitment and consent.
What makes a build take longer than expected?
Waiting on system access, unclear data ownership, and having no single person who can decide what the feature does. The coding is rarely the slow part.
What do we need to prepare before a build starts?
One task worth fixing, a current number for how long that task takes today, sandbox access or sample data, and two or three hours a week from someone who does the work.
Does a rough version get thrown away?
Often the code does, and that is fine. What survives is a clear picture of the rules, edge cases and data the production version needs.
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.
