DEV Community: Tejas Patil

How UPI Works: The ₹0 Magic Behind Every Scan-and-Pay (System Design)

Tejas Patil — Thu, 29 Oct 2026 11:55:24 +0000

System Design Simplified — Part 1

The chai stall

It's 8 AM. You're holding a cutting chai in one hand and your phone in the other. You scan a faded QR code on the counter, type four digits, and before Bablu looks up from his kettle, his phone says ₹20 received.

Two seconds. No card. No cash. No fee.

In August 2026 alone, UPI handled a record 24.51 billion transactions, about 791 million a day. That's roughly 85% of India's digital payments and nearly half of all real-time payments on Earth.

So what happened in those two seconds? Let's follow your ₹20.

Meet the cast

Every UPI payment has five characters, and each has exactly one job.

You. The person with the phone.

Your UPI app. PhonePe, Google Pay, Paytm. It does not hold your money. It's a messenger.

Your bank. Where your money lives. The only one allowed to take ₹20 out.

NPCI. The National Payments Corporation of India. It runs one central switch that every bank is plugged into. It holds no money either. It's the traffic cop at the junction.

Bablu's bank. Where the ₹20 lands.

One idea to remember: apps and NPCI are messengers. Only banks touch money.

The journey of ₹20, in motion

Purple = the request. Orange = the money. Green = done. Watch it loop once and the whole system makes sense.

Notice the order. Your bank is asked first. Money leaves your account before anyone asks Bablu's bank to accept it. That's deliberate: money stuck in transit can be reversed; money credited that was never debited cannot.

Wait, so what is Google Pay?

This is the part most explainers skip.

Google Pay, PhonePe, Paytm, CRED, Amazon Pay are not banks. NPCI has a strict rule: it talks only to banks. So how does an app made by Google reach the switch?

It borrows a bank.

Every UPI app partners with one or more licensed banks, called PSP banks (Payment Service Provider). The bank owns the actual connection to NPCI. It gets audited, holds the security certificates, and takes legal responsibility for every request the app sends. The app, officially a Third-Party Application Provider, rides on the bank's pipe.

You've seen this without noticing. The @okaxis in ramesh@okaxis means Google Pay is using Axis Bank as its PSP. @ybl is PhonePe on Yes Bank. @paytm is Paytm's own handle. The part after @ names the app's partner bank, not yours.

That's the twist: your money can sit in SBI while your Google Pay handle says Axis. Axis is the doorman who walks your request into NPCI. SBI still opens the vault.

Why build it this way? NPCI would rather trust 50 regulated banks than vet 500 apps. If an app misbehaves, its PSP bank answers for it.

There's a real-world reason the big apps now keep several PSP banks. In March 2020, PhonePe ran only on Yes Bank. When RBI put Yes Bank under a moratorium, NPCI blocked its handles, and PhonePe went down with it. Within months PhonePe added ICICI (@ibl) and later Axis (@axl). Today, if one partner bank is slow, the app quietly routes through another.

What NPCI actually does

The switch isn't a black box. It does four jobs on every single payment.

Directory. It keeps the phonebook. bablutea@okaxis maps to a real bank and account number. You never see that mapping, and neither does the person paying you.

Router. It asks your bank to debit first, then asks the receiver's bank to credit, each with a strict timeout. A slow bank gets marked pending; the switch moves on.

Tracker. If a reply never comes back, NPCI doesn't guess. It marks the payment pending, runs a check-status call, and reverses the debit if the credit never landed.

Tally. It records what every bank owes every other bank, all day. More on that below.

NPCI talks only to banks, over private certified lines. It never holds money and never sees your PIN.

The clever ideas inside

Your UPI ID is a nickname. ramesh@okaxis is like a saved contact. NPCI keeps the phonebook. Share it on a poster, switch banks later, the ID stays.

Your PIN never travels. You type it into a locked box provided by NPCI, called the common library. It's encrypted right there on your phone, and only your bank has the key. Google Pay cannot read your PIN. Neither can NPCI. Neither can Axis.

Your phone is the password. During setup, the app sends a silent SMS from your SIM. That binds your number, SIM and device together. There's no username. Your phone is the login; your PIN is the second factor.

It's a switch, not a wallet. A wallet has to hold your money. UPI never does. Money moves bank to bank, so there's no top-up, no middleman, no fee hiding in the spread.

When things go wrong

Money debited, Bablu shrugs, nothing received. What happened?

Your bank said yes and debited you. Then a message got lost between the switch and Bablu's bank. UPI doesn't guess. It marks the payment pending, and NPCI runs a check-status call to learn the truth. If the credit never landed, a reversal goes to your bank and the ₹20 comes back, usually within hours.

The promise: money is never in two places, and never nowhere. It's with you, with them, or in a tracked pending state that will resolve.

Did the banks actually move money?

Here's what almost nobody knows. When your bank debits ₹20 and Bablu's bank credits ₹20, the two banks haven't exchanged a rupee yet. Each just updated its own customer's balance.

Think of two friends who keep paying for each other all week. They don't hand over cash every time; they keep a tally and settle the difference on Sunday. NPCI is the friend with the notebook. Several times a day it tells the Reserve Bank of India "Axis owes SBI ₹340 crore net," and one transfer settles millions of chai payments.

That's why UPI is instant and free at the same time. The expensive part, moving real money between banks, happens only a few times a day, in bulk.

How does one switch survive 791 million hits a day?

Nobody waits for anyone. Every hop has a strict timeout. A slow bank gets marked pending; the switch moves on. Slow banks hurt their own customers, not the country.

The switch is stateless, copied many times. It only routes messages, so dozens of identical copies sit behind a load balancer. Any copy can handle any payment. One dies, nobody notices.

Every message has an ID that can't be reused. If your app resends because the network blinked, the switch sees the same transaction ID and says "already done" instead of charging you twice. This is called idempotency. It's the single most important idea in payments.

Five things to remember

Apps and NPCI are messengers. Only banks hold money.
Google Pay isn't a bank. It reaches NPCI through a partner PSP bank, named by the @ in your UPI ID.
Your PIN is encrypted on your phone; only your bank can read it.
Debit first, credit second. Pending is a tracked state, not a bug.
Banks settle in batches, which is why instant can also be free.

Next in the series

Part 2: How Google Pay handles the Payment Pending screen without losing your money. Retries, timeouts and idempotency, told through one stuck ₹500.

Numbers from NPCI's monthly statistics for August 2026. Bablu Tea Stall is fictional; the system is not.

Your phone is not an RTX 4090. This open model knows that.

Tejas Patil — Fri, 16 Oct 2026 12:21:11 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Every Minecraft PE player knows this moment: you install a gorgeous shader with godrays and glassy water, load your world, and your game turns into a slideshow.

I run MCPE Shaders and Textures, an Android app with [N]+ shaders and texture packs and [8,000+] installs. The #1 problem my players have isn't finding a shader. It's finding one their phone can actually run.

So this week I built ShaderFit. You type what you want, like "clear water, no lag" or "cozy sunset for building," and it:

📱 Checks your phone: GPU, RAM and Minecraft version, automatically
🔍 Finds the look: matches your words to shader descriptions and preview screenshots
⚡ Predicts lag: learns from real players' "Smooth / Laggy" taps
💬 Explains the pick: "Runs well on Adreno 610. Set render distance to 8."

Who pays? The app is free with ads.

👉 Try it on Google Play

Demo

ShaderFit is a new repo built during the challenge (Oct 12–18). The catalog app existed before.

How I Built It

