Part 1 of 2: the premise and the problem. Part 2 is the architecture deep-dive, how I cut the reply time from 30 seconds to 5.
The problem I kept having
I order a lot of packaged snacks off Swiggy Instamart. I almost never check the nutrition label before adding something to cart, not because I don't care, but because the label is a photo of tiny text three taps deep. By the time I find it, I've already decided I want the thing.
I built it end to end (Python, FastAPI, Redis, the Telegram Bot API) as a side project, without a team. It's still an early, working prototype, not a polished product. A few weeks in, it got approved into Swiggy's Builders Club, their official program for developers building on top of their platform (I posted about the approval on LinkedIn). That was the point where "side project" started feeling like something worth writing up properly.
The JTBD, in one line: see what you're eating before you buy it, without leaving your chat.
Demo Video:
Why Telegram, why solo
No app to install, no account to create: if you can message a bot, you can use it. That constraint also forced the scope down to something a solo developer could actually ship: no UI to design beyond a chat card, no app store review, no separate onboarding flow.
I built it end to end (Python, FastAPI, Redis, the Telegram Bot API) as a side project, without a team. It's still an early, working prototype, not a polished product. A few weeks in, it got approved into Swiggy's Builders Club, their official program for developers building on top of their platform. That was the point where "side project" started feeling like something worth writing up properly.
The part that wasn't obvious going in
The hard part of this project was never "call an API and show the result." Swiggy's product search doesn't return nutrition data at all, just name, brand, price, and a stock flag. Every score has to be assembled from other sources: external food databases, web search, and, when nothing structured exists, an LLM taking its best guess.
That's a very different engineering problem than a CRUD bot. It means deciding what to trust when your sources disagree or don't exist caching a verified fact very differently from an AI's best guess and, because "packaged snacks" here means Indian packaged snacks, realizing partway through that the standard European nutrition-scoring formula (Nutri-Score) doesn't actually discriminate well on the products people here are buying, and needs tuning
The first working version of all this took ~30 seconds to reply. In a chat interface, that's dead on arrival.
What's next
Part 2 is the architecture post: how the reply time came down to 5-8 seconds, why the caching strategy encodes confidence and not just staleness, and what it took to localize a food-scoring formula for a market it wasn't built for. If any of that sounds familiar (building on an API that doesn't give you the data you actually need, or caching LLM output you don't fully trust), that post is for you.
Drop a comment if you want the Telegram link to try it, or if you've hit a similar "the API doesn't have the field I need" wall on something you're building. Curious what workarounds other people have landed on. (Code's closed-source for now while this is still prototype-stage; happy to answer questions about the approach in the comments.)
A working prototype, built solo with Python, FastAPI, Redis, and the Telegram Bot API. Currently part of Swiggy's Builders Club.
Top comments (0)