DEV Community: Sanjay Kumar Sah

PlateMate — Dietary Safety & Allergen Intelligence Powered by TabPFN

Sanjay Kumar Sah — Sat, 03 Oct 2026 15:35:51 +0000

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

What I Built

I built PlateMate, a dietary safety intelligence platform designed for my close friend and roommate, Alex.

The Problem

Alex lives with two life-altering dietary restrictions:

Strict Celiac Disease: Ingesting even 20 parts per million of gluten (a microscopic crumb from a shared toaster or frying oil) triggers an autoimmune attack that damages their small intestine.
Peanut Anaphylaxis: Exposure to trace peanut proteins or cross-contact causes acute airway constriction requiring an emergency EpiPen.

Dining out or ordering takeout with friends was always an ordeal of anxiety, awkward interrogations of busy restaurant servers, and squinting at cryptic ingredient labels.

The Solution

PlateMate gives Alex instant, mathematically calibrated safety confidence before taking a single bite:

Diagnostic Food Scanner: Evaluates full meals, recipe ingredients, and packaged goods against Alex’s specific allergy rules.
Calibrated Risk Index (0–100): Displays an exact probability of safety versus hazard.
Hidden Chemical Derivative Detection: Catches sneaky gluten and peanut additives (e.g., modified wheat starch in balsamic glaze, barley malt extract in granola bars).
Kitchen Substitution Engine: Automatically suggests chef-friendly swaps (e.g., swapping soy sauce for gluten-free tamari).
Multilingual Dining Passports: Instantly creates printable and mobile-ready chef instruction cards in 5 languages (English, Spanish, Italian, Japanese, and French) to ensure safe dining when traveling.

Demo

🌐 Live Deployed Application: https://plate-mate-alpha.vercel.app/

Application Highlights

Real-Time Scanner: Select any curated dish or enter raw ingredients to see the TabPFN neural risk score update instantaneously.
TabPFN AI Laboratory: Inspect raw in-context tabular feature vectors, calibrated posterior distributions ($P(\text{Safe})$, $P(\text{Caution})$, $P(\text{Dangerous})$), and anomaly scores.
Medical Defense Matrix: Fine-tune allergen sensitivity weights (anaphylaxis vs. intolerance) and maintain custom banned ingredients.
Server Dining Pass: Generate emergency chef cards ready to hand to restaurant staff.

Code

sanjaysah101 / PlateMate

PlateMate — Dietary Safety & Allergen Intelligence Powered by TabPFN

platemate

A production-ready Next.js project scaffolded with create-notils — Bun + Tailwind v4 + shadcn/ui on Base UI + Biome. Every file is yours to edit.

Getting started

bun install
bun dev

Open http://localhost:3000.

Quality gate

bun lint
bun typecheck
bun build

What's included

ui — shadcn/ui component kit on Base UI, with the Tailwind v4 theme
api-client — Platform-neutral HTTP transport core (createHttpClient, HttpError)

This is a fresh app — no example pages or demo flows. Add capabilities as you need them.

Structure

src/app — routes (App Router)
src/components/ui — shadcn/ui components (Base UI)
src/lib/utils.ts — the cn() helper
src/app/globals.css — the theme (tokens + dark mode)

Add or update UI components from the project root:

bun run ui:add button

Environments

One environment, configured in .env.local. .env.example is the only committed env file — the reference list of every variable this project reads with no real values;…

View on GitHub

Note: Replace your-username/dev-weekend-challenge with your GitHub repo URL.

Framework: Next.js 16 (App Router, Turbopack, React 19)
Design System: OKLCH semantic tokens, Tailwind CSS v4, shadcn/ui & Base UI
Language: TypeScript (strict mode)
Deployment: Vercel

How I Built It

Why Prior Labs' TabPFN Foundation Model?

Standard generative LLMs are prone to conversational hallucinations and confabulate safety figures, while static keyword matching completely misses non-linear chemical synonyms.

Medical allergen safety is fundamentally a structured tabular prediction and anomaly detection problem. PlateMate is built around Prior Labs' TabPFN (Tabular Prior-Data Fitted Network).

The 6-Dimensional Tabular Feature Space

Every ingredient in a meal is vectorized into a structured numerical feature space:

concentrationPct: Estimated volumetric percentage in the recipe (0–100%).
processingLevel: Processing index (raw = 0.0, ultra-processed/hydrolyzed = 1.0).
facilityCrossContact: Shared equipment and commercial fryer probability (0.0–1.0).
molecularDistance: Biochemical derivative distance from raw trigger allergen.
friendSensitivityWeight: Alex's customized clinical sensitivity (anaphylactic vs. mild).
hiddenAdditiveScore: Risk rating for deceptive chemical synonyms.

In-Context Learning Without Gradient Training

TabPFN evaluates these vectors against synthetic prior exemplars in milliseconds, computing exact Bayesian posterior probabilities:
$$P(\text{Safe}) \quad|\quad P(\text{Caution}) \quad|\quad P(\text{Dangerous})$$

It also calculates an Anomaly Score to isolate suspicious ingredients that fall outside normal food matrices, alerting Alex to contaminated batch risks or unusual emulsifiers.

Why Does Open Innovation Matter?

1. Health Privacy is Sacred

Dietary medical records and allergy queries are sensitive personal health information. Proprietary closed-source APIs log and harvest user prompts on corporate servers. By building with open-source foundation models and local in-context architectures, Alex's health profile and dining queries never leave the device.

2. Edge Reliability Where it Counts

Grocery store basements, subway food courts, and remote restaurants frequently suffer from zero cellular connectivity. Closed-source APIs fail in the exact moments when allergy verification is most critical. Open innovation enables resilient, local-first inference that works anywhere, anytime.

3. Transparent, Verifiable Mathematics

When an autoimmune flare or anaphylactic shock is on the line, an AI that says "Trust me, it's probably fine" is dangerous. Open tabular foundation models like TabPFN provide mathematically calibrated confidence intervals rather than black-box guesses.

Prize Categories

Best Use of TabPFN ($200 USD): PlateMate vectorizes culinary ingredients into structured 6D feature spaces, using Prior Labs' TabPFN in-context tabular foundation model to compute calibrated safety posteriors, cross-contact probabilities, and additive anomaly detection.

RentDera Is Live on Google Play — The Rent Notebook, Now on Your Phone

Sanjay Kumar Sah — Fri, 02 Oct 2026 11:27:30 +0000

After months of building in public, RentDera is now live on Google Play.

👉 Download RentDera on Google Play

This post isn't about code. It's about what RentDera is, who it's for, and why I built it.

The notebook problem

Walk into almost any rental building in Nepal and ask the landlord how much rent is due this month. Chances are they'll reach for a notebook.

That notebook holds everything: which tenant lives in which room, who paid last month, who paid only half, what the electricity meter read on the 1st, how much deposit was taken when someone moved in three years ago. It works, until it doesn't:

A page gets torn, wet, or lost.
The meter reading was written on a scrap of paper that's gone now.
A tenant says "I already paid that" and there's no receipt to settle it.
Adding up who owes what across ten rooms takes an evening with a calculator.
Nobody remembers whether the advance from Baisakh was already used.

Landlords aren't doing anything wrong. The notebook just isn't the right tool for a job that has quietly become complicated.

What RentDera does

RentDera replaces the notebook with your phone. Here's what a month looks like in the app.

Set up once. Add your building, its rooms or flats, and the tenants living in them, along with their rent and when it's due.

Bills make themselves. Every month, RentDera creates each tenant's bill automatically. Rent is already on it. Enter this month's electricity or water meter reading and the charge is worked out for you. No calculator needed.

Record what you receive. A tenant pays in full? One tap. Pays only part of it? Enter the amount, and RentDera remembers exactly how much is still owed, month after month.

Send a receipt. Share a receipt straight to the tenant over WhatsApp, Viber or any messaging app. No more "I already paid" arguments.

Send a polite reminder. Someone's late? Share a reminder with the amount and month already filled in.

See everything at a glance. The home screen shows what you've collected this month, what's still outstanding, which rooms are empty, and how your income has looked over the past year.

Track money going out, too. Record repairs, painting, utility bills and other costs. RentDera shows a simple monthly statement: money in, money out, and what's left.

Keep deposits and advances straight. Record the deposit you took when a tenant moved in, or money they paid ahead of time. RentDera keeps it separate from your income, because it isn't yours to spend, and lets you put an advance toward a month's bill when you need to.

Bring your old records with you. Already have years of history in a notebook? You can enter past deposits, advances and unpaid amounts so you start from where things actually stand, not from zero.

Made for Nepal first

Most property apps are built for landlords in America or Europe. RentDera started with the way renting actually works here:

Nepali and English. Switch the language any time.
Bikram Sambat dates. See billing months in BS, AD, or both.
Metered utilities. Electricity and water charged by meter reading are built in, not an afterthought.
Your currency. Track rent in rupees, or whatever currency you use.
Works the way rent is really paid. Partial payments, cash in hand, payments that round up and leave a little extra — RentDera handles all of it.

It's not only for Nepal. Any landlord who manages a few buildings and is tired of the notebook can use it.

What it costs

Free for one property and five units, with every feature included. No trial that runs out, no card required, no features held back.

If you manage more than that, RentDera Pro removes the limit. That's the only difference between the plans. You can see the prices for your country on the pricing page.

If you ever stop paying, nothing is deleted. Your tenants, bills and receipts stay exactly where they were.

How it was built

RentDera is a one-person project. I built it in public as part of RevenueCat's Shipaton 2026, shipping four updates in September alone and writing up the mistakes along the way. Earlier posts in this series cover the night a missing setting crashed the app, the free-tier limits that took it offline, and a sign-in bug that only appeared after release.

Getting to a public Play Store listing meant weeks of closed testing with real testers, a review that took about a week, and a lot of learning about how app stores handle payments in Nepal. It's been a long road, and it's good to finally say: it's live.

Try it, and tell me what's missing

If you're a landlord, try RentDera with one building and see if it saves you time. If you know a landlord still using a notebook — a parent, a relative, a neighbour — please share it with them.

👉 Download RentDera on Google Play

🌐 rentdera.com

I read every message. If something is confusing, missing, or just wrong, email me at support@notils.com or leave a comment below. The next version will be shaped by what landlords actually need.

Thank you to everyone who tested the early versions and followed along. This is just the start.

Building Juryza: Hackathon Judging You Can Defend

Sanjay Kumar Sah — Thu, 01 Oct 2026 05:36:17 +0000

If you have ever participated in or organized a hackathon, you already know the open secret: most hackathon judging is an accidental lottery.

A team spends 48 sleepless hours building a brilliant distributed system, only to be evaluated by Judge Alice, who strictly scores every project between a 2.0 and a 3.0. Meanwhile, another team building a simple mock UI happens to draw Judge Bob, who hands out 5.0s like candy on Halloween.

When the raw scores are averaged in an Excel spreadsheet, the second team takes home the grand prize, while the first team walks away wondering what they did wrong.

Worse, most hackathon platforms require bloated cloud subscriptions, break the moment event Wi-Fi stutters, and hide their scoring algorithms behind a proprietary black box.

We built Juryza to solve this once and for all: The self-hosted hackathon platform with judging you can mathematically defend.

Quick Roles & Features Tour

Here is a quick look at the live platform across all four key personas: organizer dashboard, blind judge scoring, the Bradley–Terry pairwise duel arena, and the Notion-style participant project editor:

juryza.vercel.app

⚡ Quick Links & Live Demonstration

🐙 GitHub Repository: https://github.com/sanjaysah101/Juryza
🎥 YouTube Demo: https://youtu.be/gfsorn4l_WI
💻 Live Local Stack (100% Offline Capable):

git clone https://github.com/sanjaysah101/Juryza.git
cd Juryza
docker compose up

Open http://localhost:8080 — no cloud account, no credit card, and zero external network calls required at runtime. The boot sequence spins up PostgreSQL 18 and Next.js 16, runs tracked Drizzle migrations, and seeds:

The DOGFOOD Fixture Event: 41 projects, 30 judges, 126 scores, duplicate submissions, and edge-case calibration data.
A Live Sandbox Event: Submissions open so you can register, create a team, and write projects immediately.
Hackathon Raptors Real Showcase (Opt-in): 31 real-world hackathons with authentic placements (SEED_SHOWCASE=1 docker compose up).

