What AI should I buy?

When a new technology becomes accessible to everyone all at once, it can become quite overwhelming to know how you should use it. This article dives into what type of AI you should buy, from products to services to hiring engineers. We cover it all.

Everyone feels the impact of large language models (what we’re calling AI in the modern day), and each company is at a different stage of maturity and ability. Everyone has the same access to the technology, but not the same opportunity to use it. Regulation and IT teams get in the way for some companies and not for others.

So companies sit at different stages of the buying process, and the question is the same for all of them. What should I actually do with AI? Is a ChatGPT or Claude subscription enough? Or should I go further?

This guide is a simple way of thinking about that question.

What should I buy in AI?

The right word is “invest” rather than “spend”. If you are informed, it is an investment. If you are uninformed, it is just a cost.

These 4 questions will help you decide the answer.

1. How big is your company?
2. How much can your people build?
3. How restricted is your company?
4. How much do you want to invest?

The first three describe your company as it is. The fourth is your choice. Each one changes what you should buy, so I take them one at a time, then put them together.

Generally speaking, the smaller you are, the more likely a general-purpose LLM will serve you. If you are a small business, Claude or ChatGPT is perfectly fine. As you grow, you start to need other solutions.

The bigger you are, the more fragmented your usage becomes. Each team gets a little better on its own, and the company as a whole never gets the big win. Claude on its own gives you local maximums, and the global maximum stays out of reach. Fixing that needs workflow mapping, which I cover in a separate article, The local maximum fallacy of AI.

Size also decides two things later in this guide: whether outside builders can come in, and whether you need an AI policy and a head of AI.

This is what I mean by “how technical are you”. It has three levels.

1. Your people use the apps.
2. Your people build inside the apps: projects, skills, connectors.
3. Your people write code.

Most companies start at level one, with the apps: Claude, ChatGPT, and Grok for some people.

As your people become more technical, whatever the size of the company, they move away from the general-purpose apps and on to the coding tools: Codex, Claude Code, and increasingly Cursor. That is a new fork in the road. Companies at level three do not need much help, because their people are already highly proficient. If you are in that space, hire more great technical people, and they will take your AI to the moon.

In between sits level two. These people have become a bit more technical with LLMs. They have heard something, seen something online, or they know they are hitting a roadblock that should not be there. They are not quite technical enough to make the jump to coding tools. Or, simply put, they do not want to become builders. They like the job they do, and they do not want to pick up a whole new profession. I call this the glass ceiling, because I do not think it needs to exist.

If you are unregulated, go crazy. Connect to everything.

As you become more regulated, you may move into the Copilot range, where you face a different set of issues. You can still use AI. It just becomes harder and less intuitive to build with it. That matters, because the real power comes from building custom things and transforming your workflows, and that is exactly the part that gets harder.

As you move away from the base models and the model provider, you face new resistance. That resistance is expected. You are in a regulated industry, and you are not allowed to do the things a freelancer with no compliance team can do. That makes sense. The rules protect your customers and your profession.

So in regulated spaces, be extremely mindful of what you connect to. People in restricted companies already use AI on the side, when they are not meant to, and a policy is the only way to bring that into the open. The most regulated places need proper AI governance. What that looks like is in the buyer types below.

If you want to keep the budget small, stick to Claude and ChatGPT licences. Those will carry you a long way. If you are hitting usage limits, buy more usage.

If you have more margin to spend, start exploring hiring, in-house or out of house. There are many types of service provider at this point. What you generally want is people who can build, and not just people who tell you things. Why that matters, and how to choose between in-house and out of house, is in the two buying well sections at the end.

Whatever your answers, everyone starts in the same place. Buy a licence. Then learn what the application, Claude or ChatGPT, can do with your work tools.

Some people need training for this. If you are on the non-technical side and you have the budget, train. Training is always a good way to start when you do not feel very technical.

If your teams are already proficient with the apps, start exploring beyond licences.

Put the four questions together and you get four buyer types, plus one condition that sits on top of any of them.

1. A licence is enough

You are small and unrestricted. Buy Claude or ChatGPT seats. Connect everything. Expand the usage when you hit the limits.

2. Licence plus training

You are non-technical. Either you are starting out, or a few people already use AI privately inside the company and nobody has shared what they have learned. Buy licences and training, so everyone learns what the application can do with their work tools.

3. The glass ceiling

You have started to become a bit more technical, but you are hitting a ceiling, and you do not want to become a builder. You would benefit from hiring what we typically call AI engineers in-house, or from an external agency of consultants who also build, or, as the term goes, AI ninjas. If your teams are fragmented, map the workflows department by department.

4. Technical

You are technical enough to go. Use the coding tools. Hire more great technical people. You do not need much help.

The Restricted overlay

Being regulated and big is a challenging situation, even for a technical company. You need an AI policy, and someone has to own it. In companies with the technical ability, that is a head of AI. Where the company is predominantly commercial and regulated, like a financial services firm, what you really need is a committee.

The bottleneck will probably be your IT team, because they are the ones stopping employees from setting things up, and they are swamped with policy work, deployment work and development work. So you still need the AI policy, but you might also want external service providers to speed things up. These companies also need good collaboration between the technical team and the commercial team. That is an essential ingredient.

If you are very big, non-technical, highly regulated, and you have the money, bring in experts who know how to build. In technical terms these are forward-deployed engineers. In practice, they are consultants who can build.

At each stage, different people need different things.

Building is now so cheap, in every format, that you should at least expect a visualisation of what will exist in the future. Even if it is wrong, it gives you a flavour of the thing and grounds the conversation about how it could work. It is better to see how something could work and dislike it than to never see it at all.

If you receive a deck full of text that is probably 99% AI-generated, what is the point of that? The next step after the insight is to build something, so jump to that step straight away. Expect that from whoever you work with, in-house or out of house.

In-house engineers or out-of-house consultants who build: both are fine. The question that decides it is whether you want to build. Is it fun? Is it valuable for you to do? Or is it just another job, because you sell houses and not digital things?

If you want to build, go in-house and own it. Reduce your external dependencies as much as possible, so it starts to take shape as a capability of your own.

If building is just another job, bring in people who build. Bigger companies have good enough processes for external providers to come in. Smaller companies can do the same, as long as whoever comes in builds.