How a 10-second habit became a product idea — and what I learned building it.
Order food in India today and you're doing mental math. Zomato or Swiggy? Same restaurant, different prices, different coupons, different delivery fees. The user has to open two apps, compare totals, factor in wallet credits — all before they've even decided what to eat.
This isn't a rare edge case. Every delivery order triggers this friction. It's a 30–60 second tax on a decision that should take 5 seconds.
"Why am I doing price research just to order biryani?"
— A real thing I said to myself that turned into this productSwitch between two apps, apply coupons mentally, estimate delivery fees, compare total prices — for every single order.
See the final price side-by-side. One glance. No math. Pick the cheaper option and order. Done.
Before writing a line of code, I mapped three structurally different approaches. Each had a different product surface, technical risk profile, and growth ceiling. Here's how I evaluated them:
Inject a comparison widget inside Zomato/Swiggy pages. Minimal UI, contextual, zero context switch.
Dropped — API wallsDedicated search interface that pulls prices from both platforms and shows a side-by-side breakdown. Platform-independent.
✓ Chosen — Most ViableSend "pizza near me" to a bot, get a comparison back. Low friction, familiar channel.
Dropped — High ops costThe browser extension was elegant but brittle — Zomato and Swiggy actively resist scraping. The bot was delightful but required backend infrastructure and real-time data that wasn't realistic at this stage. A standalone web app was the smallest viable surface to prove the core value.
Talked to 7 people who order food regularly. Asked them: how often do you compare platforms before ordering? 6 of 7 said "always" or "sometimes". None had a good solution. That was enough signal.
The hardest part wasn't UI — it was data. Neither Zomato nor Swiggy offers a public price API. I explored official APIs (restricted), unofficial scrapers (fragile), and mock data with real UX flows (viable for MVP). Started with mock data, built real UI on top, planned real integration as V2.
Built the search, comparison table, and price breakdown components. Focused on scanability — users should be able to make the decision in under 3 seconds of looking at the screen. Color-coded delta, sorted by total cost, platform logos for instant recognition.
Showed it to 5 people. Biggest feedback: "I want to see the discount applied, not just the base price." That forced me to rethink the data model — I needed to track promo codes, platform discounts, and delivery fees separately before surfacing a final number. Rebuilt the calculation logic around this.
The product works as a functional proof of concept. The comparison flow is complete, the UI is clean, and the data architecture is ready to connect to a real API. It's not launched — but it's built with the intent to launch.
Every tech decision was made around one constraint: this needs to be easy to swap out when real data arrives.
The comparison card, price breakdown, and search input are all independent components. Swapping the data source doesn't touch the UI layer. This was intentional from day one.
A single fetchPrices() function is the only thing that knows about the data source. The rest of the app is unaware whether it's talking to a mock or a live API.
Running entirely client-side. When real API keys are needed, a lightweight Node proxy will be added — but the frontend won't change. Zero premature infrastructure.
Each price entry stores base price, delivery fee, platform discount, coupon, and final total separately. This lets the UI show transparency — not just the bottom line.
The comparison itself isn't the product. The trust in the comparison number is the product. If users doubt the accuracy of the price shown, they'll still open both apps. Transparency in how you calculate the total is what makes the product worth using.
Starting with user interviews before touching code. It prevented me from building features nobody asked for.
Abstracting the data layer early. It kept the frontend clean and made pivoting the data source painless.
Mapping multiple approaches before picking one. I avoided two dead-end paths that would've wasted weeks.
Designing for the 3-second decision. Every layout choice was measured against that benchmark.
Spent too long on polish before testing with real users. Should have shown a rough prototype at Week 1, not Week 4.
Underestimated how much the data model would drive UI decisions. Should have defined the data shape before designing components.
No defined success metric from the start. "Users should choose faster" is too vague — should have been "users make a decision in under 3 seconds on first visit."