Demo Accounts Ready to Test

Role	Email	Password	What You Can Test
Organizer	`organizer@juryza.test`	`organizer-password-123`	Rubric weighting, judge assignment planner, conflict-of-interest detection, integrity dashboard
Judge A	`judge.a@juryza.test`	`judge-a-password-123`	Blind rubric scoring console & keyboard-navigated pairwise duel arena
Judge B	`judge.b@juryza.test`	`judge-b-password-123`	Proves absolute blind isolation (Judge B gets 403 on Judge A’s scores)
Participant	`participant@juryza.test`	`participant-password-123`	Notion-style block editor, slash menu, autosave, team invites
Admin	`admin@juryza.test`	`admin-password-123`	User roles, audit logs, system-wide controls

🏗️ The Architecture: Single Container, Zero Cloud Lock-In

We designed Juryza around a single foundational constraint: A hackathon platform must survive in a basement with zero internet connectivity.

┌─────────────────────────────────────────────────────────────────┐
│ Browser Client (Next.js 16 + React 19 + React Compiler)         │
│  - Notion-style Tiptap 3 Block Editor                           │
│  - Pairwise Duel Arena & Command Palette (⌘K)                   │
└───────────────────────────────┬─────────────────────────────────┘
                                │ Session Cookie / Bearer Token
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│ Next.js 16 App Router (apps/juryza)                             │
│  - Better Auth (Multi-tenant sessions, rate-limited, RBAC)      │
│  - REST API & OpenAPI 3.1 Engine (/api/openapi.json)            │
│  - Trust Boundary: handle() turns exceptions into JSON          │
└───────────────────────────────┬─────────────────────────────────┘
                                │
        ┌───────────────────────┴────────────────────────┐
        ▼                                                ▼
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Pure Domain Engines          │        │ Data Layer                   │
│  - z-score normalizer        │        │  - Drizzle ORM               │
│  - Bradley–Terry MM solver   │        │  - PostgreSQL 18             │
│  - Quadratic voting budget   │        │  - Advisory Locks & Txns     │
│  - TF-IDF similarity matcher │        │  - Ed25519 Signed Certs      │
└──────────────────────────────┘        └──────────────────────────────┘

The Tech Stack

Framework: Next.js 16 (App Router, React 19, React Compiler)
Database & ORM: PostgreSQL 18 with Drizzle ORM in an isolated monorepo workspace (packages/database)
Authentication: Better Auth with local email/password sessions, admin controls, and per-event permission hierarchies
Rich Text Engine: Tiptap 3 with custom slash commands, floating toolbar, markdown shortcuts, task items, and autosave
Design & UI: Tailwind CSS v4 + shadcn/ui on Base UI primitives
Monorepo & Tooling: Bun + Turborepo + Biome

🧮 The Mathematics: Judging You Can Defend

Most hackathons fail because arithmetic averages confuse judge calibration with project quality. Juryza introduces three distinct, mathematically rigorous evaluation layers:

1. Cross-Judge z-Score Normalization

Judges systematically differ in two ways:

Level Bias ( $μ$ ): Some judges are harsh (averaging 2.5); others are generous (averaging 4.2).
Spread Bias ( $σ$ ): Some judges use the entire scale (1–5); others cluster tightly between 3 and 4.

Juryza standardizes every score against each judge’s individual distribution:

z = \frac{raw - μ _{j}}{σ _{j}}

normalized = clamp (globalMean + z \times 0.9, 1, 5)

Flat Judge Handling: If a judge gives every single project the exact same score, their variance is zero ( $σ_{j} \leq 1 0^{- 9}$ ). They provide zero ranking information. Juryza automatically sets their $z = 0$ , mapping them to the global mean so they neither artificially inflate nor penalize the teams they saw.
The Epsilon Division Bug: During fixture verification, we uncovered a critical floating-point trap: when a judge assigns identical scores, floating-point arithmetic produces a standard deviation around 1e-16 rather than 0.0. A naive if (sd > 0) check caused division of noise by noise, unfairly tanking projects in the leaderboard! We hardened this with strict epsilon tolerances and regression test suites.

2. Bradley–Terry Pairwise Duel Arena

When judges only review 2 or 3 projects, variance estimates ( $σ$ ) can be noisy. For high-stakes rounds, Juryza features a Pairwise Duel Arena.

Instead of awarding arbitrary numbers, judges are shown two projects side-by-side and pick the stronger one.

Under the Bradley–Terry model, the probability that project $i$ beats project $j$ is:

P (i beats j) = \frac{s _{i}}{s _{i} + s _{j}}

We fit project latent strengths $s_{i}$ using Hunter’s (2004) Minorization-Maximization (MM) algorithm:

s_{i (t + 1)} = \frac{W _{i}}{\sum _{j \neq = i} \frac{n _{ij}}{s _{i (t)} + s _{j (t)}}}

Active Pair Selection: Random pairings waste judge attention (matching a clear #1 project against a broken prototype yields zero information). Juryza dynamically selects pairs that:
1. Have the fewest prior head-to-head comparisons by the current judge.
2. Have the closest current estimated latent strengths ( $s_{i} \approx s_{j}$ ), maximizing information gain per click!

3. Quadratic Community Voting with Credit Budgets

Allowing public voting often leads to ballot-stuffing and social media brigade spam.

Juryza implements Quadratic Voting:

Every participant gets a fixed credit budget (e.g., 16 credits).
Allocating $v$ votes to a single project costs $v^{2}$ credits (1 vote = 1 credit, 2 votes = 4 credits, 3 votes = 9 credits, 4 votes = 16 credits).
Voters can support multiple projects or strongly back their favorite, but monopolizing votes becomes quadratically prohibitive.
Enforced inside PostgreSQL transactions with advisory locks to prevent concurrent race conditions.

✍️ The Participant Experience: Notion-Style Project Write-ups

Hackathon forms are usually ugly <textarea> inputs that ruin carefully formatted presentations.

In Juryza, participants write project pages using a modern Notion-style block editor built on Tiptap 3:

Slash commands (/h1, /code, /image, /todo, /callout)
Floating bubble toolbar for inline formatting
Real-time background debounced autosaving
Notion-like sidebar properties (tracks, demo URLs, GitHub repositories, license tags)
Hard deadline enforcement: At the closing second, the backend seals all mutations with atomic PostgreSQL checks. No late edits, no sneaky post-deadline commits.

🔍 Plagiarism, Rival Comparisons & Signed Certificates

Juryza goes beyond basic submission portals:

Rival Comparison Matrix: Pick any project, and Juryza uses TF-IDF cosine distance and leaderboard neighbors to find its closest competitors, comparing them side-by-side across every rubric criterion.
Duplicate Detection: Flags suspicious duplicate submissions or repo recycling across events.
Cryptographically Verifiable Certificates: Winners and judges receive verifiable certificates signed with Ed25519 keys, verifiable at /certificates/<serial>.
OpenAPI 3.1 & Developer API: Every single action in the UI is backed by clean, fully typed REST endpoints documented at /docs/api with personal API bearer tokens.

💡 What We Learned Building Juryza

Building for 100% offline forces clean architecture. Without relying on cloud services (AWS S3, Clerk, Supabase, Vercel Blob), you realize how much faster and more reliable local software can be. A full PostgreSQL instance with Drizzle and Next.js spins up in seconds and runs anywhere.
Fairness is an engineering discipline. Hackathon organizers don't need another subjective spreadsheet; they need statistical rigor with an audit trail that explains why team A placed over team B.
The power of unified REST APIs. Because the Juryza frontend consumes the exact same REST API that external CLI checkers and webhooks use, testing the platform was extraordinarily clean—88 comprehensive unit and live integration tests run with zero flaky mocks.

🚀 Get Involved!

Juryza is open-source under the MIT License. We want hackathons worldwide—from university clubs to massive global events—to run on software that is transparent, fair, and self-reliant.

⭐ Star the repo on GitHub: https://github.com/sanjaysah101/Juryza
📺 Watch & share the demo video: https://youtu.be/gfsorn4l_WI

Let us know in the comments: How does your local hackathon handle judging, and what algorithm would you like to see next?

Google Sign-In Works in Debug but Fails in Production on Android? Check This Hidden SHA-1

Sanjay Kumar Sah — Sat, 12 Sep 2026 09:12:30 +0000

🚢 #BuildInPublic for the RevenueCat Shipaton 2026. RentDera is my Shipaton entry, and I'm sharing the whole journey — the wins and the 5 AM disasters like this one. This is one chapter of that trail.

Google Sign-In worked on my development build. It worked on my preview build. On the version Google Play delivered to real testers, tapping "Sign in with Google" did absolutely nothing — no account picker, no error message, no crash. Just a button that did nothing.

It took me several days to find. The answer turned out to be a fingerprint that Play Console doesn't show you anymore.

If you're here from a search, the short version is below.

TL;DR — the fix

If your app uses Play App Signing and you've opted into Quantum-ready app signing (beta), the SHA-1 fingerprint buttons on Play Console's App signing page are not the certificate that signs your app.

Go to Play Console → Protect with Play → Play Store protection → Manage Play app signing
Click Download certificates (not the SHA-1 fingerprint buttons)
You'll get three files. The one you need is deployment_cert.der
Get its SHA-1 fingerprint (commands below)
Put that fingerprint in your Android OAuth client in Google Cloud Console

No rebuild needed. Mine started working within minutes.

What "Google Sign-In is broken" actually looked like

Nothing. That's the hard part.

On modern Android, Sign in with Google runs through a system component called Credential Manager. When it can't complete a sign-in, it hands your app back a result that means "cancelled." Here's the code in the library I use:

} catch (e: GetCredentialCancellationException) {
  OneTapResponse.cancelled()
} catch (e: NoCredentialException) {
  OneTapResponse.noSavedCredential()
}

The problem: "cancelled" is also what you get when a user swipes the dialog away. Android uses one bucket for all of these:

the user genuinely dismissed the dialog
your app isn't registered properly with Google
your app's security certificate doesn't match what Google expects
your OAuth consent screen is still in "Testing" mode and this person isn't on the tester list

No error code. No message. Nothing to look up. And it only happens in the version you can't easily debug — the one Google Play installed on someone else's phone.

Plain English: what a "signing certificate" is and why it matters

Skip this if you already know. It's the core of the bug, so it's worth being clear.

Every Android app is digitally signed — think of it as a tamper-proof wax seal stamped onto the app file. The seal proves the app came from you and hasn't been modified.

A SHA-1 fingerprint is just a short, unique ID for that seal. It looks like this:

88:93:67:BB:FA:76:AC:40:3E:1D:AC:E2:9B:7D:2A:C0:45:7E:D1:BF

When your app asks Google "please sign this person in," Google checks two things:

Is this app's package name registered with me? (e.g. com.example.myapp)
Does the app's seal match the fingerprint I have on file?

If either answer is no, Google refuses — and on Android, that refusal comes back as "cancelled." So a wrong fingerprint looks exactly like a user changing their mind.

The twist: Google Play re-seals your app

Here's what trips up most people, and it's worth understanding even if your bug turns out to be something else.

When you upload your app to Google Play, you sign it with your upload key. Play then removes your seal and applies its own before sending the app to users. This is a feature called Play App Signing, and it exists so that losing your own key doesn't lock you out of updating your app forever.

The consequence: the app on a user's phone has a different fingerprint than the file you uploaded.

So you need to register both fingerprints with Google:

your upload key fingerprint (for builds you install directly, e.g. from a CI service)
Play's app signing key fingerprint (for everything from the Play Store)

Register only the first, and every Play Store install fails while every local install works perfectly. That is the classic version of this bug.

I checked the obvious thing. It looked correct.

So naturally, that's where I looked first.

I opened Google Cloud Console. The Android OAuth client had the right package name. It had a SHA-1 fingerprint copied straight from Play Console's app signing page. The consent screen was published to production. No unusual permissions requested. Everything matched.

I concluded the fingerprint theory was dead and started investigating the user's Google account on the device instead.

That was wrong, and it cost me another day. My mistake was simple: I was comparing a field in one console against a field in another console and trusting both. Neither of them described the app sitting on the phone.

