What Software Consulting Actually Does

• Software consulting is paid judgment. You’re buying a decision and the written record behind it, and that record is all you can inspect afterwards.

• Consulting, discovery and delivery get sold under the same word. They’re three different purchases with three different outputs.

• If the output can’t be handed to a firm that had nothing to do with producing it, nothing was produced.

• Plenty of consulting engagements exist to qualify you for a build. That isn’t automatically dishonest, but it changes what the advice points at.

• It’s worth buying when the decision is expensive, hard to reverse, and you have no way to check it yourself. Otherwise it’s a delay you’re paying for.

• Ask what you’ll be holding at the end, in writing, before you sign anything.

The Line Item Nobody Will Define

Someone has quoted you for a software consulting engagement and you can’t work out what actually arrives at the end of it. Nobody is going to write code. There’s no product to open when it’s over. The proposal talks about assessment, roadmap and alignment, and every firm you ask defines the term slightly differently, always in a way that describes what they sell. That vagueness isn’t an accident, and it’s why this is one of the easiest things in business to be overcharged for.

Strip the vocabulary and there’s one thing underneath. You’re paying someone to look at how your business works, form a view about what software should exist, and write that view down so you can act on it. No code changes hands. The deliverable is a decision, plus the record of how it was reached.

The industry’s own definitions circle without landing. One widely read guide to software consulting defines it as “analyzing a company’s software needs and selecting the right technology set,” then closes by offering to build you a product development team. That’s not a scandal, it’s a business model, and it’s why nobody in the category writes a tight definition. One specific enough to hold a firm to would also be specific enough to fail.

It isn’t a small category either. Gartner’s 2026 forecast puts IT services ahead of both software and hardware as the largest single slice of worldwide technology spending, and consulting sits inside that number as one of its least specified lines. A lot of money moves through a word nobody will pin down.

Three genuinely different things get sold under one word.

Consulting is buying a view

You don’t yet know what should be built, or whether anything should be. The question is whether custom software is the right answer at all, or whether you’d do better buying something that already exists, changing a process, or doing nothing this year. The output is a recommendation you could act on with any vendor, or with none.

Discovery is buying a specification

You’ve decided to build. Now somebody defines what, in enough detail that a real number can be attached to it. That produces user flows and wireframes, a scope document stating what’s excluded as well as what’s included, acceptance criteria per deliverable, and an agreed process for handling changes mid-build. It’s the work that makes a fixed price mean anything, which is an argument we’ve made at length elsewhere.

Delivery is buying the thing

Design and build. The only one of the three with something you can open at the end.

Here’s the practical version. Most buyers who think they need consulting need discovery, because they’ve already decided what to build and can’t get a number they trust. And plenty who get sold discovery needed consulting, because nobody asked whether the thing should exist. That second mistake stays invisible until the software is live and nobody uses it.

We keep the two separate on purpose, which is the shape you’ll see on our services page: scope gets defined before a number is attached to anything. A firm quoting a build before the scope exists is quoting a guess, and a firm charging you to advise on a build it has already decided you need isn’t advising.

Consulting is the one purchase where you can’t inspect the work. You weren’t in the interviews, you can’t evaluate the technical reasoning, and there’s no software to click around in. So judge it by what’s written down at the end, and whether it would be useful to someone who wasn’t in the room.

Software consulting services worth paying for hand you, at minimum:

• The problem restated in specific terms, including the part of your own framing that turned out to be wrong. If it only plays back what you said in the first meeting, nobody did any work.

• The options that were considered and dropped, with the reason each one was dropped. Buying something off the shelf and doing nothing both belong on that list.

• A recommendation with its conditions attached. Not “build a custom client portal” but “build a custom client portal if these two things are true, and here’s how to check them.”

• The risks named specifically. An integration nobody has tested, a data migration nobody has sized, a permissions model nobody has agreed. Vague risk language is the tell that the work stopped at the surface.

• A rough sequence, with what has to be true before each step can start.

• A scope skeleton detailed enough that a different firm could quote against it without re-interviewing your team.

• A written list of what the engagement did not look at. Almost nobody offers this, and it’s the most revealing item here.

One test covers all of it. Could you hand the entire output to a firm that had nothing to do with producing it, and get a sensible quote back? If yes, you bought judgment. If no, you paid someone to write down what you already told them, formatted.

This part needs saying plainly, because the rest of the category won’t. For any firm that also builds software, a consulting engagement is the cheapest and most credible way to qualify a lead, shape a scope toward the work it’s already good at, and arrive at a proposal the buyer feels they helped write. That incentive exists whether or not anybody in the room is acting on it.

The structural version is made at book length by Mariana Mazzucato and Rosie Collington, who describe an industry that can profit from a client’s continued dependence rather than from building up the client’s own capability. They’re writing about governments and large corporations. The mechanism is the same at your scale, and easier to spot, because there are fewer people in the room.

Three things tell you which one you’re in. The recommendation was never genuinely in doubt, which you can check by asking what evidence would have produced a different answer. The alternatives got a sentence each and no numbers, so “buy something existing” and “wait a year” were never really on the table. And the output doesn’t travel: it’s a deck of your own words with a proposal stapled to the back.

None of that means a firm which both advises and builds is compromised. Often it’s the only way to get advice from people who have actually shipped the thing you’re considering, and pure advisers who have never delivered produce confident, expensive, wrong answers of their own. What makes the combination safe is narrow and checkable. The advice survives being taken somewhere else. The recommendation is sometimes to build less, or later, or not at all. And the two are bought separately, so you can stop after the first without owing anybody an explanation. Those are the same signals that separate a good build partner from a bad one.

The rule is short. Buy it when the decision is expensive, hard to reverse, and you have no way to evaluate it yourself. Everything outside that is optional.

In practice, that’s four situations. You have an idea and nobody technical, and no way to tell whether it’s a six-week build or a two-year one. Three firms have quoted you numbers that aren’t in the same universe, which is a scope problem wearing a pricing problem’s clothes. You’re about to replace a system the business actually runs on, where being wrong costs you a year rather than a project. Or you got burned last time and no longer trust your own read of a proposal, and want a second opinion from someone with no stake in the build.

The stakes are lopsided, and that part is documented. Research by McKinsey and the University of Oxford across more than 5,400 IT projects found large ones ran 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted. That was 2012, and those projects were far bigger than anything you’re weighing. The failure modes travel down intact, though. Unclear objectives and requirements nobody pinned down are exactly what an advisory engagement is supposed to catch, and the only cheap moment to catch them is before anyone starts building.

It isn’t worth paying for when you already know what to build and you’re using an assessment to put off committing. It isn’t worth it when the engagement costs a meaningful fraction of just trying the thing. And it isn’t worth it as a second opinion on a decision you’ll make regardless, which is a more common purchase than anyone admits.

If you want a cheaper first pass, our product readiness check is a short set of questions on where a product actually stands before you commit budget. It won’t replace a proper engagement. It will tell you whether you need one.

Four questions, and you can ask them all on one call. They work on any firm, including the ones you’d otherwise have no way of telling apart.

• “What will I be holding at the end of this, and can I show it to another firm?”

• “What would have to be true for you to tell me not to build this?”

• “Which parts of the business will you look at, and which will you not?”

• “Is this priced and contracted separately from any build that follows it?”

Ask the second one first. A firm that can describe, specifically, the conditions under which it would tell you not to build is a firm whose recommendation is worth buying, because it could have gone the other way. A firm that can’t describe those conditions is selling you the build, and the consulting is just how the invoice starts.