We’ve been on both sides of this. We’ve paid consultants $15,000 for advice we could have Googled. And we’ve spent three months trying to sort out a data migration ourselves that a specialist could have done in two weeks. Both felt like mistakes at the time.

After enough of these experiences, we’ve developed a rough framework for when to bring someone in and when to figure it out internally. It’s not perfect, but it’s saved us from repeating the worst of our past decisions.

When You Should Probably Just Figure It Out

If the problem is well-documented online, you have someone on the team with adjacent skills, and the timeline isn’t critical — do it yourself. Seriously.

Setting up a new project management tool? There are hundreds of guides, comparison videos, and community forums. You don’t need a consultant to tell you whether Asana or Monday.com fits your team better. You need someone on your team to trial both for two weeks and report back.

Same goes for basic automation. Connecting your CRM to your email tool with Zapier or Make doesn’t require outside expertise unless your setup is genuinely complex. The learning curve is part of the value — your team comes out the other side understanding the tools better.

We’ve also found that solving problems internally builds institutional knowledge. When we set up our own analytics dashboards (painfully, over several weekends), the person who did it became our go-to for anything data-related. If we’d outsourced it, we’d have a nice dashboard and no idea how to change it.

The general rule: if the problem is common, the stakes are low, and the timeline is forgiving, keep it in-house. You’ll spend more time, but the knowledge stays with you.

When You Should Bring Someone In

There are situations where doing it yourself is false economy. We’ve learned to spot them.

You don’t know what you don’t know. This is the big one. If you’re evaluating a technology category you’ve never worked with — say, migrating your infrastructure to the cloud, or implementing an AI model for a specific business process — you don’t just lack the technical skill. You lack the context to evaluate your options. You might not even be asking the right questions.

A good consultant doesn’t just do the work. They frame the problem correctly. We hired one consulting group to help us scope an AI project last year, and the most valuable thing they did was talk us out of half of what we thought we wanted. That saved us more than their fee.

The cost of getting it wrong is high. Data migrations, security configurations, compliance-related work — if a mistake means lost data, a breach, or a regulatory issue, the calculus changes completely. The cost of a consultant looks very different when compared with the cost of getting it wrong.

You need it done fast. Sometimes the business need doesn’t wait for your team to learn a new skill. If a client project depends on getting a system live in four weeks and nobody on your team has done it before, that’s not the time for a learning exercise.

Your team is already stretched. This one’s easy to overlook. Even if your people could figure it out, can they afford to? If your developer is already behind on three projects, adding a research-and-learn task to their plate isn’t free. It’s an opportunity cost that shows up in delayed delivery everywhere else.

How to Hire a Consultant Without Wasting Money

Assuming you’ve decided to bring someone in, here’s what we’ve learned about making it worth the spend.

Define the outcome, not the process. Don’t hire someone to “advise on our tech strategy.” Hire them to “produce a prioritised roadmap for reducing our manual reporting by 60 percent within six months.” Specific outcomes keep the engagement focused and give you something to measure against.

Ask for references in your category. A brilliant enterprise architect isn’t necessarily useful for a 15-person company. We’ve had the best results with consultants who work specifically with businesses our size. They understand the constraints — limited budget, small team, no dedicated IT.

Insist on knowledge transfer. This is non-negotiable for us now. Whatever the consultant builds or configures, someone on our team needs to understand it well enough to maintain and modify it. We build this into the statement of work. If they’re not willing to teach your people, find someone who is.

Start small. We don’t sign six-month engagements with new consultants. We start with a scoped discovery phase — usually two to four weeks — and evaluate from there. This protects both sides and lets you assess the working relationship before committing serious money.

Be honest about your internal capability. The worst consulting engagements we’ve had were ones where we overstated our team’s readiness. If you can’t maintain what the consultant builds, say so upfront. A good consultant will adjust their approach accordingly.

The Middle Path

There’s a third option we’ve started using more: fractional or part-time technical help. Instead of a full consulting engagement or going it alone, we bring in a specialist for a few hours a week over several months. They guide our team’s work, review decisions, and step in for the genuinely tricky bits.

It’s cheaper than a full engagement, builds internal capability faster, and provides a safety net for the decisions that matter most. Not every consultant offers this model, but more are starting to.

Our Rule of Thumb

We ask one question: “If we get this wrong, what happens?” If the answer is “we waste a few days and try again,” we figure it out ourselves. If the answer involves lost revenue, security exposure, or months of rework, we call someone. It’s not a perfect heuristic. But it’s kept us out of the worst traps on both sides.