EmbeddingGemma 2 (Google's new open model) puts text and images in the same space, so "crystal clear water" finds the shader whose screenshot shows clear water, even if its description never says it.
TabPFN predicts the chance a shader runs smooth on your phone from [N] real player reports, with no training needed.
Gemma 4 writes the one-line tip.
Everything runs on one small server on Render.

Did it work?

Phone	Most popular shader	ShaderFit's pick
[Budget phone]	[30 ] FPS 🐌	[70 ]FPS
[Mid-range phone]	[45 ] FPS	[85 ] FPS
[Flagship phone]	[58 ] FPS	[94 ] FPS

The right shader was in the top 5 for [100]% of real player requests, up from [80]% with my old keyword search.

What still breaks: [1–2 honest limits, e.g. rare GPUs have little data yet.]

Why Does Open Innovation Matter?

Free apps can't pay per search. A closed AI API would cost [amount] a month for my players. Open models cost [amount].
It sees screenshots, not just words. That's how players actually pick shaders.
Player data stays mine. No outside AI company gets anyone's device info.
I'm allowed to sell it. EmbeddingGemma 2 and Gemma 4 are Apache 2.0.

My First User

[Real player feedback in 2–3 lines: how many tried it, one real quote (with permission), what they asked for next.]

Prize Categories

Best Use of Gemma · Best Use of TabPFN · Best Use of Render

Unofficial app, not affiliated with Mojang or Microsoft.

The Last Time I Googled an Error Message

Tejas Patil — Wed, 02 Sep 2026 13:18:27 +0000

I don't remember the last time I pasted an error into Google.

Not the date. I mean the habit left and I didn't notice it go. Something I did five times a day just stopped.

Here's the whole six years.

2019. Google it.
Copy the error. Delete the parts with your name in them. Paste. Stack Overflow, result one. Scroll past the 2013 answer everyone says is outdated. Find the one with 400 upvotes sitting fourth.

Forty minutes. But you understood the fix by the time you shipped it, because you had to read four wrong answers to find the right one.

2020. Everyone goes home.
Same ritual. Worse chair.

Nov 2022. ChatGPT.
We used it to talk like a pirate for two weeks. Then somebody pasted an error in as a joke.

It answered your error. Your variable names. Your file. No "closed as duplicate."

That's the moment. Not the launch.

2023. Paste, patch, repeat.
It was bad. Invented functions. Wrong library versions. Fix one error, get two.

Still faster than being wrong alone. So Google went second. Then optional. Then gone.

2024. Too long.
"Message exceeds limit." You chopped your own project into snacks for a model with a small mouth. More time deciding what to paste than actually coding.

Then context windows got huge and you just pasted everything.

2025. It reads the repo.
Cursor. No more describing your folder structure like a dream you had. The ask changed from "how do I do X" to "do X."

Nov 2025. Agents.
Antigravity ships with Gemini 3. Claude Code lives in the terminal, and somehow that plain black rectangle became the serious one.

2026. You.
Describe the thing. Go make chai. Come back. Review a diff.

Stack Overflow went from over 200,000 questions a month to under 50,000 by late 2025. Lowest since May 2009, ten months after it launched.

The part that bugs me

I'm not doing the "learn real coding" speech. I use these every day.

But those forty minutes in 2019 were annoying and they were the entire learning mechanism. Four wrong answers taught you the shape of the problem. Now you get the right one in nine seconds and learn nothing, because nothing had to be survived.

And there's a worse one. All of that AI knowledge came from people posting questions and answers in public. We stopped posting. Every bug since 2024 gets solved in a private chat window and then deleted.

We're all debugging alone in a room and calling it a community.

Two questions

1. When did your default switch from Google to a chat box? Not the launch date. The specific moment you noticed.

Mine was a library whose docs were wrong. Google gave me four threads about a different version. I pasted the stack trace into a chat window and it got it in one, and I never really went back.

2. What's the last thing you actually googled? Be honest.

Mine was "why is my laptop fan so loud." Not a coding question. That's kind of the point.

Drop yours below. I genuinely want to see how differently we all walked the same six years.

If you've been coding since before 2022, you lived this whole timeline. If you started after, you walked into the middle of it and everyone acted like it had always been this way.

Either way, I'd like to hear which year you came in at.

My Code Works. An AI Wrote It. Neither of Us Knows Why.

Tejas Patil — Wed, 02 Sep 2026 12:17:20 +0000

here's a meme we've all posted some version of.

"My code works and I have no idea why."

Classic. Universal. Every developer since 1970 has felt it.

But it changed this year, and nobody really announced it. Now it goes:

"The AI wrote code that works. Neither of us knows why."

Same joke. Completely different problem.

The old version was funny because it was temporary

Back then, "I don't know why it works" meant you'd get there eventually. You wrote it. You'd tripped over something, and if you sat with it for twenty minutes you'd figure out what.

The confusion was yours. So was the code. So was the fix.

The new version is different. You didn't write it, you can't debug it, and there is no twenty-minute session that gets you there, because you were never in the loop to begin with.

You approved it. That's a different verb.

The numbers are genuinely wild

By 2026, 92% of US-based developers are expected to use AI coding tools daily, and 41% of all code globally is projected to be AI-generated. Roughly 40% of junior developers deploy code without fully understanding it.

Sit with that last one. Not "wrote without understanding." Deployed.

Then there's my favourite study, the one nobody wants to talk about: developers believed AI made them about 20% faster, and measurement showed they were actually around 19% slower.

We're not just shipping code we don't understand. We're wrong about whether it's even helping.

Meanwhile, at the top

Andrej Karpathy, who coined "vibe coding" in the first place, called the term passé back in February. His argument was that the frontier had already moved past autocomplete to agents that plan, test and correct themselves across whole codebases.

The guy who named it retired it before most of us finished arguing about it.

And underneath, junior software developer employment has now declined for 33 consecutive months.

So the entry-level job is disappearing at the exact moment the main skill being demanded is judgement, which is the one thing you can only get by doing the entry-level job.

Great. Love that for us.

The part I actually think about

I'm a final-year student. I'm supposed to be the target market for all of this.

And the honest version is that AI is incredible when I already know what I'm looking at, and quietly dangerous when I don't. Same tool. The difference is entirely me.

When I understand the domain, it's the best pair programmer I've ever had. When I don't, it's a very confident stranger handing me something and walking away.

The trap isn't that AI writes bad code. It writes fine code, usually. The trap is that working code feels like finished code, and those have never been the same thing.

My rule now, for whatever it's worth:

If I can't explain why the code works, I haven't finished. I've just stopped.

Not "read every line." Nobody does that and you know it. Just: can I say out loud what it does and why that's the right approach? If not, I'm not done, no matter how green the tests are.

Your turn

I want the honest answers, not the LinkedIn ones.

What's the worst thing you've shipped that you didn't fully understand?

I'll start. I once merged a fix for a bug I never actually reproduced. It worked. It's still in production. I still don't know if it fixed the bug or just moved it somewhere I haven't looked yet.

Drop yours below. No judgement, we're all in the same boat and the boat was generated by an LLM.

Sources: daily.dev on vibe coding in 2026 · Forbes on entry-level coding jobs

Pawscript - Your Dog's Letter to You

Tejas Patil — Mon, 17 Aug 2026 10:57:21 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

Pawscript. Upload a photo of your dog, optionally with a bark, whine, or sigh, and Gemini reads the actual photo (and sound, if given) and writes a short, warm letter in your dog's own voice, along with a few honest "Tail Tell" observations about their visible posture and expression.

My goal was to avoid the usual "upload a photo → get a random label" pattern that many pet apps use, and instead build something that is actually grounded in the specific photo you provide. So if you scan the same dog twice, the result can genuinely be different rather than feeling like a copy-paste response.

Demo

Live: https://pawscript.ai.studio

Code

Tejas164321 / Pawscript

Pawscript. Upload a photo of your dog - optionally with a bark, whine, or sigh - and Gemini reads the actual photo (and sound, if given) and writes a short, warm letter in your dog's own voice, plus a few honest "Tail Tell" observations about their visible posture and expression.

How I Built It

I started with a UI I liked, a five-paw "scanning" progress meter with a breathing/pulse animation, and rebuilt the logic underneath so it actually does something.

The core is a single multimodal call to Gemini. The uploaded photo, along with optional audio, is sent with a system instruction that tells the model to reference specific visual details it can actually see in that photo, such as the coat, posture, setting, and expression. This helps keep the letters specific to the image instead of making them sound generic. I also enforced structured JSON output with letter, mood_tag, observations, and used_audio, so the UI never has to guess how to parse the response.

The trickiest part was the optional audio path. I had to send the image and inline base64 audio in the same request and ask Gemini to combine the acoustic tone, such as a bright yip or a low grumble, with the visual details when writing the letter. I also made sure it never invents sound characteristics when no audio is provided.

I tied the paw-progress animation to the real fetch lifecycle instead of using a fixed timer, so the scanning moment is based on the actual request rather than being purely decorative.

If shipped, letters can optionally be read aloud using ElevenLabs voice narration.

Nothing uploaded is stored. Photos and audio go directly to Gemini for analysis and aren't kept.

Prize Categories

Best Use of Google AI — Gemini multimodal vision + audio understanding with enforced structured output.

Best Use of ElevenLabs — if you shipped voice narration, keep this line; if not, delete it.

Thanks for reading, and happy Dog Days! 🐾

I Chased a Data Bug for an Afternoon. It Was Never About the Data.

Tejas Patil — Wed, 12 Aug 2026 11:11:24 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Here's the thing about the bug I'm about to describe: for the first hour, I was completely sure I knew where it lived. I was wrong, and I want to walk you through exactly how wrong, because the actual location was almost insulting in how little sense it made until suddenly it made total sense.

The Setup

npmx.dev is an open-source browser for the npm registry. One of its features lets you compare two packages side by side — versions, install size, dependencies, the works. Somebody filed a bug: compare tinyclip against anything, and it would report tinyclip stuck at version 0.0.1 — its very first-ever published version — when the real latest was 0.1.8.

My first thought was the obvious one: the comparison logic is reading the wrong field. Maybe it's grabbing the first published version instead of the latest dist-tag. Confident, reasonable, and completely wrong.

Chasing the Wrong Suspect

I went into the comparison composable expecting to find some sloppy array indexing or a fallback that defaulted to the wrong thing. Instead I found totally reasonable code: fetch the package's registry data, read dist-tags.latest, done. No obvious bug. No off-by-one. Nothing.

This is the part of debugging nobody puts in the tutorial: the moment where your working theory just quietly stops being true, and you have to admit you don't know where the bug is anymore.

So I went one level down, into the actual fetch function behind that call. And that's where things got strange.

The Parameter That Wasn't Doing Anything

Buried in the fetch wrapper was this:

_ttl: number = FETCH_CACHE_DEFAULT_TTL,

An underscore-prefixed parameter. If you've spent any time in TypeScript, you know what that prefix means: "accepted, but deliberately unused." Someone had designed a whole caching contract around a configurable time-to-live — and on the client, it was accepted into the function signature and then never touched again.

Right next to it, the actual caching behavior was hardcoded:

cache: 'force-cache',

I want to be honest about my reaction to this, because it wasn't "aha, found it" right away. It was closer to "okay but that can't be the whole thing, this is a comparison page, not a caching page." I almost moved on. The bug I was hunting was about wrong data, not stale data — or so I thought, before I remembered that from a browser's perspective, those are frequently the exact same problem wearing different clothes.

Why `force-cache` Is a Trap

force-cache tells the browser one very specific thing: if any cached response already exists for this URL, use it — don't bother checking whether it's still fresh. That's different from the browser's normal behavior, which checks Cache-Control headers and quietly revalidates once something goes stale.

So here's what was actually happening: the very first time your browser ever fetched tinyclip's registry data — however long ago that was — it locked that response in. New versions could publish on npm every week after that, and your browser would never know, because it had been explicitly told not to ask again.

It wasn't a data bug. It was a bug about when the browser was allowed to ask for new data, disguised as a data bug.

Making Sure I Wasn't Just Telling Myself a Nice Story

Before I trusted this theory, I checked what registry.npmjs.org actually sends back on a real request:

cache-control: public, max-age=300
etag: "..."

The registry was already doing its job — five-minute freshness window, an ETag for cheap revalidation after that. The app just wasn't listening to any of it. That was the moment the theory stopped being a theory.

The Fix

- cache: 'force-cache',
+ cache: 'default',

One line, in two places (there's a client branch and an identical server-fallback branch — both needed the same fix, or the bug would've just moved house). 'default' means: respect what the server actually told you about freshness, instead of assuming a months-old response is still gospel.

I ran the full test suite afterward — 1,000+ tests, all green — and checked the network panel to confirm requests were genuinely round-tripping instead of resolving instantly from a frozen local copy.

PR, if you want to see the actual diff: npmx-dev/npmx.dev#3156

What I'd Actually Tell Someone About This

If a bug report describes wrong-looking data, "check the data logic" is a completely reasonable first move — it's just not the only move. Data can be wrong because the logic is wrong, or because the logic is right and it's being fed a version of reality that's frozen in time. Those look identical from the outside. They are not identical to fix.

And the real lesson, the one I keep coming back to: an unused parameter isn't nothing. It's a question the codebase is quietly still asking, that nobody's gotten around to answering. _ttl sat there the whole time, patiently doing nothing, waiting for someone to notice that it should have been doing something.

I noticed. Eventually.

Vada Pav - An Interactive Landing Page for Mumbai's Favorite Street Food

Tejas Patil — Tue, 11 Aug 2026 11:27:27 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing.

An interactive landing page for vada pav — not a restaurant, not a recipe blog, a love letter to one dish that means something specific to me.

Vada pav is comfort food that people from Maharashtra will defend with real conviction — everyone has an opinion about the right ratio of garlic chutney to green, whether onion belongs on it, and which cart does it best. I wanted the page to feel like the dish itself: warm, a little chaotic, and specific rather than generic.

What I Built

The site has a hero section with an animated illustration (continuous steam, twinkling string lights evoking a stall at dusk, a slow monsoon-rain layer in the background), a personal story section, a four-moment "Day With It" timeline walking through the same dish at different times of day, and an interactive centerpiece: the Vada Pav Builder.

The builder lets you toggle five real toppings — green chutney, dry garlic chutney, a fried chili, raw onion, and sev — and watch them stack in the correct order on an SVG sandwich, regardless of what order you click them in. As you build, a live-generated sentence describes your exact combination in plain English, and an animated heat meter tracks how spicy your choices are.

Demo

Live site: https://mumbaivadapav.netlify.app/

CodePen: https://codepen.io/editor/lvjstkex-the-vuer/pen/019ff081-af80-78e8-8213-5a8a3f37f6cb

Journey

I wanted to avoid the landing-page defaults I kept seeing myself reach for — a cream background with a single warm accent, or a generic hero with a stock gradient. Since vada pav already has a strong, specific visual identity, I built the palette directly from the dish instead: a deep frying-oil brown-black (the kadhai it's cooked in), turmeric gold, chili red, and curry-leaf green, with a warm cream reserved for the reading sections.

The Vada Pav Builder is the part I'm most proud of. Under the hood it's plain vanilla JavaScript — a state object mapping each ingredient to a boolean, rendered into a fixed-order stack using CSS order so the sandwich always assembles correctly no matter which order you click ingredients in. Tying it to three things at once — the visual stack, a live-generated natural-language sentence, and an animated heat meter — is what took it from "a toggle list" to something that actually feels like assembling food.

The "Day With It" timeline walks through the dish at four real moments (a station-platform grab, after school, a monsoon evening under a stall's tarpaulin, and the last cart open at night) — a real sequence, not just a stylistic list, which is why it's numbered/ordered rather than presented as flat cards.

On accessibility: every ingredient toggle is a real <button aria-pressed>, not a clickable div; an aria-live region announces each addition and removal for screen reader users; all interactive elements have visible keyboard focus states; and every animation — the steam, the string lights, the stack's spring-in motion, the rain layer — is disabled cleanly via a prefers-reduced-motion check, both in CSS and in the JavaScript that spawns the sparkle effects.

The whole thing is a single self-contained HTML file — no build step, no framework — which felt like the right scope for a food-themed love letter rather than a full application.

Thanks for reading — go find your own fifteen-rupee miracle. 🌶️

Fixing a Silent Cache Bug in npmx.dev

Tejas Patil — Mon, 10 Aug 2026 05:32:55 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup.

The bug

npmx.dev is a fast browser for the npm registry — you
can look up any package or compare two side by side. On the compare
page, package version numbers were sometimes just... wrong. Not
crashing-wrong, just quietly stale — showing a version that npm had
long since replaced.

The bug had already been reported (issue #1832):
comparing tinyclip and copy-paste showed tinyclip stuck at its
very first published version, 0.0.1, when the real latest was
0.1.8. The original screenshots in that issue show the mismatch
clearly next to what the npm registry itself reports.

The original bug, as reported in issue #1832 — tinyclip stuck at v0.0.1 instead of the real latest, v0.1.8.

The kind of bug that's easy to shrug off as "just a display issue" —
but on a site whose entire purpose is showing accurate package data, a
silently wrong version number undermines the one thing the tool exists
to do.

Chasing it down

My first assumption was that the comparison logic itself was buggy —
maybe it was reading the wrong field, or resolving latest incorrectly.
That assumption was wrong, and figuring out why it was wrong is most
of this story.

Tracing the data flow: the compare page calls a composable called
usePackageComparison, which for each package calls $npmRegistry(...)
to fetch that package's full registry data — including which version is
tagged latest. That function is a thin wrapper around another
composable, useCachedFetch().

That's where it got interesting. useCachedFetch() takes a ttl
(time-to-live) argument — a signal for how long a cached response
should be considered fresh. Except on the client, the parameter was
named _ttl:

_ttl: number = FETCH_CACHE_DEFAULT_TTL,

The underscore prefix is a convention for "this parameter is
intentionally unused." It was accepted, and then never referenced again
in the function body. Whatever caching strategy the ttl value was
supposed to control, it wasn't actually controlling anything on the
client.

Instead, the client branch hardcoded this:

const defaultFetchOptions: Parameters<typeof $fetch>[1] = {
  cache: 'force-cache',
}

force-cache is a browser fetch option with a specific meaning: if any
cached response already exists for a URL, use it — don't check whether
it's still fresh. That's different from the browser's normal caching
behavior, which checks Cache-Control headers and revalidates once a
response goes stale.

So once a browser had fetched a package's registry data one time —
whenever that first happened, possibly weeks earlier — it would keep
serving that exact same response indefinitely. New versions could be
published to npm and the app would never know, because the browser was
never allowed to ask again.

I checked what the npm registry actually sends back, to confirm this
wasn't just a theory:

cache-control: public, max-age=300
etag: "..."

The registry's actual response headers — it was already telling clients how to cache correctly.

The registry is already telling clients exactly how to cache correctly
— treat this as fresh for 5 minutes, then use the ETag to check back
efficiently. The app just wasn't listening to that instruction.

The fix

The fix itself is small — which is sometimes a sign you've found the
actual root cause rather than papered over a symptom. In
app/composables/useCachedFetch.ts, both places that hardcoded
cache: 'force-cache' (the client branch, and a server-side fallback
branch with identical logic) now use:

const defaultFetchOptions: Parameters<typeof $fetch>[1] = {
  cache: 'default',
}

'default' tells the browser to follow standard HTTP caching rules —
respect the registry's max-age, and revalidate via ETag once it
expires, rather than assuming a response is correct forever regardless
of age.

PR: https://github.com/npmx-dev/npmx.dev/pull/3156

Verifying it

Ran the existing test suite — all 1,000+ unit tests across 55+ files passed with zero failures, confirming the change doesn't break anything else relying on this composable
Loaded the compare page against the fix and confirmed it renders cleanly with no console errors
Inspected the request in DevTools and confirmed a full, real network
round-trip completes end to end (DNS lookup, connection, waiting for
server response, content download) rather than resolving instantly —
consistent with the browser actually being allowed to talk to the
registry instead of only ever reading a frozen local copy
Added a regression test (test/unit/app/composables/use-cached-fetch.spec.ts) confirming the fetch call uses cache: 'default' — ran the full suite afterward: 84 test files, 1,723 tests, zero failures

A full network round-trip completing after the fix — not an instant cache hit.

What I'd take from this

The most useful signal in this whole investigation wasn't a stack trace
or an error message — it was an unused function parameter. _ttl was
evidence that someone had designed a caching contract around a real TTL
concept, and a later implementation detail (hardcoding force-cache)
quietly bypassed it without anyone updating the signature to match.
Dead parameters are worth pausing on — they're often a fossil record of
intent the code no longer honors.

Fixes npmx-dev/npmx.dev#1832 via PR #3156

FinPal - I Built a Finance App You Can Actually Ask Questions To

Tejas Patil — Fri, 10 Jul 2026 06:31:27 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

India runs on UPI now - small, constant, invisible payments for chai, autos, groceries, rent splits, all day, every day. What nobody's built is a way to actually ask your money anything. Not another dashboard you have to squint at - an app you can talk to. FinPal reads your real UPI and bank transaction history (GPay, PhonePe, CSV, PDF exports), auto-categorizes it with a hybrid rules-plus-Gemini engine, and now lets you ask it questions in plain English and get a real answer, grounded in your actual spending.

Why This

I use UPI dozens of times a day, and so does basically everyone I know - that's not an exaggeration in India anymore, it's just how money moves now. NPCI's own numbers make the scale hard to overstate: UPI processed 23.2 billion transactions worth ₹29.9 lakh crore in a single month (May 2026) - an average of 737.79 million transactions every day - and over 500 million people now use it regularly, most of it in small, routine purchases averaging around ₹1,300 a transaction. That's the part that gets lost: when your financial life is made of hundreds of tiny, scattered UPI pings instead of a handful of big bank entries, "where did my money go" stops being a simple question. None of the apps handling those payments were built to answer it - they show you a list, not an explanation. I built FinPal because I wanted the app itself to be able to tell me, the way a person would if you just asked them.

The Product

FinPal treats AI as infrastructure, not decoration. The hybrid categorization engine keeps things fast and cheap for the transactions it already recognizes, and only calls on Gemini for the genuinely ambiguous ones - the cryptic UPI merchant strings every Indian user has seen and ignored. On top of that foundation, I added Ask FinPal: a natural-language chat layer that answers real questions against your real transaction data, not canned responses.

Demo

Instead of scrolling a transaction list trying to piece it together yourself, you just ask. Type something like "How much did I spend on food delivery last month, and is that more than usual?" or "Can I afford a ₹15,000 trip next month if I keep spending like this?" - Ask FinPal answers directly, reasoning over your actual categorized transaction history instead of giving generic financial-tips-style advice.

Live

Try it: https://finpal.tejasfolio.in/

In under a minute:

Open the dashboard and load a sample statement (or your own CSV/PDF export).
Watch transactions auto-categorize - rule engine first, Gemini fallback for anything ambiguous.
Check the income/expense breakdown and SIP/FD simulator update live.
Open Ask FinPal and type a real question about the data you just loaded - no canned demo script, it reasons over what's actually there.

Code

Repo: https://github.com/Tejas164321/FinPal

How I Built It

Frontend: React 18 + TypeScript on Vite, TailwindCSS 3 with a custom purple-gradient/glassmorphism theme, Radix UI primitives wrapped by shadcn/ui for accessible components, Framer Motion for transitions, Recharts for the dashboard visualizations, React Query for data/caching, React Hook Form + Zod for validated inputs, react-dropzone for uploads, date-fns, sonner for toasts.

Backend: Node.js + Express 4.18. Multer handles multipart uploads; csv-parser, pdf-parse, and xlsx normalize wildly inconsistent Indian bank/UPI export formats into one internal schema.

AI layer: Categorization is rule-based first - heuristics tuned on real UPI merchant-string patterns - escalating to Google Gemini only for what the rules can't confidently place. Ask FinPal builds a compact structured summary of the user's categorized transaction data (not raw dumps - token budget matters) and passes it to Gemini alongside the question, so answers are grounded in the person's actual numbers instead of generic financial advice.

Why the hybrid approach matters: most AI finance tools go all-in on the LLM for everything, which is slow, costs more than it needs to, and occasionally gets confidently wrong about things a simple lookup would nail. Splitting the load means the fast path stays fast, and Gemini only gets pulled in where it actually adds value - ambiguous categorization, and now open-ended natural-language questions that no rule engine could ever anticipate.

Prize Category: Best Use of Google AI

Gemini isn't bolted on as a chatbot widget - it's doing two distinct jobs in FinPal. First, as a categorization fallback, it only fires for transactions the rule engine can't confidently place, so it's doing targeted, cost-aware work rather than processing every row. Second, in Ask FinPal, it's given a compact, structured summary of the user's own categorized spending - not a raw transaction dump - and asked to reason over it directly, so answers like "is that more than usual?" are grounded in real computed averages rather than generic advice. That combination - cheap-and-fast where possible, Gemini only where genuinely needed - is the core design decision behind the whole app.

Closing

I built FinPal because the money moving through my life - and everyone else's around me - got faster and more constant than any of the apps meant to explain it. Hundreds of millions of us are running our financial lives through a payment rail that was built for speed, not clarity. FinPal is my attempt to close that gap: not another list of transactions, but an app you can actually ask.

Sources

NPCI/DFS UPI data, May 2026: 23.2 billion transactions, ₹29.9 lakh crore value - https://www.ibef.org/news/upi-transactions-soar-to-record-us-312-21-billion-in-may
NPCI data via ANI, May 2026 daily average (737.79M/day) - https://www.aninews.in/news/business/upi-hits-new-high-in-may-2026-with-232-billion-transactions-worth-rs-299-trillion-npci-data-shows20260602155337/
UPI user base and ticket-size figures - https://coinlaw.io/upi-statistics/

Turing's Mirror - A Game About the Question We Still Haven't Answered

Tejas Patil — Sun, 21 Jun 2026 07:08:00 +0000

This is a submission for the June Solstice Game Jam

What I Built

Turing's Mirror is a browser game about the one question Alan Turing asked in 1950 that we still haven't answered: can you tell the difference between a human and a machine?

You read 10 conversations. For each message, you decide: human or AI?

Sounds simple. Round 1, it is. By Round 5, you'll second-guess everything.

That's the point.

🎮 Play it here
💻 GitHub

Video Demo

Why Alan Turing, Why Now

June is Turing's birth month. This jam runs through June 21st — the solstice, the longest day, the turning point of the year. The timing felt too right to ignore.

Turing gave computing its soul. Not the circuits, not the transistors — the question. In his 1950 paper Computing Machinery and Intelligence, he didn't ask "can machines think?" He replaced that impossible question with a practical one: can a machine fool a human into thinking it's human?

He called it the Imitation Game.

We've been playing it ever since — except now, in 2026, we're the ones being fooled. Regularly. By machines that learned from us.

I wanted to make people feel that shift. Not read about it. Feel it.

The Game Design — Light, Dark, and the Solstice

The visual design maps directly onto the jam themes.

Dark = the machine's world. The game opens on a near-black background. Cold, clean, perfect. That's what early AI sounds like: polished in the wrong way, like someone who memorised manners without understanding them.

Light = human truth. As rounds progress and the AI gets more convincingly human, the screen warms. Win — correctly spot the human more than half the time — and the screen floods with light. Solstice light.

Lose, and you stay in the dark. The machines have crossed the line Turing drew.

Each round is labelled with a real year from AI history:

Round	Year	What it represents
1	1926	Before Turing — AI is science fiction
2	1936	Turing's first paper on computation
3	1950	The Turing Test is published
4	1966	ELIZA, the first chatbot
5	2026	Today: AI that passes the test regularly

By 2026, you're trying to find humanity in text generated in milliseconds. Welcome to the present.

Code

Tejas164321 / Turing-s-Mirror

Turing-s-Mirror

View on GitHub

How I Built It

No frameworks. No API keys. No backend. Just HTML, CSS, and vanilla JavaScript — because the simplest formulation of a problem is usually the most revealing one.

The game data is an array of message pairs — one human, one AI — shuffled randomly so you can't pattern-match by position:

const rounds = [
  {
    messages: [
      { text: "Hello! I am doing well today. How may I assist you?", isAI: true },
      { text: "ugh it's so hot today lol, can't even think straight", isAI: false }
    ],
    difficulty: "1926 — Before the Test"
  },
  // rounds 2-5 get progressively harder
];

The hardest part wasn't the code — it was writing the messages. I spent real time rewriting the Round 5 pair. Write an AI response, decide it's too obviously robotic. Make it more human. Decide it's too human now. Realize: that uncertainty is exactly the problem Turing described.

The final Round 5 pair:

AI: "I think the complicated feeling is the honest one. The clean versions of things usually aren't real."
Human: "that's... actually kind of what I needed to hear. weird how the right words help"

I got this one wrong myself, re-reading it cold a day later.

The ending closes on Turing's real story, in four lines:

Alan Turing (1912–1954). He gave us the test to define intelligence. He was persecuted for who he loved. He was pardoned in 2013 — 59 years too late. The light he switched on for computing never went out.

June is also Pride Month. Turing was gay, and the British government chemically castrated him for it. He died at 41. We live in the world he built; the dignity he was owed never arrived in time. I didn't want to make a game that skips that.

What I Learned Building This

The Turing Test is not really about AI. It's about us. The game teaches you to look for imperfection and emotional messiness as signals of humanity. The scariest moment in playtesting was when someone pointed at a human message and said "that sounds so AI." We've started writing like the models we trained.

Simplicity is a design choice. The entire game is one HTML file and one JS file. No build step. I tried to honor Turing's own instinct: reduce the problem to its essentials.

Prize Category

Best Ode to Alan Turing — this submission honors Turing through:

Mechanics: the Turing Test isn't referenced, it is the gameplay
Historical narrative: each round anchors to a real year in AI history
Visual design: light and dark as human truth vs. machine mimicry, tied directly to the solstice
Emotional close: the full weight of Turing's contribution and the injustice he faced, during his birth month, during Pride Month

Try It

🎮 Play Turing's Mirror
💻 View the code

It takes about 5 minutes to play. The Round 5 messages will make you pause.

Built solo by Tejas Patil (@tejas164321) for the DEV June Solstice Game Jam, June 2026.
Tech: Vanilla JS · HTML5 · CSS3 · no dependencies

Why Hermes Agent Compounds While LangChain Stays Flat — A Deep Architectural Breakdown

Tejas Patil — Tue, 26 May 2026 04:49:17 +0000

This is a submission for the Hermes Agent Challenge

Every AI agent framework promises to make your agent "smarter." Most of them are lying — not maliciously, but structurally. They build a better loop, a cleaner abstraction, a faster tool-calling interface. And then the 1,000th time your agent runs a task, it performs exactly the same as the first time.

Hermes Agent does something different. It gets better.

That's not marketing. It's a specific architectural claim with measurable evidence behind it, real limitations, and a genuine reason it matters to developers who are serious about deploying agents in production. This piece is my attempt to explain it precisely — including the parts that are overstated.

The Three-Tier Framework You Need to Understand

Before Hermes makes sense, you need a mental model of where it sits in the agent landscape. I've found this three-tier classification genuinely clarifying:

Tier 1 — Hosted runtimes (OpenAI Agents, Anthropic Agents)
These are managed cloud services. Excellent defaults, lowest setup friction, zero self-hosting. The tradeoff: you can't run them on your own infrastructure, your data leaves your perimeter on every call, and the agent's "memory" is whatever the provider chooses to expose through their API.

Tier 2 — Orchestration libraries (LangChain, CrewAI, AutoGen, LlamaIndex)
These are the workhorses of the current AI agent ecosystem. They're flexible, model-agnostic, community-supported, and widely understood. But they're stateless per-run by default. Each task execution starts from the same baseline. The agent has no memory of having done something similar before, no learned shortcuts, no accumulated expertise. You can add memory manually, but it's bolted on — not baked in.

Tier 3 — Runtime agents with persistent memory, learning, and deployment in the same binary
This tier barely existed until 2026. OpenClaw proved the concept. Hermes Agent, released by Nous Research on February 25, 2026, is the first fully MIT-licensed Tier 3 runtime.

The architectural implication of Tier 3 is significant: the agent's capability is not static. It compounds with use.

What "Compounding" Actually Means (With the Math)

Here's the specific mechanism. After any task that involves 5 or more tool calls, Hermes Agent does something Tier 2 frameworks don't:

Observe the completed workflow — what tools were called, in what order, with what parameters
Abstract it into a skill document — a structured Markdown file following the agentskills.io open standard
Index it into memory — now searchable and loadable for future sessions
Apply it next time — when a similar task appears, the agent loads the relevant skill instead of reasoning from scratch

The performance claim from Nous Research's internal benchmarks: agents with 20+ self-created skills complete similar tasks 40% faster than fresh instances. This is a specific, bounded claim — not "40% better output quality" but "40% less token consumption and wall-clock time to reach equivalent output."

This distinction matters. The gain is efficiency, not intelligence. The agent isn't smarter — it's not re-doing work it's already learned to do. That's actually a more reliable improvement than "smarter" would be.

The honest caveat

Cross-domain generalization doesn't transfer. A skill learned from summarizing GitHub PRs does not help the agent plan a database migration. The skill library is domain-specific. If you're running a general-purpose agent across wildly varied tasks, the compounding effect is weaker than if you're running a focused agent on a narrow, repeated workflow.

Hermes doesn't claim to solve cross-domain generalization. Nobody has. The compounding advantage is real within a domain, limited across domains.

The execute_code Tool: The Feature Everyone Underestimates

Every agent framework has tools. Hermes has one that changes the economics of complex tasks in a way most write-ups miss: execute_code.

Standard agentic tool use looks like this:

Turn 1: Call tool A → get result
Turn 2: Call tool B with result → get result
Turn 3: Call tool C → get result
Turn 4: Call tool D with results from B and C → final output

Each turn requires a full model forward pass. On a complex 20-step workflow, that's 20 forward passes, 20 rounds of context building, and the token cost grows with every step.

execute_code collapses this. The agent writes a Python script that calls other Hermes tools directly via a local RPC bridge. The entire multi-step workflow executes as a single model turn:

# Hermes writes and executes this as one turn
import hermes_tools

# Tool calls via RPC — no new model turns needed
repos = hermes_tools.search_github(query="agent frameworks 2026", limit=10)
summaries = [hermes_tools.fetch_url(r['url']) for r in repos]
analysis = hermes_tools.analyze_text(summaries, focus="security model")
hermes_tools.write_file("agent_security_analysis.md", analysis)

The model thinks once, plans the entire workflow, executes it in code, and returns the result. For research pipelines, data processing workflows, and multi-step automations, this is dramatically more efficient than the standard turn-by-turn approach.

The Architecture That Makes Self-Hosting Safe

One of the underreported stories around Hermes is its security model, especially compared to OpenClaw which has had multiple CVEs in 2026 (including CVE-2026-25253 for unsafe WebSocket token exposure and documented supply-chain issues).

Hermes ships with:

Read-only root filesystems — the agent can't modify system files even if a malicious tool tries
Dropped Linux capabilities — privilege escalation attack surface is minimized at the kernel level
Namespace isolation — each execution environment is isolated
Tirith pre-execution scanner — prompts are scanned for injection attempts before any tool call executes

This isn't just checkbox security. For developers running Hermes agents against internal codebases, company documentation, or databases that contain sensitive data, these defaults matter enormously. The agent getting a malicious instruction through an injected document should not be able to exfiltrate credentials or modify system state. Hermes is designed to fail safely.

The Bidirectional MCP Story

Version 0.6.0 of Hermes Agent added something architecturally interesting: it can now act as an MCP server, not just an MCP client.

Most agent MCP integrations are one-directional — the agent calls external MCP servers to access tools. Hermes flips this. A development team running Claude Code, Cursor, or VS Code with an MCP-compatible AI assistant can route specific tasks to a locally running Hermes instance via MCP.

The practical implication: you don't have to choose between Hermes and your existing AI stack. You can use Claude for primary reasoning and interface, while delegating long-running autonomous tasks — research pipelines, multi-step file operations, scheduled workflows — to Hermes as a specialized subagent. Hermes runs on your infrastructure, accumulates skills in your domain, and handles the stateful long-horizon work that session-based cloud agents don't do well.

This bidirectional capability is genuinely new in the open-source agent landscape. It's not in AutoGPT, LangChain, or CrewAI.

Setting Up Hermes: What the First 30 Minutes Actually Look Like

# Install
pip install hermes-agent

# Configure with your preferred model (works with any OpenAI-compatible endpoint)
hermes configure --model claude-sonnet-4-20250514 --api-key YOUR_KEY

# Or use a local model via Ollama
hermes configure --model ollama/llama3.1 --base-url http://localhost:11434

# Start the agent
hermes start

# Set a persistent goal (works across multiple turns)
/goal Research and summarize the top 5 open-source agent frameworks released in 2026, focusing on security models and self-improvement capabilities. Save the result as research/agent_frameworks_2026.md

# The agent will work on this goal autonomously until a judge model determines it's complete
# If it involves 5+ tool calls, it writes a skill document for future reuse

For the multi-channel gateway:

# v0.10.0 — single gateway serves all channels
hermes gateway start \
  --telegram-token YOUR_TOKEN \
  --slack-webhook YOUR_WEBHOOK \
  --discord-token YOUR_TOKEN

When to Use Hermes vs the Alternatives

Use Hermes Agent when:

You have a focused domain with repeated workflows (research, code review, data processing, content pipelines)
Self-hosting and data sovereignty are requirements
You want the agent to become more efficient over weeks and months of use
You need a long-running autonomous agent, not a session-based one
You're integrating with an MCP-based stack and want bidirectional compatibility

Use LangChain/LangGraph when:

You need maximum framework flexibility and ecosystem breadth
You're building a custom, highly specific agent architecture from scratch
You have existing LangChain infrastructure and migration cost is real

Use OpenClaw when:

You need immediate access to 5,700+ community skills covering diverse domains
Rapid time-to-value matters more than long-term optimization
You've evaluated and accepted the security tradeoffs (or applied the relevant CVE patches)

Use OpenAI/Anthropic hosted agents when:

Setup friction matters more than data sovereignty
You don't need persistent memory or self-improvement
The task is session-bounded and doesn't recur

What 95,000 Stars in 10 Weeks Tells You

Hermes Agent crossed 95,600 GitHub stars within roughly ten weeks of launch — a trajectory matched only by a handful of open-source projects in AI history. That growth rate is a signal, not just a vanity metric.

The developers starring Hermes Agent are not AI hobbyists. They're practitioners who have spent time with LangChain, run OpenClaw in production, and know exactly what gaps they're looking for. When that community signals this strongly about a new framework, the gap being filled is real.

The gap Hermes fills is the compounding problem. Every serious developer who has built a production AI agent has eventually hit the same wall: the agent is as good on day 300 as it was on day 1. All the prompt engineering, all the tool integrations, all the careful orchestration — none of it makes the agent better at the specific workflows you've taught it to do. It stays flat.

Hermes Agent is the first MIT-licensed system that is architecturally designed to solve this. Whether it fully delivers over long deployment horizons — and whether the skill compounding holds up across diverse real-world tasks — is still being validated by the community. Three months is not enough time to know.

But the architecture is right. And the 95,000 stars suggest that developers who have been waiting for this design to exist in open-source form agree.

Resources

Hermes Agent official site — full docs, setup guide
agentskills.io — open standard for portable agent skills
Hermes Agent GitHub — MIT licensed
v0.10.0 release notes — 118 bundled skills, 6-channel gateway

Have you run Hermes Agent on a real workflow? I'm particularly curious about skill compounding in practice — whether the 40% efficiency claim holds in your domain. Drop your experience in the comments.

How I Finally Shipped FinPal — Reviving My AI Finance App for 350M UPI Users with GitHub Copilot

Tejas Patil — Mon, 25 May 2026 06:31:57 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

FinPal is an AI-powered personal finance companion built specifically for India's UPI ecosystem — the world's largest real-time payments network with over 350 million active users.

The problem it solves is real and largely ignored by mainstream finance apps: if you're an Indian user, your transaction history is scattered across Google Pay, PhonePe, Paytm, and your bank's PDF statements. There is no single place to see it all, categorize it, and actually understand where your money goes. Western apps like Mint or YNAB don't understand UPI. Indian banking apps don't talk to each other.

FinPal does. Upload your GPay history CSV, your bank statement PDF, or your PhonePe export — and it parses, categorizes, and analyzes everything in one dashboard using a hybrid rule-based + Google Gemini AI system.

Tech stack: React 18 + TypeScript, Vite, TailwindCSS, shadcn/ui, Framer Motion, Recharts, Node.js + Express backend, Google Gemini AI, Radix UI.

Repo: github.com/Tejas164321/FinPal

Demo

🔗 Live app: finpal.tejasfolio.in

The dashboard shows real financial overview cards, interactive monthly trend charts, category breakdowns, and budget progress tracking. The Transactions page now accepts CSV/PDF uploads, the AI Insights tab runs live Gemini analysis, the Budgets page has full CRUD, and the Investments page has working SIP/FD calculators.

The Comeback Story

Where It Was: The Beautiful Graveyard

Three months ago, I had 137 commits and a project that looked stunning from the outside and was completely hollow on the inside.

The homepage was polished. The dashboard rendered beautiful charts with mock data. The glassmorphism dark UI was exactly what I'd envisioned. And then there were four pages — Transactions, Budgets, AI Insights, and Investments — that each showed a placeholder:

🚧 Coming Soon
This feature is under development

The backend existed (/server) with file processing architecture — multer for uploads, csv-parser, pdf-parse, xlsx — all wired up to handle UPI file formats. But it wasn't connected to anything on the frontend. The Gemini AI integration was marked in the README as "architecture prepared." The SIP calculators were listed under "Future Enhancements."

I'd built the skeleton of something genuinely useful and then got buried in other work. The repo sat there with its four placeholder pages, deployed but empty.

Why It Stalled

The honest reason: I built FinPal in a sprint and the codebase grew faster than my documentation. Coming back to it after two months felt like picking up someone else's project. The component tree was deep. The custom hooks were tightly coupled to mock data. I knew what I wanted to build — I just couldn't remember how I'd set everything up, and re-reading 137 commits of history to reconstruct the mental model felt like a week of work before writing a single line.

That's where GitHub Copilot changed everything.

What Changed: The Before → After

Transactions Page

Before: Placeholder page with a "Coming Soon" card
After: Drag-and-drop file upload zone (CSV/PDF/Excel), transaction table with pagination, AI/Rule source indicators per row, search and filter, real-time parsing status

Budgets Page

Before: Empty shell
After: Budget creation form with category selection, progress bars with percentage tracking, over-budget alerts, monthly reset logic, edit/delete functionality

AI Insights Page

Before: Listed in README as "Gemini-powered analysis and chat — architecture prepared"
After: Live Gemini API integration, spending pattern analysis cards, natural language chat interface, personalized recommendations based on actual uploaded transactions

Investments Page

Before: "SIP calculators and portfolio comparison" listed under Future Enhancements
After: SIP calculator with compound interest visualization, FD calculator, maturity comparison chart, editable parameters with real-time chart updates

Backend

Before: Server folder existed with file processing modules but no connected API routes
After: /api/upload endpoint fully wired, transaction parsing pipeline connected to frontend, Gemini analysis endpoint live

My Experience with GitHub Copilot

This is the part I want to be specific about, because "Copilot helped me write code faster" is a nothing statement. Here's what it actually did.

1. Re-onboarding to My Own Codebase

The first thing I did after reopening the project was open GitHub Copilot Chat and ask:

"Explain the data flow in this codebase from a file upload to displaying transactions on the dashboard. Reference the actual files."

Copilot walked me through server/server.js → server/processors/ → the React Query hooks in src/hooks/ → the dashboard component. It took 4 minutes to get back the mental model that would have taken me hours of reading commits. That alone was worth it.

2. Generating the Transaction Parser

The most complex piece was the UPI transaction parser. Different banks export CSV in completely different formats. GPay's export has different column headers than HDFC Bank's statement. Copilot generated the initial parsing logic:

// Copilot generated this parsing strategy after I described the problem
const detectFormat = (headers: string[]): 'gpay' | 'phonepe' | 'hdfc' | 'sbi' | 'generic' => {
  const headerStr = headers.join(',').toLowerCase();

  if (headerStr.includes('transaction id') && headerStr.includes('upi')) return 'gpay';
  if (headerStr.includes('transaction ref') && headerStr.includes('phone')) return 'phonepe';
  if (headerStr.includes('narration') && headerStr.includes('chq/ref')) return 'hdfc';
  if (headerStr.includes('txn id') && headerStr.includes('ref no')) return 'sbi';
  return 'generic';
};

const normalizeTransaction = (row: Record, format: string): Transaction => {
  const formatMap = {
    gpay: { date: 'Date', amount: 'Amount (INR)', description: 'Description', type: 'Transaction Type' },
    phonepe: { date: 'Date', amount: 'Amount', description: 'Transaction Details', type: 'Type' },
    hdfc: { date: 'Date', amount: 'Withdrawal Amt.', description: 'Narration', type: null },
    sbi: { date: 'Txn Date', amount: 'Debit', description: 'Description', type: null },
    generic: { date: 'date', amount: 'amount', description: 'description', type: 'type' }
  };
  // ... normalization logic
};

I described the problem — multiple CSV formats, need a normalizer — and Copilot drafted this structure. I modified the field mappings and added error handling. What would have been 2 hours of trial-and-error across real bank exports took 25 minutes.

3. The Gemini AI Integration

The AI Insights page needed Gemini to analyze spending patterns and return structured recommendations. I prompted Copilot:

"Write a function that sends transaction data to Google Gemini and returns categorized spending insights as structured JSON."

const analyzeWithGemini = async (transactions: Transaction[]): Promise => {
  const prompt = `
    Analyze these UPI transactions for an Indian user and return a JSON object with:
    - topCategories: array of {category, amount, percentage, trend}
    - savingsOpportunity: string (specific actionable tip)
    - unusualSpending: array of flagged transactions
    - monthlyComparison: {current, previous, change}

    Transactions: ${JSON.stringify(transactions.slice(0, 50))}

    Respond ONLY with valid JSON, no markdown.
  `;

  const result = await genAI.getGenerativeModel({ model: 'gemini-pro' }).generateContent(prompt);
  return JSON.parse(result.response.text());
};

The key insight Copilot helped me land: constraining the output to JSON and specifying the exact schema in the prompt. My initial attempts returned markdown-wrapped JSON that broke the parser. Copilot suggested the "Respond ONLY with valid JSON" constraint after I described the problem.

4. SIP Calculator with Live Chart

The investments page needed a SIP calculator where changing the inputs updates the chart in real time. Copilot wrote the compound interest formula and the Recharts integration in one shot:

const calculateSIP = (
  monthlyAmount: number,
  annualRate: number,
  years: number
): SIPResult[] => {
  const monthlyRate = annualRate / 12 / 100;
  const months = years * 12;

  return Array.from({ length: months }, (_, i) => {
    const month = i + 1;
    const invested = monthlyAmount * month;
    const returns = monthlyAmount * 
      ((Math.pow(1 + monthlyRate, month) - 1) / monthlyRate) * 
      (1 + monthlyRate);

    return {
      month,
      invested,
      returns: Math.round(returns),
      gain: Math.round(returns - invested)
    };
  });
};

I connected this to a useState hook for the inputs and wired the output directly to a Recharts AreaChart. The real-time update as you slide the monthly amount input is one of the most satisfying moments in the whole app.

5. What Copilot Couldn't Do

In the spirit of honesty: Copilot didn't understand the UPI-specific domain context without heavy prompting. It generated generic "credit/debit" category logic that missed obvious Indian patterns like "Swiggy" → Food Delivery, "IRCTC" → Travel, "Zepto" → Groceries. I had to build the Indian merchant categorization rules manually — a lookup table of ~80 common UPI merchant patterns. Copilot helped me structure it, but the domain knowledge was mine.

It also occasionally hallucinated Recharts API props that don't exist. Cross-referencing the Recharts docs was still necessary. Copilot is a fast first draft, not a final implementation.

The Numbers

Metric	Before	After
Feature pages working	2 of 6	6 of 6
Lines of code added	—	~2,400
API endpoints connected	0	4
Time to finish (with Copilot)	Estimated 3 weeks	8 days
File formats supported	0	4 (GPay, PhonePe, HDFC, SBI)

Why FinPal Matters

350 million Indians transact on UPI every month. The average urban Indian does 40+ UPI transactions monthly — food delivery, transport, groceries, rent. All of it flows through 3-4 different apps with no unified view.

FinPal is the tool I wanted and couldn't find. It's not a generic expense tracker. It's built for the specific reality of how Indian digital payments work: the merchant names, the UPI IDs, the bank statement formats, the SIP culture, the FD-first savings mentality.

GitHub Copilot helped me finish it in 8 days instead of 3 weeks. More importantly, it helped me pick up a codebase I'd half-forgotten and start shipping immediately instead of spending days just getting reoriented.

The project is live. The placeholder pages are gone. FinPal is finally FinPal.

🔗 Live Demo: finpalai.vercel.app
📦 Repo: github.com/Tejas164321/FinPal

If you're an Indian developer building for the UPI ecosystem, I'd love to connect. Drop your thoughts in the comments — especially if you've tried parsing HDFC/SBI statements. The column naming inconsistencies deserve their own post.

DEV Community: Tejas Patil

How UPI Works: The ₹0 Magic Behind Every Scan-and-Pay (System Design)

The chai stall

Meet the cast

The journey of ₹20, in motion

Wait, so what is Google Pay?

What NPCI actually does

The clever ideas inside

When things go wrong

Did the banks actually move money?

How does one switch survive 791 million hits a day?

Five things to remember

Next in the series

Your phone is not an RTX 4090. This open model knows that.

What I Built

Demo

How I Built It

Did it work?

Why Does Open Innovation Matter?

My First User

Prize Categories

The Last Time I Googled an Error Message

The part that bugs me

Two questions

My Code Works. An AI Wrote It. Neither of Us Knows Why.

The old version was funny because it was temporary

The numbers are genuinely wild

Meanwhile, at the top

The part I actually think about

Your turn

Pawscript - Your Dog's Letter to You

What I Built

Demo

Code

Tejas164321 / Pawscript

Pawscript. Upload a photo of your dog - optionally with a bark, whine, or sigh - and Gemini reads the actual photo (and sound, if given) and writes a short, warm letter in your dog's own voice, plus a few honest "Tail Tell" observations about their visible posture and expression.

How I Built It

Prize Categories

I Chased a Data Bug for an Afternoon. It Was Never About the Data.

The Setup

Chasing the Wrong Suspect

The Parameter That Wasn't Doing Anything

Why force-cache Is a Trap

Making Sure I Wasn't Just Telling Myself a Nice Story

The Fix

What I'd Actually Tell Someone About This

Vada Pav - An Interactive Landing Page for Mumbai's Favorite Street Food

What I Built

Demo

Journey

Fixing a Silent Cache Bug in npmx.dev

The bug

Chasing it down

The fix

Verifying it

What I'd take from this

FinPal - I Built a Finance App You Can Actually Ask Questions To

What I Built

Why This

The Product

Demo

Live

Code

How I Built It

Prize Category: Best Use of Google AI

Closing

Sources

Turing's Mirror - A Game About the Question We Still Haven't Answered

What I Built

Video Demo

Why Alan Turing, Why Now

The Game Design — Light, Dark, and the Solstice

Code

Tejas164321 / Turing-s-Mirror

Turing-s-Mirror

How I Built It

What I Learned Building This

Prize Category

Try It

Why Hermes Agent Compounds While LangChain Stays Flat — A Deep Architectural Breakdown

Why `force-cache` Is a Trap