DEV Community: Sanjay Kumar Sah

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.

Why I Stopped Copy-Pasting Repositories and Started Building My Own Starter CLI

Sanjay Kumar Sah — Sat, 18 Jul 2026 18:51:36 +0000

Every developer has a "starter project." Some keep a GitHub template. Some duplicate their previous SaaS project. Some run create-next-app and spend the next two hours installing the same dependencies, configuring the same tools, and recreating the same folder structure.

I was in the second group. Every new project started the same way.

bun create next-app

Then came the checklist.

Install Tailwind CSS.
Configure Biome.
Add shadcn/ui.
Organize folders.
Set up a UI library.
Configure TypeScript.
Add environment files.
Set up a monorepo.
Copy utility functions.
Configure path aliases.
Install development tools.

None of these tasks were difficult. They were just repetitive. After starting enough projects, I realized something:

I wasn't building products. I was rebuilding the same foundation over and over again.

The Starter Kit Trap

Like many developers, I created a "starter repository." Whenever I wanted to build something new, I'd clone it. It worked... until it didn't.

Eventually I had multiple starter repositories.

One for a monorepo.
One for a standalone project.
One with authentication.
One without authentication.
One for experiments.
One that was already outdated.

Keeping them synchronized became its own maintenance project. Fix a bug in one. Forget to fix it in another. Upgrade Next.js in one repository. Forget the rest.

The more starters I created, the less useful they became.

Why Existing Starters Didn't Quite Fit

There are already fantastic starter kits in the ecosystem. Some focus on minimalism. Others include every feature imaginable. The problem wasn't that they were bad. The problem was that they optimized for someone else's workflow.

Every project I build starts with almost the same stack.

Next.js
TypeScript
Bun/pnpm
Tailwind CSS v4
shadcn/ui
Biome
Production-ready project structure

I didn't want to answer twenty configuration questions every time I scaffolded a project.

I wanted one command.

npx create-notils my-app

…and be ready to start building.

Opinionated Doesn't Mean Inflexible

One thing I've learned is that being opinionated is often a strength. Frameworks like Laravel, Rails, and even Next.js provide sensible defaults. You can always change them later. The important thing is that you're productive on day one.

That's the philosophy I'm following. Instead of trying to support every possible technology combination, I picked a stack that I genuinely enjoy using every day.

Everything generated by the CLI lives inside your repository.

Nothing is hidden.
Nothing is hosted.
Nothing prevents you from changing it.

The starter gives you a foundation—not a cage.

Building for Myself First

A question I've been asked is:

"Why not make everything configurable from the beginning?"

Because I'm the first user. The goal wasn't to build the most flexible scaffolding tool. The goal was to eliminate repetitive work from my own workflow. Once something proves useful in real projects, it can become configurable.

Until then, I'd rather spend my time building products than building configuration screens.

The Beginning of `create-notils`

That idea eventually became create-notils.

Right now, it focuses on doing one thing well:

Scaffold a modern Next.js project.
Support both standalone and monorepo layouts.
Configure a shared shadcn/ui setup.
Use Bun, Biome, Tailwind CSS v4, and TypeScript out of the box.

It's intentionally small.

Future releases will add authentication, database integration, API clients, Docker support, and more—but only after those features have been battle-tested in my own projects.

What's Next?

One design decision turned out to be far more interesting than I expected. I wanted to support both standalone projects and monorepos. Most tools solve this by maintaining two different templates.

I chose a different approach: The monorepo is the single source of truth, and the standalone project is generated from it through a deterministic transform.

That means I only maintain one project while generating two different project shapes.

In the next article, I'll dive into how that architecture works, why I chose it, and how it avoids template duplication.

I'd love to hear how you start new projects.

Do you use GitHub templates, starter repositories, scaffolding tools, or something completely different?

Building React Native Shouldn't Feel Like Assembling IKEA Furniture: A Modern Monorepo Starter Kit

Sanjay Kumar Sah — Tue, 14 Jul 2026 10:54:50 +0000

"I just want to build my app."

That sentence sounds simple. But if you've ever started a new React Native project, you know that is rarely what actually happens.

You open your terminal with excitement:

npx create-expo-app my-app

Five minutes later, you're already searching:

"How to set up Tailwind CSS in React Native?"
"Should I use NativeWind?"
"How do I share components between mobile and web apps?"
"Expo Router or React Navigation?"
"How do people organize React Native monorepos?"
"Should I use Turborepo?"
"How do I keep multiple apps sharing the same UI?"

Before you have written your first screen... you have already spent hours making architectural decisions. Not product decisions. Not business decisions. Just project setup.

The Invisible Tax Every React Native Developer Pays

Imagine you are opening a restaurant. You have recipes. You have chefs. You know exactly what food you want to serve. But before opening the doors, someone tells you:

"First, build the kitchen."

So you start researching:

which stove?
Which oven?
Which refrigerator?
How should the plumbing work?
How do multiple restaurants share ingredients?

Months later... you still haven't served a single customer.

Software development often feels exactly like that. We don't struggle because building apps is hard. We struggle because building the environment to build apps is hard.

