Product Development

The ugliest app that farmers loved

Priya's first real app was ugly. The colors were wrong. The fonts were inconsistent. The "Add Produce" button sometimes disappeared on older phones. The search didn't work if you typed in Hindi. One screen had a typo that said "Oder" instead of "Order."

But here's what happened: within three weeks, 47 farmers were using it daily. Not because it was beautiful. Because when Harish uncle in Dwarahat listed his 500 kg of rajma on the app at 8 AM, by 10 AM he had three buyers competing for it. He sold at ₹95/kg instead of the ₹65/kg the mandi trader was offering.

Nobody cared about the typo. Nobody complained about the colors. They cared that the app solved their problem.

"Priya beti, ye phone wali cheez bahut kaam ki hai," Harish uncle told her. "Fix the Hindi typing thing though."

This is the most important lesson in product development: solve the real problem first, polish later. Too many founders spend months perfecting a product nobody wants. Priya spent three weeks building something ugly that people actually used.

Before you write a single line of code: talk to users

Priya didn't build the app based on what she thought farmers needed. She talked to 50 farmers before her developer wrote a single line of code.

Not surveys. Not Google Forms. Face-to-face conversations, sitting on charpais in orchards and at mandi gates at 5 AM.

What she asked:

• "Walk me through what happens from the time your crop is ready until you get paid."
• "What's the most frustrating part of selling your produce?"
• "If you could change one thing about how you sell, what would it be?"
• "Do you use a smartphone? WhatsApp? Have you ever bought or sold anything online?"
• "If there was an app that showed you today's prices from different buyers, would you use it?"

