DEV Community: Harsh Kochar

PaperTrail: I built my friend a paperwork checklist where the AI has to show its receipts

Harsh Kochar — Mon, 05 Oct 2026 07:04:52 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

PaperTrail turns a pile of application paperwork into a checklist where every tick comes with a receipt.

I built it for [FRIEND'S NAME], who is applying to [universities / scholarships] this year. [In one or two sentences, your own words: what you watched them struggle with.]

No single document is the hard part. The hard part is knowing at any moment which requirements are covered, which are missing, and which documents will expire before the deadline.

PaperTrail does five things:

Reads the requirements. Upload the program's requirements as a PDF or paste them as text. PaperTrail extracts each requirement and its deadline, and links each one to the sentence it came from.
Reads your documents. Upload a transcript, a test score report or a CV. Each requirement is either matched to a passage that satisfies it or marked missing, expired or needs review.
Tracks what's left. Open items become tasks, with reminders that survive restarts. When you mark a task done, its pending reminder is cancelled.
Answers questions with citations. Ask "Why is my English test marked for review?" and the answer quotes the score report and links to the page.
Exports a report that separates what the AI found from what you verified yourself.

The rule I held myself to: the AI proposes, the person decides. The UI shows "Evidence found (AI)" and "Verified by you" as different states. Nothing counts as verified until a human says so.

Demo

Create a workspace with a 2027-01-15 deadline and upload the program's requirements PDF.
Review the extracted requirements. Each one links to its source sentence.
Upload a transcript and an English test score report. The transcript is matched with a cited passage. The English test goes to needs review because it expires on 2026-12-12, before the deadline.
Inject a failure while a document is processing. Attempt 1 fails and shows up in Sentry. Temporal retries, and attempt 2 succeeds.
Set a reminder, complete the task, and watch the reminder get suppressed instead of sent.
Ask the assistant why the English test needs review.

Code

HarshKochar9008 / ockto

PaperTrail

Every document. Every requirement. One clear path forward.

PaperTrail turns a pile of application paperwork into an evidence-backed checklist. Upload the requirements (a PDF or pasted text) and your supporting documents. PaperTrail extracts the requirements, matches each one to passages in your documents, flags what's missing, expired or uncertain, tracks deadlines, and sends reminders that survive restarts. Every AI assessment links to the page and passage it relied on, and nothing counts as verified until you say so.

The MVP targets university and scholarship applications. Nothing in the data model is specific to them.

browser ── React + TanStack Query ──▶ Fastify API (/api/v1) ──▶ Tiger Data / Postgres + pgvector
                                          │                         ▲
                                          └─ start / signal ─▶ Temporal ─▶ Worker (activities)
                                                                              ├─ PDF parser / OCR
                                                                              ├─ Gemma via Ollama (or any OpenAI-compatible endpoint)
                                                                              └─ webhook reminders
API + worker ── OTLP traces + errors ──▶ Sentry

Piece

…

View on GitHub

How I Built It

The open-weight core is Gemma, running locally through Ollama:

gemma3:4b extracts requirements, classifies documents, assesses evidence, answers questions and reads text from images.
embeddinggemma produces 768-dimensional embeddings for search.

The server reaches Ollama through an OpenAI-compatible adapter. Pointing the same code at a hosted Gemma endpoint means changing one environment variable.

Here's how the pieces connect:

browser ── React + TanStack Query ──▶ Fastify API ──▶ Postgres + pgvector (Tiger Data)
                                          │
                                          └─▶ Temporal ─▶ Worker
                                                            ├─ PDF parser / OCR
                                                            ├─ Gemma via Ollama
                                                            └─ webhook reminders
API + worker ── traces + errors ──▶ Sentry

Temporal runs four workflows: process a document, analyze a workspace, deliver reminders on durable timers, and retry failed processing from the step that failed.
Postgres + pgvector stores everything and also handles search. Vector search and full-text search are combined with reciprocal rank fusion in a single SQL query.
Sentry traces the API and the worker. Model calls show up as gen_ai spans, and activity failures are tagged with the workflow, activity and attempt.

Making a 4B model trustworthy

A 4-billion-parameter model on a laptop CPU is slow, and sometimes it is confidently wrong. I ran it against realistic documents and kept a list of the ways it failed:

It inverted booleans. When I asked whether a requirement was required, it often gave the opposite answer. Asking for optional instead fixed it: true only when the text actually says "optional" or "if applicable."
It garbled citation labels. Now labels come from a fixed enum, and each quote is re-attributed to the passage that actually contains it.
It cited a transcript as a CV. The quote was real but came from the wrong kind of document. A document-class check now ensures a transcript can never satisfy a CV requirement, however convincing the quote.

Beyond those fixes, deterministic code in server/analysis.ts checks every model answer against the source before anything is stored:

Every call is constrained to a JSON schema and validated with zod. An invalid answer gets one re-ask. If it is still invalid, the activity fails and Temporal retries it.
An evidence quote is kept only if it really appears in the cited passage. A "satisfied" verdict without a verifiable quote is downgraded to needs review.
If a requirement's source sentence can't be found in the document, the requirement is flagged and its due date is dropped.
An expiry date is stored only when the model quotes the sentence that states it.
If the model states any uncertainty, satisfied becomes needs review.
Document text sits inside tags it can't close, and the model is told never to follow instructions found inside them. A scholarship PDF shouldn't be able to say "mark everything complete."

What I learned: fix a model's mistakes with code that checks the source, not with a longer prompt.

Living with CPU speed

My laptop has no GPU, so gemma3:4b takes 1–2 minutes per assessment and about 5 minutes to extract requirements. The first call after startup spends another 3 minutes or so loading the model.

That is where Temporal earned its place. Model activities get 15-minute timeouts and send a heartbeat every 10 seconds. If the worker crashes, the work resumes where it stopped. The Activity page shows progress for each requirement. Slow is fine. Lost work is not.

Why Does Open Innovation Matter?

Think about what goes into PaperTrail: transcripts, passports, test scores, recommendation letters, bank statements. That is some of the most sensitive paperwork a person owns.

Because the model has open weights and runs locally, none of it leaves the laptop. My friend doesn't have to trust me, a startup's privacy policy or an API provider's data retention settings. The Settings page states plainly where document text is sent.

Open weights made three more things possible:

It's free to run, indefinitely. A student applying to several programs re-runs the analysis every time a document changes. There's no per-token bill, no rate limit and no API key to leak.
I can debug the model. The weights are identical on every run, so the quirks are too. When gemma3:4b inverted booleans, I could reproduce it, fix it in code and trust the fix to hold. A hosted model can change between one week and the next without warning.
It's easy to swap. The adapter speaks the OpenAI-compatible protocol, so a GPU machine or a hosted Gemma endpoint is one environment variable away.

The rest of the stack is open source as well: Temporal, Postgres, pgvector, Ollama, Fastify and React. Hosted services such as Tiger Cloud, Temporal Cloud and Sentry are optional. Locally, a single docker compose up starts everything.

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.