6 questions to ask before you invest in AI

Everyone is being asked to do something with AI right now. The harder question is where it actually earns the spend, because AI costs scale with usage in a way traditional software costs do not. These are the six questions we work through with clients at Very Technology before any model or architecture decision gets made.

1. What business goal is this supposed to move?

Start here rather than with the technology. What are you trying to achieve, and which number would change if this worked?

It sounds obvious written down, and it is the step skipped most often, because the pressure to add AI usually arrives as a mandate rather than as a problem. A feature with no business goal attached has no way to prove it was worth building.

2. Will this return the investment, or is it just interesting?

We will not build technology just because it is cutting edge if it is not going to return that investment for your business.

That is a commercial test rather than a technical one, and applying it early is what keeps a roadmap from filling up with capabilities that demo well and cost more than they return. A feature can be genuinely impressive and still be the wrong thing to fund this year.

3. What does it cost to run once everyone is using it?

This is the question that catches teams out. Model costs scale with how often a feature is called, so something inexpensive while a handful of people test it can become a real line item once it is in every customer’s hands.

Model the cost at realistic production volume before you commit, not after. The gap between the two numbers is often large enough to change the design.

4. Where does AI genuinely belong?

In practice this is usually a short list. The places where AI meaningfully changes the work or the operating economics are easier to defend, easier to measure, and easier to afford than a broad deployment.

The goal is AI where it makes sense for your business and no AI where it does not. Starting narrow also leaves room to expand once the first use case has shown what it returns.

5. What does the budget allow, and what does that rule out?

Requirements and budget belong in the design conversation as real constraints, not as problems discovered partway through the build.

A scope shaped against the actual limits from the start tends to hold. One shaped against ambition and then cut back to fit usually loses the wrong things, because by then the decisions have already been made.

6. How will we know whether it worked?

Decide the measure before you build, and capture the baseline while you still can. Time spent on the task, error and exception rates, and the quality of the output are the three that usually matter.

Measuring on real data during the build rather than estimating afterward is what turns a value case into evidence. That evidence is what makes the next investment an easier conversation, which matters more than it sounds: proving the value once changes what you can fund after it.

How we scope this at Very

This is where our AI and machine learning work starts. Before any model or architecture decision, we work out what the business needs the system to do, what a result is worth, and what budget it has to live inside.

From there we build the AI into the product itself, whether that is predictive maintenance, anomaly detection, computer vision, or an LLM-powered interface, and we run it where the product needs it to run rather than where it is easiest to deploy.

If you are deciding where AI belongs in your business and what it will return, we can help you scope it against your goals and your budget. See how we approach AI and machine learning, or start a conversation.