Every New Project Starts With The Same Questions

Every engineering team eventually reaches the same crossroads:

"How should we organize this codebase?"

Should every app have its own repository?
Or should they share everything?
Should design components live inside the mobile app folder, or inside separate workspace packages?
What about authentication, API clients, themes, icons, and utilities?

Every answer seems correct... until six months later.

Then The Real Problems Begin

Imagine your company builds two applications: a Customer App and a POS App. Both need:

Buttons & Forms
A consistent design theme
Icons & Typography
Authentication plumbing
A typed API client

At first, copy-pasting feels faster. Until the designer changes one button style. Now your codebase looks like this:

Customer App  👉  Updated ✅
POS App       👉  Outdated ❌

Next week, the typography changes. Then the color palette. Then spacing. Suddenly, you are spending your weekends maintaining two separate design systems that were supposed to be one.

"Let's Make a Shared UI Package"

Sounds easy. Until you actually try to set it up in a mobile environment. Now you are diving deep into:

npm / pnpm workspaces
Turborepo pipeline caching
Package export maps
Metro bundler configuration
TypeScript path aliases & references
Babel plugins & module resolution

You started because you wanted one shared button. Now you are spending your evening debugging why Metro cannot resolve an SVG icon.

Styling Was Supposed To Be Easy, Too

Most web developers already know and love Tailwind CSS. So naturally, they ask:

"Can I just use Tailwind in React Native?"

The answer is yes. Then comes another rabbit hole:

Babel plugins
Metro config adjustments
Dark mode persistence
Theme CSS variables
Hot reload bugs
And version compatibility.

When NativeWind v5 arrived, it solved many long-standing pain points and made styling feel much closer to the web Tailwind experience developers love. But getting everything configured correctly - and keeping it working smoothly across SDK upgrades - still takes considerable time.

The styling itself isn't the hard part. The boilerplate setup is.

Building Components Is Harder Than It Looks

Most production apps don't need fancy, animated components. They need consistent, accessible components. A button should always look and feel like a button. An input should always handle keyboard focus correctly. A modal dialog should behave predictably across iOS and Android.

Projects like React Native Reusables made this dramatically easier by bringing modern, accessible UI primitives into the React Native ecosystem. Instead of reinventing custom components for every project, you start with well-designed building blocks.

But even then... someone still has to integrate, theme, and wire everything together across version upgrades.

⚡ The NativeWind v5 Migration Gap (And How RNStack Solves It)

Right now, React Native Reusables officially targets NativeWind v4. If you try using it with NativeWind v5, you will immediately hit styling bugs and breaking changes.

In RNStack, I have already fully migrated all included components to NativeWind v5 (Tailwind v4) and pre-fixed common problem areas—especially complex components like Icon, Button, and Select—so they render seamlessly across iOS, Android, and web out of the box.

And Then Comes Scale

Your first app becomes successful. Now the business asks:

"Can we build another app for our internal team?"

Great! Except now your architectural requirements have multiplied:

📱 Customer App   |   🛠️ Admin App   |   🏪 POS App   |   🚚 Driver App

Four applications. One engineering team. One design language. One backend API. One authentication system.

Should you create four separate repositories? Or one? This is where monorepos stop being a buzzword and start becoming a practical survival tool.

A monorepo isn't just about putting everything into one giant folder. It is about giving every project access to the exact same foundation: One shared UI. One shared API layer. One shared configuration. One source of truth.

But Monorepos Bring Their Own Challenges

Large repositories can easily become painfully slow. Without proper tooling, every build starts rebuilding everything from scratch, and every dependency install feels heavier.

That is where Turborepo changes the story. Instead of rebuilding the entire house every time you make a change, it only rebuilds the rooms you have actually touched.

The result is a development workflow that stays lightning-fast even as your codebase grows. Not because your apps became smaller—but because your tooling became smarter.

After Solving The Same Problems Again And Again...

I noticed a pattern. Every project I worked on looked different on the surface... but the foundational setup looked almost identical.

Every time I started a new React Native project, I found myself

copying the same workspace files
installing the exact same dependencies
configuring the same Metro resolver fixes
setting up the same TypeScript aliases
building the same shared UI package
and configuring Expo Router and NativeWind.

Over and over again.

Eventually, I stopped asking: "How do I start another project?"

Instead, I asked: "Why am I solving this plumbing problem every single time?"

That's Why I Built RNStack

RNStack isn't trying to replace Expo. It isn't another heavy UI library. It isn't a random collection of disconnected snippets.

It is simply the mobile-first, production-ready monorepo foundation I wished every new React Native project started with. A clean architecture where the difficult, time-consuming setup decisions have already been made for you. So you can focus on building your actual product instead of wrestling with build tools.

One Command To Start

You can scaffold a clean, production-ready project instantly using the create-rnstack npm package:

pnpm create rnstack my-app

A few moments later, you have a fully wired workspace that already includes:

Category	Pre-Configured Tooling
Core Framework	Expo (SDK 56) + Expo Router
Styling & UI	NativeWind v5 + React Native Reusables
Architecture	Turborepo + pnpm Workspaces
Shared Packages	Pre-linked `@repo/ui`, `@repo/api-client`, and `@repo/config`
Code Quality	Strict TypeScript, Biome, Husky
Reliability	Automatic Expo dependency validation & native bundle ID management

