AI Engineering
A four-week assessment that tells you which of your AI ideas is worth funding, which is not, and what it would actually cost — written by the people who would have to build it.
Most AI consulting produces a deck. Ours produces a decision, because the people writing it are the people who would have to deliver the build, and that changes what gets promised. An AI readiness assessment answers four questions in sequence: which of the use cases on your list would actually create value, whether your data can support them, whether you should build or buy each one, and what the honest cost and timeline look like. The uncomfortable part is that the assessment frequently kills the use case the sponsor is most attached to — usually the impressive-sounding one — and elevates something dull that saves four hours a day in an operations team. We run these for enterprises and mid-market firms in India, the UK, the Gulf and APAC. We charge a fixed fee, we do not take a percentage of any resulting build, and there is no obligation to use us afterwards. That structure matters: a consultant whose recommendation determines the size of their own next contract is not giving you an assessment. If the right answer is that you should buy an off-the-shelf tool for a fraction of a custom build, the assessment will say so and name the tool.
Every candidate gets scored on value, data feasibility, and operational tolerance for being wrong. Almost every idea that fails does so on the third one, and almost nobody scores it.
Value is the easy dimension and the one everyone brings. We insist it be expressed as a number with a baseline — hours saved per week, tickets deflected per month, revenue per additional qualified lead — because a use case described only as strategic cannot be evaluated or, later, be proved to have worked. Data feasibility is the second filter and kills a meaningful share of the list: the information the system would need either does not exist in structured form, exists only in someone's judgement, or is spread across systems that would take longer to integrate than the value justifies.
The third dimension is the one that separates a useful assessment from a hopeful one. What is the cost of a wrong answer, and who bears it? A system that drafts internal summaries can be wrong occasionally with little consequence. A system that quotes prices, approves claims or advises on medication cannot, and the required accuracy pushes cost up by an order of magnitude — or makes the use case unviable entirely at current capability. Scoring this explicitly is what stops an organisation from building the high-risk use case first because it sounded most impressive in a steering committee.
We also weigh change tolerance. A technically sound system that requires forty people to alter a habit is a change management project wearing an engineering costume, and it should be resourced accordingly or not started.
Buy when the problem is common and your process is not special. Build when the differentiation is real and the integration surface is yours. Wait when capability is moving faster than your procurement cycle.
The default answer should be buy, and we say that as a firm that makes money building. If a hundred companies have your problem in roughly the same shape, someone has productised it, and their product has absorbed thousands of hours of edge case handling you would otherwise pay to rediscover. Where buying goes wrong is when the tool assumes a process you do not have, and the implementation quietly becomes a change programme to fit your organisation to the software.
Building is right when the process genuinely is your differentiation, when integration with your internal systems is the bulk of the work anyway, or when data residency and control rule out the vendors. It is also right, more often than people expect, for narrow internal tools — a focused workflow automation is frequently cheaper to build than to license per seat across a large team. The third option is the one consultants rarely offer: wait. Some use cases sit just beyond current reliable capability, where a build today would need substantial rework within a year.
If we think that is your situation, we will tell you what specifically needs to improve and what signal to watch for, rather than selling you the version that will disappoint you. There is usually something adjacent worth doing in the meantime — often the data work that any future version will need regardless.
A ranked use case shortlist, a data readiness finding per case, a build-buy-wait call with reasoning, a costed roadmap with sequencing, and the risks written plainly.
The document runs to a few dozen pages and is deliberately readable by both a CFO and an engineering lead, because those two people have to agree for anything to happen. The use case section gives each candidate its value estimate with the arithmetic exposed, its data finding, its risk profile and its recommendation. The data section is usually the part clients find most valuable and least expected: a plain account of what exists, what is trustworthy, what is duplicated across systems with conflicting definitions, and what would need to be built before any of it can be used.
The roadmap sequences the work so that shared foundations are built once rather than three times, and it is costed in ranges with the assumptions named, so you can see which assumption to challenge. The risk section covers what we think will go wrong: the integration that will take longer than the owning team believes, the accuracy threshold that may not be reachable, the stakeholder whose workflow changes most and who has not yet been consulted. We include a governance note as well — who signs off on model behaviour, how outputs get reviewed, what your obligations look like under the DPDP Act and, where relevant, GDPR and sectoral regulation. That section exists because the organisations that get stuck are rarely stuck on technology.
A consultant whose recommendation sets the size of their own next contract cannot give you an independent assessment. Fixed fee, no build obligation, and a willingness to recommend a competitor's product.
The structural problem with most AI consulting is straightforward. If the recommendation is a large build and the consultant delivers large builds, the recommendation is not advice. We charge a fixed fee for the assessment, agreed before we start and unaffected by what we conclude. You are under no obligation to engage us for delivery, and a meaningful share of our assessments recommend either buying a product or doing nothing at all for now. We will name specific vendors where a product fits, including ones we have no relationship with, because a recommendation you cannot act on is not a recommendation.
What we get out of this is a filter. The clients who do go on to build with us do so having already agreed what the number is, what the data problem is and what the risks are, which makes those projects dramatically more likely to succeed. We would rather run ten honest assessments and build three of them than sell ten builds and watch six stall. It is also worth saying what we are not: we are not a change management practice, we do not run training programmes, and we do not write policy documents for their own sake. Where those things are needed we will say so and suggest you find someone who does them properly.
What you get
Every candidate scored on measurable value, data feasibility, cost of being wrong and change tolerance, with the arithmetic exposed rather than asserted. Includes the cases we recommend dropping and the reasoning, so the decision can be revisited when circumstances change.
A plain account of what data exists, what is trustworthy, what is duplicated across systems with conflicting definitions, and what would have to be built before any AI use case can rely on it. Written to be read by non-specialists without losing precision.
A specific call for each shortlisted case with the reasoning attached, naming actual vendors where buying is right — including vendors we have no commercial relationship with — and naming the capability signal to watch for where waiting is right.
Phased delivery plan ordered so shared foundations get built once, costed in ranges with every assumption named and challengeable. Each phase ends at a decision point where stopping is a legitimate and clean outcome.
What we expect to go wrong and why, plus the governance layer: who approves model behaviour, how outputs are reviewed, and what your obligations look like under India's DPDP Act and any sectoral or foreign regulation that applies.
How we work
Week one. We talk to the people who would use the system, not only the people sponsoring it, because the gap between those two accounts is usually where the project would have failed. Everything on the wish list gets captured, including the ideas nobody has said out loud in a steering committee.
Week two. We look at the actual data — samples, schemas, freshness, duplication, definitional conflicts — rather than at the architecture diagram describing it. This is where optimistic assumptions in the use case list meet reality, and where the shortlist usually shortens.
Week three. Each candidate is scored, vendor options are evaluated where relevant, and costs are estimated by the engineers who would deliver the work rather than by a commercial team. Estimates are ranges with named assumptions, not single numbers.
Week four. We deliver the document, then run a session with both the finance and engineering sides present so disagreements surface while we are in the room. You leave with a decision, not a deck to circulate and never resolve.
Every phase ends at a decision point you can stop at — see how that works across fixed-scope projects, embedded pods and retainers.
Stack
Questions
A fixed fee in the low lakhs for a four-week assessment, agreed before we start and unaffected by what we conclude. Larger estates with many source systems cost more because the data inspection takes longer. There is no percentage of any resulting build and no obligation to engage us for delivery.
Four weeks in most cases: one week of interviews, one of data inspection, one of analysis and costing, and one to write and present. We can compress to three weeks where the scope is a single use case, but rushing the data inspection is exactly the wrong economy.
Frequently, and we will name the specific products including ones we have no relationship with. If a hundred companies have your problem in the same shape, someone has productised it and absorbed thousands of hours of edge cases you would otherwise pay to rediscover.
No, and a good share of our assessments end with a recommendation that does not involve us at all. The fixed fee structure exists precisely so that our recommendation is not shaped by the size of the contract it might generate.
A sponsor who can make a funding decision, someone who understands the data as it actually is rather than as documented, and access to the people who would use the system daily. That last group is the one most often skipped and the one whose input changes the conclusion most.
Then the assessment gets narrower and cheaper — usually a two to three week feasibility and costing exercise focused on the data and the accuracy threshold. We would still check the cost-of-being-wrong dimension, because that is the one that most often makes a well-defined project unviable.
Questions about cost, timelines, IP ownership and data residency are answered on the general FAQ, and how this practice came out of blockchain infrastructure explains why we build the way we do.
Related
The pipelines and quality layer every AI project stalls on.
A working AI product in weeks, scoped to prove one thing to investors or users.
Retrieval that cites its sources, measured with a real evaluation harness.
See also: test the surviving idea cheaply with AI PoC and MVP development · fix what the data readiness finding uncovers with data engineering for AI · start with the unglamorous automation that usually scores highest
Tell us what you are trying to build. We will tell you honestly whether we are the right team for it, and what it would realistically take.