The breakthrough: stop reading the console, read the phone

The console tells you what you configured. The phone tells you what's true. Google checks the certificate of the app that's actually installed, so that's the thing to measure.

So I plugged in the test phone, pulled the installed app off it, and read its fingerprint directly. (Full step-by-step is further down — it's optional, and you probably won't need it.)

Out came:

88:93:67:BB:FA:76:AC:40:3E:1D:AC:E2:9B:7D:2A:C0:45:7E:D1:BF

That matched neither the fingerprint registered in Google Cloud nor my upload key. A third fingerprint I had never seen before.

The real cause: Quantum-ready app signing (beta)

Back in Play Console, there was a small badge on the app signing page I'd never paid attention to: Quantum-ready (beta).

Quantum-ready app signing is Google preparing for a future where today's encryption can be broken by quantum computers. If you opt in, your app gets a hybrid key — a traditional ("classical") half and a new post-quantum half.

It also quietly changes the page. Where Play Console used to show plain text rows — MD5, SHA-1, SHA-256 of your app signing certificate — it now shows two buttons instead: Classical key and Post-quantum cryptography key.

Neither button gives you the certificate that signs your app.

Click Download certificates and you get three files:

File	What it actually is
`deployment_cert.der`	The certificate Play uses to seal your app. This is the one to register.
`hybrid_classical_cert.der`	Classical half of the quantum-ready pair — what the SHA-1 button copies
`hybrid_pqc_cert.der`	Post-quantum half — also not it

The deployment certificate — the ordinary Play App Signing key that has been there all along — has no fingerprint button on that page at all.

I had dutifully copied the only SHA-1 the page offered me. It was never going to work.

Fixing it, step by step

