DEV Community: Harsh Kochar

Meet Flywheel — I Turned My Daily Habit Into Fire You Can Actually Own

Harsh Kochar — Mon, 13 Jul 2026 06:37:17 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Everyone says "consistency is everything," then loses the streak in a spreadsheet nobody opens again. A habit — a craft, a team, a side project — deserves proof that outlives the app you tracked it in.

Flywheel is a Solana devnet app that turns a daily streak into a badge you actually own. Declare something you refuse to miss a day of, check in, and when you cross a threshold, mint the streak as an on-chain trophy that lives in your wallet — not in my database.

Here's the loop:

🔥 Declare a habit — name it, pick a category, pick an emblem
✅ Check in daily — miss a day and the streak resets; the badges you already minted don't
🏅 Four tiers to earn — Spark (7 days), Motion (30), Momentum (100), Unstoppable (365)
⛓️ Immortalize it — one click mints a Metaplex Core NFT straight to your Phantom wallet, with a live Solana Explorer link
🃏 Trophy Shelf — a flip-card gallery that reads badges from the chain, not local storage — clear your browser and they're still there

Everything runs on Solana devnet with free airdropped SOL, on purpose — this is about proving the habit, not spending money on it.

What Inspired This

I have a graveyard of streaks that only ever lived in my own head: a run of gym mornings, a stretch of daily commits, a season of never missing a match. Every one of them evaporated the moment I stopped believing my own memory of them — no proof, no receipt, nothing to show for the discipline once the feeling faded.

The "passion" theme made me want to build the opposite of a vanity metric. Not a streak counter that resets your pride to zero the day you forget to open the app, but something that keeps the momentum — the flywheel — spinning even after you've moved on. If a habit is real, it should survive outside your own head, verifiable by anyone, on a ledger that doesn't care whether you're still paying attention.

Demo

🔗 Live → [https://flywheel0.vercel.app/]

How I Built It

Layer	Tech
Frontend	React 19 + TypeScript + Tailwind v4 + Vite
Wallet	`@solana/wallet-adapter-react` (Phantom, devnet)
Mint	Metaplex Umi + `mpl-core` — one Core asset per badge
Art	Badge SVGs generated per tier, uploaded via Irys
State	Streaks live in `localStorage`; badges live on-chain

The chain is the only source of truth that matters. The Trophy Shelf never trusts local state — it queries devnet RPC for Core assets owned by the connected wallet. I could wipe every cookie on my machine and my Momentum badge would still be sitting in my wallet, because that's the entire point of the project.

The part I'm proudest of is the failure handling. Metadata upload to Irys can time out — so after 60 seconds the mint falls back to static metadata served from the app itself, logs it loudly, and still lands on-chain. Faucet rate-limited mid-demo? Retry button, no crash. The ownership and the mint are never fake; only the JSON description occasionally takes the scenic route.

There's also a hidden time machine (Ctrl+Shift+D) that fast-forwards the clock and simulates check-ins so a 365-day streak can be demoed live in ninety seconds — it can shift time, but it can't fake a single thing on-chain.

Why It's Passion

The theme was "passion," and the easiest interpretation is a fan page. I wanted proof instead of a page. A streak that only lives in an app's database is a vibe. A streak minted as a wallet-owned, Explorer-verifiable NFT is a receipt — and receipts are what separate "I say I'm passionate" from "here's 100 days, audit it yourself."

My own longest streak while building this was the project itself: several days of shipping straight through, no missed check-ins, until the Unstoppable tier stopped being hypothetical.

Built solo in a weekend. Momentum, proven daily.

— Harsh Kochar (harshkochar88@gmail.com)

Branch Your Database Like You Branch Your Code

Harsh Kochar — Thu, 09 Jul 2026 05:25:51 +0000

Stop Testing Migrations in Production: Why Database Branching Changes Everything

If you've ever run git checkout -b feature/new-schema and felt a little too confident about it — only to realize your database doesn't work the same way your code does — you know the problem. Branching solved collaboration for code decades ago. Your database is still stuck in 2005.

Neon fixes that. With database branching, you can create a full, isolated copy of your Postgres database in seconds — not by cloning terabytes of data, but by taking a lightweight snapshot of the current state. It works the same way git branch works for code: cheap, instant, and disposable.

The problem with "just use a staging database"

Most teams handle this today with one of three approaches, and all of them hurt:

A shared staging database. Someone runs a migration, it breaks another engineer's feature branch, and now three people are debugging the same broken table.
Spinning up a fresh database per environment. This means writing seed scripts, waiting for provisioning, and hoping your synthetic data resembles production closely enough to catch real bugs.
Testing directly against production (or a stale nightly dump). Fast, but terrifying — and stale data means your tests don't reflect what's actually happening in the app.

None of these give you what you actually want: a real copy of your production data, isolated from everyone else, that you can throw away when you're done.

How branching works under the hood

Neon separates storage from compute. Your data lives in a multi-version, copy-on-write storage layer, not tied to a single running instance. When you create a branch, Neon doesn't copy your data — it creates a new pointer into that same storage layer at a specific point in time.

That means:

Branch creation takes seconds, regardless of database size. A 5GB database and a 500GB database branch in roughly the same amount of time.
Branches are copy-on-write. You only pay for the data that diverges from the parent branch, not a full duplicate.
Every branch is a fully functional Postgres database. Same connection string format, same extensions, same behavior — nothing to relearn.

You can create a branch from main, from another branch, or from a specific point in time — which means you can also use branching to recover a table you accidentally dropped ten minutes ago, without restoring the entire database.

What this looks like in practice

Per-PR preview databases. Wire branch creation into your CI pipeline so every pull request gets its own database branch, seeded with real (or anonymized) production-like data. Your preview deploy and your database preview deploy together. When the PR closes, delete the branch.

# Create a branch for a new feature
neon branches create --project-id your-project-id --name feature/add-invoicing

# Get the connection string and point your app at it
neon connection-string feature/add-invoicing

Safe migration testing. Branch from main, run your migration against the branch, verify it does what you expect, then run it against production with confidence. No more crossed fingers.

Instant rollback for experiments. Try a risky schema change, a bulk data transformation, or a new indexing strategy on a branch. If it doesn't work, delete the branch — production was never touched.

Reproducing bugs with real data. Branch from the exact point in time a bug was reported, and debug against the data as it actually existed — not a guess at what might have caused it.

Getting started

Branching is built into every Neon project — there's no separate feature to enable. From the console, the CLI, or the API:

neon branches create --project-id your-project-id --name my-branch

Or straight from a point in time, if you need to look backward:

neon branches create --project-id your-project-id --timestamp "2026-07-01T12:00:00Z"

Each branch gets its own compute endpoint and connection string, so it plugs into your existing workflow without any special handling in your application code.

The bigger idea

Branching isn't just a nice developer-experience feature bolted onto Postgres — it's what becomes possible once you stop treating storage and compute as one inseparable unit. When creating a database is as cheap and fast as creating a Git branch, it stops being a thing you plan around and starts being a thing you do constantly, without thinking twice.

Give it a try on your next PR. It's a small habit change with an outsized effect on how confidently your team ships schema changes.