What Feeding India Taught Me About Engineering Under Constraints
What leading engineering at an NGO taught me about constraints, field research, and small experiments.
Apr 23, 2025
Leading engineering at Feeding India taught me to treat constraints as design input. Our users were the NGOs and schools receiving meals, the vendors supplying them, and the students eating them. Their needs were immediate; our engineering budget was not.
I joined in November 2022 as the first engineering lead. The goal was to use data and software to improve meal distribution across the NGO network. We had one full-time engineer and a limited budget, so every new system had to earn its place.
Three lessons from the work
1. Spend constraints force cleaner choices
At Zomato, starting a project, hiring for it, provisioning infra, or launching a campaign usually meant submitting the right request. At Feeding India, every rupee mattered. We initially relied on third-party integrations for identity verification, SMS verification, and email communication.
We soon realized the NGO partnership lifecycle could be digitized, reducing data discrepancies and repeated manual work. By renegotiating vendor contracts and using open-source solutions where they fit, we simplified workflows without paying for software we did not need.
What changed: We stopped treating every vendor integration as permanent infrastructure and asked whether it was still the cheapest reliable path.
2. Observe the work, not only the dashboard
The people affected by the system were not the people writing requirements. We had to see the work firsthand.
Spending weekends on-site at meal distributions revealed painful inefficiencies. For instance, our initial third-party face based attendance system took about 8 seconds per child, resulting in nearly half an hour of waiting for a school of 200 kids, particularly difficult in India's harsh summers. Recognizing this unacceptable latency, we brought the solution entirely in-house, significantly improving performance and ensuring better control for troubleshooting. Our in house solution takes under 2 seconds in recognising a child (as opposed to the 8 seconds by the third-party system). This felt insanely fast. The fastest attendance recorded was under 400ms.
What changed: A dashboard would have shown latency. Being at the distribution site showed us that latency meant children waiting in the heat.
3. Pilot before you scale
Limited resources made it risky to spend months on an untested solution. We started with a small prototype, tested it with one partner NGO, and expanded only after each version held up.
Our facial-recognition system began as an office prototype. After testing it with a partner NGO, we benchmarked it against the third-party system and improved it over five development cycles. Error rates fell by 60%, and the model now updates monthly without manual intervention.
What changed: Each pilot gave us a smaller failure surface and better evidence for the next investment.
The lessons followed me to Zomato. We rewrote and open-sourced PDF generation services, reducing costs by 90%. We used volunteer “tech champions” to build ownership around critical metrics and piloted micro-frontend rollouts in peripheral markets before expanding them.
Feeding India changed the order in which I make decisions: observe the work, identify the constraint, run the smallest useful test, and only then invest in scale. That sequence works whether the system is distributing meals or serving millions of users.