Play Console → Protect with Play → Play Store protection → Manage Play app signing
Click Download certificates and unzip. Find deployment_cert.der
Read its SHA-1 fingerprint (see the next section)
Google Cloud Console → APIs & Services → Credentials
Open your Android OAuth client, or create one (type Android, package name = your app's package)
Paste the fingerprint into SHA-1 certificate fingerprint. Save
Wait a few minutes, then test on a Play Store build

While you're there, create a second Android OAuth client with your upload key fingerprint, so builds you install directly also work. Each client holds exactly one fingerprint, so you need one per certificate.

Three ways to read a .der fingerprint

A certificate's SHA-1 fingerprint is simply a SHA-1 hash of the certificate file itself. So you don't need any Android tooling at all.

Windows PowerShell — nothing to install, and it formats the result with colons exactly the way Google Cloud wants:

$c = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("deployment_cert.der")
$c.Thumbprint -replace '(..)(?!$)','$1:'

Windows, even shorter — certutil ships with Windows (output has no colons; Google Cloud accepts it either way):

certutil -hashfile deployment_cert.der SHA1

macOS / Linux / anywhere with a JDK or OpenSSL:

keytool -printcert -file deployment_cert.der

# or
openssl x509 -inform DER -in deployment_cert.der -noout -fingerprint -sha1

A genuine Play App Signing certificate shows CN=Android, O=Google Inc. as its owner. That's a good sanity check that you grabbed the right file.

Optional: prove it by reading the app on the phone

You probably don't need this section. If registering deployment_cert.der's fingerprint fixed your sign-in, you're done — close the tab.

Do this when the fix didn't work, or when you want hard proof of which certificate is on a device before you change anything. It's the step that ended a week of guessing for me, and it works on any Android phone with any app.

Step 1 — Get `adb`

adb (Android Debug Bridge) is the tool that talks to a connected phone. You do not need Android Studio.

Download SDK Platform-Tools for your OS: developer.android.com/tools/releases/platform-tools
Unzip it anywhere — a platform-tools folder with adb inside
Either add that folder to your PATH, or just run adb with its full path

Quick check that it runs:

adb version
# Android Debug Bridge version 1.0.41

macOS users can alternatively brew install --cask android-platform-tools.

Step 2 — Turn on USB debugging on the phone

Settings → About phone → tap Build number seven times. You'll see "You are now a developer"
Settings → System → Developer options → turn on USB debugging
Plug the phone into your computer with a USB cable
Change the USB mode to File transfer / MTP (not "Charging only") — on some phones the debugging prompt won't appear otherwise
A dialog appears on the phone: "Allow USB debugging?" → tick Always allow from this computer → Allow

Confirm the computer can see it:

adb devices -l
# List of devices attached
# 95QW4TIFNRIBCAR8   device product:... model:...

If it says unauthorized, you missed the prompt on the phone. If the list is empty, try a different cable — plenty of USB cables are charge-only.

Step 3 — Confirm you're testing the Play Store build

This matters. A sideloaded build carries a different certificate, and testing the wrong one sends you down the wrong path.

adb shell pm list packages -i | grep com.example.myapp

Look at the installer= value:

installer=com.android.vending → installed by the Play Store ✅ this is what you want
installer=com.google.android.packageinstaller → sideloaded APK
installer=null → installed by a developer tool

Step 4 — Pull the app off the phone

adb shell pm path com.example.myapp
# package:/data/app/~~aBcD.../com.example.myapp-XyZ.../base.apk

adb pull /data/app/~~aBcD.../com.example.myapp-XyZ.../base.apk ondevice.apk

Paste the exact path the first command printed. If it prints several lines, you want the one ending in base.apk.

Step 5 — Read its real fingerprint

If you have Android SDK build-tools installed, this is a one-liner:

apksigner verify --print-certs ondevice.apk

Watch out for this trap. The obvious command does not work:

keytool -printcert -jarfile ondevice.apk
# (prints absolutely nothing)

Apps delivered by Play use a newer signature format that -jarfile can't read. It doesn't fail with an error — it succeeds and prints nothing at all. Easy to misread as "no info available." I did exactly that.

No build-tools? Save this as apk-cert.js and run node apk-cert.js ondevice.apk. No dependencies:

// apk-cert.js — print the signing certificate fingerprint of an APK.
// Works on modern (v2/v3-signed) APKs, including ones delivered by Google Play.
const fs = require("fs");
const crypto = require("crypto");

const buf = fs.readFileSync(process.argv[2]);

// 1. Find the ZIP "end of central directory" record. It points at the central
//    directory, and the APK Signing Block sits immediately before that.
let eocd = -1;
for (let i = buf.length - 22; i >= Math.max(0, buf.length - 66000); i--) {
  if (buf.readUInt32LE(i) === 0x06054b50) { eocd = i; break; }
}
if (eocd < 0) throw new Error("Not a ZIP/APK file");

const cdOffset = buf.readUInt32LE(eocd + 16);
if (buf.slice(cdOffset - 16, cdOffset).toString("latin1") !== "APK Sig Block 42") {
  throw new Error("No APK Signing Block — try: keytool -printcert -jarfile <apk>");
}

// 2. Walk the block's id/value pairs. 0xf05368c0 = scheme v3, 0x7109871a = v2.
const blockSize = Number(buf.readBigUInt64LE(cdOffset - 24));
let off = cdOffset - blockSize - 8 + 8;
const blockEnd = cdOffset - 24;
const blocks = {};
while (off < blockEnd) {
  const len = Number(buf.readBigUInt64LE(off));
  blocks[buf.readUInt32LE(off + 8)] = buf.slice(off + 12, off + 8 + len);
  off += 8 + len;
}

const schemes = [[0xf05368c0, "v3"], [0x7109871a, "v2"]].filter(([id]) => blocks[id]);
if (schemes.length === 0) throw new Error("No v2/v3 signature found");

// 3. signers -> first signer -> signed data -> certificates -> first certificate (DER).
//    Every field is a 4-byte little-endian length followed by that many bytes.
for (const [id, name] of schemes) {
  const v = blocks[id];
  let p = 0;
  const u32 = () => { const x = v.readUInt32LE(p); p += 4; return x; };
  u32();                                  // length of the signers sequence
  u32();                                  // length of the first signer
  const signedDataLen = u32();
  const sd = v.slice(p, p + signedDataLen);

  let q = 0;
  const s32 = () => { const x = sd.readUInt32LE(q); q += 4; return x; };
  const digestsLen = s32();
  q += digestsLen;                        // skip the digests section
  const certsLen = s32();
  const certsEnd = q + certsLen;

  console.log(`--- ${name} signature ---`);
  let n = 0;
  while (q < certsEnd) {
    const certLen = s32();
    const der = sd.slice(q, q + certLen);
    q += certLen;
    const fp = (alg) =>
      crypto.createHash(alg).update(der).digest("hex").toUpperCase().match(/../g).join(":");
    console.log(`  certificate #${++n}`);
    console.log(`    SHA-1  : ${fp("sha1")}`);
    console.log(`    SHA-256: ${fp("sha256")}`);
  }
}

Output looks like this — and both signature versions should agree:

--- v3 signature ---
  SHA-1  : 88:93:67:BB:FA:76:AC:40:3E:1D:AC:E2:9B:7D:2A:C0:45:7E:D1:BF
  SHA-256: 27:9F:A2:D6:99:52:E5:03:6F:94:26:86:00:B7:FB:81:A4:D9:4A:F8:...
--- v2 signature ---
  SHA-1  : 88:93:67:BB:FA:76:AC:40:3E:1D:AC:E2:9B:7D:2A:C0:45:7E:D1:BF

Step 6 — Compare

Whatever comes out of Step 5 is what Google checks. If it doesn't match the SHA-1 on your Android OAuth client, that is your bug, no matter how correct the consoles look.

One more sanity check, in case your app's signing key was ever rotated:

adb shell dumpsys package com.example.myapp | grep signatures
# signatures:[...], past signatures:[]

An empty past signatures:[] means no key rotation is muddying the comparison.

Quick troubleshooting checklist

If Google Sign-In fails only on your Play Store build, work down this list:

[ ] Is the package name on your Android OAuth client exactly right? Many setups add suffixes like .dev or .staging per build type — each needs its own client
[ ] Did you register Play's app signing fingerprint, not just your upload key?
[ ] If you use Quantum-ready app signing, did you use deployment_cert.der rather than the SHA-1 buttons?
[ ] Is your OAuth consent screen published ("In production"), not left in Testing? In Testing mode, anyone not on the tester list is blocked — and that also shows up as "cancelled"
[ ] Are you passing your Web client ID to the sign-in library, not an Android one? Most libraries want the Web client ID even on Android — it's confusing, and it's correct
[ ] Still stuck? Pull the APK off the phone and read its real fingerprint (section above)

Five things I'd tell myself a week ago

When two dashboards agree and reality disagrees, go measure reality. I spent days comparing a Google Cloud field to a Play Console field. Both were internally consistent. Neither described the app on the phone. The first adb pull ended the investigation in minutes.

Beta features move where the truth lives. Quantum-ready app signing didn't break anything. It relocated a value and left a similar-looking, differently-named one in its place. Every blog post and checklist that says "copy the SHA-1 from the app signing page" is now quietly wrong for these apps — including my own team's internal docs, which I've since fixed.

A tool that prints nothing is worse than one that errors. keytool -printcert -jarfile on a modern APK succeeds silently and outputs nothing. Empty output is not the same as "no data exists." Always question it.

Add your diagnostics before you need them. I'd already wasted a build cycle adding a console.log, so I made the app report on itself: every stage of sign-in sends an analytics event carrying the app version, build number, device model and configuration fingerprints. That didn't find the bug — but it eliminated my entire app as a suspect in one afternoon, and told me exactly which build and which phone each failure came from.

When an error collapses several causes into one label, add something that separates them. "Cancelled" means four different things here. I now time how long the sign-in call takes: under about 300 milliseconds means no dialog ever appeared, which points at configuration; several seconds means the user really did see the dialog, which points at their device or account. That one number would have halved my search space on day one.

If this saved you a day, the specific thing to remember is short: deployment_cert.der, not the SHA-1 button.

750 Free Hours a Month, but a Month Is 730: 3 Free-Tier Mistakes That Took Down My App

Sanjay Kumar Sah — Fri, 11 Sep 2026 09:58:16 +0000

🚢 #BuildInPublic for the RevenueCat Shipaton 2026. RentDera is my Shipaton entry, and I'm sharing the whole journey — the wins and the 5 AM disasters like this one. This is one chapter of that trail.

At 9 PM on September 10th, 2026, Render emailed me to say my production services had been suspended.

At 5 AM on September 11th, I published v1.2.0 to the Play Store.

In between was the worst night of this project so far — and it was entirely my own doing. Three separate mistakes, each individually reasonable, stacked into an outage that took down a shared identity service, a product API, and a mail service at once.

Here's all three, with the numbers.

The 30-second version (if you only read this far)

Free tiers are metered. Render gives ~750 machine-hours/month across a workspace; a month is ~730 hours. Keeping one service awake 24/7 eats almost the entire budget.
A keep-alive cron is a trap. Pinging services to stop them sleeping doesn't outsmart the platform — it just spends the free quota faster, and then everything gets suspended.
On a serverless database, min_connections: 0 is mandatory. One idle connection held open keeps the database awake 24/7 and can nearly double your usage at zero traffic.
Never bake a platform's URL into a mobile app. Use a domain you own, so you can move servers without shipping a new app build.

If you're new to this, don't worry — I explain every term below in plain language.

Jargon, in one line each:
Free tier = the no-cost plan, with usage caps. · Cold start / spin-down = a sleeping server takes a few seconds to wake. · Cron job = a task on a timer. · Connection pool = a small set of reusable database connections. · Serverless / scale-to-zero database = a database that sleeps when idle and bills by the second. · Compute Unit (CU) = Neon's unit of database processing time. · Hostname / subdomain = the address in a URL, like auth.notils.com.

The setup

I'm a solo developer. The stack is deliberately cheap:

Three Rust backend services — a shared identity service, a product API, and a transactional email service
Postgres on Neon's free tier
A React Native + Expo mobile app, in Play Store closed testing with 20 testers
Everything on Render's free tier, in one workspace

Free tier everywhere. That was the point. There's no revenue yet, and 20 testers don't justify a hosting bill.

Mistake #1: the keep-alive cron

Render's free services spin down after ~15 minutes of inactivity. The next request pays a 30–60 second cold start.

For 20 testers, that's a genuine problem. A landlord opens the app, waits 40 seconds, and concludes the app is broken. So I did the obvious thing: a cron job pinging every service every 5 minutes to keep it awake.

It worked perfectly. That was the problem.

Render's free allowance is 750 instance-hours per month, per workspace — shared across every free service in it.

A calendar month is about 730 hours.

Read those two numbers again. The free tier is sized so that one always-on service consumes the entire monthly allowance with 20 hours to spare. It is not sized for two. The spin-down isn't a defect you work around — it's the mechanism that makes the arithmetic work at all.

I had four services (production and staging for two of them), all pinned awake by my own cron:

4 services × 24 hours/day = 96 instance-hours per day
750 ÷ 96 ≈ 7.8 days

Just under eight days to burn a month's allowance. Mine lasted about ten, because the cron didn't catch every service on every pass. Not much longer.

And when the allowance runs out, Render suspends every free service in the workspace. Not the greediest one. All of them. Staging and production together.

The lesson: before you defeat a platform's idle timeout, check what the idle timeout is paying for. If the free quota is smaller than a calendar month, sleeping is not optional — it's the business model.

Mistake #2: one connection, held forever

Then Neon emailed me too. 100 compute-unit hours on the free plan, and I was at 80%.

This one took longer to find, because the culprit was four lines in a config struct I'd written weeks earlier and never looked at again:

DbConfig {
    max_connections: 10,
    min_connections: 1,                        // ← this line
    connect_timeout: Duration::from_secs(5),
    acquire_timeout: Duration::from_secs(5),
    idle_timeout: Duration::from_secs(600),
    max_lifetime: Duration::from_secs(1800),
}

min_connections: 1 is a completely ordinary pool setting. It means: always keep at least one connection open, so the first request after a quiet period doesn't pay for a TCP handshake and TLS negotiation. On a traditional Postgres box, it's free. You'd have no reason to think about it.

On serverless Postgres, it's a standing charge.

Neon (and Supabase, and PlanetScale, and every other scale-to-zero database) suspends your compute after a few minutes of inactivity. But it cannot suspend while a client is still connected. A pool that always holds one open connection keeps the compute awake 24 hours a day, at zero traffic.

0.25 CU × 730 hours = ~182 CU-hours/month
Free tier allowance:     100 CU-hours/month

Nearly twice the free allowance, burned by a service nobody was using. And idle_timeout: 600 didn't save me — the pool closes an idle connection after 10 minutes and then immediately opens a new one to satisfy the minimum.

The fix is four lines:

DbConfig {
    max_connections: 10,
    min_connections: 0,                        // let the last connection actually close
    connect_timeout: Duration::from_secs(10),  // absorb a suspended compute resuming
    acquire_timeout: Duration::from_secs(10),
    idle_timeout: Duration::from_secs(60),     // well under Neon's ~5-min suspend timer
    max_lifetime: Duration::from_secs(1800),
}

Two things worth noting beyond min_connections: 0:

idle_timeout has to be well below the provider's suspend timer. Closing your connection after 10 minutes when the provider suspends at 5 means you never suspend. It has to drain first.
Raise your timeouts. Once the compute does suspend, the next request has to wait for it to wake up. A 5-second budget that was generous for a warm connection can be tight for a cold resume. Scale-to-zero trades a standing charge for occasional latency — you have to actually budget for the latency.

All three of my services were generated from the same template, so all three had the identical bug on the identical line. If you run a service template, a default like this propagates silently into everything you'll ever generate from it.

The lesson: connection pool defaults were written for servers that are always on. If your database bills by the second and sleeps when idle, min_connections: 0 isn't a tuning preference. It's a correctness requirement.

Mistake #3: the one I can't undo

The first two mistakes cost me money I didn't spend and a night I didn't sleep. This one cost me something I can't get back.

While cleaning up, I deleted the suspended Render service.

Render assigns every service a unique *.onrender.com address. Delete the service and that address is gone permanently — you cannot recreate it, and a new service gets a new unique name. There's no "restore".

My mobile app v1.1.0 — already in the hands of closed testers, already through Play Store review — had that address compiled into the binary.

v1.1.0 is now permanently dead. Not degraded. Not slow. Requests to the old hostname return:

HTTP/1.1 404 Not Found
x-render-routing: no-server

There is no configuration change, no server-side fix, and no rollback that can save it. The only repair is a new build, a new review, and every tester updating.

That's why I was publishing at 5 AM.

The actual root cause wasn't the deletion

It was that a hostname I didn't own was baked into a binary I couldn't hot-fix.

A mobile app is the least forgiving consumer you will ever have. A web frontend redeploys in a minute. A backend service reads an environment variable and restarts. An app in a store is frozen the moment it ships, and unfreezing it costs a review cycle measured in hours or days.

So v1.2.0 ships pointing at domains I control:

❌  my-service-a3f9.onrender.com     ← platform's address, platform's to revoke
✅  auth.notils.com                  ← mine, points wherever I say

Now migrating providers is a DNS change. Testers notice nothing. The app doesn't need to know where the server lives, and that was true the whole time — I just hadn't made it true in the config.

The lesson: anything compiled into a store binary must be a name you own. Not a convenience URL. Not a platform subdomain. A hostname on a domain you control, from the very first build that reaches another human being.

One detail that nearly caught me a second time: I picked hostnames one label deep — auth.notils.com, not api.auth.notils.com. Cloudflare's free Universal SSL covers example.com and *.example.com, one level only. A deeper subdomain needs Advanced Certificate Manager at $10/month per zone, which is more than the server. Free-tier constraints show up in the strangest places.

Verifying it actually worked

Two production services are now live on owned domains, both fronted by Cloudflare and proxying to a Render origin:

$ curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://auth.notils.com/health
200 0.31s

$ curl -s https://auth.notils.com/.well-known/jwks.json
{"keys":[{"kty":"EC","crv":"P-256","alg":"ES256","use":"sig","kid":"…","x":"…","y":"…"}]}

Three things I checked, and would check again:

/health/ready, not just /health. Liveness only proves the process is up. Readiness does a database round-trip, which is what actually proves the pool change didn't break the cold-resume path.
The JWKS response contains no d field. On an identity service, d is the private key component of an EC key. A JWKS endpoint that leaks it hands over the ability to mint tokens. It's a one-line check and it should be in your deploy runbook forever.
The response headers. CF-RAY: …-KTM told me Cloudflare was terminating TLS at a Kathmandu edge — in-country for my users — while x-render-origin-server: Render confirmed it was reaching the right origin. Useful to know before optimizing anything about where the server itself lives.

The economics nobody writes about

The obvious response to all this is "just pay for hosting." Let's do that math honestly.

Render's paid tier is $7/month per service. I need three services in production, so $21/month, every month, before the database or anything else.

A VPS with more RAM and more cores than all three services combined is cheaper per month — but the advertised price usually requires committing to one to four years upfront. The monthly rate is often double, and renewal rates are higher still. "Cheaper per month" and "affordable this month" are not the same sentence when you're a solo developer with no revenue.

So the real options for a pre-launch solo project are:

Pay $21/month indefinitely for 20 testers
Prepay a year or more for a VPS and become your own sysadmin
Make the free tier actually work

I picked option 3, but properly this time: a new workspace, production services only, no staging, no keep-alive cron, a pool that drains to zero, and custom domains in front of everything. The spin-down is back, and testers will occasionally wait a few seconds on first open. That's an honest trade for $0, and it's reversible — the day upgrading makes sense, it's a dashboard toggle and nothing else changes, because nothing downstream knows where the service lives.

The staging environments are simply gone for now. That's a real cost, not a clever saving: I test against production and I'm careful. It buys back the headroom that keeps production inside the free allowance, and it's the first thing I'll restore when there's a budget.

What I'd tell myself two weeks ago

Read the quota arithmetic before designing around it. 750 hours/month sounds generous until you divide by a 730-hour month.
Never add a keep-alive ping to a metered free tier. You're not outsmarting the platform, you're spending the budget faster.
Set min_connections: 0 on any serverless database. Check this today if you're on Neon, Supabase, or PlanetScale with a pooled client. It's four lines and it may be your entire bill.
Own the hostname before the first store release, not after.
Deleting a resource on a platform that assigns unique names is irreversible. Read the dialog. I didn't.
Don't miss the first warning email. Render and Neon both warned me before suspending. I caught the second one, at 9 PM, after the damage.

It isn't finished

In the interest of not writing a tidier ending than I earned: the third service — the one that sends transactional email — is still down while I work through this. Both of its addresses return 404.

Its two call sites fail differently, and one of them fails silently. The email-verification endpoint propagates the error, so a client gets a real 500 and can tell the user to retry. But the forgot-password endpoint deliberately swallows delivery errors — because an endpoint that behaves differently for registered and unregistered addresses is an account-enumeration oracle. Correct security design. It also means a real user can request a password reset right now, see "check your email," and wait forever.

That's next. But v1.2.0 is live, the testers are unblocked, and the two root causes are fixed in all three services.

I'll take it.

If you're running a free-tier stack, go check min_connections right now. It'll take two minutes and it might be the most expensive line in your codebase.

This is part of **Building RentDera in Public* — my journey shipping a rent-management app for the RevenueCat Shipaton 2026. Follow the series for the next chapter (including whether the email service ever comes back). If this saved you a bad night, drop a comment with the free-tier gotcha that bit you. 🚢*

Built with Rust · Neon · Render · Cloudflare · React Native + Expo. Full RentDera changelog: https://rentdera.com/changelog. #BuildInPublic #Shipaton

OpenPledge: See Exactly Where Your Donation Goes (Blockchain + AI for Charity)

Sanjay Kumar Sah — Sun, 06 Sep 2026 20:09:41 +0000

This is a submission for Weekend Challenge: Generosity Edition

The problem, in one sentence

When you donate $5 to a small charity online, you have no idea what actually happens to it — and you usually never hear back.

Big donation platforms ask you to trust them. OpenPledge flips that around: it's a giving app where you don't have to trust anyone, because you can see everything.

What I built

OpenPledge is a "glass box" for charity. You pick a cause, give any amount, and in that same moment four things happen — each one making your gift more transparent and more human:

🪙 Your donation is written onto the Solana blockchain. Think of it as a public receipt that no one can secretly edit or delete. Anyone in the world can look it up.
🤖 Google Gemini writes you a personal thank-you note. Not a canned "Thanks for your donation!" — a warm, specific message about the exact cause you supported.
🔊 ElevenLabs reads that note out loud in a natural human voice, so you get a real spoken thank-you. (If the voice service is unavailable, the app falls back to your browser's built-in voice so it always speaks.)
❄️ Snowflake keeps the big-picture numbers — total raised, gifts by cause, trends over time — and powers a public Impact Dashboard the whole community can see.

There's also a public ledger page: a plain, honest list of every donation with a link to its blockchain record. No login, no sign-up, nothing hidden.

See it working (this is real, not a mock-up)

Here's an actual donation recorded on the Solana blockchain during testing — click it and you'll see the live transaction on the official Solana Explorer:

👉 View the on-chain donation on Solana Explorer

That link is the whole point of the project: your generosity leaves a permanent, public, verifiable trail.

🔗 Live app: open-pledge.vercel.app
💻 Source code: github.com/sanjaysah101/open-pledge

A quick look

Home — "Give small. See everything."

Browse causes

Give, and get an instant receipt

Proof on the blockchain — the same donation, live on Solana Explorer

The three pages

Give: browse causes and donate. A receipt pops up with your AI thank-you note, a play-voice button, and your blockchain link.
Ledger (/ledger): every gift, listed openly, each linkable to Solana Explorer.
Impact (/impact): live totals and charts powered by Snowflake, plus a one-line summary written by Gemini.

Why "generosity" — the causes

I built six example campaigns around the charity themes the International Day of Charity and the challenge highlight, so the demo feels real:

💧 Clean water for a school (climate & poverty)
👩‍💻 A neighborhood code lab for girls (equity & inclusion)
🚲 A youth-led food-rescue bike brigade (youth leadership)
🦾 Free 3D-printed assistive devices (tech-driven giving)
🌱 Replanting a wildfire-burnt ridge
🧣 Winter survival kits for unhoused neighbors

How I used each sponsor technology

I integrated all four prize technologies, and each one does real work — none are bolted on for show:

Technology	What it does in OpenPledge
Solana	Records every donation on-chain (devnet) with a verifiable signature and explorer link.
Google AI / Gemini	Writes each donor's personal thank-you note and the impact-page summary.
ElevenLabs	Turns the thank-you note into natural-sounding speech (a "voice receipt").
Snowflake	Stores donations and powers the aggregate analytics on the Impact Dashboard.

A "Bring Your Own Key" mode lets anyone (including the judges) paste their own API keys in the browser to test the live features — the keys stay on your device and are never stored on the server.

Tech stack

Built with Next.js 16 (React 19), Bun, Tailwind CSS v4, and shadcn/ui on Base UI — scaffolded with create-notils and linted with Biome.

A note on honesty: no real money ever moves — the blockchain entry is a symbolic, public "anchor," not custody of funds. And every integration degrades gracefully: if a key or service isn't available, the app keeps working and clearly tells you which parts are live vs. simulated. That transparency felt exactly right for a project about trust.

What I learned

The biggest takeaway: trust in charity isn't about a bigger promise — it's about a smaller, verifiable receipt. Putting a donation on a public ledger, then wrapping it in a genuinely warm AI thank-you, made a tiny $5 gift feel both accountable and human at the same time.

Thanks to the DEV team for the theme — building in the spirit of generosity was a genuinely lovely way to spend a weekend. 💚

One Missing Environment Variable Crashed My App in Production (and I Lost My Play Store Testing Streak the Same Night)

Sanjay Kumar Sah — Sat, 05 Sep 2026 17:46:32 +0000

#BuildInPublic for the RevenueCat Shipaton 2026. RentDera is my entry, and I'm sharing the whole messy journey in public — wins, crashes, and gut-punches like the one below. This post is part of that trail.

The setup

Today I shipped v1.1.0 of RentDera, my rent-management app for landlords built with Expo + React Native. It was a big release:

Edit properties, units, and tenants after creation
Custom & recurring charges on dues
Profile pictures
Password reset from the login screen
Email verification for new accounts
Sign in with Google (alongside email)
Multi-currency support
A Nepali language option

I published at 5 PM and left to enjoy the Janmashtami festival. That's when everything went sideways.

Bug #1: The app crashed on launch

Within 30 minutes, closed testers reported the app crashing immediately. The cause was almost embarrassingly small: I forgot to add one environment variable to my production build:

EXPO_PUBLIC_LEGAL_BASE_URL

In development, the variable was set in my local .env, so everything worked. In the published build, it was undefined — and the code that read it blew up on startup.

The real lesson: a missing env var should fail loudly at build time, not silently ship and crash users. This is exactly why RentDera routes every env access through a single Zod-validated module that throws on a missing or invalid variable:

// src/lib/env.ts (simplified)
import { z } from "zod";

const schema = z.object({
  EXPO_PUBLIC_API_BASE_URL: z.string().url(),
  EXPO_PUBLIC_LEGAL_BASE_URL: z.string().url(), // <-- the one I forgot to provide
});

// Fails fast: if a var is missing, this throws immediately.
export const env = schema.parse({
  EXPO_PUBLIC_API_BASE_URL: process.env.EXPO_PUBLIC_API_BASE_URL,
  EXPO_PUBLIC_LEGAL_BASE_URL: process.env.EXPO_PUBLIC_LEGAL_BASE_URL,
});

The validation was doing its job — it did crash because the value was missing. The gap was in my CI/release pipeline, where the variable was never injected. Validation catches bad values; it can't invent values you never provided to the build.

I rebuilt, republished at 6 PM, and headed back out.

Bug #2: "Sign in with Google isn't working"

Then a tester called: the shiny new Google Sign-In wasn't working. I came home at 9 PM and started reading server logs. Nothing conclusive yet — Google Sign-In on native has a lot of moving parts (OAuth client IDs per platform, SHA-1 fingerprints on Android, the release keystore differing from debug). Still investigating this one.

The part that actually hurt: losing the testing streak

To publish to the Play Store as an individual developer, Google requires 12 testers active for 14 consecutive days in closed testing. I was on day 5. I had my 12 testers yesterday.

Tonight, I refreshed the Play Console and saw one tester had opted out. The streak resets. There's no appeal, no recovery — you start counting again.

A production crash you can hotfix in an hour. Lost days you can't get back. That stung more than either bug.

Takeaways for solo mobile devs

Validate env vars and verify your release pipeline injects them. Fail-fast validation is necessary but not sufficient — the CI/EAS build must actually supply every variable.
Always smoke-test the production/release build, not just the dev build. Native OAuth, signing, and env handling all differ between the two.
Over-recruit Play Store testers. With a 12-tester / 14-day requirement, a single opt-out can reset weeks of progress. Build a buffer.
Shipping is humbling — keep shipping anyway.

Off to find my 12th tester. If you'd like to help test a real-world rent-tracking app, drop a comment. 🙏

I'm building RentDera in public as my RevenueCat Shipaton 2026 entry — follow along for the next chapter (including whether I ever recover that testing streak). 🚢

Full v1.1.0 changelog: https://rentdera.com/changelog

#BuildInPublic · #Shipaton · Built with Expo + React Native.

I Built a Database in Rust With Zero Dependencies (and What the Standard Library Quietly Gave Me)

Sanjay Kumar Sah — Sat, 05 Sep 2026 06:11:16 +0000

TL;DR — I built a small database in Rust for a 72-hour hackathon with one rule: no third-party packages allowed. Just the language and nothing else. Here's what I had to write by hand, in plain English, and the surprisingly capable standard-library features that made it possible. Full source and a 5-minute video at the bottom.

First, what's a "dependency" — and why does anyone care?

When you build software today, you almost never write everything yourself. You install code other people wrote. In the JavaScript world you run npm install, in Python it's pip install, in Rust it's adding a "crate." These installed packages are called dependencies.

They're incredibly useful. They're also a little scary when you stop and look:

A typical modern web app pulls in over 1,200 packages once you count everything. ¹
In 2025 alone, public registries catalogued 454,600 new malicious packages — pushing the running total past 1.2 million. ²
AI coding assistants now invent package names that don't exist — one study across 576,000 samples found 19.7% of AI-suggested packages were hallucinated — and attackers register those fake names and wait for someone to install them. ³

The famous example: back in 2016 a developer deleted an 11-line package called left-pad (it just added spaces to the start of a string) and it broke builds across half the internet — React, Babel, thousands of projects. Eleven lines. A stranger's eleven lines, sitting inside everyone's app. ⁴

So a hackathon called Zero Dependency a hackathon run by @partnerships_raptors asked a simple, slightly rebellious question:

What if you built something genuinely useful using **nothing but the language itself?

No packages. No npm install. Just the "standard library" — the batteries that ship inside the language when you download it. I said yes. Here's what happened.

What I built: `zdb`, a tiny database

I built zdb, a key-value store. If you've used a dictionary in Python or an object in JavaScript, you already understand it: you put a value under a key, and later you get it back.

zdb put greeting "hello, world"
zdb get greeting
# → hello, world

The twist: it saves everything to disk and survives crashes. Close the program, reopen it, your data's still there. Pull the power cord mid-write, and it recovers cleanly instead of corrupting.

That's the kind of thing people normally reach for a big library like RocksDB, sled, or SQLite to do. I wrote the whole engine by hand, in one Rust file, with an empty dependency list. Here's the proof, and it's the whole point:

$ cargo tree
zdb v0.1.0

That's it. That's the entire "supply chain." One line: my own code.

The fun part: what I'd normally install, and what replaced it

This is the heart of the story. For each thing I needed, I'll show you the package I'd usually grab — and the standard-library feature I used instead. No jargon, I promise.

1. Turning data into bytes → I did it by hand

Normally I'd install: serde + bincode (Rust's go-to tools for converting data structures into a stream of bytes you can save to a file).

What it actually takes: A file is just a long line of numbered boxes, each holding one byte. To save a record, I decided exactly which byte goes where:

[ checksum ][ key length ][ value length ][ the key ][ the value ]

That's the entire "format." Rust's standard library already knows how to turn a number into bytes (to_le_bytes()) and back (from_le_bytes()). Once I picked the layout, saving and loading was a dozen lines. No library needed — I just had to decide the shape instead of letting a package decide it for me.

The lesson: serialization libraries are amazing when your data is complicated. When your data is simple and you control both ends, hand-writing the format is clearer and faster.

2. Detecting corruption → a 15-line checksum

Normally I'd install: crc32fast (checks whether data got scrambled).

What it actually takes: A "checksum" is a small number calculated from your data. Save it alongside the data; if you recompute it later and it doesn't match, you know something got corrupted. The specific recipe I used — CRC-32 — is the same one inside ZIP files and your ethernet cable.

It's a small loop over a lookup table. The magic moment: I tested my version against the internationally-known "correct answer" (CRC32("123456789") must equal 0xCBF43926) — and it matched on the first try. My hand-written 15 lines produce bit-for-bit the same result as the popular package.

The lesson: Some famous algorithms look intimidating because they have scary names, but the actual code is short and testable.

3. Stopping two programs from clobbering the same file → a "lock file"

Normally I'd install: fs2 (file locking).

What it actually takes: I needed to make sure two copies of zdb don't write to the same database at once and scramble it. The trick is beautifully old-school: try to create a file called LOCK, using a mode that says "only succeed if this file does not already exist." If it's already there, someone else is using the database, so I refuse to start.

The standard library has exactly this: OpenOptions::new().create_new(true). One method call. When the program exits cleanly, it deletes the lock. It's the digital version of hanging a "occupied" sign on a door.

The lesson: The standard library often hides a whole feature inside a single well-named option.

4. Reading command-line options → a simple loop

Normally I'd install: clap (parses --flags and sub-commands for command-line tools).

What it actually takes: For a handful of commands (put, get, del, list), I just read the words the user typed and matched on them. Rust hands you those words with std::env::args(). A match statement does the rest. Big argument-parsing libraries are worth it for huge tools with 50 options — for 6 commands, a loop reads more clearly than a library's special syntax.

5. A "run this once, lazily" global → now built in

Normally I'd install: once_cell or lazy_static (for setting up a value the first time it's used).

