Deciding what to build, and whether to build anything
AI consulting establishes what is worth doing before money is committed to building it. That means assessing which processes are genuine candidates, what each would cost against what it would save, and which should be rejected, which is often most of the list.
Organisations arrive at AI work from two directions. Some have a process that costs too much and are looking for a solution. Others have been told they need an AI strategy and are looking for a problem. The second group is larger, and the most useful thing consulting does for them is reduce a long list of possibilities to the small number that would actually pay back.
AI initiatives fail before implementation, in the selection. Projects are chosen for visibility rather than value, so the pilot is something impressive rather than something expensive. Nobody quantifies the current cost of the process, so there is no baseline to justify the spend against. Feasibility is assumed from a demo rather than tested against real data. And success is defined as 'launched' rather than as a measurable change in the thing it was meant to improve.
When this work makes sense
Questions worth asking any supplier
Is the consultant also the implementer? That is not disqualifying and it is a bias worth naming.
Will the assessment include projects that should not be done? A list with no rejections is a sales document.
Does it quantify current cost? Without a baseline there is nothing to measure against.
Is feasibility tested against your data, or assumed from general capability?
Does it end in a decision, or in a strategy document nobody implements?
Deliverables
Process inventory with current cost quantified in time or headcount
Feasibility assessment against your actual data rather than general capability
Prioritisation by value against effort and risk
An explicit list of what not to do, with reasoning
Build-versus-buy assessment for each viable candidate
Data readiness review, since most blockers are data rather than model
Cost modelling including ongoing API spend
An implementation sequence with success measures defined per project
Built with
Process
The deliverable includes a rejection list, and it is usually longer than the recommendation list. Processes are assessed and the ones that should not be automated are named with reasons: too rare, too high-stakes, better served by a simple rule, or the data does not exist. Consulting that recommends everything it examined is a sales process wearing a different name, and we would rather hand over a short list than a flattering one.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Assessment, pilot, or straight to build
Assessment first
Fits: Organisations with several candidates and no clear priority
Limits: Costs time before anything is built, which some stakeholders find hard to justify
Pilot one use case
Fits: A single obvious candidate where feasibility is the open question
Limits: Pilots that succeed often fail to scale, for reasons the pilot did not test
Straight to build
Fits: Well-understood problems with proven approaches
Limits: Commits budget before feasibility against your data is established
Case studies
No published consulting case study. Assessments are confidential to the organisations that commissioned them.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Do we actually need AI?
Often not, and that answer is a legitimate outcome of this work. Many processes are better served by ordinary automation, a configuration change, or by removing a step nobody questioned. We would rather tell you that than build something you regret.
You build AI systems. Can your advice be neutral?
Not entirely, and it is better to name that than to claim otherwise. The rejection list is how we keep ourselves honest, if an assessment recommends building everything it looked at, treat it as a sales document regardless of who produced it.
What is data readiness?
Whether you have the data a project needs, in usable condition, in sufficient volume, with permission to use it. It is the most common blocker, and it is usually discovered mid-build rather than during assessment, which is the expensive order to find it in.
How long does an assessment take?
Typically two to six weeks depending on how many processes and whether feasibility prototypes are built. Longer than that usually means the scope was not bounded, and the output tends to be a document rather than a decision.
Will you build what you recommend?
If you want us to, and it is not a condition. Some clients take the assessment to their own team or to another supplier, which is a legitimate outcome and one we price for accordingly.
Our pilot worked but we could not scale it. Why?
Common causes are cost per operation that only worked at pilot volume, accuracy measured on a favourable sample, integration with production systems left out of scope, or no operational owner. A pilot that excludes the hard parts is a demonstration.
What should we do first?
Usually the highest-volume, lowest-stakes process with clean data, not the most impressive one. Early projects should establish capability and trust, and a visible failure on something high-stakes sets the whole programme back.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.