Consulting for technology decisions that matter
Senior technology consulting for organisations facing difficult decisions across AI, architecture, software, data and modern technology.
“What technology should we use?”
“What problem are we actually trying to solve?”
We don't begin with “What technology should we use?” We begin with “What problem are we actually trying to solve?”
The commercial model
The first 30-minute technical conversation is free. It is not a sales presentation. You bring a real problem. We bring structured thinking.
A problem worth discussing.
We can continue into deeper advisory, architecture or engineering work, on the terms that make sense for the problem.
You walk away. No follow-up sequence, no proposal you didn't ask for.
You should leave with more clarity than you arrived with: a sharper problem statement, named assumptions, and the questions that actually matter.
A typical conversation moves through the areas below. It is not a checklist. Some problems spend twenty minutes on assumptions and two on architecture.
Context
Who are you and what are you trying to achieve?
The conversation follows the problem, not a script.
Interactive
You don't need to know the answer. You don't even need to know whether AI is involved.
Tell us what you're trying to solve.
What we'd want to understand
Start typing and this panel fills in as you go with the missing information, assumptions, questions and constraints we'd take into a first conversation, each one showing the words that produced it.
Methodology
Seven stages. The order matters: architecture comes fifth, after we know what the problem is, which beliefs are load-bearing, and what solving it is worth.
Stage 01 of 07
Before any option is on the table, we build a picture of what exists and what is being attempted.
Stage 03
Most bad technology decisions are not made on bad information. They are made on assumptions that were quietly promoted to facts. The ladder keeps each statement where it belongs until the evidence moves it.
Separate what we know from what we believe.
Try it · challenge an assumption
“Customers will accept a 24-hour turnaround if the result is more accurate.”
What's the evidence?
The statement doesn't change. Where it sits on the ladder does, and so does how much weight it can bear.
Traceability
Every important technology decision should be traceable back to a problem, evidence and a reason.
Stage 04 · Quantify
A build estimate on its own is a partial answer. Every option is costed across four horizons, and every figure carries its basis and its confidence.
Cost to create.
People, tooling, licences and the opportunity cost of the team while it is building.
Cost to operate.
Cloud, inference, support, on-call, monitoring. The bill that arrives every month.
Cost to evolve.
How expensive is the next feature, the next integration, the next regulatory change?
Cost to replace or leave.
Data export, contract terms, retraining, migration. The cost you only discover when you want out.
Do not fabricate ROI. If the information is unavailable, label it an assumption or an unknown.
Every estimate in a Desha Decision Pack carries a basis and a confidence level. “Unknown” is a legitimate value. A false number is not.
Decision dimension
Every architectural element carries a permanent operating cost that is cognitive, financial and organisational. Before it goes on the diagram, it has to be justified by a real requirement.
Try it · what goes on the diagram?
Operating cost, cognitive load and failure modes rise with every element, earned or not.
Select once to add without a requirement; again to attach one; again to remove.
Complexity should be justified by a real requirement. Do not use complexity to make an architecture look sophisticated.
Decision dimension
Some decisions are a door that swings both ways. Others are a door that locks behind you. Both are fine, as long as you know which one you're walking through.
What it means for the decision
Worth a deliberate decision and a written reason.
What we evaluate for significant decisions
We do not collapse this into a score unless the underlying information supports one. A single number hides exactly the detail that matters.
Stage 05 · Architect
The architecture stage happens fifth, on purpose. By then we know the problem, the evidence, the value and the constraints, so the design has something to be right about.
HLD
The shape of the system on one page.
Application
Services, boundaries, ownership.
Data
Stores, flows, lineage, residency.
AI
Models, retrieval, evaluation, fallback.
Integration
What talks to what, and how it fails.
APIs
Contracts, versioning, consumers.
Cloud
Runtime, regions, managed vs self-run.
Security
Threats, controls, secrets.
Identity
Who is who, and what can they do.
Non-functional requirements
NFRs are first-class requirements.
Each carries a target where one can be stated, such as a latency, an availability figure or a recovery objective, and each target links back to the evidence that justifies it.
Consulting output
A tangible output of deeper consulting engagements: one document that carries the problem, the evidence, the economics, the architecture and the reason, so the decision survives the meeting it was made in.
The full pack is an output of deeper advisory work where it is appropriate. The free 30-minute session will not produce one, though it will usually produce the first three sections.
Every pack ends with one of three outcomes. It is a decision aid for you. It is not a verdict, and it is not a sales mechanism.
There appears to be sufficient evidence and value to investigate or proceed further.
Important assumptions, questions or prerequisites need to be resolved.
Based on the information available, there is not currently sufficient justification to proceed.
[Executive problem statement]
Prepared for [client] · [date]
Rationale: [Two load-bearing assumptions remain unverified; the investment ceiling is unknown.]
Prerequisites: [Measure current volume · confirm data-residency requirement · agree ceiling.]
Services
Six ways the method is applied. Each starts with the same question: what problem are we actually solving?
Where and how AI can create real value.
“Is AI the right tool for this, and if so, where exactly?”
Architecture, system design, integration and technical strategy.
“What shape should the system be, and why?”
Production AI systems and products.
“Can we build this so it works reliably outside the demo?”
Objective review of an existing or proposed architecture.
“Would this design survive contact with production, scale and change?”
Commercial, technical and operational comparison.
“What does each option really cost across build, run, change and exit?”
Senior technology guidance for founders and engineering leaders.
“What should we decide this quarter, and what can wait?”
Anti-positioning
Anti-positioning, stated plainly. These are the ways technology consulting usually goes wrong.
If the right answer is “don't build it”, we will tell you.
Recommend AI because it is fashionable.
Recommend technology before understanding the problem.
Manufacture ROI numbers.
Hide cloud or operating costs.
Introduce unnecessary complexity.
Pretend assumptions are facts.
Ignore non-functional requirements.
Hide architectural trade-offs.
Recommend a vendor simply because it is familiar.
Tell you something will work when we don't have enough evidence.
Force an engagement because we had a consultation.
Worked examples
Ten worked examples, each from a different sector, each turning on a different kind of decision. They exist to show how a decision gets made: the evidence that moved it, the options rejected, and what it would take to change the answer.
Illustrative. These are illustrative worked examples, not exact engagements. They are written to show the method rather than to claim results. Figures taken from published sources are cited; everything else is labelled as an assumption, exactly as it would be in a real Decision Pack.
Maritime logistics
A terminal operator wanted to predict vessel arrival times to plan berths, tugs and labour. The data the model would learn from turned out not to exist in usable form, so the money went to the contract that produces the data instead.
Evidence stopped a project that every stakeholder wanted.
Veterinary care
A practice group wanted an AI assistant to advise owners out of hours. Professional rules on what constitutes an animal being “under care” meant the assistant could never do the valuable-sounding part, so the design changed to the part it could legitimately do.
A regulatory rule turned a broad product idea into a narrow, useful one.
Specialty insurance
A marine cargo underwriting team wanted to automate submission intake. Treated as one decision it was a stalemate; split into two, document handling and risk judgement, it answered itself.
Build versus buy answered per component, not per project.
About
Desha.AI Consulting is the technology advisory practice of Desha.AI, led by its founder Deep Sharma. The consulting work applies the same discipline used to build and operate production AI systems: problem first, evidence before belief, economics next to architecture.
Principal
Deep Sharma
Principal · Architecture, AI & Engineering
Free · 30 minutes · one real problem
Thirty minutes, one real problem, structured thinking. If there's no value, there's no engagement.