What it actually takes: Nothing new — Rust added this to the standard library in version 1.80 as LazyLock. This is the happiest kind of "package killer": the language caught up, and a crate millions of people still install out of habit is now unnecessary. I used it to build my checksum table exactly once.

The thing that turned out harder than the docs made it look

Here's the honest part — hackathons reward honesty over hype.

One of the bonus challenges was a "reproducible build": compile the program twice and get a byte-for-byte identical file both times. Sounds trivial, right? Same code, same result?

Nope. My first two builds were different — 20 bytes apart. I nearly assumed my code was non-deterministic.

After comparing the two files byte by byte, the culprit was almost comedic: on Windows, the compiler stamps the current timestamp and a random ID into the program file's header. Nothing to do with my code — the build process itself was sprinkling in randomness.

The fix was a single linker flag (/Brepro, which tells the toolchain "zero out the timestamp, make the ID a hash of the content instead"). ⁵ After that, both builds produced the identical hash:

build A: 6d93cd01…dc0f
build B: 6d93cd01…dc0f   ✅ identical

The lesson: "Deterministic" is a discipline, not a default. Most of us never notice because we never check. Checking is the whole exercise.

So… should you delete all your dependencies?

No! That's not the takeaway, and the hackathon organizers said so themselves. Libraries exist for good reasons. You should not hand-roll cryptography, and you should not rewrite a mature database for production on a Tuesday.

