How we scope and price an AI project

Start with what you need

On the first call, we talk through the task, how your team handles it today, and what you want to improve. Examples of the work help us understand the scope: a report you produce, a set of support questions, or the documents someone reviews each week.

If the requirements are clear enough, we can scope the build. If there are important gaps, we may recommend an audit first. The audit should have an agreed scope, fee, and deliverables, so you know what you are buying at that stage.

What affects the price

Two projects described as an AI assistant can involve very different amounts of work. An assistant that searches a small set of documents is a different build from one that also updates customer records, manages permissions, and asks for approval before taking an action.

• Scope: the tasks the system must complete and the exceptions it must handle.
• Data: where the information lives, how consistent it is, and what preparation it needs.
• Integrations: which systems it connects to and what access they provide.
• Testing: how we check the results and what your team needs before using it.
• Operation: monitoring, support, and the changes needed after launch.

What the proposal includes

The proposal describes what we will deliver, what is outside the scope, the timeline, the fee, and the payment schedule. It also sets out what we need from your team, such as access to a system or someone to review sample outputs.

We agree on how you will assess the finished work. For a document tool, for example, that could include which fields it must extract, how it flags uncertain results, and where a person reviews the draft. If the scope changes, we agree on the effect on price and timing before doing the extra work.

Budget for running the system

The build fee is one part of the cost. Depending on the project, there may also be charges for AI models, hosting, data providers, or other software. We estimate those costs using the expected volume and explain which assumptions could change the bill.

Ongoing support is scoped separately. We agree on monitoring, maintenance, how problems are reported, and what counts as an additional feature. If your team plans to operate the system, documentation and training should be part of the build scope.

To track costs after launch, measure cost per accepted task, including retries and human review.

Check that the benefit justifies the cost

We compare the proposed cost with the improvement you expect. That might be time saved, faster response times, fewer corrections, or more research completed. Use your own operating figures where they are available, and label estimates where they are not.

Time saved does not automatically become a reduction in payroll. Consider how the team would use that time, how much review the system still needs, and the cost of keeping it running. A smaller first project can be useful when those benefits are still uncertain.

If the expected benefit or feasibility is unclear, first evaluate the proposed AI project.

Questions to settle before starting

• What exactly will be delivered, and how will we decide it is ready?
• Which access and decisions do you need from our team?
• What is included in the fee, and which costs are separate?
• Who owns the code and accounts, and what licenses apply?
• Who supports the system after launch, and how do we report a problem?