Automation budget: how to choose a project and avoid overpaying

How to compare an off-the-shelf feature with custom development, calculate costs for a year and decide in advance when a project should be stopped.

By Artem Korsakov ·

An automation budget includes much more than the cost of the first launch. After development come subscriptions, support, employees' work, rule changes and data processing costs. When spare money is scarce, it is useful to compare projects over the same horizon and limit follow-on commitments in advance. Otherwise a small purchase turns into a service the company is forced to maintain even though the original task has changed.

In short: compare several ways of solving one task, calculate annual costs and the impact on cash flow. Release the budget in stages, each with a clear result. Before launch, write down the conditions for continuing, reducing the scope and stopping the project.

An owner and a finance director compare two budget options
Generated editorial illustration for the article topic. Not a photograph of a real project.

Compare ways of solving the problem first, then contractors

Suppose a manager wants to collect requests from branches. The solution could be configuring the existing CRM, a form with a register, a ready-made industry service or a separate portal. Comparing two proposals for custom development does not yet answer whether it is needed at all.

For each option, fix the same result: who submits a request, what checks the fields go through, who approves exceptions and where the outcome is visible. If one option includes maintenance and another only hands over the source code, their initial prices are not comparable. Separately state the limitations: number of users, availability of export, dependence on a specific vendor and the cost of changes.

Check capabilities you have already paid for. For example, 1C:ERP contains treasury and settlement functions (1C is a widely used Russian business accounting platform). If the problem can be solved by configuring an existing report, developing a second financial register may be unnecessary. The availability of a function is checked in the installed configuration specifically, taking into account permissions, data and employees' work.

Separate mandatory costs from investment ideas

Automation priorities are easier to discuss if you do not put restoring a broken data exchange and a new AI assistant into one ranking. The first returns an existing process to working order. The second tests a hypothesis about an improvement. These decisions have different grounds for allocating money.

The proposed management scheme consists of three buckets: keeping necessary work running, eliminating confirmed losses, and new capabilities. Within each, the scope, timeline, owner and alternatives are discussed. The amount in a bucket does not mean automatic approval of every initiative. It lets you avoid spending the whole resource on an attractive prototype while leaving the working data exchange without support.

A universal scoring table tends to get in the way here. If data quality is unknown, you cannot compensate for that with a high “potential benefit” score. Uncertainty must first be reduced with a cheap check of data access, sample documents or configuring a single report.

What the total cost of ownership of automation includes

The total cost of ownership of automation is calculated for a chosen period, for example a year. One-off costs include discovery, configuration, development, preparation of reference data, training and migration of the agreed history. Ongoing costs include infrastructure, licences, document recognition, model calls, monitoring, support and mandatory updates.

Add the cost of ending use: data export, handover of the field descriptions, disabling the exchange and switching to a fallback procedure. It may be small, but leaving it out of the agreements creates dependence. Show employees' internal time separately from external payments so as not to mix the need for money with the load on the team.

Microsoft's guidance on cost models suggests taking into account initial and ongoing costs, maintenance and load factors. We apply this general principle to a small business product. The document describes cloud systems and does not set market prices for development in Russia.

A hypothetical calculation of two options

All amounts below are illustrative, in Russian roubles (RUB), and are not tied to trike_dev rates or market statistics. Option A requires RUB 90,000 for launch, RUB 15,000 for data preparation and RUB 12,000 a month for the service and support. Over twelve months, external costs will be 90,000 + 15,000 + 144,000 = RUB 249,000.

Option B requires RUB 180,000 for launch, RUB 30,000 for data preparation and RUB 6,000 a month for operation. Over the same period, that comes to 180,000 + 30,000 + 72,000 = RUB 282,000. The lower monthly fee does not yet make the second option cheaper. The difference in initial costs is RUB 105,000, and the difference in ongoing costs is RUB 6,000 a month. If conditions stay unchanged, they break even after 17.5 months.

Illustrative calculation of cumulative costs for the two options over 24 months, external payments only, excluding employees' internal time. Over 12 months, A costs RUB 249,000 and B costs RUB 282,000. The costs break even after 17.5 months.

