Most agritech companies get pitched with a clean origin story: founders spot a market gap, build a product, raise money, scale. Thoplo Machine's story didn't happen that way, and I think the messier version is more useful to anyone actually trying to build something in Nepal's tech ecosystem.
The Partnership That Started It
I met Krishna Chaudhary at a point where we were working on completely different problems. He came from an electronics background — sensors, circuits, hardware design, the physical layer of any IoT system. I came from the computer science side — software, systems, the layer that turns raw sensor data into something a person can actually use and act on.
Neither of us set out to start a company. What we had was a complementary skill gap: he could build the hardware that measures what's happening in the physical world, and I could build the software that makes that data useful.
That combination — one person who understands electronics and one who understands software — turned out to be the exact team composition agritech hardware needs.
Neither of us fully appreciated that at the time.
The Erasmus Mundus Project That Became the First Prototype
The real starting point wasn't a business plan — it was an academic one. We got involved in a project under the Erasmus Mundus collaboration framework focused on greenhouse monitoring, working alongside Kantipur Engineering College. The brief was straightforward on paper: build a system that could monitor greenhouse conditions and help growers make better decisions about irrigation, temperature, and humidity.
In practice, it meant building an entire IoT stack from close to nothing:
- Sensor hardware that could survive real greenhouse conditions (heat, humidity, dust)
- A way to get that data off the hardware and somewhere useful
- A software layer that could turn raw temperature and moisture readings into decisions a farmer could actually act on
This is where Krishna and I first worked as a real team rather than two people solving adjacent problems. He handled the sensor design and hardware reliability. I handled the data pipeline and the interface. Kantipur Engineering College gave the project an academic home and access to a testing environment we wouldn't have had otherwise.
What came out of that project wasn't a company yet — it was proof. Proof that the two of us, working together, could take an idea from concept to a working prototype that solved a real, physical problem for a real grower.
From Academic Project to Actual Company
The gap between "working prototype in a research context" and "product a farmer will actually pay for and rely on" is enormous, and this is where most academic IoT projects die. A few things had to change before Thoplo Machine became a real business rather than a research output:
- Durability over elegance. A sensor that works perfectly in a controlled academic test environment often fails within weeks in an actual greenhouse — dust, power fluctuations, and humidity are unforgiving in ways a lab setting doesn't prepare you for.
- Cost had to come down dramatically. Research-grade components are not commercially viable at the price a smallholder or mid-size greenhouse operator in Nepal can pay.
- The software had to disappear into the background. Growers don't want a dashboard full of raw sensor charts — they want a clear signal: irrigate now, don't irrigate, temperature is trending toward a problem.
- Trust had to be earned individually, one grower at a time. Unlike enterprise software sales, agritech in Nepal is a relationship-first market.
No amount of technical sophistication replaces sitting with a grower, understanding their actual operation, and proving the system works over an actual growing season before they trust it with their livelihood.
Lessons From Building Agritech in Nepal Specifically
Building hardware-software products in Nepal comes with constraints that don't show up in a typical startup playbook written for Silicon Valley or even for other South Asian markets.
Hardware supply chains are a real bottleneck. Sourcing reliable components locally is limited, and importing hardware brings customs delays, duties, and unpredictable timelines that directly affect how fast you can iterate.
Rural connectivity assumptions will break your architecture if you don't plan for them. A system designed assuming constant, reliable internet will fail in the exact environments agritech is meant to serve.
Building for intermittent connectivity — local data buffering, graceful degradation, sync-when-available patterns — isn't an edge case in Nepal's agritech context, it's the default condition to design around.
Academic and institutional partnerships are a legitimate, underused path to your first real prototype. Kantipur Engineering College gave us testing infrastructure, credibility, and a collaborative environment that would have taken significant capital to replicate independently.
The right co-founder isn't always someone from your own discipline. Krishna and I didn't succeed because we thought the same way — we succeeded because we didn't. An electronics expert paired with a software-proficient partner covers the two halves of an IoT product that almost never live in one person's skillset.
Where Thoplo Machine Stands Today
What began as a greenhouse monitoring research project is now a working agritech venture built around the same core insight that started it:
Growers don't need more data, they need clearer decisions — delivered through hardware that survives real field conditions and software that respects how intermittent rural connectivity actually works.
The company exists because of a partnership that combined two different technical disciplines, an academic collaboration that gave us room to fail safely before customers were involved, and a willingness to rebuild almost every early assumption once real greenhouse conditions replaced lab conditions.
If you're building a hardware-software company in Nepal, or trying to figure out whether an academic or institutional partnership could get you to your first working prototype faster than going it alone, I'm happy to talk through what worked and what we'd do differently.
Book a free 30-minute consultation if you're working through a similar hardware-software venture and want a sounding board.