The real lesson is smaller and more useful:

Know what's underneath the packages you install. A surprising number of them wrap a feature your language already has for free.

Before your next npm install / pip install / cargo add, spend 30 seconds asking: "Does the standard library already do this?" Often — especially in modern Node, Python, Go, and Rust — the answer is yes. Fewer strangers in your code. Less to audit. One less name for an attacker to hijack.

That's the whole idea. And honestly? Building the "boring" layer by hand was the most fun I've had coding in months.

See it in action (5-minute video)

I recorded a short walkthrough — the database working, the crash-recovery test, and the cargo tree moment that proves the dependency list is empty:

The code (MIT licensed, read it top to bottom)

GitHub: github.com/sanjaysah101/zdb
STDLIB.md — the full list of 12 packages I replaced and how: read it here
DESIGN.md — how the crash-safe engine actually works: read it here

The whole engine and command-line tool live in one readable file, src/main.rs. If you've ever been curious what's inside a database, it's a friendly place to start.

Sources

Built for the Zero Dependency Hackathon 2026 by Hackathon Raptors. All statistics above are cited in the Sources section. If this was useful, a ❤️ or a ⭐ on the repo genuinely helps. Thanks for reading!

OneUptime, "The hidden costs of dependency bloat in software development" (1,200+ full-tree dependencies). https://oneuptime.com/blog/post/2025-09-02-the-hidden-costs-of-dependency-bloat-in-software-development/view ↩
Sonatype, "2026 State of the Software Supply Chain" (454,600 new malicious packages in 2025; 1.2M cumulative). https://www.sonatype.com/state-of-the-software-supply-chain/2026/open-source-malware ↩
Spracklen et al., "Package Hallucinations" (USENIX Security 2025) — 19.7% of AI-suggested packages hallucinated across 576k samples; see also "Slopsquatting". https://en.wikipedia.org/wiki/Slopsquatting ↩
The Register, "How one dev broke Node, Babel and thousands of projects in 11 lines of JavaScript" (2016). https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ ↩
Microsoft, link.exe /Brepro (reproducible builds). https://learn.microsoft.com/en-us/cpp/build/reference/link-command-file ↩

The bug that differential fuzzing cannot find

Sanjay Kumar Sah — Mon, 10 Aug 2026 08:44:34 +0000

I ported a 30-million-download-a-month cron parser from TypeScript to Go and ran 36,000 differential test cases with zero unexplained divergence. Then I found a bug that no amount of fuzzing could ever have caught — because the output wasn't actually a function of the input.

Written for Port Mortem 2026, a porting hackathon run by @partnerships_raptors.

I spent a weekend porting cron-parser, a TypeScript library responsible for roughly 30 million npm downloads a month, to Go.

The result was 2,234 lines of Go replacing 2,823 lines of TypeScript, with zero dependencies. The original relies on Luxon for its date and timezone handling.

But the port itself wasn't the interesting part.

Getting a library to compile in another language is mostly mechanical. The difficult question was:

How do you prove that two implementations behave the same when they don't share a runtime, standard library, or date/time implementation?

That question led me through 36,000+ differential tests, several real bugs, some deliberately strange timezones, and eventually a dependency whose behavior depended on something I wasn't testing at all:

the current time.

First problem: you can't just run the original tests

The hackathon required the original test suite to pass against the port.

For a TypeScript → Go port, that's not literally possible.

The upstream suite contains 302 Jest tests written in TypeScript. They call expect() and directly exercise the TypeScript implementation. A Go binary can't execute those tests.

There was another option: have Jest call into the Go implementation through Node FFI.

But FFI was explicitly prohibited.

And translating the tests into Go didn't solve the problem either. At that point, I would have a new test suite rather than the exact suite the judges provided. Passing my translation wouldn't prove that the original tests still passed.

So instead of translating the tests, I treated them as an oracle.

Turning the test suite into a conformance oracle

I wrote a small recorder that reads the untouched .test.ts files as text and extracts literal calls such as:

CronExpressionParser.parse('<expression>', { ...options })

There were 130 such call sites.

Each call was executed against the original TypeScript implementation, and I recorded either:

the exact error string, or
the next 8 and previous 8 fire times as epoch milliseconds.

The Go implementation then replayed those exact inputs and compared the results.

The result:

130/130 matched.

The original test files were never modified. I verified that independently by running the suite itself — all 302 tests passed under TZ=UTC — and by committing SHA-256 hashes of all 24 upstream files.

That gave me a clean baseline.

And then the oracle immediately found three bugs my fuzzer hadn't found.

The bug my fuzzer could never see

The biggest one was the default timezone.

When no tz option is provided, the TypeScript implementation ultimately uses the process timezone, because Luxon falls back to the system zone.

I had defaulted the Go implementation to UTC.

On the machine I was developing on, that meant a difference of exactly 5 hours and 30 minutes.

91 of the 130 recorded call sites were silently wrong.

My differential fuzzer hadn't found it.

And this wasn't because I got unlucky.

It was structurally impossible for that particular fuzzer to find the bug.

Every generated test explicitly supplied a timezone.

So the fuzzer was exploring thousands of timezone combinations while completely bypassing the behavior that mattered.

Lesson #1: the original test suite knows things your generated corpus doesn't.

A generated test can only explore the assumptions encoded into its generator. If the generator always supplies a timezone, it can never discover what happens when the timezone is omitted.

That realization changed how I approached the rest of the port.

Then DST got weird

With the obvious bugs fixed, I built a proper differential fuzzer.

The basic idea was simple:

Generate a random cron expression and date/time configuration.
Run it against TypeScript.
Run it against Go.
Compare absolute epoch milliseconds.
Repeat.

I used 16 timezones specifically chosen to exercise different kinds of DST transitions.

Not every DST transition is one hour.

Zone	Transition
`America/New_York`	60 minutes
`Antarctica/Troll`	120 minutes
`Australia/Lord_Howe`	30 minutes
`Pacific/Chatham`	60 minutes, with a `+12:45` base offset
`America/Santiago`	60 minutes, occurring at midnight

These cases exposed six separate places where Go's time package and Luxon behaved differently.

None of these differences were obvious from reading the TypeScript code.

They existed at the boundary between two languages' interpretations of time.

Three cases were particularly nasty.

Ambiguous local times

During the fall-back transition, a local time such as 01:30 can occur twice.

There are two valid instants that both look like:

01:30

Go's time.Date chooses the first occurrence.

Luxon preserves the offset it already has.

My iteration logic couldn't escape the repeated hour and eventually hit its loop limit.

The problem wasn't simply "DST is complicated."

The problem was that the same wall-clock timestamp can represent two different points in time.

Month overflow

Go and Luxon also disagree about month arithmetic.

In Go:

January 31 + 1 month

normalizes forward and becomes:

March 3

Luxon clamps it to:

February 28

That difference had a nasty consequence.

February could effectively disappear from some iteration paths, meaning:

L 2 *

—the last day of February—

could fail to match anything.

Midnight transitions

Then there was America/Santiago.

Its DST transition occurs at midnight.

On September 6, 2026, the local day begins at 01:00.

There is no local 00:00.

This seemingly innocent code:

time.Date(2026, 9, 6, 0, 0, 0, 0, santiago)

resolves to:

2026-09-05T23:00:00

The previous day.

Now consider what happens when an iterator does something equivalent to:

Sep 5 midnight
        ↓ +1 day
Sep 6 midnight
        ↓ timezone resolution
Sep 5 23:00

The resulting date is still September 5.

The iterator asks for September 5 again.

And again.

Eventually it hits the loop limit.

These weren't hypothetical edge cases.

The harness found them.

That is exactly what the fuzzer was supposed to do.

Then I hit a wall

At this point, the fuzzer was doing useful work.

But it kept producing another kind of failure.

After roughly 70 seconds of fuzzing, it would sometimes find a divergence of exactly one DST shift.

Then the next run wouldn't.

The failures were concentrated around ambiguous start times.

So I tried to reverse-engineer the rule.

Which of the two valid instants does Luxon choose?

I collected examples:

Zone	Ambiguous time	Luxon chooses
`Antarctica/Troll`	2026-10-25 01:15	Earlier
`Europe/Berlin`	2026-10-25 02:30	Earlier
`America/New_York`	2026-11-01 01:30	Earlier
`Pacific/Auckland`	2026-04-05 02:30	Later
`Australia/Lord_Howe`	2026-04-05 01:45	Later

I tried five different hypotheses:

choose the earliest instant
choose the latest instant
choose the larger offset
choose the smaller offset
choose the pre-transition offset

Every rule worked for some zones and failed for others.

Each experiment meant another code change, rebuild, and roughly two-minute fuzzing run.

That is where the six hours went.

Eventually, I stopped guessing and opened Luxon's source.

The answer was hiding in 40 lines of code

Inside luxon/src/datetime.js was this function:

// find the right offset a given local time. The o input is our guess, which
// determines which offset we'll pick in ambiguous cases
function fixOffset(localTS, o, tz) { ... }

The comment was the clue.

Luxon wasn't following a universal rule like "always choose the earlier instant."

It was doing a guess-and-correct search.

And the initial guess mattered.

So where did the guess come from?

Another function:

function guessOffsetForZone(zone) {
  if (zoneOffsetTs === undefined) {
    zoneOffsetTs = Settings.now();
    // ...
  }
}

There it was.

The guess was based on:

the zone's offset right now.

The output depends on the clock

This took me a while to accept.

For an ambiguous local timestamp — the repeated hour during a fall-back transition — the actual instant returned by parse() can depend on when the function is called.

Run the same parse in January and then in July, in a timezone that observes DST, and the ambiguous timestamp can resolve differently.

Same input.

Same code.

Different output.

The difference is the wall clock.

There was no hidden deterministic rule waiting to be reverse-engineered.

My five failed hypotheses weren't simply bad guesses.

They were attempts to fit a deterministic function to behavior that wasn't actually a function of the input alone.

Conceptually, I had been trying to reason about:

output = f(input)

But the real behavior was closer to:

output = f(input, current_time)

And my differential fuzzer only controlled the first variable.

The faithful fix

At that point, the right solution was no longer to infer Luxon's behavior.

It was to reproduce it.

I transcribed fixOffset into Go, including the Math.min / Math.max branch for invalid local times, and seeded the calculation from:

time.Now().In(loc)

That means the Go port now inherits the same time-dependent behavior for ambiguous start times.

That's intentional.

I'm porting the library, not redesigning it.

If the original implementation behaves strangely, a faithful port needs to preserve that behavior unless the goal is explicitly to create a better implementation.

What differential fuzzing can — and cannot — prove

By the end, my harness had run:

36,040 cases across 106 rounds and 180 seconds.

That's strong evidence of equivalence.

But it could never have discovered the time-dependent behavior described above.

Not with 36,000 cases.

