How we work
Written for engineers and operators, not for a pitch deck.
How does an Aksh Intelligence engagement run?
Every engagement opens with a paid discovery period rather than a fixed quote against a specification. Discovery produces an architecture, a scoped plan and a real estimate. Delivery then runs in short cycles with something demonstrable at the end of each, sequenced so that any step touching production can be reversed without a rebuild.
What a first engagement looks like
Most work follows this shape. The durations are typical rather than fixed, and discovery frequently changes what the later phases should be — which is the point of running it first.
Phase 1 · 1–2 weeks, paid
Discovery
We examine the data, the existing systems and the actual constraint before quoting a build. Specifications written before anyone has looked are usually wrong in ways that surface around month three, and finding that out early is considerably cheaper than finding it out late.
You get: An architecture, a scoped plan, and an estimate that means something.
Phase 2 · 3–6 weeks
First working slice
The narrowest version that reaches real users or real data. Not a prototype — something that runs, so the assumptions most likely to be wrong get tested against reality rather than against a document.
You get: A deployed feature, and a written record of what the build changed our minds about.
Phase 3 · ongoing
Iterate on evidence
Short cycles with something demonstrable at the end of each. Where the work touches production, sequencing is designed so every step is independently reversible — the ability to undo quickly is what makes frequent shipping safe rather than reckless.
You get: Measured change against the number agreed at the start.
How we make decisions
These are the positions that shape an engagement, including the ones that occasionally lose us work.
Paid discovery before a fixed quote
Fixed price against an unclear specification serves neither side. It forces padding into the estimate and turns every discovered requirement into a negotiation instead of a decision.
The constraint, not the feature list
The useful first conversation is about what is currently not working and what would count as success. A feature list describes a solution someone already chose, and it is frequently the wrong one.
Reversible steps
Database changes separated from the code that depends on them, deployments that keep the previous version available, and feature flags for anything risky. Recovery in minutes is what makes small, frequent releases possible.
Documentation as a deliverable
Written while context is fresh rather than assembled at handover, with more than one person holding working knowledge of anything critical. That is what makes a departure an inconvenience rather than a crisis.
Visibility decided at build time
Whether an AI assistant can extract an answer from a page depends on that page's structure, and structure is a build decision. Adding it afterwards means rewriting the frontend.
We say what we do not know
Where an approach depends on data that may not support it, or where a timeline depends on something outside our control, we say so at the start rather than discovering it in delivery.
Why discovery is paid, and why that is better for you
Free discovery is a sales process wearing a delivery costume. An agency giving away two weeks of senior time is recovering it somewhere, usually in a padded estimate, and it has a commercial incentive to conclude that the project should go ahead. Paying for it removes that incentive and changes what you get.
What you get is a real deliverable. A system design with the expensive-to-reverse decisions identified and justified. A plan broken into phases that each ship something usable rather than a Gantt chart of internal milestones. An estimate that means something because it was made after looking at the data, the existing systems and the actual constraint.
You own that output whether or not you continue with us. A discovery that produces a plan you take to another team is a reasonable outcome and we would rather that than an engagement neither side wanted. It also means the recommendation can be genuinely unwelcome — that the project should be substantially smaller, or should not happen at all — which is the most valuable thing discovery produces and the thing a free version will never tell you.
What a fixed-scope phase actually fixes
After discovery, engineering work is quoted as fixed-scope phases. That is possible because by then the scope is understood, and the risk of having scoped it wrongly sits with us rather than with you.
What is fixed is the scope and the price. What is not fixed is the approach inside that scope, because the whole point of short cycles is that evidence changes decisions. If a better way to satisfy the requirement appears in week three, we take it — the requirement is the commitment, not the implementation we assumed in week one.
Where a change alters the scope rather than the approach, it is a conversation with a number attached rather than an argument about what the contract implied. That distinction is why the scope has to be written in terms of outcomes rather than tasks.
How we handle the parts that go wrong
Every engagement of length hits something unplanned. The useful question about an agency is not whether that happens but what they do when it does.
The technical answer is that delivery is designed to be reversible. Database changes are separated from the code depending on them, so the previous version still runs against the new schema. Deployments keep the last version available. Anything risky sits behind a feature flag. The result is that a bad change is corrected in minutes rather than becoming an incident, and that ability is what makes shipping frequently safe rather than reckless.
The commercial answer is that we tell you when an estimate is going to be wrong at the point we know, not at the point it becomes undeniable. An overrun disclosed in week two is a decision you can make. The same overrun disclosed in week eight is a position you have been put in.
Working alongside your engineering team
A substantial share of engagements involve a client team rather than replacing one, and the arrangement that works has a specific shape.
Changes arrive as pull requests against your repository, with the reasoning in the description rather than only the diff. Your people review on your terms and can reject anything. We work in your conventions rather than importing ours, because a codebase written in two dialects is worse than one written in either.
What does not work is being handed a specification with no ability to question it. Where we cannot say that an approach is wrong, the value we add is reduced to typing, and you would be better served by hiring contractors directly at lower cost.
What you are left holding
The measure of an engagement is what remains after it ends, and the failure mode is well known: a working system nobody internally understands, where every subsequent change requires coming back to the people who built it.
We treat documentation as a deliverable written while context is fresh rather than assembled at handover, when the incentive has gone and the reasoning has faded. More than one person holds working knowledge of anything critical. Patterns are conventional rather than clever, because a conventional system can be picked up by someone new and an ingenious one that lived in one person's head cannot.
Concretely, handover is documented code, deployment pipelines and runbooks your own team can operate. If taking the work in-house after the first phase is the right decision for you, that should be possible without a rewrite — and if it is not possible, something was built wrongly.
How we price, and what drives it
Engineering runs as fixed-scope phases after discovery. Search runs as quarterly retainers. That difference follows from the shape of the work rather than from a pricing preference.
A build has a definable end, so it can be scoped and priced. Search does not: competitors publish, algorithms change, and a position held this quarter is not held next quarter without work. A fixed-scope search engagement is either a technical audit, which is genuinely finite and which we do sell that way, or it is a fiction.
The practical consequence for planning is that engineering spend is lumpy and predictable while search spend is level and continuous. They do not behave the same way in a cash flow forecast, and a company budgeting for both should not expect them to.
What we decline, and why saying so is useful
We do not take staff augmentation where the requirement is people against a specification written elsewhere. We do not take fixed-price contracts against specifications nobody has validated. We do not guarantee rankings, because they depend on competitor behaviour and algorithm changes nobody controls. And we decline briefs whose goal is volume of pages or content without a corresponding claim to being useful, because that carries real penalty risk at the domain level.
Publishing that list costs us some enquiries, which is the point. An agency that will take any brief is telling you something about how it will handle yours, and the conversations we lose to this list are conversations that would have ended badly later.
Questions before you start
Why does every engagement start with paid discovery?
Because a specification written before anyone has examined the data, the existing systems and the real constraint is usually wrong in ways that surface around month three. Discovery produces an architecture, a scoped plan and an estimate we can stand behind. You own that output whether or not you continue.
What exactly do I get from discovery?
A system design with the expensive-to-reverse decisions identified and justified, a plan broken into phases that each ship something usable, and a real estimate. It frequently recommends something different from what was originally asked for, which is its most valuable and least comfortable outcome.
Do you work on a fixed price?
For well-understood builds after discovery, yes. Not against an unvalidated specification, because that forces padding into the estimate and turns every discovered requirement into a negotiation instead of a decision. Exploratory work is time-based, which is honest about where the uncertainty actually sits.
How long does a typical engagement take?
Discovery runs one to two weeks. A first working slice reaches real users or real data in three to six weeks after that. Beyond the first slice, delivery continues in short cycles for as long as the work justifies it, with each cycle producing something demonstrable.
Why are there no case studies on this page?
Because we have not completed engagements we can write up honestly. Publishing invented case studies with fabricated metrics is a claim a prospective client can check, and it is the most common thing agency sites get wrong. Real ones will appear with actual numbers and their measurement windows.
Who actually does the work?
The person who does the engineering leads the engagement, from discovery through handover. Work is not handed from a salesperson to a delivery team you have not met. Where a skill is needed that we do not have, we say so and either bring in someone specific or decline.
What happens if the project needs to change direction?
That is expected rather than exceptional, which is why delivery runs in short cycles with something demonstrable at the end of each. A change of direction discovered in week five is cheap. The arrangement that makes it expensive is a fixed scope agreed before anyone had evidence.
Who owns the code?
You do, assigned on payment. That clause does real work rather than restating a default, because Indian copyright law vests authorship with the creator absent an agreement. It should also be explicit about pre-existing components and any open-source licences travelling with them.
What happens when the engagement ends?
You receive documented code, deployment pipelines and runbooks your own team can operate without us. Documentation is written while context is fresh rather than assembled at handover, and more than one person holds working knowledge of anything critical, so a departure is an inconvenience rather than a crisis.
Can you work with our existing engineering team?
Yes, and that is frequently the better arrangement. Changes arrive as pull requests against your repository with the reasoning in the description, reviewed by your people on your terms. What does not work is being handed a specification with no ability to question it.
What work do you decline?
Staff augmentation against a specification written elsewhere, fixed-price contracts against unvalidated specifications, and any brief whose goal is volume of pages or content without a corresponding claim to being useful. That last one carries genuine penalty risk at the domain level.
How do we start?
Tell us what is currently not working, what you have already tried, and what would count as success. Those three answers are usually enough for us to say whether this is work we should take and roughly what it involves — and if we are not the right fit, we say so then.
Bring us the constraint
Tell us what is currently not working, what you have tried, and what would count as success. That is enough for us to say whether this is work we should take.