Sharp by subtraction.
Pruning Labs is a software engineering studio headquartered in Kolkata, India. Founded by engineers from IIT Kharagpur and IIT Guwahati, we build production AI systems, intelligent workflow automation, and custom software - and we take a deliberately small number of projects at a time so that the engineers who scope the architecture are the ones who write and ship it.
Why the name
Pruning is a subtractive discipline. You do not make a tree healthier by adding branches; you make it healthier by removing the ones taking energy from the rest. Software systems fail the same way - not from a missing feature, but from twelve years of accumulated things nobody removed.
So the first question we ask on every engagement is not what to build. It is what can be deleted. Roughly a third of what a discovery uncovers turns out to need removal rather than replacement, and that part is free to run and impossible to break.
Who we are
Pruning Labs was founded by three engineers who still build every system. Manish Meena (IIT Kharagpur & IIT Guwahati), co-founder and principal engineer, owns technical architecture across every engagement and writes the studio’s engineering notes. Deepak Mardi (IIT Kharagpur), co-founder and full-stack engineer, builds the operator consoles and customer surfaces and holds the performance budgets. Shubham Choudhary (IIT Kharagpur), co-founder and head of growth, runs discovery and scoping - including the calls that end with a recommendation not to hire us.
How we are set up
- Engineers only, founder-led. No outsourced delivery layer, no bench being trained on your budget. The people in your architecture review are the ones shipping the pull requests.
- Few projects at a time. We turn work down. It is the only way start dates stay real and the quality bar stays where we want it.
- Fixed scope, written criteria. Acceptance criteria agreed up front, weekly demos measured against them.
- You own everything. Repository, infrastructure definitions, runbook, and an architecture document explaining the trade-offs - including the ones we would revisit.
What we believe about AI systems
The interesting engineering in 2026 is not the model. It is the boundary around it: what is retrieved, what a tool is allowed to do, what happens on a low-confidence answer, and how anyone proves the system is still correct after three prompt changes.
We treat a language model as one non-deterministic component inside an otherwise deterministic system. Everything that touches money, health, or legal state is validated by ordinary code before it leaves the process. That is not conservatism; it is what makes an AI system shippable in a regulated environment at all.
What we will tell you honestly
- When the problem does not need custom software. Off-the-shelf plus a careful process change beats a build more often than a studio has any commercial incentive to admit.
- When AI is the wrong tool. A rules engine that is right every time beats a model that is right most of the time, whenever the rules are actually knowable.
- When we are not the right studio. If the work needs a large team, twenty-four-hour coverage, or a specialism we do not have, we will say so on the first call.
Where we are
Kolkata, West Bengal, working with clients across India and internationally. See what we have built or how we work.