What she learned (that she wouldn't have guessed):

1. Most farmers didn't care about getting the best price. They cared about getting a fair price reliably. Reliability mattered more than optimization.
2. Payment timing was as important as payment amount. A buyer who paid in 3 days was worth more than a buyer who paid 20% more but took 3 weeks.
3. Many farmers were not literate in English. The entire app needed to work in Hindi and with voice notes.
4. Trust was everything. Farmers wouldn't transact with an anonymous buyer. They needed to see the buyer's name, photo, and past transaction history.
5. Smartphone usage was high, but data was expensive. The app needed to work on slow 2G connections and consume minimal data.

These five insights shaped every product decision. None of them came from a whiteboard in a co-working space. They came from sitting with farmers.

Rule of thumb: Talk to at least 30-50 potential users before building anything. Not people who will politely nod. People who actually have the problem you're trying to solve. If you can't find 50 people with the problem, the problem might not be big enough.

MVP thinking: what's the minimum that solves the core problem?

We introduced MVP in the last chapter. Let's go deeper.

The word "minimum" is the hard part. Every founder wants to add one more feature. "What if we also add..." is the most dangerous sentence in product development.

Priya's core problem: farmers can't find buyers and don't know current prices.

Her MVP needed exactly three things:

1. Farmers can list what they have (crop type, quantity, location, asking price)
2. Buyers can browse listings and express interest
3. Both get notified when there's a match

That's it. No payment processing. No logistics coordination. No quality grading. No review system. No chat. No analytics dashboard.

All those features are useful. None of them are necessary to test the core assumption: will farmers and buyers actually transact through a digital platform?

How to decide what goes into your MVP:

Ask yourself: "If the product could only do ONE thing, what would that one thing be?"

Build that. Ship it. See what happens.

Then ask users: "What's the one thing you wish this could do that it can't?"

Build that next.

This is how you avoid building features nobody asked for.

Build, Test, Iterate

Product development isn't a straight line. It's a loop.

Build something small
    → Put it in users' hands
        → Watch what they do (not what they say)
            → Fix what's broken
                → Add what's missing
                    → Repeat

Priya's iteration cycle looked like this:

Week 1-3: Built MVP with freelance developer. Three screens, basic functionality.

Week 4: Gave it to 23 farmers from her WhatsApp group. Sat with 5 of them while they used it. Watched where they got confused, what they tapped first, where they gave up.

Week 5-6: Fixed the top 3 pain points:

• Hindi input wasn't working → fixed
• Listing produce took 8 taps → reduced to 4
• No way to see if a buyer was genuine → added buyer verification badge

Week 7-8: Expanded to 60 farmers. New problems emerged:

• Farmers in remote areas had bad connectivity → added offline mode that syncs when connected
• Buyers wanted to filter by location → added location filter

Week 9-12: Expanded to 150 farmers. The app stabilized. Transactions started happening without Priya's manual intervention.

Notice what she didn't do: she didn't spend 6 months building a perfect product in isolation. She shipped something rough in 3 weeks and improved it based on real usage.

The 80/20 of product development: 80% of your users will use 20% of your features. Find that 20% and make it excellent. Everything else can wait.

Product-Market Fit: how do you know when you have it?

Product-market fit (PMF) is the moment when your product clearly satisfies a strong market demand. It's the most important milestone for any startup.

How do you know you have it?

The simplest test (from Rahul Vohra of Superhuman): Ask your users, "How would you feel if you could no longer use this product?"

• If 40%+ say "Very disappointed" → you likely have PMF
• If less than 40% → you don't yet

Other signs of product-market fit:

• Users come back without being reminded (organic retention)
• Users tell other people about it (organic growth)
• You're struggling to keep up with demand rather than struggling to find users
• Usage metrics go up and to the right, week after week
• You start getting inbound interest from buyers/partners you didn't contact

Signs you do NOT have PMF:

• You have to personally convince every user to try the product
• Users sign up but rarely come back
• People say "nice idea" but don't actually use it
• Your best growth channel is paid ads (if you have to pay for every user, something is off)
• You're adding features hoping something will stick

Priya knew she had early PMF when farmers started calling her to complain that the app was down. If they didn't care about the product, they wouldn't bother complaining. Angry users who want the product to work are a better sign than polite users who don't care.

User feedback: gathering and prioritizing

Once your product is in users' hands, feedback will come — sometimes too much of it. The challenge is figuring out what to act on.

How to gather feedback:

1. Watch users, don't just ask them. People say one thing and do another. Priya learned more by watching a farmer use the app for 5 minutes than by asking him what features he wanted.

2. Track behavior data. Where do users drop off? Which features do they use most? Which screens do they skip? Simple analytics tools (even basic Google Analytics) tell you what's actually happening.

3. Talk to churned users. People who stopped using your product are more valuable than active users for understanding problems. "Why did you stop?" is the most important question.

4. Talk to power users. Your top 10% of users know things about your product that you don't. They've found workarounds, edge cases, and use cases you never imagined.

5. Ignore feature requests from people who don't use your product. Everyone has opinions. Only opinions from actual users matter.

How to prioritize feedback:

Not all feedback is equal. Use this framework:

Priya made a simple Google Sheet: one column for the feedback, one for how many users mentioned it, one for severity (blocks core use / annoying / nice-to-have). Every week, she and her developer picked the top 3 items and fixed them. Simple system, but it worked.

Tech decisions for non-technical founders

Priya studied computer science in college, so she could understand the technical side. But many founders aren't technical — and that's fine. You don't need to code. You need to make good decisions about technology.

Key questions every non-technical founder should be able to answer:

1. What platform? Mobile app (Android, iOS, or both)? Web app? WhatsApp bot? The answer depends on your users. Priya's farmers were mostly Android users with low-end phones, so Android-first made sense.

2. Native app or cross-platform? Native (separate code for Android and iOS) gives better performance. Cross-platform (React Native, Flutter) is faster and cheaper to build. For most early-stage startups, cross-platform is the right call.

3. Where does data live? Cloud (AWS, Google Cloud, Azure) is standard for startups. Don't build your own servers. The cost of cloud is tiny compared to the cost of your server going down.

4. How do you handle payments? Use existing payment gateways (Razorpay, Cashfree, PhonePe for Business). Never build your own payment system.

You don't need to understand the code. You need to understand the trade-offs.

Hiring developers vs outsourcing vs no-code

This is one of the most consequential decisions for a non-technical founder.

Option 1: Hire a full-time developer (or find a technical co-founder)

Best for: Products where technology IS the core business (which is most tech startups).

Pros: They understand your product deeply. They can iterate fast. They're committed.

Cons: Expensive (a decent developer costs ₹6-15 lakh/year). You need to find, evaluate, and manage them.

Option 2: Outsource to a development agency or freelancers

Best for: Building a v1 to test the concept before hiring.

Pros: Cheaper upfront. You get a finished product without committing to salaries.

Cons: They don't understand your users like you do. Communication overhead. Quality varies wildly. They leave when the project ends, and you're stuck maintaining code you don't understand.

Priya used this for her v1 — a freelance developer for ₹2 lakh. It got the job done for testing. When she was ready to build v2, she hired a full-time developer.

Option 3: No-code / low-code tools

Best for: Non-tech businesses that need a simple digital presence or workflow.

Tools like Bubble, Glide, Adalo, or even Google Sheets + Zapier can build surprisingly functional products without writing code.

Pros: Fast, cheap, no developer needed.

Cons: Limited customization. Can feel generic. Hard to scale. Not suitable for complex, data-heavy products.

Ankita's approach: Ankita is not a tech person. Her D2C pahadi food brand runs on Shopify (no-code e-commerce), WhatsApp Business for customer communication, and a Google Sheet for inventory tracking. Total "tech" cost: ₹2,000/month for Shopify. She doesn't need a developer. Her product is the food, not the website.

Design matters — but functionality first

A beautiful product that doesn't work is useless. An ugly product that solves a real problem will get used.

That said, design isn't just about beauty. Good design means:

• Users can figure out what to do without instructions. If you need a tutorial, your design has failed.
• The most important action is the most prominent. On Priya's app, the "List Produce" button is the biggest element on the farmer's home screen.
• It works on the worst device your users have. Priya tested on a ₹5,000 Redmi phone on a 2G connection. If it worked there, it worked everywhere.
• Consistency. Same colors, same button styles, same patterns everywhere. Users learn the product once and navigate instinctively.

When to invest in design:

• After you have product-market fit. Before PMF, functionality matters more.
• When users are confused by your interface (watch them struggle → fix the design)
• When you're competing for users who have alternatives (better design = trust = conversions)

Ankita's product development journey

Not all product development is about apps. Ankita's pahadi food brand went through its own product development cycle:

Phase 1: Kitchen experiments Ankita started making pahadi chutneys (bhang ki chutney, til ki chutney, kafal jam) in her mother's kitchen in Almora. She gave samples to friends and family. "This is amazing, you should sell this."

Phase 2: Testing with real customers She made 50 jars and sold them at a local Haldwani market stall. Some sold out. Some didn't move. She learned:

• Bhang ki chutney was the bestseller (unique, not available elsewhere)
• The 500g jar was too big — people wanted to try smaller quantities first
• Her label looked handmade (because it was) — buyers at higher price points wanted professional packaging

Phase 3: Standardized recipe The hardest part of food product development: making it taste exactly the same every time. When Ankita made 10 jars, the taste was consistent. When she made 100, it varied. She spent two months documenting exact measurements, temperatures, and processes.

Phase 4: Shelf stability Fresh chutney lasts 2 weeks. For e-commerce, she needed 6-month shelf life. This meant:

• Working with a food technologist (found through FSSAI contacts)
• Testing preservative options (she chose natural preservatives to maintain the "pahadi" positioning)
• Investing in proper vacuum-sealed packaging

Phase 5: D2C launch Only after all of this did she launch on her Shopify website. The product had been tested, standardized, and validated by real customers over 8 months.

The lesson: whether your product is an app or a chutney, the process is the same. Build → Test → Improve → Repeat. Don't scale until the product is right.

When to add features vs when to say no

The hardest word in product development is "no."

Every user has a suggestion. Every investor has an opinion. Your team has ideas. The temptation is to build everything.

The cost of saying yes:

Every new feature:

• Takes time to build (which means other things don't get built)
• Takes time to maintain (forever)
• Makes the product more complex for ALL users
• Creates more things that can break
• Dilutes your focus

How to decide:

1. Does this help the core use case? Priya's core use case: farmers selling produce to buyers. A weather forecast feature is cool but doesn't help the core use case. A better price comparison tool does.

2. Have multiple users asked for it? One user's request is an anecdote. Fifty users' request is data.

3. Can you build it without derailing your current priorities? If the top priority is fixing the payment flow, a new "farmer profile" feature can wait.

4. Will it help you grow? Some features don't make existing users happier but attract new users. Referral features, sharing features, integrations with existing tools — these can drive growth.

Priya's "no" list:

• Chat between farmers (not the core use case — use WhatsApp)
• Weather forecasts (useful but other apps do this already)
• Farmer loans (important problem but completely different business)
• English language support (her users don't need it)

Priya's "yes" list:

• Hindi voice input for produce listings (her users struggle with typing)
• Photo upload for produce (buyers want to see what they're buying)
• Payment tracking (when did the buyer pay? how much is pending?)
• Repeat order functionality (buyers ordering the same thing every week)

Key takeaways

1. Build something that solves the real problem. Polish comes later.
2. Talk to 30-50 users before building. Watch them, don't just ask them.
3. Your MVP should do one thing well, not ten things badly.
4. Build → Test → Iterate. Ship fast, learn fast.
5. Product-market fit means users come back without being asked. "How would you feel if this disappeared?" is the test.
6. Non-technical founders: you don't need to code, but you need to make good tech decisions.
7. Design matters, but only after functionality works.
8. Product development for physical products (Ankita's chutney) follows the same loop as digital products.
9. Say "no" to most feature requests. The cost of complexity is real.

Priya's app now has 500 farmers and 40 institutional buyers. Transactions are growing. But an investor asks her: "What are your metrics?" She has app downloads. But DAU? Retention? Cohort analysis? She has no idea. In the next chapter, we learn the numbers that actually matter.