There are three ways to bring AI into a business: do it yourself with off-the-shelf tools, hire an AI consultant to tell you what to do, or hire an AI software firm to build it. Do it yourself when a product already does the job. Hire advice when you don't yet know which problems are worth solving. Hire a builder when the work needs custom integration with your own systems. Plenty of businesses need all three at different stages, and the expensive mistakes come from using one where another was needed.
We should say up front that we're not neutral. Abrams & Luchanski advises, and Nexos, our technology division, builds. So this piece tries hard to describe the cases where you don't need us at all.
What does each option actually give you?
The labels get used loosely, so here is what each one usually means in practice.
Do it yourself (DIY). You buy AI products off the shelf, such as a company AI assistant, AI features inside the software you already use, or a no-code automation tool, and your own people set them up and drive adoption. You pay in subscriptions and staff time.
AI consultant. Someone reviews your business and tells you where AI fits: a strategy, a roadmap, a vendor shortlist, a policy. The deliverable is usually a document or a set of recommendations. Building it is left to you or to someone else.
AI software firm. Someone designs, builds and integrates a system for you: a custom agent, an automation across your tools, a private model connected to your documents. The deliverable is working software. Its quality depends on whether they understood the problem before they started building.
How do they compare?
| Do it yourself | AI consultant | AI software firm | |
|---|---|---|---|
| Best for | Common tasks a product already handles | Deciding what to do and in what order | Workflows that need custom integration |
| What you get | Tools and your own team's learning | Recommendations, roadmap, policy | Working, integrated software |
| Upfront cost | Lowest: subscriptions plus staff time | Moderate: advisory fees | Highest: a scoped project |
| Speed to first result | Fastest for simple tasks | Slow to reach a working result, since advice isn't a system | Weeks per scoped project |
| Who owns the outcome | You | You, since the consultant owns only the advice | Shared: they own the build, you own adoption |
| Main risk | Tool sprawl, no integration, stalled adoption | A good report that never gets built | Building the wrong thing well |
| Knowledge left behind | High, because your team learned it | Depends on the handoff | Depends on documentation and ownership terms |
No column wins across the board, which is the point. The right choice depends on what the specific problem needs.
When should you do it yourself?
Before paying anyone, check whether you can do it yourself. DIY is the right call when:
- A product already does the job. Drafting, summarising, meeting notes, searching your own files, first-pass research: mature products handle these, and many already sit inside software you pay for. Buying means someone else maintains it.
- The data doesn't need custom plumbing. If the task lives inside one tool, there's nothing to integrate.
- Someone owns adoption. The usual way DIY fails isn't the tool. It's that nobody is responsible for training people, writing the usage guidelines and checking whether anyone uses it.
The warning sign is tool sprawl: five AI subscriptions, none connected to each other, each used by two people, and data copied between them by hand. At that point you've recreated the problem you were trying to solve. We call it the copy-paste tax.
When is a consultant worth paying for?
Advice earns its fee when the question is "what should we do?" rather than "how do we build this?" That typically means:
- You have a dozen possible uses for AI and no way to rank them.
- Leadership disagrees about where to start.
- You need a policy for which data can go into which tools before anyone picks one.
- You're about to spend real money and want someone independent to check the plan.
The main risk with pure advisory work is a good report that never gets built. A roadmap is only worth something if it's specific enough to act on: named workflows, what "done" means for each, rough cost and effort, and the order to do them in. If a consultant's output doesn't say which workflow to fix first and how you'll know it worked, it's a presentation, not a plan.
Also ask whether the advice is tied to the adviser's own products. A recommendation that always ends at the adviser's own platform is sales material, not independent advice.
When do you need a software firm?
You need someone who builds when the answer to "does a product already do this?" is no. Usually that's because:
- The workflow runs across several of your systems (inbox, CRM, accounting, scheduling) and has to read from and write to each of them.
- The task needs judgment on unstructured input, such as reading an email to work out what's being asked, and then acting on it in your tools.
- It needs approval steps, audit trails, or rules about what the AI may do on its own.
- Your data can't leave your control, so the model has to run privately.
The main risk here is building the wrong thing well: a technically good system aimed at a workflow that didn't need it, or one that a $40-a-month product would have handled. The defence is to scope before building. We cover that sorting in Buy, build, or automate.
Why do the categories blur?
In practice most useful engagements need both advice and implementation. The advice is only as good as its understanding of what can be built, and the build is only as good as its understanding of the business. That's why many firms, including us, now do both.
If you hire one team for both, check:
- Is the advice free to say "don't build"? Ask for an example of when they recommended buying a product or doing nothing.
- Is there a written deliverable before any build commitment? You should be able to take the plan elsewhere.
- Is the scope a named workflow, with a definition of "done", rather than "AI transformation"?
- Who owns what afterwards? Accounts, data, documentation and configuration should be yours whenever practical.
- Is maintenance priced separately and optional? You should be able to run what they built without them.
Our own model follows that shape. Every engagement can start with a free audit, a 30-minute call plus a written report that's yours to keep with no obligation to build with us. Builds are scoped per project from $4,900, and ongoing support is optional (pricing). We describe how the audit runs, step by step, in The AI-readiness audit, step by step.
A quick way to decide
Take one problem at a time, not "our AI strategy", and ask:
- Does a product already solve this? If yes, do it yourself: buy it, set it up, own adoption.
- Do we know this is the right problem to solve first? If not, get advice before spending on a build.
- Does it need our systems connected, judgment on messy inputs, or private data handling? If yes, you need a builder, ideally one who scoped it with you first.
Many businesses end up using all three: DIY for the common tasks, advice to set priorities, and a build for the one or two workflows that justify it. The mistake is using one option for everything.
Not sure which one your problem needs? A free audit will tell you, even if the answer is to buy a product.
Discuss a project with Abrams & Luchanski →You can also see what the firm does or get in touch directly.