DEV Community: Ravi

Mirchi & Mirabelle: every dish on this menu is two places that never met 🍲

Ravi — Tue, 11 Aug 2026 12:18:56 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing
Mirchi & Mirabelle is the landing page for a supper club that doesn't exist. It serves six courses, and every course is two places that have never met, put on one plate.

Disclaimer: I am not an expert JS developer. Just a guy with some thinking capacity and a lot of time to bother Claude to build something from that.

Demo:

🔗 Live: https://ravipurohit1991.github.io/MirchiMirabelle/
📦 Source: https://github.com/ravipurohit1991/MirchiMirabelle

Note: Code is completely written by Claude, the story and the dishes are mine :)

Motivation:

I was born in Jodhpur, grew up in Coimbatore and Tiruppur, spent ten years moving between Bordeaux, Metz, Poitiers, Toulouse and Grenoble, and now live in Copenhagen. Once a year I land in Kolkata, where my brother is.

For a long time I thought that made my food palette incoherent. It turns out it just makes the coincidences visible. Lets take beans for example: Rajasthan dries beans because nothing fresh survives the desert; Toulouse soaks beans overnight because that's how cassoulet works. Nobody copied anybody. Both places just looked at a dried bean and reached the same conclusion.

So the menu is built out of those collisions:

Course	Dish	Parents
I	Cassoulet de Sangri	Ker sangri, Marwar × cassoulet, Toulouse
II	Degree Coffee Canelé	Kumbakonam decoction × canelé bordelais
III	Gratin Dauphinois, Kongu Tadka	Grenoble × Coimbatore
IV	Rugbrød Baati	Dal baati × Danish rye
V	Mirabelle Phuchka	Kolkata street water × Lorraine plums
VI	Mishti Skyr	Bengal clay pot × Nordic straining

Underneath the menu is the part I actually enjoyed building: the pairing board. Five places, ten intersections, pick any two and the dish between them appears.

Halfway through writing those ten pairings I realised I wasn't inventing all of them.

Rajasthan's mirchi vada and Tamil Nadu's milagai bajji are the same chilli in the same batter, 1,800 km apart, neither borrowed.
Tamil pazhaya sadam and Bengali panta bhat are both last night's rice left in water overnight, and both regions will tell you it's the best breakfast in India.
France calls its best pastry viennoiserie, "the Viennese things." Denmark calls its best pastry wienerbrød, "Vienna bread." The rest of the world calls it Danish. Nobody involved is claiming it.
And France was in Bengal long before I got to France. Chandannagar flew the tricolour until 1950, an hour up the Hooghly from my brother's flat.

What I'd do next:

I want the pairing board to accept places it's never heard of. Right now it knows five, the five I have lived in; potentially allowing people to add their places.

There's a small thing at the bottom of the page that writes you a line and copies it to your clipboard, and it exists entirely so I can ask this:

What are your two places? The ones that got mixed together somewhere along the way, and what's the dish that lives between them? I'll take any pairing, including the ones you think don't work, those are usually the good ones.

I used to smoke 20 a day. I'm down to 5. Not me, but AI built the app that helped.

Ravi — Thu, 06 Aug 2026 11:46:34 +0000

Let me start with the honest part, because it's the whole point of this post.

I am not an Android developer. Before this I had never written a line of Kotlin. I didn't know what Jetpack Compose was, or what a widget actually is under the hood. What I had was an idea and a problem: I was smoking about 20 cigarettes a day and I wanted to stop.

I built it for myself. It's on GitHub (Free) now in case it helps someone else: if it helps even one person, that's mission success for me.

Why counting worked when nothing else did

I tried the usual things. Willpower. "I'll stop after this pack." None of it stuck, because I genuinely had no idea how much I was smoking. It was just... a thing my hands did (not sure if I am addicted to the nicotine, the action of mere smoking, or the warmth of the smoke in my mouth, etc..). Research papers are filled with non-correlative or non-convincing conclusions.

The app Pace does one thing: count. One tap, one cigarette. And then it showed me the number I had never actually looked at before.

Seeing "14" at 4pm hits differently than a vague feeling of "I smoke a bit much."

Then I added the second half, which turned out to be the important one: how much time is left until the next one. Not a rule, not a punishment: just a countdown. Tuns out, for me countdown provided the patience and will power to hold on for another 30 minutes. And something about waiting for a timer instead of reaching for a pocket changed the whole thing for me.

The widget that appears on the homescreen is the part that actually changed my habit

This is the bit I want to say properly.
Our phones have become body parts. We look at them every few minutes without deciding to. So I put the counter and the countdown on my home screen as a widget.