This calculation does not prove that A is better. B may have a necessary function that A lacks. Conversely, support in B may not include changes. Before using the comparison, you need to equalise the scope of work, how taxes are included in prices, load, limitations and exit terms. Internal hours and possible enhancements are added as separate lines.

Check whether the budget survives load growth

For AI, cost depends only partly on the number of employees. It may be affected by the volume of text, number of pages, repeated recognition, number of attempts and manual checks. The estimate needs a clear unit: for example, one verified document with a set size limit. The price of a single model call by itself says little about the cost of the process.

Take another illustrative scenario: 2,000 documents at RUB 4 of variable cost each give RUB 8,000 a month. If additional attempts equal 20% of the original volume and cost the same, the total becomes RUB 9,600. Employee review, storage and support are not included in these figures. If the volume doubles, the variable part in this simple model doubles too.

Set a spending limit and the behaviour once it is reached. The service can stop non-essential processing and pass the remainder to a manual queue. A simple overspend notification is not enough if processing keeps spending money uncontrollably. The technical feasibility of a limit and the billing delay are checked with the chosen provider.

How AI helps evaluate proposals

AI can be given several commercial proposals and an agreed list of requirements. The output should be a table: function, whether it is included in the price, limitation, recurring payment, source and question for the vendor. If the price of support is not stated, the assistant writes exactly that: “not stated”. It does not substitute an average market figure.

An employee checks the table against the documents and clarifies ambiguities. After that, ordinary formulas calculate the scenarios. AI is useful for extracting terms and preparing questions, but the budget decision should not be handed to a text model. It does not know the future load or your team's real readiness.

Training example: AI collects the terms of two commercial proposals into a table. A price missing from a proposal stays a gap and turns into a question for the vendor. The scenarios are calculated by ordinary formulas.

The FinOps Foundation links technology spending with business value and shared responsibility. For a small company, a simple implementation of this principle is enough: the project has a process owner, someone responsible for costs and a regular review point. There is no need to create a separate finance department for this.

Stop conditions are better written before the contract

Automation on a limited budget requires the right not to continue an unsuccessful hypothesis. Before the first payment, define what exactly must be proven at each stage. For example: data access is confirmed; the agreed set of documents has been processed and checked; employees were able to go through the full route; operating costs fit within the accepted limit.

It is worth stopping or reducing the project if a critical integration is unavailable, the data source cannot be used legally and technically, checking the result takes longer than the previous operation, or the useful volume turned out to be substantially smaller than originally assumed. The exact threshold is set by the business before the test. Money already spent does not make further investment mandatory.

On stopping, you need results you can take with you: a process description, approved rules, labelled examples and an export of records. Then even an unsuccessful test leaves clear knowledge. The phrase “we'll continue once everything works” without a deadline, a budget limit and an acceptance criterion does not protect the client.

How to allocate money across stages

The first part of the budget buys a reduction in uncertainty: checking data, limitations and several real scenarios. The next part pays for a complete route for a limited group. Scaling starts after the result and the cost of support have been confirmed. It is better not to set a percentage split without knowing the task.

A contingency reserve is shown separately from the base estimate and spent for an agreed reason. The same enhancement should not be included in a fixed estimate, the reserve and monthly support at the same time. For each payment, the basis and the result should be clear, after which the next stage can be accepted or stopped.

If you are discussing several projects, bring a list of processes, existing systems and a limit on spending for launch and for a month of operation. trike_dev will help compare options for small digital products and define a first scope for which the benefit and operating cost can be tested.

Related reading: Small business automation: which task to choose first; Automation effectiveness: how to check the result of implementation.

Частые вопросы ### Should you choose the cheapest proposal?

First compare the scope of the result, ongoing costs and limitations. A low launch price may mean no support, no data migration or no required connection. A more expensive option is not automatically justified either: the extra function must solve your task.

Can payback be estimated before implementation?

You can build several scenarios on your own volumes and measurements. Count cash inflows and freed-up time separately: the latter does not always reduce payouts. Before testing, this is an estimate that needs updating once actual data is available.