Not with 36 million.

Not with unlimited compute.

Because differential fuzzing fundamentally asks:

f(input) == g(input)

But this behavior wasn't determined solely by input.

It depended on the wall clock.

That's the important limitation.

Randomized differential testing is still the best tool I know for this kind of port.

It found six real bugs in my implementation — several serious enough that I would have confidently shipped them.

But differential fuzzing has a shape:

It can only discover divergences that are reproducible from the inputs it controls.

Ambient state is invisible unless you deliberately model it.

That includes things like:

current time
process timezone
locale
environment variables
operating-system behavior
cached state
values initialized once at process startup

The fuzzer told me that something was wrong.

It couldn't tell me why.

And throwing more compute at it wouldn't have changed that.

Reading about 40 lines of dependency source code did.

So is the port equivalent?

I wouldn't claim that.

My honest claim is narrower:

The Go port matches 6,400 generated cases across 10 fixed seeds, all 130 recorded call sites from the original suite, and a 180-second continuous differential run — with one known residual edge case whose scope and reproduction are committed.

That's a weaker statement.

It's also a more truthful one.

For a compatibility project, "I tested a lot" is not the same thing as "I proved equivalence."

The decision I'd change

If I did the project again, I would change one major thing:

Build the oracle first.

I initially created 15 hand-picked regression cases based on what I saw while reading the DST implementation.

Those cases were useful.

They found three divergences in only 15 tests.

But they had a fundamental weakness:

they inherited my assumptions.

My generated corpus inherited those assumptions too.

Both always supplied an explicit tz.

That's why the biggest correctness bug — the default timezone behavior — survived all 36,040 fuzz cases.

91 call sites were wrong by 5 hours and 30 minutes.

The conformance oracle caught it almost immediately.

And I had initially treated that oracle as little more than bookkeeping.

That was backwards.

The original test suite is a corpus created by someone else, against assumptions I don't share.

That's precisely what makes it valuable.

Generated tests explore the space I thought of.

Recorded tests explore the space the library's authors thought of.

The second is often where your blind spots live.

So next time, my order would be:

Original suite
      ↓
Conformance oracle
      ↓
Differential fuzzing
      ↓
Targeted regression cases
      ↓
Source-level investigation

Not because fuzzing is less useful.

Because each technique covers a different failure mode.

Two things I'd rather admit than hide

One residual divergence

There is one remaining divergence that occurs roughly 1 in 30,000 cases.

It involves backward iteration from an ambiguous instant in a timezone with a sub-hour DST transition.

I traced it to Luxon's endOf(unit) implementation:

startOf(unit)
    + 1 unit
    - 1ms

That combines wall-clock truncation with absolute-time arithmetic.

During a 30-minute fall-back transition, the result can land an hour earlier than expected.

I attempted a faithful transcription.

It caused iteration to stall.

The remaining alternatives were either blind approximations or porting enough of Luxon's Duration and objToTS machinery to effectively create a second library.

I chose not to do either.

The divergence is documented at the relevant function and in the findings, including its observed rate.

A known, reproducible limitation is something judges can evaluate.

A hidden one isn't.

Two claims I got wrong

I also made mistakes during the investigation.

At one point, I claimed that Go's most popular cron library uses AND semantics for day-of-month/day-of-week, while POSIX specifies OR.

That was wrong.

I had sourced the claim from an issue tracker for a different library in a different language and never verified it.

It's OR.

I also gave two different incorrect explanations for one of the DST mechanisms before a proper sweep settled what was actually happening.

Those mistakes remain in the write-up.

That's intentional.

The entire point of this exercise is that running the code and checking the evidence should be allowed to prove you wrong.

Removing the incorrect claims would remove part of the evidence of that process.

What the port revealed about the original library

The port was the instrument.

The original library was where some of the more interesting problems surfaced.

1. An existing DST bug is more complicated than it looks

CronDate.ts detects DST changes by subtracting hour numbers — effectively doing wall-clock arithmetic.

That breaks for transitions that aren't exactly one hour.

In Antarctica/Troll, the transition is two hours, and the observed difference can become 3, overshooting the constant being checked.

In Australia/Lord_Howe, the transition is only 30 minutes.

Depending on which minute the iterator enters the hour, the calculated difference can be either 1 or 2.

So there isn't a single hour-based constant that can correctly represent the transition.

The consequence is serious:

a daily job can silently skip an entire day.

2. The proposed fix doesn't handle 30-minute transitions

There is an open PR proposing:

Math.floor((offset - prevOffset) / 60)

That works for hour-based transitions.

But for Lord Howe:

floor(30 / 60) = 0

A real 30-minute DST transition therefore receives zero compensation.

The deeper issue is that the fields being written to are expressed in hours.

This isn't a constant problem.

The unit itself needs to become minutes.

3. `prev()` can hang on a valid expression

I also found a previously unreported case where prev() can exhaust its loop limit.

For example:

CronExpressionParser.parse('0 0 0 * * *', {
  tz: 'Pacific/Chatham',
  currentDate: '2026-09-27T05:45:00',
}).prev();

// Error: Invalid expression, loop limit exceeded

The expression is completely valid:

0 0 0 * * *

means:

every day at midnight.

But iterating backward across the Chatham spring-forward gap eventually exhausts the 10,000-step limit.

The same behavior reproduces in Australia/Lord_Howe.

My port deliberately does not reproduce this hang.

Compatibility doesn't mean inheriting an infinite loop when the behavior is clearly pathological.

Instead, the case is recorded in a known-divergences file with a deliberately narrow predicate so it cannot silently hide a regression in the port.

One more undocumented disagreement

There is another interesting difference between cron implementations.

During the fall-back transition in America/New_York, consider:

30 1 * * *

A daily job at 1:30.

Under cron-parser, it fires once.

Under Go's most popular cron library, it fires twice.

For wildcard hours, both implementations fire twice.

So the behavior differs depending on whether the hour field is literal or wildcard.

Neither library clearly documents this rule.

That means running the same schedule through both implementations can produce a real production difference:

one of your nightly jobs runs twice a year.

The boring win

And yes, the Go port is faster.

On my benchmark:

Parse() + 10 × Next()

Mean:  1330 µs → 37.6 µs
p99:   ~20× faster
Memory: ~5× lower
Dependencies: 0

That's roughly 35× faster on the mean.

It's a nice result.

It's also the least interesting part of the project.

Rewriting a JavaScript library in Go and discovering that Go is faster isn't particularly surprising.

The difficult work was reproducing the semantics of two completely different approaches to time.

The real lesson

I started this project thinking the hard part would be porting TypeScript to Go.

It wasn't.

The hard part was discovering what the original implementation actually means by the same operations.

"Add a month."

"Start at midnight."

"Choose the timezone."

"Parse an ambiguous timestamp."

"Find the previous occurrence."

Those sound deterministic.

They aren't always.

They can depend on:

language semantics
standard-library behavior
timezone databases
DST transition width
wall-clock arithmetic
environment configuration
process timezone
and, surprisingly, the current moment

That's why no single testing strategy was enough.

The original tests exposed assumptions my generator didn't know existed.

Differential fuzzing found edge cases I hadn't imagined.

Source inspection explained behavior that neither could fully explain.

And the most important discovery was the one I couldn't have found by generating more inputs:

Sometimes the bug isn't hiding in the input space.

Sometimes the output depends on state you forgot was part of the program.

That's the bug differential fuzzing could never find.

Reproduce it

Repository: https://github.com/sanjaysah101/port-mortem-cron-parser

Demo: https://youtu.be/4O2HAY4QAoM

Everything in this write-up is reproducible with:

node run.mjs

The script:

clones the pinned upstream repository,
runs the untouched upstream test suite,
replays the conformance oracle,
and runs the differential fuzzer.

Built for Port Mortem 2026 by Hackathon Raptors. Track C, TypeScript → Go.

You Should Own Your UI Components, Not Just Install Them

Sanjay Kumar Sah — Wed, 29 Jul 2026 05:00:03 +0000

One of my favorite ideas behind shadcn/ui has nothing to do with components. It's about ownership. Unlike most UI libraries, shadcn/ui doesn't ask you to install a package and hope the maintainers keep it stable forever. Instead, it generates the source code directly into your project.

Those components become yours. You can edit them. Refactor them. Delete them. There is no vendor lock-in.

When I started building create-notils, I realized this philosophy shouldn't stop at components. It should extend to the entire project.

Installing Dependencies vs. Owning Your Code

Most starter kits work like this:

npm install some-ui-library

Your application now depends on another package. Every update means waiting for a new release, and every customization risks diverging from upstream. Sometimes you end up wrapping library components just to make them fit your project. Slowly, your application becomes a thin layer around someone else's code.

There's nothing inherently wrong with this approach, but I wanted something different.

Source Code Is the API

In create-notils, the generated project belongs to you. The UI components are copied into your repository. The configuration files are yours. The project structure is yours. Nothing is hidden behind an SDK.

That means changing a button isn't a breaking change—it's just another Git commit.

One Design System, Multiple Applications

One challenge with monorepos is avoiding duplicated UI code. Instead of installing shadcn/ui inside every individual application, create-notils keeps a single, shared design system at the workspace root:

packages/
└── ui/
    ├── components/
    ├── lib/
    └── styles/

Every application imports components from the exact same package:

import { Button } from "@notils/ui/components/ui/button";

When a new component is added, every application immediately has access to it. There is one source of truth, not three slightly different copies floating around your workspace.

Updating Isn't a Package Upgrade

One thing I always found awkward about UI libraries is updating them. Usually, it looks like this:

npm update some-library

Then you read the changelog, hope nothing broke, and fix any breaking changes.

With shadcn/ui, updating is different because you're updating raw source files. In create-notils, the workflow is intentionally simple. Want to add a component?

bun ui:add dialog

Need to see what changed upstream before you pull it in?

bun ui:diff button

Ready to update?

bun ui:update button

Every change is visible as a normal Git diff. No hidden abstractions. No magic.

The Same Philosophy Beyond Components

This release made me realize something: the idea of ownership applies to much more than just UI.

Authentication should live in your repository. Configuration should live in your repository. Database schemas should live in your repository. Generated code should be fully understandable without having to read a framework's internal source code.

That's the direction I want create-notils to move toward. I don't want to build a platform that owns your application. I want to build a platform that helps you own it.

Version 0.2.0 is Live

This release introduces the foundation for that philosophy. Highlights include:

Interactive project creation: Scaffold exactly what you need.
Monorepo and standalone generation: Two outputs from one canonical source.
Shared @notils/ui package: A unified design system for your workspace.
Built-in UI commands: Add, preview, and update shadcn/ui components effortlessly.
Dedicated developer guide: Generated specifically for your new project.
Better documentation & testing: For all generated applications.

The project is still early. Authentication, database integration, and additional capabilities are coming in future releases. But the core philosophy is already taking shape: Own your code. Reduce repetitive setup. Spend your time building products instead of rebuilding infrastructure.

Opinionated by Design: Why I Chose Sensible Defaults Over Endless Configuration

Sanjay Kumar Sah — Wed, 22 Jul 2026 06:33:14 +0000

When people hear about a new project scaffolding tool, one of the first questions they ask is:

"Can I choose React Query or TanStack Query?"
"What about pnpm instead of Bun?"
"Can I use ESLint instead of Biome?"
"Can I choose Radix instead of Base UI?"
"Can I skip Tailwind?"

These are reasonable questions. In fact, I asked myself the same ones while building create-notils. My first instinct was to make everything configurable.

The more I thought about it, the more I realized I was about to build something I didn't actually want to use.

The Configuration Trap

Most project generators start simple. Then someone requests another option. Another package manager. Another ORM. Another authentication provider. Another CSS framework. Another UI library.

Eventually the CLI starts looking like this:

? Which package manager?
❯ npm
  pnpm
  yarn
  bun

? Which CSS framework?
? Which ORM?
? Which auth library?
? Which formatter?
? Which icon library?
? Which deployment target?

It feels flexible. But every new option creates more combinations to support. Five choices in one prompt don't create five possible projects. They multiply with every other prompt. The complexity grows much faster than the number of features.

I Built the Tool I Wanted to Use

One thing I've learned from building side projects is this: the first user should always be yourself.