Now I don't have to remember to open an app during a craving. I unlock my phone for something completely unrelated and the reminder is just there. "3 today. 22 minutes to go."

It's constant, but it doesn't nag. And honestly, seeing that little card a hundred times a day is the reason my confidence has changed. For the first time I actually believe I will be able to quit.

Finding: Five minutes of distraction gets you past it

Here's the other thing I learned about myself: a craving is not permanent. It's about five minutes long. If I can get through those five minutes, I am fine.

So Pace sends me a notification when a craving is likely, and it opens straight into a chat. Ollama LLM model (with a personality) then tries to distract. Not a lecture, just something to talk about, or a riddle, or one silly specific thing to do for two minutes. The distraction eats the five minutes, and then it passes, and then it's ok.

That's the entire trick. It sounds too simple to work. It worked for me. Sharing it here not for views or stars or collaboration or anything. Even if it helps 1 person, I am happy, thats the purpose of this post.

So how did someone who can't code build an Android app?

I used AI. Specifically Claude Code completely to build the app and improve it.

I want to be clear about the split of work, because I think people oversell this:

What I did: described what I wanted in plain English. Used the app every single day on my own phone. Found the things that felt wrong and said so "the countdown on the widget is frozen", "I tapped it by accident in my pocket and it logged a cigarette I never smoked", "this animation feels sluggish". Made pretty much every decision about how it should behave.

What the AI did: all of the actual Kotlin. The database, the Compose screens, the widget, the notifications, the tests.

What I'm honest about: I do not fully understand every file in that repository. I can read it and follow it, but I couldn't have written it. If a real Android developer looks at the code and finds things to criticise, they're probably right, and I would like to hear it.

