One-time engagement
Architecture review
A one to two week review of your AI system as it runs, from the code and the traces to the paths customers take, that tells you what gets expensive or fragile at ten times today’s usage and what to change first.
Know what breaks at ten times today’s usage before you get there.
- 1 to 2 weeks
- Priced on the call
- Written review, ranked fix list
Is this for you?
You are about to scale what you have
Usage, customers or traffic are about to multiply, and the system was built for today’s numbers.
The bill is growing faster than usage
Each new customer costs more than the last, and nobody can say which part of the architecture is doing it.
Something feels fragile
Incidents are starting to cluster around one service, one database or one provider, and you want to know how far it is from breaking.
Not this? The production readiness audit tests a live agent on your real use cases against six gates; the 48-hour verdict ($399) is the short form for a design or a small app, credited against this review.
What you get
- 01
The review
Each of the six checks on your system as it runs, with what holds, what gives at ten times and the evidence from your traces.
- 02
The ranked fix list
Every change ranked by what it saves or prevents and what it takes, written for your team to act on without me.
- 03
The ten-times map
Where the first failures and the first cost jumps land as usage grows, so you know what to change before each one.
Illustrative pages. Yours carry your system’s scores, numbers and fixes.
At ten times today
Ranked changes
- 1CostFix
- 2CostFix
- 3CostFix
- 4CostFix
- 5CostFix
Architecture review
Six checks, read on your system
- The hot path
- The data layer
- Retrieval at scale
- The cost curve
- Single points of failure
- Queues and limits
What I check
Six places an AI system gets expensive or fragile as it grows. I read each one on your system as it runs and model it at ten times today’s usage.
01The hot path
I follow the request your customers make most, step by step, and find the part that will slow everyone down first as traffic grows.
I measureThe slowest step on the busiest path, and its limit
02The data layer
I read how every service reaches the database and the stores behind it, and find where the next ten times of traffic piles up.
I measureThe queries and stores that give first, with the fix
03Retrieval at scale
I check how the index, the embeddings and the retrieval hold as the documents and the customers multiply.
I measureRecall and latency as the index grows
04The cost curve
I plot what one customer costs you today and what it costs at ten times, by model, step and retry, and find where the curve bends the wrong way.
I measureThe cost curve, and the step that bends it
05Single points of failure
I map what everything depends on: one provider, one queue, one service, one person. Then I check what happens when each of them goes.
I measureEvery single point, and what stands behind it
06Queues and limits
I check the rate limits, the queues and the back-pressure between services, and find where a burst of traffic turns into dropped work.
I measureEvery limit, and what happens past it
1 to 2 weeks, written review and readout
The two weeks
- Days 1 to 2
Read the system
Access in place, the code and the architecture read end to end, the traces and the usage numbers collected.
- Days 3 to 7
Trace and model
The busiest paths traced, each of the six checks read on the running system and modelled at ten times today.
- Days 8 to 10
Rank and write
Every change ranked by what it saves or prevents, the ten-times map drawn, a readout with your team.
The next step
Start with a
20-minute call.
Tell me what the system does and what is about to grow. You leave knowing whether the review fits, how long it would take and what it would cost.
Bring
- What the system does, in a sentence
- What is about to grow: customers, traffic, data
- Where it already hurts, if it does
Why me
I have read and rebuilt systems at the point where they had to grow. At Devnagri AI, as fractional CTO, I scaled a localisation platform across 22 languages, with its LLM workflows, voice and RAG, as the customers grew. At TWINii I cut database load by about half and ran a capacity upgrade with no downtime. Before AI, I built the core integrations at Shiprocket and spent five years on Balluun’s marketplace as it grew.
The track record“Mandeep didn't just put in a patch, he helped redesign the system architecture to handle 5x the load without too much of extra server hardware.”
Jaspreet Singh OberoiHead of Engineering, DevnagriAsked on most first calls
The questions.
How long does the review take?
One to two weeks from the day access is in place. A single service with one model is usually one week; several services, a retrieval layer and real-time traffic usually two.
What access do you need?
Read access to the code and the architecture docs, a sample of production or staging traces, your usage numbers as they stand and an hour with whoever built the system.
What if we only have a design or a small app?
Then the 48-hour Production Readiness Verdict is the right size. Send the diagram, the design doc or the repo and you get a written verdict for $399, credited in full if you go on to the review or the audit.
Do you sign NDAs?
Yes, yours or mine, before I see anything.
Do you rebuild anything?
No. The review ends in a written ranked list your team can act on. If you want me on the changes, I can join part-time after the review.
What if nothing is fragile?
Then you have a written review that says what holds at ten times and why, which is what your board or your buyer was asking for.
What does it cost?
It depends on the size of the system, so it is fixed on the first call, in writing, before anything starts.
How is this different from the production readiness audit?
The audit tests a live agent on your real use cases against six gates over three to four weeks. The review reads the architecture for scale and cost in one to two weeks, and suits systems with or without agents.