Every project I start today uses almost exactly the same stack:

Next.js 16
React 19
Bun
Tailwind CSS v4
shadcn/ui
Base UI
Biome
TypeScript
Turborepo (when needed)

I wasn't switching between ten different combinations every week. I was rebuilding the same foundation over and over. So instead of asking twenty questions during scaffolding, I decided to optimize for the workflow I actually have.

npx create-notils my-app

A few seconds later, I'm writing features instead of answering prompts.

Opinionated Doesn't Mean Closed

There's an important distinction between opinionated and restrictive.

Some tools hide their implementation behind abstractions. Others generate code you aren't expected to touch. That isn't the direction I wanted.

Everything create-notils generates belongs to you. The UI components are source files. The configuration files are yours. The project structure is yours. If you don't like one of my decisions, you can change it immediately.

There is no vendor lock-in. The CLI gives you a starting point, not a framework you have to live inside forever.

Defaults Should Be Battle-Tested

Every opinion in create-notils comes from building real projects.

I didn't choose Bun because it was trendy; I chose it because it's the package manager and runtime I use every day. I didn't choose Biome because it's newer than ESLint; I chose it because having one fast tool for linting and formatting simplified my workflow.

The same applies to Tailwind CSS v4, shadcn/ui, Base UI, and the rest of the stack. The goal isn't to pick the newest tools. The goal is to reduce decisions that I already know the answer to.

Configuration Can Come Later

One question I get is: "What if someone doesn't want your stack?"

That's a fair point. The answer is: not every problem needs to be solved in version 0.1.

As create-notils evolves, it will become more modular. Instead of exposing every decision through dozens of prompts, I'm exploring a different direction: generate a solid foundation first, then let developers add capabilities as they need them.

Authentication
Database
Email
Storage
Payments
Monitoring

Those additions can evolve independently without turning the initial project creation into an interrogation.

Optimizing for Momentum

One of the biggest costs of starting a new project isn't writing code. It's context switching.

Every prompt interrupts momentum. Every configuration choice forces another decision before you've even written your first component. I'd rather spend those first ten minutes building a homepage than deciding which formatter to use.

That's why create-notils intentionally has very few questions. It assumes a sensible set of defaults and gets out of the way.

The Road Ahead

Being opinionated today doesn't prevent flexibility tomorrow. In fact, I think it makes future flexibility easier.

By first defining a production-ready baseline, I can later introduce optional capabilities without compromising the core experience. The foundation stays consistent. The project grows through composition instead of endless configuration.

That's the direction I want to explore next. In the next article, I'll take a closer look at how create-notils is organized internally, why the UI lives in its own package, and how that decision helps keep multiple applications consistent without duplicating components.

Try out the compiler architecture yourself by running npx create-notils my-app, or check out the source code on GitHub.

One Monorepo, Two Outputs: How I Eliminated Duplicate Starter Templates

Sanjay Kumar Sah — Mon, 20 Jul 2026 09:53:00 +0000

Part 2 of the Building create-notils series.

In my previous article, I explained why I stopped copy-pasting repositories and started building my own project scaffolding tool. However, one major architectural problem remained: I wanted create-notils to support both of these primary project structures.

A standalone Next.js application:

my-app/
├── src/
├── public/
├── package.json
└── components.json

And a Turborepo monorepo:

my-app/
├── apps/
│   └── app/
├── packages/
│   ├── ui/
│   └── config/
├── turbo.json
└── package.json

At first glance, the obvious solution is to maintain two separate templates—one for standalone and one for monorepo. Problem solved, right?

Except... it isn't.

The Hidden Cost of Multiple Templates

Every starter template starts out identical. Then one day, you fix a subtle bug in one template and forget to update the other. A week later, you upgrade Next.js in one repository before getting around to the second. A month later, you improve your UI package and find yourself manually copying files back and forth between folders.

Eventually, the templates slowly drift apart. The true cost isn't creating templates; the cost is maintaining them forever.

What Actually Changes?

When I sat down and compared the two project layouts side by side, surprisingly little was different. The actual application code, UI components, theming, and utility functions were 100% identical.

The only real differences were the structural project boundaries:

Concern	Monorepo	Standalone
UI Package	`packages/ui`	`src/components/ui`
Utilities	`@notils/ui/lib/utils`	`@/lib/utils`
Configuration	Shared workspace package	Local configuration
Package Manifests	Multiple (`package.json` files)	Single root manifest
Workspace Tooling	Present (`turbo.json`, workspaces)	Removed entirely

Everything else was effectively the exact same code. That single observation changed the entire architecture of create-notils.

A Different Approach: The Canonical Source of Truth

Instead of maintaining two templates, I decided to maintain only one. The monorepo became the canonical source of truth.

Whenever a developer chooses the monorepo option, the CLI simply clones and scaffolds it directly:

Canonical Monorepo
│
▼
Generated Monorepo

When someone chooses a standalone project, something much more interesting happens. The CLI dynamically transforms the canonical monorepo into a flattened standalone application:

Canonical Monorepo
│
▼
Flatten Transform
│
▼
Generated Standalone

Instead of storing two separate templates, I generate one directly from the other.

Thinking Like a Compiler

This shift changed how I thought about the CLI. It isn't just copying static files anymore; it is compiling a project. The monorepo acts as the source code, and the generated starter is the compiled output.

Because of this, the transformation can be cleanly broken down into deterministic, sequential steps:

Canonical Project
│
▼
1. Resolve Workspace Packages
│
▼
2. Rewrite Import Paths
│
▼
3. Move & Flatten Files
│
▼
4. Merge package.json Manifests
│
▼
5. Inline Shared Configurations
│
▼
6. Output Standalone Project

Each step in this pipeline has a single, isolated responsibility. That makes the entire process predictable, highly testable, and easy to evolve over time.

How the Monorepo Flattening Works

The transformation itself is surprisingly straightforward under the hood. Workspace packages simply become internal directories inside the application structure. For example, UI components are shifted directly into the source tree:

packages/ui/src/components/ui  ──►  src/components/ui

Shared utility functions are moved alongside them:

packages/ui/src/lib/utils.ts  ──►  src/lib/utils.ts

Next, the Abstract Syntax Tree (AST) or file contents are processed to rewrite import paths. A workspace import like this:

// Monorepo Workspace Import
import { Button } from "@notils/ui/components/ui/button";

Is automatically rewritten to a standard Next.js path alias:

// Standalone Local Import
import { Button } from "@/components/ui/button";

The exact same transformation happens for every shared workspace reference across the codebase. Zero component logic changes—only the artificial project boundaries disappear.

The Architectural Benefits

Treating the monorepo as a canonical compilation source provides several massive advantages for long-term maintenance:

1. One Source of Truth

Every bug fix, UI tweak, and architectural improvement is made exactly once. I never have to second-guess whether both project styles are synchronized.

2. Effortless Upgrades

When breaking changes drop for Next.js, Tailwind CSS, or React, I only update the canonical monorepo. Every generated project shape automatically inherits the upgraded foundation.

3. Automated CI Testing

Because generation is 100% deterministic, I can rigorously verify both outputs in a automated Continuous Integration (CI) pipeline:

Generate Monorepo ──► Build & Typecheck
       │
       ▼
Generate Standalone ──► Build & Typecheck ──► Verify Zero "@notils/*" Imports Remain

If the standalone transformation accidentally leaves behind even a single @notils/* workspace import, the CI pipeline fails immediately. Subtle scaffolding bugs become instant, actionable build failures.

Why Not Keep a "Shared Core" Submodule?

One common alternative I explored was keeping shared files in a common repository or submodule and wrapping two thin project templates around them. While this sounds clean in theory, it doesn't actually eliminate maintenance duplication.

You still end up manually managing:

Two separate package.json manifests
Two TypeScript (tsconfig.json) configurations
Two distinct linting and formatting setups
Two shadcn/ui configuration files
Two separate build and deployment pipelines

The duplication doesn't disappear; it just gets pushed to a different layer of the codebase. By treating the monorepo as the canonical compiler source, the standalone application becomes a zero-maintenance generated artifact.

Looking Ahead: From Templates to Targets

Right now, create-notils focuses exclusively on modern Next.js environments. But this compiler-style architecture opens up an exciting possibility: instead of thinking in terms of static templates, I'm starting to think in terms of compilation targets.

A single canonical project can eventually compile into completely different project shapes depending on the exact requirements of the developer. Today's supported targets are simply monorepo and standalone. Tomorrow, they could expand to include mobile-first layouts, desktop wrappers, or alternate frameworks that share a unified design system and backend layer.

Conclusion

The most valuable lesson I learned while building create-notils wasn't about Next.js app routers or Turborepo caching—it was about aggressively reducing maintenance overhead.

Every duplicated template is future technical debt. Every generated template is automation working in your favor.

When building developer tooling, the fundamental question stopped being:

"How many templates should I maintain?"

And became:

"How many project shapes can I generate from a single source of truth?"

That mindset shift fundamentally transformed how I build and maintain open-source software.

What do you think of generating standalone projects from a monorepo source of truth? Have you tackled template drift in your own tooling before? Let's discuss in the comments!

Try out the compiler architecture yourself by running npx create-notils my-app, or check out the source code on GitHub.

DEV Community: Sanjay Kumar Sah

PlateMate — Dietary Safety & Allergen Intelligence Powered by TabPFN

What I Built

The Problem

The Solution

Demo

Application Highlights

Code

sanjaysah101 / PlateMate

PlateMate — Dietary Safety & Allergen Intelligence Powered by TabPFN

platemate

Getting started

Quality gate

What's included

Structure

Environments

How I Built It

Why Prior Labs' TabPFN Foundation Model?

The 6-Dimensional Tabular Feature Space

In-Context Learning Without Gradient Training

Why Does Open Innovation Matter?

1. Health Privacy is Sacred

2. Edge Reliability Where it Counts

3. Transparent, Verifiable Mathematics

Prize Categories

RentDera Is Live on Google Play — The Rent Notebook, Now on Your Phone

The notebook problem

What RentDera does

Made for Nepal first

What it costs

How it was built

Try it, and tell me what's missing

Building Juryza: Hackathon Judging You Can Defend

Quick Roles & Features Tour

juryza.vercel.app

⚡ Quick Links & Live Demonstration

Demo Accounts Ready to Test

🏗️ The Architecture: Single Container, Zero Cloud Lock-In

The Tech Stack

🧮 The Mathematics: Judging You Can Defend

1. Cross-Judge z-Score Normalization

2. Bradley–Terry Pairwise Duel Arena

3. Quadratic Community Voting with Credit Budgets

✍️ The Participant Experience: Notion-Style Project Write-ups

🔍 Plagiarism, Rival Comparisons & Signed Certificates

💡 What We Learned Building Juryza

🚀 Get Involved!

Google Sign-In Works in Debug but Fails in Production on Android? Check This Hidden SHA-1

TL;DR — the fix

What "Google Sign-In is broken" actually looked like

Plain English: what a "signing certificate" is and why it matters

The twist: Google Play re-seals your app

I checked the obvious thing. It looked correct.

The breakthrough: stop reading the console, read the phone

The real cause: Quantum-ready app signing (beta)

Fixing it, step by step

Three ways to read a .der fingerprint

Optional: prove it by reading the app on the phone

Step 1 — Get adb

Step 2 — Turn on USB debugging on the phone

Step 3 — Confirm you're testing the Play Store build

Step 4 — Pull the app off the phone

Step 5 — Read its real fingerprint

Step 6 — Compare

Quick troubleshooting checklist

Five things I'd tell myself a week ago

750 Free Hours a Month, but a Month Is 730: 3 Free-Tier Mistakes That Took Down My App

The 30-second version (if you only read this far)

The setup

Mistake #1: the keep-alive cron

Mistake #2: one connection, held forever

Mistake #3: the one I can't undo

The actual root cause wasn't the deletion

Verifying it actually worked

The economics nobody writes about

What I'd tell myself two weeks ago

It isn't finished

OpenPledge: See Exactly Where Your Donation Goes (Blockchain + AI for Charity)

The problem, in one sentence

What I built

Step 1 — Get `adb`

What I built: `zdb`, a tiny database

3. `prev()` can hang on a valid expression