Insights
Consultant, advisor, or software shop: which one you actually need
Eleven 186 ·
Key takeaways
- A consultant, an advisor, and a software shop solve different problems and get paid in different ways.
- A consultant is typically hired for a defined, bounded piece of analysis, and involvement usually ends at delivery.
- An advisor works the decision with you and often stays through what happens next.
- A software shop builds what you tell it to build.
- Picking the wrong category for your actual problem is the most common source of frustration after hiring any of the three.
A consultant, an advisor, and a software shop solve different problems and get paid in different ways, and most of the frustration owners report after hiring one traces back to picking the wrong category for the problem they actually had. A consultant tells you what to do inside a defined scope, an advisor works the decision with you and often stays through what happens next, and a software shop builds what you tell it to build. Working out which one you need before you call anyone saves months.
The confusion is understandable. All three get called in to fix a business problem, all three send an invoice, and all three will describe their own work as strategic if you ask them to. The difference isn't in how they talk about themselves, it's in what they're actually built to produce and where their involvement stops.
Side by side
| Consultant | Advisor | Software shop | |
|---|---|---|---|
| Typical scope | A defined analysis or recommendation | The decision itself, often ongoing | A specified technical build |
| How it is priced | Per project or per engagement | Scoped to the problem, often phased | Per project or by development hours |
| Where it ends | At the report or recommendation | Often through implementation | At delivery of the specified build |
| Best fit | A well-defined question, with internal capacity to act on the answer | An unclear or high-stakes decision that needs to stay owned past the recommendation | A known requirement that just needs to be built |
| What it will not tell you | Whether you asked the right question | Nothing withheld by design | Whether the requirement was the right one to build |
Two worked examples
A company evaluating a new product line had already collected competitor pricing and a rough market-size estimate. Thinking they needed more research, they hired a research consultant for a market study. The study confirmed what they already knew and added detail nobody used, because the real open question wasn't market size at all. It was whether their existing sales team could sell a product with a different buying process. That belonged to an advisor rather than a consultant, because it needed a decision about organizational structure, not another report.
In a separate case, a company that had already decided to build an internal scheduling tool went straight to a software shop with a one-page specification. The shop built exactly what was specified and delivered on time. Six weeks after launch the tool didn't account for a scheduling exception that came up in about a third of real bookings, because nobody had scoped it and the software shop had no mandate to ask whether the specification was complete. An advisor engaged before the build would probably have surfaced that gap during diagnosis, before a line of code was written.
Neither example means the consultant or the software shop did bad work. Both delivered exactly what they were hired to deliver. The mismatch happened a step earlier, when the company picked which kind of help to hire before it had correctly named the kind of problem it had. You can't fault a consultant for not questioning a market-size assumption nobody asked it to question, or a software shop for building precisely to a specification it was handed as final.
Questions to ask before you hire any of the three
- Do you already know exactly what needs to be built or analyzed, with no real ambiguity left? If yes, a consultant or a software shop, scoped tightly, is probably enough.
- Is the real uncertainty about what decision to make, rather than just what the facts are? Then it's advisory work, not a research project.
- Will you need someone accountable after the recommendation or the build ships, or does the relationship reasonably end at delivery? Answer this before signing anything.
- Has more than one of these questions come back ambiguous? Then the problem probably crosses categories, and a single-category hire will only solve part of it.
When one is not enough
Plenty of well-defined problems are genuinely single-category. A compensation benchmark is consulting work, a known integration is a software build, and neither needs an advisory relationship wrapped around it. The mismatch shows up when a company hires the cheaper or more familiar option, a report or a build, for something that was actually a decision. If your problem sits cleanly in one category, hire for that category directly.
The harder case is where a problem genuinely crosses all three. A company that has to decide whether a new market is worth entering, and then how to structure the offer, and then needs a system built to support it that doesn't exist yet, isn't looking at three separate hires. It's looking at one problem that happens to touch strategy, structure, and software at the same stage. Split that across a consultant, an advisor, and a software shop hired separately and each one optimizes their own piece while nobody owns whether the pieces fit together. That's the situation an advisory and execution firm is built for, not because every problem needs one, but because some problems genuinely don't separate cleanly along these lines.