Building an Agriculture Knowledge Platform for Nepal

Good farming knowledge in Nepal exists. It's just scattered across PDFs, government pages, radio programs and the memory of experienced farmers. I've been building a platform to make it findable, in Nepali, on a weak connection.

This project changed how I think about content-heavy apps more than anything else I've worked on. Most of my work is dashboards and business tools, where users sit in front of a screen with decent internet. Here, the user might be standing in a field with one bar of signal on a budget Android phone, trying to figure out why the leaves on their tomato plants are curling.

Every design and technical decision followed from that picture.

The problem

When a farmer has a question, like when to plant a certain crop at their altitude, what a particular pest is, or how much fertilizer to use, the answers are often out there. But they tend to be:

• In the wrong language. A lot of good material is in English, or in formal, technical Nepali that's hard to follow.
• In the wrong format. Long PDFs that are slow to download and painful to read on a phone.
• Not specific enough. Advice for "Nepal" doesn't help much when the Terai, the hills and the mountains have completely different climates and seasons.
• Not searchable. You have to know where to look before you can find anything.

The goal was not to create new agricultural knowledge. It was to organize existing, trustworthy knowledge so people can actually reach it.

Who it's for

I wrote down three people before designing anything:

• A farmer in the hills with a mid-range Android phone, comfortable reading Nepali, less comfortable with English, using mobile data carefully.
• A younger family member who helps their parents look things up and is happy to search in romanized Nepali or English.
• An agriculture extension worker or volunteer who wants to share specific guidance with farmers they support.

All three needed the same content in different ways. The farmer needs simple, direct answers. The younger user needs good search. The extension worker needs shareable links to specific pages.

Content model first

Before any UI, I spent a long time on how the knowledge itself should be structured. This was the most important decision in the project.

The core entities:

• Crop. Rice, maize, tomato, cardamom, and so on. Each with local names.
• Region or agro-climatic zone. Terai, hills, mountains, with the option to go more specific.
• Season and calendar. When to sow, transplant, and harvest, tied to region.
• Practice. Soil preparation, irrigation, fertilizing, harvesting, storage.
• Problem. Pests and diseases, with symptoms people can recognize.
• Source. Where the information came from, so every piece of advice is traceable.

The relationships matter more than the entities. A practice belongs to a crop and a region. A problem affects certain crops and is common in certain seasons. Modelling it this way means a farmer can start from "my crop" or from "this thing I'm seeing on my plants" and still end up at the same answer.

Content-heavy apps live or die on the content model. You can redesign a UI in a week. Restructuring thousands of pieces of content is a different kind of project.

The source field was non-negotiable. Farming advice that's wrong can cost a family a season's income. Every article shows where it came from.

Nepali first, not Nepali too

Nepali is the primary language. English is available, but the content is written for Nepali readers first, in plain, everyday language rather than formal textbook Nepali.

On the technical side, that meant:

• Fonts that render Devanagari well at small sizes, with enough line height that matras don't collide.
• Layouts tested with real Nepali text, which often runs longer than the English equivalent.
• Bikram Sambat months for seasonal calendars. Farmers plan by Baisakh and Asar, not April and June. Showing Gregorian months would make the calendar useless to the people it's for.

I covered the routing and dictionary setup in building a multilingual Next.js application. Getting the strings translated was the easy part. Getting the tone right took several rounds.

Search that matches how people type

Search turned out to be the hardest UX problem. People don't search the way the content is written. The same crop can have different local names. Someone might type in Devanagari, in romanized Nepali, or in English, and spell things in several ways.

What helped:

• Synonyms and alternate names stored on each crop and problem, including local and romanized names.
• PostgreSQL full-text search for the main index, with trigram matching to forgive typos and spelling variants.
• Browse paths alongside search. Not everyone wants to type. Picking a crop, then a region, then a topic works well on a phone and avoids the spelling problem entirely.
• Symptom-based entry. "Yellow leaves," "holes in leaves," "rotting fruit." Farmers often know what they see, not what it's called.

Built for slow networks

This is where the project pushed me hardest. A typical page has to be useful on a slow, unstable connection, and it has to respect the user's data.

The decisions that made the biggest difference:

• Server-rendered pages. Content arrives as HTML, readable before any JavaScript loads. Most pages need very little client-side JavaScript at all.
• Text first, images optional. Images are compressed, lazy-loaded, and sized for phones. Where an image isn't essential, the text stands on its own.
• No heavy UI libraries. Every dependency had to justify its weight.
• Caching aggressively. Agricultural content doesn't change minute to minute, so pages can be cached at the edge and in the browser.
• Offline reading. Using the same service worker approach from my portfolio PWA, pages someone has visited stay available offline. A farmer can look something up at home on Wi-Fi and read it again in the field.

I test on a throttled connection and a cheap Android phone throughout development, not at the end. The number of things that feel fine on my laptop and fall apart on a real device is always humbling.

Designing for clarity

The visual design is deliberately plain. Large readable type. High contrast, because phones get used outdoors in bright sunlight. One clear primary action per screen. Short sections with clear headings, so people can skim to the step they need.

Articles follow a consistent structure: what this is, when it applies, what to do step by step, what to watch out for, and where the information came from. Consistency means people learn the layout once and can find their way through any page.

I also avoided anything that looks like an app trying to keep you engaged. No streaks, no notifications nagging people to come back. The platform's job is to answer a question and get out of the way.

What was harder than expected

• Content takes longer than code. Structuring, simplifying and checking information was much more work than building the features.
• Regional variation is endless. Every time I thought a piece of advice was general, it turned out to depend on altitude or season.
• Plain language is a skill. Turning technical guidance into something clear without making it wrong takes careful editing and review.
• Trust has to be designed. Showing sources, dating content and making corrections visible matter as much as any feature.

Where I've landed

Building for farmers in Nepal made me a better developer for everyone. Designing for weak networks, low-end phones and Nepali readers forced me to cut everything that wasn't necessary, and the result is faster and clearer for every user, including the ones on fibre in Kathmandu.

If you're thinking about building something in this space, start with the content model and the real conditions your users live in. I made a longer case for this kind of work in building software for Nepal. The technology is the easy part.