The parts I did go through carefully are the ones about my own data: where things get stored, what leaves the phone. (Answer: everything stays on the device. There's no server, no account, no analytics. The AI chat is optional and uses your own API key.)

Where I am now

From ~20 a day to 5–6 a day. Some days 4.
I haven't quit yet. Iam not going to pretend I have. But I'm not where I was, and for the first time it feels like a matter of when rather than if.

If you are in the same boat, the code is here: github.com/ravipurohit1991/pace. It's free, there's nothing to sign up for, and I'm not selling anything.

And if you have got an idea for something small that would make your own life a bit better: I think this is genuinely the moment to try building it. Not knowing how to code used to be the end of the conversation. It isn't anymore.

Good luck. Genuinely.

What Is the Most Technically Impressive Useless Thing You Have Built?

Ravi — Thu, 23 Jul 2026 20:59:41 +0000

We have plenty of posts on DEV announcing new tools, libraries, agents, and frameworks.

I want to hear about the opposite.

What did you build that worked perfectly, perhaps even taught you a lot, but nobody actually needed?

Maybe it solved a problem that only you had or perhaps did not exist. Maybe an existing tool already did it better. Maybe you spent three weekends automating something that took five minutes per year. Or perhaps you built it simply because the idea was fun.

There is nothing wrong with building for curiosity. The problem begins when we confuse “I enjoyed making this” with “the world needs this product.”

Before starting another project, I am trying to ask:
Who actually has this problem?
How are they solving it today?
Would they change their current process to use my solution?
Am I building this because it is needed, or simply because I want to build it?

Both answers can be valid. A hobby project does not need a market. But we should at least be honest with ourselves about which one it is.

So, what is your most impressive useless project?
What did it do, why did nobody use it, and what did you learn from building it?

Why do so many comments here Feel AI-Generated?

Ravi — Fri, 10 Jul 2026 17:49:04 +0000

I have used AI tools quite a lot for writing, so I have started noticing certain patterns: polished but vague compliments, repeated sentence structures, overly balanced phrasing, and the occasional suspiciously enthusiastic “Great insights!”.

I absolutely hate the frequent em dashes "—", which screams AI-generative text. (happy hunting).

Of course, none of these things prove that a comment was written by AI. Plenty of people naturally write this way (not that I know any of them), and many others may use AI simply to improve their grammar or express themselves more clearly.

But it does make me wonder:

Are people genuinely reading posts and responding because they have something to say?

Or are some comments being generated mainly for visibility, engagement, badges, or profile activity?

I don’t think using AI to help write a comment is necessarily bad. I do it too, I see the benefit of it. The real issue is whether the person behind the comment actually reads the post and do they mean what they write ?

And yes, absolutely, I am fully aware of the irony.
The main purpose of this post is also visibility and engagement.

I made a template for building full-stack app from the stack I keep reusing

Ravi — Thu, 09 Jul 2026 23:36:41 +0000

Over the past few years I have had to build a few different apps (having no formal CS background), usually some version of a full-stack product with an API, web UI, CLI tooling, packaging, etc.

Using the tech stack and the knowledge acquired during the last few years, I have tried to ask Claude to make a reuseable template based on that. Putting it out here, in case it helps anyone.

OpenProductKit: github.com/ravipurohit1991/OpenProductKit

It’s a Copier template that generates a product repo with:

FastAPI backend
React/Vite frontend
Typer CLI
pywebview desktop app
plugin API
licensing hooks
generated OpenAPI TypeScript client
an Agent.md file so any AI agent can fill in your app idea into the template

The main idea is to keep the business logic in a framework-free Python core (this was a personal choice), and then build the web, CLI, and desktop surfaces around that same core.

It is still early, and I’m sure there are things that are overbuilt, missing, or just based too much on my own way of working.

I would love feedback from people who have built/shipped full-stack apps:

does this structure feel useful?
what would you change based on your experience?

A product template your AI agent can finish

Ravi — Thu, 09 Jul 2026 20:33:27 +0000

OpenProductKit is a white-label, full-stack template for shipping commercial apps across web, CLI and desktop from one decoupled core.

To prove the pitch, I generated a project from it and reworked that generated app into Tally, a real freelancer time tracker, using an AI coding agent that followed nothing but the generated project's own AGENTS.md.

The repo history is the tutorial: the first commit is the pristine template output, and every commit after it is one layer of the rework.

The gap between a boilerplate and a product

Every developer has a folder full of app ideas. Most die in the same place: not at the idea, but at the product part.

The licensing. The desktop packaging. The typed API client that drifts out of sync. The migrations. The "how do I rebrand this template without a find-and-replace mess" problem.

Boilerplates solve day one. Almost none solve week four, when you need to sell a license key, ship a Windows build, or pull upstream template fixes into a project you have heavily customized.

And in 2026 there is a question classic boilerplates were not designed to answer:

What does your AI coding agent do with the template?

You are probably not hand-writing every route and component anymore. You generate a project, open Claude Code, Cursor or Codex, and say: "build my idea into this." Most templates give the agent no rules, no map, and no replacement recipe, so it guesses. The architecture starts eroding from the first commit.

OpenProductKit is built to close both gaps.

What you start from

OpenProductKit is a Copier template. One command, a few questions, and you get a branded monorepo:

One decoupled core: packages/core is pure Python with dataclasses, ports and services. No FastAPI, no database, no HTTP.
Thin adapters: FastAPI, Typer, React and pywebview sit around the same business logic.
Desktop without a sidecar: the same React UI runs in a native window and calls the core in-process over a JS bridge.
Real licensing: Ed25519-signed offline tokens, vendor tooling, route gates and lock-card UI.
Plugins: Python entry-point plugins with license gating and an admin UI.
Generated typed client: OpenAPI to TypeScript, so backend drift becomes a compile error.
Migrations, tests, docs and CI: all rendered into the generated project.
AGENTS.md and CLAUDE.md: pre-rendered with your package names, CLI command and architecture rules.

The template ships a deliberately small demo domain, a notes-and-tags "Resource Vault", threaded through every layer. Every demo line is fenced with a grep-able [demo] marker. It exists to be deleted.

The proof: building Tally

Tally is a local-first time tracker for freelancers:

Clients with hourly rates
One running timer at a time
Recent time entries
Weekly billable reports
CSV export as a paid feature
Web, CLI and desktop surfaces
Same core, same data

Here is the generated app after replacing the demo with realistic Tally data:

And the weekly billable report:

Step 0: generate the project

The first commit is just the output of the template:

uvx copier copy gh:ravipurohit1991/OpenProductKit tally
# project_name=Tally, cli_name=tally, pkg_slug=tally

That initial project already runs. It has a web UI, CLI, desktop shell, licensing, plugins, migrations, docs, CI and tests. That matters because it makes the rest of the history honest: everything after commit zero is the product rework.

Step 1: let the agent read AGENTS.md

The generated AGENTS.md opens with the rule that keeps the codebase sane:

Business logic never leaves packages/core.

FastAPI, Typer, React and pywebview are delivery mechanisms. If a product decision is encoded inside a route, CLI command or React component, it belongs in a core service instead.

The file also gives the agent a layer-by-layer recipe:

Add the new core domain.
Add ports and services.
Test the core with in-memory fakes.
Add persistence.
Add API routes.
Regenerate the typed client.
Replace the frontend.
Replace CLI commands.
Rework plugins.
Delete every [demo] marker.

This is the important bit: the agent is not guessing the architecture. It is following the project's own instruction manual.

Step 2: build the core first

Tally's product rules live in the core package:

Client
TimeEntry
TimerService
ReportService

The central rule is simple but important: only one timer can run at a time.

That rule is enforced in the core, so the web UI, CLI and desktop app cannot disagree. The CLI does not need its own timer logic. The React app does not need its own timer logic. The API route does not need its own timer logic. They all call the same service.

Core tests run against in-memory fakes, so the most important behavior can be tested before touching FastAPI, SQLModel, React or pywebview.

Step 3: add persistence and API

After the core exists, the backend becomes an adapter:

SQLModel rows
Repositories implementing the core ports
Alembic migrations
FastAPI routes over the services

The paid CSV export is just a route gate:

@router.get("/export", dependencies=[Depends(require_plan("pro"))])
def export_report_csv(...) -> Response:
    ...

Tests cover both sides of the gate: the dev license stub grants pro, while a free plan returns a structured 403.

Step 4: regenerate the typed frontend client

After changing the API, the agent regenerates the frontend schema:

uv run tally gen

The React UI uses types derived from the backend OpenAPI schema. If an endpoint changes and the UI call site is wrong, TypeScript catches it.

Tally's frontend is intentionally modest: a timer view, a report view, plugin settings and license status. The point is not to be flashy. The point is that the product can move from generated scaffold to working application without breaking the architectural line.

The plugin manager is still there too, now reworked for the Tally domain:

Step 5: make the CLI a real adapter

The CLI is not a second implementation. It is another adapter over the same services:

$ tally client add "Acme Corp" --rate 100
$ tally start "Acme Corp" "api integration"
Timer started for Acme Corp.  api integration

$ tally status
Running: Acme Corp  0:03  api integration

$ tally stop
Stopped: Acme Corp  0:09

$ tally report --week
Client                      Hours     Rate     Amount
Acme Corp                    0.00   100.00       0.25
TOTAL                        0.00                0.25

The one-running-timer rule is enforced here too, because it comes from TimerService.

Step 6: delete the demo

This is where the [demo] markers pay off:

rg "\[demo\]" packages apps

The agent can find the entire old demo surface, delete pure-demo files, trim marked sections from mixed files, regenerate the typed client and keep the project clean.

After the purge, Tally had:

45 tests
Zero [demo] markers
No dead Resource Vault scaffold
Web, CLI and desktop still sharing one core

The desktop app required no product work

This was the nicest validation.

Tally's desktop app did not need a separate rewrite. The pywebview shell already knows how to load the same frontend and dispatch requests into the FastAPI app in-process. No sidecar. No local port. No second backend.

Once the web UI and API were reworked, the desktop app came along for free:

uv run tally build web
uv run tally desktop

That is what the "core never assumed HTTP" rule buys you.

Dogfooding caught a real bug

Full honesty: the first CI run of the generated project failed.

The generated workflow file is copied verbatim because GitHub Actions syntax uses ${{ }}, which collides with Jinja templating. One desktop smoke-test step still contained an unrendered {{ pkg_slug }}_desktop.

Tally was the first generated project to run its own CI. It caught that bug quickly, and the fix went back upstream.

That is exactly why I wanted a real proof project instead of a polished demo video. Building something from your own template finds the bugs that documentation misses.

Try it with your own idea

The workflow Tally validated is:

1. uvx copier copy gh:ravipurohit1991/OpenProductKit my-product
2. Open it with your coding agent:
   "Read AGENTS.md, then replace the demo with <my idea>."
3. Review the diffs layer by layer.
4. Ship.

The agent does not guess the architecture. It is told.

It does not hunt for the demo. It greps the fence.

It does not hand-write client types. The recipe tells it when to regenerate.

And you review commits shaped like product layers instead of one giant rewrite.

What it is not

OpenProductKit is intentionally lean and opinionated:

SQLite, SQLModel and Alembic
React and Vite
Typer
pywebview and PyInstaller
Dev-time Python entry-point plugins
Local/offline licensing primitives

It is not a multi-tenant SaaS starter with Stripe, teams, billing portals and Kubernetes. Runtime plugin installation is still on the roadmap. Code signing is documented, not solved.

But if your idea is a product that a customer downloads or logs into, with a license key, plugins, and web + CLI + desktop surfaces, this is the fastest honest path from template to shipped that I know how to build.