No hunting through outdated Medium tutorials. No copy-pasting broken configurations. No wondering whether you forgot a crucial setup step.

Small Details Matter

The biggest improvements in developer experience are often the ones you never notice because everything just works. RNStack automatically handles the subtle details that are easy to forget but painful to fix later:

✅ Unique Native Bundle IDs: Every generated app automatically gets a clean, unique bundle identifier.
✅ Aligned SDK Versions: Expo dependency versions stay strictly aligned with your installed SDK.
✅ Immediate Git Hooks: Pre-commit formatting and linting work right out of the box.
✅ Zero Bloat: Projects start clean without shipping dozens of unnecessary boilerplate demo screens.

These aren't flashy marketing features. They are the quiet, architectural details that save dozens of hours over the lifetime of a production codebase.

The Goal Was Never To Build Just Another Boilerplate

There are already plenty of starters out there. But most of them stop right after generating a few static files.

RNStack tries to go one step further: it gives you an evolving foundation meant to survive far beyond your first commit. Something robust enough to build your next weekend side project on, scale into a startup MVP, or ship to thousands of production users.

Try It Out & Join The Journey

If you are starting a new React Native project this week, give RNStack a spin. I would genuinely love to hear your feedback—what feels intuitive, what feels awkward, and what could be improved!

Every issue opened, suggestion made, and pull request submitted helps make the mobile development experience better for the next engineer.

🔗 Get Started in Seconds

Scaffold your new project right now from your terminal:

pnpm create rnstack my-app

📦 NPM Package: Check out the CLI documentation on the create-rnstack npm page.
⭐ GitHub Repository: Explore the monorepo architecture, star the repo, or contribute on sanjaysah101/rnstack.

If RNStack saves you a few hours—or helps you skip a frustrating evening of configuration—that is exactly why I built it.

Happy building! 🚀

BrewOps: A Production-Grade HTCPCP Dashboard

Sanjay Kumar Sah — Thu, 02 Apr 2026 11:40:36 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built BrewOps, a highly serious, production-grade DevOps dashboard for a delightfully useless protocol: the Hyper Text Coffee Pot Control Protocol (HTCPCP, RFC 2324).

Tired of walking to the breakroom only to find the coffee pot empty? BrewOps brings 1998's best internet joke into the modern era. It's a sleek control center that lets you monitor your network of coffee pots and teapots. You can issue BREW and PROPFIND requests, select your Accept-Additions (like Milk, Syrup, or Alcohol), and watch the live terminal logs.

And yes, if you try to brew coffee using the "Earl Grey Teapot" appliance, the server will correctly reject your request with a 418 I'm a teapot status code, complete with a panic animation.

Demo

Live App: BrewOps HTCPCP Dashboard

Code

Source Code: Google AI Studio Project

How I Built It

I built this using Next.js and Tailwind CSS to give it that authentic, dark-mode "serious developer tool" aesthetic. The icons are from lucide-react, and I used motion/react (Framer Motion) to create the smooth terminal log entries and the bouncing teapot animation when a 418 error is triggered.

The entire project was generated, iterated on, and deployed using Google AI Studio.

Prize Category

I am submitting this for two categories:

1. Best Ode to Larry Masinter:
This project is a literal, playable implementation of Larry Masinter's legendary RFC 2324. It faithfully recreates the HTCPCP headers (Accept-Additions, message/coffeepot content types) and intentionally triggers the famous 418 I'm a teapot error when you target the wrong appliance.

2. Best Google AI Usage:
I built this entire application from scratch using Google AI Studio (powered by Gemini 3.1 Pro). The AI agent helped me scaffold the Next.js app, design the Tailwind UI, write the simulated terminal logic, and instantly deploy the final build to Google Cloud Run (which is where it is currently hosted!).

DEV Community: Sanjay Kumar Sah

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

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

A quick look

The three pages

Why "generosity" — the causes

How I used each sponsor technology

Tech stack

What I learned

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

The setup

Bug #1: The app crashed on launch

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

The part that actually hurt: losing the testing streak

Takeaways for solo mobile devs

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

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

What I built: zdb, a tiny database

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

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

2. Detecting corruption → a 15-line checksum

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

4. Reading command-line options → a simple loop

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

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

So… should you delete all your dependencies?

See it in action (5-minute video)

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

Sources

The bug that differential fuzzing cannot find

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

Turning the test suite into a conformance oracle

The bug my fuzzer could never see

Then DST got weird

Ambiguous local times

Month overflow

Midnight transitions

Then I hit a wall

The answer was hiding in 40 lines of code

The output depends on the clock

The faithful fix

What differential fuzzing can — and cannot — prove

So is the port equivalent?

The decision I'd change

Build the oracle first.

Two things I'd rather admit than hide

One residual divergence

Two claims I got wrong

Step 1 — Get `adb`

What I built: `zdb`, a tiny database

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

The Beginning of `create-notils`