How two weekend warriors built a ₹1,000 device that solved a problem Silicon Valley hadn't noticed.
The Problem Nobody Was Solving
It was 2012. Smartphones were becoming ubiquitous in Indian cities. Apps were the answer to everything. And yet, on a small dairy farm in Hubbali (Hubli), Karnataka, a friend and colleague of mine was drowning in paper registers.
His family farm had around 30–50 animals - buffaloes and cows across different breeds. Every day, workers would milk the animals, note down yields on scraps of paper (if at all), and try to remember which cow was due for vaccination, which one had calved recently, and when the vet had last visited. The paper registers were incomplete, illegible, and often lost. Correlating milk yield to a specific breed or animal? Forget it.
Girish Desai came to me with a simple ask: "How can technology help us capture this data directly from the farm and make an attempt to solve this problem?"
The obvious answer in 2012 was - "Get a smartphone app."
But the obvious answer was wrong.
Why We Didn't Build an App
Here's what the app-for-everything crowd didn't understand about a working dairy farm in rural Karnataka:
The operators were low-literate daily wage workers. They could recognize animals by sight, measure milk by hand with remarkable accuracy, and manage complex farm routines - but navigating a smartphone interface with its tiny icons, English text, and multi-step workflows was not realistic.
Smartphones were distracting and multi-purpose. We wanted a tool that could only do one thing: capture farm data. Not browse the internet, not play games, not make calls. A single-purpose device that workers couldn't misuse and farm owners could trust.
Infrastructure was unreliable. Internet connectivity was patchy. Power was intermittent. We needed something that could work both offline and online and transmit data when possible.
Cost mattered. Handing expensive smartphones to multiple farm workers wasn't practical. We needed something cheap, rugged, and replaceable.
So we decided to build our own Point of Interaction (POI) device from scratch.
What We Built (Over Weekends, in 2 Months)
The team was just the two of us (with a crucial assist):
Girish - my colleague and the farm owner who knew the domain inside out. He built the backend APIs and a dashboard to visualize incoming data.
Me - I designed and built the hardware: the POI device itself, its interface, UI/UX, and the firmware.
Girish's brother - contributed his CAD skills to design the enclosure once I'd worked out the component and PCB dimensions.
My background was in both software (professionally) and hardware (as a hobbyist), which turned out to be essential. This wasn't a project you could outsource to a contractor - it required intimate understanding of both the farm's workflow and the electronics. But honestly we were broke...JK.
The Hardware Stack
Brain: ATMEGA 328P microcontroller - cheap, well-documented, and I was quite familiar with its features (it runs the Arduino framework).
Input: A custom-built matrix keypad with icon-based overlays - an array of tactile switches with an I/O Extender (IO on the ATMEGA was sparse).
Animal ID: RFID reader. Each cow wore an RFID tag, eliminating manual ID entry entirely.
Display: Simple 16×2 LCD to show feedback and confirmations.
Audio: Piezo buzzer for prompts, confirmations and errors - crucial for guiding low-literate operators.
Communication: GSM module for Edge and SMS-based data transmission - the unsung hero of rural connectivity in 2012.
Power: LiPo 2000mAh battery charging over Mini USB.
Enclosure: And here's where it gets interesting...
The ISRO Connection (Yes, Really)
We needed a rugged enclosure that could survive farm conditions - dust, humidity, the occasional bump. I worked out the approximate dimensions and fitment requirements for all the boards and components. Girish's brother, skilled with CAD, took those rough specs and designed a proper enclosure to house everything securely.
But where do you get a one-off custom enclosure manufactured affordably?
Through Girish's connection, we found an acquaintance who was a vendor to ISRO (Indian Space Research Organisation), manufacturing parts using composite materials. When we explained our project, they offered to do a single production run for FREE.
So yes, our dairy farm data device was housed in space-grade composite materials. Sometimes the universe has a sense of humour.
Designing for Low-Literacy (The UX Challenge)
The interface was perhaps the most critical design decision. Our operators couldn't read English. Many couldn't read Kannada fluently either. Numbers were okay, but text-heavy menus were out.
We went with icon-based buttons:
Milk container - Record milk yield
Stethoscope icon - Veterinary visit / vaccination
Cow & Calf symbol - Calving / breeding cycle entry
We tested the icons with farm workers before finalising. Some icons we thought were obvious, weren't. The stethoscope icon went through three iterations before workers consistently recognised it. We also added a PLUS (+) symbol next to each icon so they could relate to the operation better.
The RFID Game-Changer
Here's where we eliminated the biggest source of potential error - animal identification.
Each cow on the farm wore an RFID tag. When the operator pressed a function button (say, milk recording), the device would enter RFID read mode and emit multiple beeps - an audio cue prompting the operator to tap the device against the cow's tag.
The operation was intuitive: one tap, beep-beep-beep, animal identified. No numbers to remember. No IDs to mis-key. The cow identified herself.
The workflow became:
- Press data type icon (milk / vet / calving)
- Hear the beeps → tap the cow's tag
- Enter value using numeric keypad
- Confirm
No menus. No scrolling. No text. Just icons, beeps, one tap, and numbers.
Why SMS Was Our Secret Weapon
In 2012, GSM coverage in rural Karnataka was surprisingly good. 3G data? Not so much. But SMS worked almost everywhere, was cheap, and didn't require a persistent internet connection.
Our device would:
- Collect data entries throughout the day
- Batch and send over EDGE when available
- Fall back to SMS messages to a fixed server number when EDGE failed
- Receive confirmation SMS back
On the server side, Girish built a simple backend that processed incoming HTTP requests and SMS messages, stored data in a database, and generated dashboards showing milk yield trends, vaccination schedules, and breeding cycles.
Was it elegant? No. Did it work reliably in conditions where "smart" solutions would have failed? Absolutely.
The Numbers
Prototype cost: Under ₹5,000 (retail components from multiple vendors)
Projected unit cost at scale: ₹500–1,000
Development time: ~8 weekends over 2 months
Operational life: 12 months as a proof of concept
Data points captured per session: daily milk yield per animal, animal identification and breed tracking, calving dates and breeding cycles, veterinary visits, vaccination records.
What We Learned
The project achieved what we set out to prove - a cheap, purpose-built device could capture farm data more reliably than paper or smartphone apps in a low-literacy, low-infrastructure environment.
For the months it operated, Girish finally had visibility into his herd's productivity. He could see which breeds were performing better, track health events against yield drops, and plan veterinary visits proactively.
Why It Didn't Scale
Life happened. We both had day jobs. The farm had other priorities. It was a proof of concept, and it proved the concept. Sometimes that's enough.
What I'd Do Differently With Today's Tech
ESP32 instead of Arduino - built-in WiFi/Bluetooth, more processing power,
similar price.
LoRa for connectivity - better range in rural areas, lower power (for the absolutely remote regions) terminating into either WiFi or cellular data. (TV White space based WiFi is also a possibility.)
Solar charging - remove dependency on mains power entirely.
Better backend - a proper cloud dashboard with alerts and analytics.
AI-assisted code - For better and faster output by utilizing AI generated code blocks. But more on that in my article on AI assisted coding.
But honestly? The core insight hasn't changed: the best technology is the technology that gets used. A ₹50,000 IoT solution that intimidates workers is worse than a ₹1,000 box they actually press buttons on.
Why I'm Writing This Now
India is in the middle of an AgriTech boom. Venture capital is pouring into startups promising to digitise farming with AI, IoT, drones, and blockchain. Some of these will succeed. Many will fail because they're building solutions for investors, not farmers.
In 2012, we didn't have a pitch deck or a term sheet. We had a friend with a problem and weekends to spare. We built something that worked - maybe not at scale, maybe not forever, but it worked.
India is a country of opportunities. Problems are everywhere - in your neighbour's shop, your relative's farm, your local school. You don't need permission or funding to start solving them. You don't need to wait for the perfect technology stack.
You need curiosity, persistence, and the willingness to be the first one.
Look around you. Find a problem. Build something. It might not change the world. But it might change someone's world. And that's enough to start.
This article is part of the "Blast from the Past" series (expect a couple more like this), where I revisit old projects and extract lessons for today. If you've built something similar - a scrappy solution to a local problem - I'd love to hear about it in the comments below.