DEV Community: Anand Rathnas

Why Our Android Build Was Signed with the Wrong Key (A Regex Cautionary Tale)

Anand Rathnas — Fri, 22 May 2026 01:47:58 +0000

"Your Android App Bundle is not signed with the correct key."

That was the Google Play Console rejection after what should have been a routine release. The SHA1 fingerprint on the uploaded AAB didn't match the expected upload key. We'd been deploying to the Play Store for weeks with no issues. What changed?

Nothing, as it turned out. The signing had been broken the whole time -- we just hadn't noticed until Google tightened its fingerprint check.

The Setup

We use Expo with expo prebuild --clean to generate the android/ directory before each build. Because it's regenerated every time, the entire android/ folder is gitignored. This means any customization to build.gradle needs to happen through a post-prebuild injection script.

Our scripts/release.sh runs after prebuild and uses Node.js to patch the generated build.gradle with the release signing configuration. It finds the release buildType block and replaces signingConfig signingConfigs.debug with signingConfig signingConfigs.release.

Sounds straightforward. But the regex doing this work had a subtle, devastating bug.

The Symptom

After release.sh ran, we expected build.gradle to look like this:

buildTypes {
    debug {
        signingConfig signingConfigs.debug
    }
    release {
        signingConfig signingConfigs.release  // patched
    }
}

Instead, it looked like this:

buildTypes {
    debug {
        signingConfig signingConfigs.release  // WRONG
    }
    release {
        signingConfig signingConfigs.debug    // WRONG
    }
}

The configs were swapped. Debug was using the release keystore. Release was using the debug keystore. The build succeeded (both keystores are valid), but the release AAB was signed with the debug key.

The Buggy Regex

Here's the regex our script used:

const patched = buildGradle.replace(
  /release \{[\s\S]*?signingConfig signingConfigs\.debug/,
  match => match.replace('signingConfig signingConfigs.debug', 'signingConfig signingConfigs.release')
);

The intent: find release { followed (lazily) by signingConfig signingConfigs.debug, then replace that debug with release.

The problem: release { appears twice in the generated build.gradle.

signingConfigs {
    debug {
        // ...
    }
    release {        // <-- FIRST occurrence of "release {"
        storeFile file("release.keystore")
        storePassword "..."
        keyAlias "..."
        keyPassword "..."
    }
}

buildTypes {
    debug {
        signingConfig signingConfigs.debug   // <-- target line
    }
    release {        // <-- SECOND occurrence of "release {"
        signingConfig signingConfigs.debug   // <-- intended target
    }
}

The lazy quantifier [\s\S]*? matched the first release { (inside signingConfigs), then expanded minimally until it found signingConfig signingConfigs.debug. The first signingConfig signingConfigs.debug it encountered was inside the debug buildType. So the regex matched from signingConfigs.release { all the way down to the debug buildType's signing config -- and replaced it.

This is the core misunderstanding: lazy quantifiers don't find the closest release { to the target. They find the first release { in the file, then minimize the gap from there. If the first match is in the wrong block, the lazy expansion crosses block boundaries to reach the target string.

The Fix

Anchor the regex to the buildTypes section:

const patched = buildGradle.replace(
  /(buildTypes\s*\{[\s\S]*?release\s*\{[\s\S]*?)signingConfig signingConfigs\.debug/,
  '$1signingConfig signingConfigs.release'
);

By requiring buildTypes { before release {, the regex skips the signingConfigs.release block entirely. The capture group grabs everything from buildTypes { through release { and any content before the signing config line. Then we replace just the signingConfig reference while preserving the surrounding structure.

The key difference:

BEFORE: /release \{[\s\S]*?signingConfig signingConfigs\.debug/
AFTER:  /(buildTypes\s*\{[\s\S]*?release\s*\{[\s\S]*?)signingConfig signingConfigs\.debug/

The buildTypes\s*\{ anchor ensures we're in the right block before we ever look for release {.

Bonus Bug: versionCode Stuck at 1

While debugging the signing issue, we found a second problem. Expo prebuild defaults versionCode to 1 in every generated build.gradle. Google Play requires versionCode to be strictly increasing -- you can never upload a version code equal to or lower than a previously uploaded one.

Our fix: auto-generate versionCode from epoch minutes in the release script:

VERSION_CODE=$(($(date +%s) / 60))

This produces a value like 29432517 that increases every minute. No manual tracking, no CI state to maintain, and no collisions as long as you don't release twice in the same minute.

The Node.js injection then patches this into build.gradle:

buildGradle = buildGradle.replace(
  /versionCode \d+/,
  `versionCode ${process.env.VERSION_CODE}`
);

Lessons Learned

1. Lazy quantifiers aren't always lazy enough.

The *? quantifier minimizes the match after fixing the start position. If your start anchor (release {) appears multiple times, the regex locks onto the first occurrence and expands from there. It doesn't backtrack to try the second occurrence unless the first one fails entirely.

2. When a pattern appears in multiple blocks, anchor to the surrounding context.

Don't match release { when you mean buildTypes { ... release {. The extra context eliminates ambiguity. This applies to any structured text you're patching with regex -- Gradle files, XML, YAML, anything with nested blocks.

3. Gitignored generated files need persistent injection scripts -- and those scripts need tests.

We tested the app. We tested the build. We never tested release.sh in isolation. A simple assertion -- "after running the script, the release buildType should have signingConfigs.release" -- would have caught this immediately.

4. Always verify build artifacts before pushing to a store.

A one-line check would have saved hours:

# Verify the AAB is signed with the correct key
jarsigner -verify -verbose -certs app-release.aab | grep "SHA1:"

If the fingerprint doesn't match your expected upload key, stop. Don't submit and hope for the best.

The Meta-Lesson

Regex on structured data is inherently fragile. Every time expo prebuild changes the generated build.gradle format, our regex could break in new and creative ways. The real long-term fix is to use Expo's config plugins to inject signing configuration declaratively, removing the regex entirely. We're migrating to that approach now.

But until then -- anchor your patterns, test your scripts, and verify your artifacts.

Have you been burned by regex matching across block boundaries? What's your approach to patching generated build files? We'd love to hear about it in the comments.

Building jo4.io -- a URL shortener with analytics, QR codes, and a mobile app that is now correctly signed.

CDN Cache Invalidation: Why Deleted URLs Still Redirect (And How We Fixed It)

Anand Rathnas — Wed, 20 May 2026 01:48:55 +0000

You deleted the URL. Redis says it's gone. The database confirms it. But users click the link and still get redirected to the destination. cf-cache-status: HIT. Cloudflare is happily serving a cached copy that nobody told it to forget.

The Problem

We run a URL shortener behind Cloudflare CDN. For performance, we cache redirect responses at the edge with a 2-hour TTL. This means popular short URLs resolve in under 50ms globally without touching our origin.

The issue surfaced when a customer deleted a short URL and then clicked it to verify. Still working. They tried again 30 minutes later. Still working. They opened a support ticket.

Same story with URL updates. A user changed the destination from https://old-site.com to https://new-site.com. The short URL kept redirecting to the old destination. OG metadata updates had the same problem — social cards showed stale titles and images because the HTML page was cached at the edge.

Three distinct mutations, all broken:

Delete URL — link stays alive via CDN cache
Update URL — old destination served from CDN, old metadata in Redis
Admin force-expire — neither Redis nor CDN gets invalidated

The Root Cause: Layered Caching, Partial Invalidation

Our caching architecture has two layers:

User Request → Cloudflare CDN (edge cache) → Spring Boot API → Redis (app cache) → PostgreSQL

When a URL is deleted, the service correctly invalidated the Redis cache. But it never told Cloudflare. The CDN layer continued serving stale responses until the TTL expired naturally.

The update path was worse. UrlService.updateUrl() wrote the new destination to the database but invalidated neither Redis nor Cloudflare. Reads hit Redis first, got the old cached value, and never saw the database update.

Admin operations were the worst. AdminService.forceExpireUrl() and AdminService.deleteUrl() updated the database directly and skipped both cache layers entirely. Admin code had been written as direct repository calls, bypassing the service-layer cache invalidation that regular user operations went through.

The Fix: Purge Both Layers on Every Mutation

Step 1: Add `purgeUrls()` to CloudflareService

Cloudflare exposes POST /zones/{zone_id}/purge_cache with a {"files": [...]} body. We wrapped it in a service method:

@Async
public void purgeUrls(List<String> urls) {
    if (!isEnabled() || urls == null || urls.isEmpty()) {
        return;
    }

    // Cloudflare API allows max 30 URLs per purge request
    List<List<String>> batches = partition(urls, 30);
    for (List<String> batch : batches) {
        purgeUrlBatch(batch);
    }
}

private void purgeUrlBatch(List<String> urls) {
    String endpoint = CLOUDFLARE_API_BASE + "/zones/" + zoneId + "/purge_cache";
    try {
        HttpHeaders headers = createHeaders();
        Map<String, Object> body = Map.of("files", urls);
        HttpEntity<Map<String, Object>> request = new HttpEntity<>(body, headers);

        ResponseEntity<CloudflareResponse> response = restTemplate.exchange(
            endpoint, HttpMethod.POST, request, CloudflareResponse.class
        );

        if (response.getBody() != null && response.getBody().isSuccess()) {
            log.info("Purged {} URL(s) from Cloudflare cache", urls.size());
        } else {
            log.warn("Cloudflare cache purge returned non-success for URLs: {}", urls);
        }
    } catch (Exception e) {
        log.warn("Failed to purge Cloudflare cache: {}", e.getMessage());
    }
}

Two design decisions here:

@Async (fire-and-forget). CDN purge should never block the user operation. If Cloudflare is slow or down, the delete/update still completes instantly. The cache will expire naturally via TTL as a fallback.

Batched in groups of 30. Cloudflare's API limits purge requests to 30 URLs per call. A single short URL can produce up to 3 cacheable URLs (UI page, API endpoint, custom domain), so this limit matters for bulk operations.

Step 2: Build the List of Cacheable URLs

Each short URL can be cached under multiple paths. We need to purge all of them:

private void addCacheableUrls(List<String> urls, String shortUrl, String customDomain) {
    // UI page (HTML with OG tags, served via Cloudflare CDN)
    urls.add(uiHost + "/a/" + shortUrl);
    // API endpoint (JSON, also cached by Cloudflare)
    urls.add(apiHost + "/api/v1/public/a/" + shortUrl);
    // Custom domain URL (if configured)
    if (StringUtils.isNotBlank(customDomain)) {
        urls.add("https://" + customDomain + "/a/" + shortUrl);
    }
}

For updates where the short URL or custom domain itself changed, we purge both old and new URLs:

private void purgeCloudflareCache(String shortUrl, String customDomain,
                                   String oldShortUrl, String oldCustomDomain) {
    List<String> urlsToPurge = new ArrayList<>();
    addCacheableUrls(urlsToPurge, shortUrl, customDomain);

    if (oldShortUrl != null && !oldShortUrl.equals(shortUrl)) {
        addCacheableUrls(urlsToPurge, oldShortUrl, oldCustomDomain);
    } else if (oldCustomDomain != null && !oldCustomDomain.equals(customDomain)) {
        urlsToPurge.add("https://" + oldCustomDomain + "/a/" + shortUrl);
    }

    if (!urlsToPurge.isEmpty()) {
        cloudflareService.purgeUrls(urlsToPurge);
    }
}

Step 3: Wire Into Every Mutation Path

This is where the original bug lived. We had to audit every code path that mutates URL state:

UrlService (user-facing operations):

updateUrl() — added Redis invalidation + Cloudflare purge
deleteUrl() — already had Redis invalidation, added Cloudflare purge

AdminService (admin operations):

forceExpireUrl() — added both Redis + Cloudflare invalidation
deleteUrl() — added both Redis + Cloudflare invalidation
refreshMetadata() — added Cloudflare purge (OG tags changed)

The admin fix required a dedicated helper since admin code was calling repositories directly:

private void invalidateUrlCaches(UrlEntity url) {
    urlCacheService.invalidateCache(url.getShortUrl());

    List<String> urlsToPurge = new ArrayList<>();
    urlsToPurge.add(uiHost + "/a/" + url.getShortUrl());
    urlsToPurge.add(apiHost + "/api/v1/public/a/" + url.getShortUrl());
    if (StringUtils.isNotBlank(url.getCustomDomain())) {
        urlsToPurge.add("https://" + url.getCustomDomain() + "/a/" + url.getShortUrl());
    }
    cloudflareService.purgeUrls(urlsToPurge);
}

One method. Both cache layers. Called from every admin mutation.

Why `@Async` Is the Right Call

CDN purge is a network call to Cloudflare's API. It adds 100-300ms of latency. If we made it synchronous:

User deletes a URL — waits an extra 200ms for Cloudflare confirmation
Cloudflare API is down — user's delete fails or hangs
Bulk operations — each URL adds another round-trip

With @Async, the user operation completes immediately. The purge runs in the background thread pool. If it fails, the cache expires naturally via TTL (2 hours max). The user never notices.

The tradeoff: there's a brief window (milliseconds to seconds) where the CDN might still serve stale content after an update. For a URL shortener, this is acceptable. For something like financial data, you'd want synchronous purge with error handling.

Lessons Learned

1. Cache invalidation has layers. If your architecture has CDN → Redis → Database, you need to invalidate from the outside in. Clearing Redis doesn't help if Cloudflare is still serving cached responses. Most requests never reach your app server when the CDN has a hit.

2. Admin code is a blind spot. Admin operations often bypass service-layer abstractions. They call repositories directly for flexibility, but that means they skip whatever cache invalidation the service layer provides. Audit every mutation path, not just the user-facing ones.

3. Fire-and-forget is correct for CDN purge. Don't block user operations on external API calls. Use @Async, log failures, and rely on TTL expiration as your safety net. The worst case is stale content for a bounded time window.

4. Enumerate all cacheable URLs. A single logical resource can exist at multiple CDN URLs. Miss one and you have a partial purge. Our short URLs have three: the UI page, the API endpoint, and the custom domain variant. All three need purging.

Ever been bitten by a stale CDN cache hiding a "deleted" resource? What's your cache invalidation strategy?

Building jo4.io - URL shortener with analytics, custom domains, and team workspaces.

How to Track Link Clicks with Meta Pixel for Facebook Retargeting

Anand Rathnas — Mon, 18 May 2026 01:49:34 +0000

You're running Facebook ads. You want to retarget people who clicked your links. But you're sending traffic to someone else's site (affiliate offer, client landing page, whatever) where you can't add your pixel.

Here's how to fire Meta Pixel on every click using jo4's built-in retargeting.

How It Works

When someone clicks your jo4 short link, the redirect page loads your Meta Pixel before sending them to the destination. Facebook sees the PageView event with your pixel ID.

User clicks jo4.io/abc123
    ↓
Pixel fires (PageView event)
    ↓
User redirected to destination
    ↓
Facebook audience updated

This happens in milliseconds. Your audience grows with every click.

Prerequisites

A jo4 account (free tier works)
A Meta Pixel ID from Facebook Business Manager

Step 1: Get Your Meta Pixel ID

Go to Facebook Events Manager
Select your pixel (or create one)
Copy the 15-16 digit Pixel ID

It looks like: 123456789012345

Step 2: Add Pixel to Your Link

When creating or editing a link in jo4:

Expand the Retargeting section
Paste your Pixel ID in the Meta Pixel ID field
Save the link

That's it. Every click on this link now fires your pixel.

Step 3: Verify It's Working

Use the Meta Pixel Helper Chrome extension:

Install the extension
Click your jo4 short link
Check the extension icon - it should show a green checkmark

You'll see:

PageView event fired
Your Pixel ID in the details

Advanced: Track Multiple Pixels

Need different pixels for different campaigns? Each jo4 link can have its own pixel ID. Create separate links for:

Different ad accounts
Different clients
A/B testing audiences

Advanced: Combine with UTM Parameters

jo4 passes UTM parameters through to your destination. Combine with pixel tracking for full attribution:

jo4.io/abc123 (with Meta Pixel + UTMs)
    ↓
Pixel fires with PageView
    ↓
User lands on destination.com/?utm_source=facebook&utm_campaign=spring_sale

Now you have:

Facebook audience data (for retargeting)
UTM tracking (for conversion attribution)

What Events Are Tracked?

Currently, jo4 fires a PageView event on every link click. This is what you need for:

Building Custom Audiences ("People who clicked my links")
Retargeting campaigns
Lookalike audience creation

For Purchase, Lead, or other conversion events, those fire on your destination site where the action happens.

Cost Comparison

Solution	Cost	Complexity
Add pixel to destination	$0	Need site access
Third-party redirect service	$50-200/mo	Medium
jo4 retargeting	$0-16/mo	Low

Most link shorteners charge extra for retargeting features. With jo4, it's included in every plan including free.

Common Pitfalls

Wrong Pixel ID format: Make sure you're using the numeric Pixel ID, not the Pixel Name or Business Manager ID.

Ad blockers: Some users run ad blockers that prevent pixels from firing. This is normal - your tracked audience will be slightly smaller than total clicks.

Pixel not verified: Facebook requires domain verification for some features. The pixel will still fire for building audiences even without verification.

Result

After setup, your Facebook audience grows automatically with every link click. No code changes to destination sites. No complex integrations.

Check Events Manager after a few clicks - you'll see the PageView events with your short link URL.

Already using Meta Pixel with short links? Share your setup in the comments!

jo4.io - URL shortener with built-in retargeting pixels for marketers who track everything.

iOS App Store Screenshots and Compliance: The Gotchas After Your Build Succeeds

Anand Rathnas — Sat, 16 May 2026 01:36:05 +0000

Your EAS build succeeded. The IPA uploaded to App Store Connect. Time to submit for review, right?

Click. "Unable to Add for Review."

The Problem

App Store Connect has requirements that have nothing to do with your code. Screenshots need exact dimensions. Export compliance needs declarations for every country. Privacy questionnaires want to know about every SDK you use.

Here's everything that blocked my submission and how I fixed it.

Part 1: Screenshot Dimensions

I ran the simulator, took screenshots, uploaded them. Error:

Screenshots must be 1284 x 2778 pixels
Uploaded: 1320 x 2868 pixels

iPhone 16 Pro Max uses different dimensions than what App Store Connect expects for the "6.5-inch display" category.

The fix:

# Resize all iPhone screenshots to App Store requirements
for f in ./assets/appstore/iphone/*.png; do
  sips -z 2778 1284 "$f"
done

sips is macOS's built-in image processing tool. The -z flag resizes to exact dimensions.

Part 2: iPad Screenshots - The Stretching Disaster

"Easy," I thought. "Just resize the phone screenshots for iPad."

# DON'T DO THIS
sips -z 2732 2048 phone-screenshot.png --out ipad-screenshot.png

The result looked like someone grabbed my UI and pulled it sideways. Buttons were ovals. Text was bloated. Everything was wrong.

The actual fix:

Boot an actual iPad simulator and take native screenshots:

# Start the iPad simulator
xcrun simctl boot "iPad Pro 13-inch (M4)"

# Build and run on iPad
npx expo run:ios --device "iPad Pro 13-inch (M4)"

# Take screenshots at native resolution
xcrun simctl io booted screenshot ./assets/appstore/ipad/screenshot01.png

Phone and tablet are different form factors. The UI adapts. Resizing just stretches.

Part 3: The Screenshot Content Problem

Now I had the right dimensions. But my app requires login. Screenshots of a login screen aren't compelling.

The solution: Onboarding carousel with demo data.

I created a branch (ft/screenshots) with:

An OnboardingCarousel component showing app features
Hardcoded demo data (fake URLs, fake analytics)
A flag to show this instead of the login screen

// Check if we're in "demo mode" for screenshots
if (isDemoMode) {
  return <OnboardingCarousel />;
}

The carousel showed:

"Shorten Any URL" with a mock input and result
"Track Every Click" with demo analytics charts
"Share From Anywhere" showing the iOS share sheet integration
"Generate QR Codes" with a sample QR code

Took screenshots of each carousel page. Stashed the changes. Real users never see it.

Part 4: Export Compliance - The France Question

Uploaded screenshots. Hit submit. New blocker:

Missing Compliance: Export Compliance Information Required

The form asks about encryption. My app uses HTTPS. Does that count?

Then it asks specifically about France:

The options mention DES, triple-DES, RC4... algorithms I'm not using.

The correct answer: "None of the algorithms mentioned above"

If your app only uses HTTPS (TLS) through iOS's built-in networking, you select that it uses encryption, but then confirm you're only using standard iOS APIs. No custom cryptographic implementations = no export restrictions beyond what Apple already handles.

Part 5: Privacy Declarations

App Store Connect wants to know every piece of data your app collects. For each data type, you specify:

Is it linked to the user's identity?
Is it used for tracking?

My app uses Auth0 and Sentry. Here's what I declared:

Auth0:

Email Address: Linked to identity, not for tracking
Name: Linked to identity, not for tracking
User ID: Linked to identity, not for tracking

Sentry (crash reporting):

Crash Data: Not linked to identity, not for tracking
Performance Data: Not linked to identity, not for tracking

The gotcha: If you use analytics, you need to declare it. If you use third-party login, you're collecting identity data. Be honest - Apple reviews this.

The Complete Screenshot Workflow

For anyone doing this in the future:

Step 1: Capture iPhone Screenshots

# Boot iPhone 15 Pro Max (or similar 6.5" device)
xcrun simctl boot "iPhone 15 Pro Max"

# Run your app
npx expo run:ios --device "iPhone 15 Pro Max"

# Navigate to each screen and capture
xcrun simctl io booted screenshot ./assets/appstore/iphone/screenshot01.png

Step 2: Resize to App Store Dimensions

# iPhone 6.5" requires 1284 x 2778
for f in ./assets/appstore/iphone/*.png; do
  sips -z 2778 1284 "$f"
done

Step 3: Capture iPad Screenshots Separately

# Boot iPad Pro 13"
xcrun simctl boot "iPad Pro 13-inch (M4)"

# Run your app on iPad
npx expo run:ios --device "iPad Pro 13-inch (M4)"

# Capture at native resolution (2048 x 2732)
xcrun simctl io booted screenshot ./assets/appstore/ipad/screenshot01.png

Step 4: Compliance Declarations

Export Compliance: Standard iOS HTTPS = no additional export requirements
Privacy: Declare Auth0 data as identity-linked, crash reporting as not linked

Lessons Learned

Don't resize across form factors. Phone screenshots stretched to iPad dimensions look terrible. Capture natively on each device type.
Create demo content for screenshots. Login screens don't sell apps. Build an onboarding flow or demo mode, capture screenshots, then remove it.
Export compliance isn't scary. If you're using standard iOS networking (URLSession, Alamofire, etc.), you're just using Apple's TLS implementation. Select the exemption options.
Privacy declarations require honesty. List every SDK that touches user data. Auth0, Sentry, analytics - all of it.
sips is your friend. Built into macOS, handles resizing without installing ImageMagick or Photoshop.

Submitting your first iOS app? What unexpected blockers did you hit? Drop them in the comments.

Building jo4.io - URL shortener with a mobile app that survived App Store review.

One Push, Two App Stores: Parallel iOS and Android Builds with GitHub Actions

Anand Rathnas — Thu, 14 May 2026 01:39:58 +0000

Liquid syntax error: Unknown tag 'endraw'

Why We Removed Ads from Our Free Tools (And Put Them Only on Blog Posts)

Anand Rathnas — Tue, 12 May 2026 01:36:44 +0000

We built a suite of free developer tools: JSON formatter, JWT decoder, QR generator, UTM builder, and about a dozen others.

Then we added AdSense to every page.

Then we removed it from most of them.

Here's why.

The Original Plan

The logic seemed sound:

Free tools bring traffic (SEO)
Traffic sees ads
Ads generate revenue
Revenue funds development

We added a simple <AdSlot /> component to our UtilityPageLayout:

// Before: Ad on every utility page
export function UtilityPageLayout({ children }) {
  return (
    <main>
      <AdSlot position="top" />
      {children}
      <AdSlot position="bottom" />
    </main>
  );
}

Every tool page now had ads at the top and bottom.

What Actually Happened

Week 1: Impressions up, RPM decent.

Week 2: Noticed something odd in analytics.

Users on utility pages had:

Higher bounce rate (+15%)
Lower time on site (-20%)
Fewer conversions to signup (-25%)

The ads were working as ads. They were also working as exit doors.

The Problem with Ads on Utility Pages

Utility pages have a specific user intent: Do one thing, leave.

Someone using a JSON formatter:

Pastes JSON
Gets formatted output
Copies it
Leaves

Total time on page: 30 seconds.

An ad in this flow is a distraction. Worse, it's a competing call-to-action. The user came to format JSON. The ad says "Hey, check out this other thing."

If they click the ad, they leave. If they don't click the ad, it just... sits there, making the page feel cluttered.

Blog Posts Are Different

Blog posts have a different user intent: Learn something.

Someone reading a blog post:

Searches for a problem
Reads the solution
Maybe reads related sections
Considers the author's credibility
Might explore more content

Total time on page: 3-5 minutes.

An ad in this flow is... fine. The user is already in "reading mode." They're not trying to complete a task. A well-placed ad between sections doesn't interrupt a workflow because there's no workflow to interrupt.

The Fix

We removed ads from utility pages entirely:

// After: No ads in UtilityPageLayout
export function UtilityPageLayout({ children }) {
  return (
    <main>
      {children}
    </main>
  );
}

And kept them only on blog posts:

<!-- posts template -->
<article class="blog-post">
  <header>...</header>

  <div class="ad-container ad-top">
    <!-- Ad after title, before content -->
  </div>

  <div class="post-content">
    {{ content }}
  </div>

  <div class="ad-container ad-bottom">
    <!-- Ad after content, before footer -->
  </div>

  <footer>...</footer>
</article>

The Results

After removing ads from utility pages:

Bounce rate: Back to baseline
Time on site: +10% (people explored more)
Signups from utility pages: +30%

Ad revenue from blog posts alone: About the same (blog traffic is smaller but more engaged)

Net effect: More signups, same ad revenue.

The Principle

Match monetization to intent.

Page Type	User Intent	Monetization
Utility tools	Complete task quickly	None (or subtle "Made by X")
Blog posts	Learn, explore	Ads okay
Landing pages	Evaluate product	None (focus on conversion)
Documentation	Find answer	None (builds trust)

Ads work when they don't compete with the page's purpose. On a blog post, the purpose is consumption. On a utility page, the purpose is production.

What We Do Instead on Utility Pages

Instead of ads, utility pages now have:

Subtle branding: "Built by jo4.io" in the footer
Relevant CTAs: "Need to track these links? Try jo4.io" on the UTM builder
Cross-links: "You might also like: QR Generator, Link Shortener"

These don't generate direct ad revenue, but they:

Keep users in our ecosystem
Build brand recognition
Convert better than ads ever did

The Takeaway

Free tools are marketing, not monetization.

The ROI of a free JSON formatter isn't the $0.03 per ad click. It's the developer who bookmarks it, uses it weekly, and eventually needs a URL shortener for their project.

Ads on utility pages optimize for the wrong metric.

Do you run ads on your free tools? Curious how others handle this tradeoff.

Building jo4.io - free developer tools that won't interrupt your workflow.

The Auth0 Pricing Trap: Why Upgrading to Paid Gives You Less

Anand Rathnas — Sat, 09 May 2026 01:35:57 +0000

I was about to upgrade our Auth0 plan to get a cleaner domain. Then I looked at the pricing page.

And closed the tab.

The Setup

Auth0 gives you a randomly generated tenant URL when you sign up:

dev-exjsxdx8c6qt3uhf.us.auth0.com

Not exactly brand-inspiring. I wanted something cleaner like jo4.us.auth0.com.

To get a custom tenant name, you need to create a new tenant. To create a new tenant on the free plan:

❌ You have reached the limit for Tenants in your current plan.
   Upgrade your plan to create more tenants.

Fine, I thought. What does the paid plan cost?

The Math That Doesn't Math

Free Plan:

25,000 MAU included
1 tenant
Basic features
$0/month

Essentials Plan (Paid):

500 MAU included
Multiple tenants
MFA, RBAC
$35/month (B2C)

Wait. The paid plan includes fewer users than the free plan?

Yes. When you upgrade from free to Essentials, you go from 25,000 included MAUs to 500 included MAUs. Want more? Pay per MAU.

The Real Pricing Table

Here's what Auth0 pricing actually looks like:

Plan	Included MAU	Price	Cost per Additional MAU
Free	25,000	$0	N/A (hard limit)
Essentials	500	$35/mo	~$0.07/MAU
Professional	1,000	$240/mo	~$0.24/MAU
Enterprise	Custom	$30k+/year	"Let's talk"

So if you have 10,000 users and want to upgrade to Essentials, you'd pay:

$35 base + (9,500 × $0.07) = $35 + $665 = $700/month

For a cleaner URL and MFA.

What You Actually Get on Free

The free tier is surprisingly capable:

✅ 25,000 monthly active users
✅ Social login (Google, Apple, GitHub, etc.)
✅ Email/password authentication
✅ Passwordless (magic links)
✅ Universal Login (hosted login page)
✅ Basic user management
✅ 3 team members

What you DON'T get:

❌ Multi-factor authentication (MFA)
❌ Role-based access control (RBAC)
❌ Multiple tenants
❌ Custom domains (like auth.yourapp.com)
❌ More than 5 organizations (B2B)

When to Actually Upgrade

Stay on Free if:

You have < 25,000 MAU
You don't need MFA
You can live with dev-xxx.auth0.com
You're B2C or have < 5 B2B customers

Upgrade to Essentials if:

You NEED MFA (compliance, enterprise customers)
You have < 2,000 MAU (cost is reasonable)
Multiple environments are critical (staging/prod tenants)

Upgrade to Professional if:

You need > 3 SSO connections
You have enterprise customers requiring specific compliance
You're at the "money is less important than time" stage

Go Enterprise if:

You have > 25,000 MAU anyway
You need 99.99% SLA
You want a dedicated account manager to yell at

The Alternative: Don't Upgrade

Here's my actual decision:

Keep the free plan - 25,000 MAU is plenty for now
Accept the ugly URL - Users see it for ~1 second during OAuth redirect
Revisit when we need MFA - That's the real trigger, not vanity URLs

The dev-exjsxdx8c6qt3uhf.us.auth0.com domain is ugly, but it works. Users don't care. They're looking at their phone, waiting for the login to complete.

The Real Question

Before upgrading Auth0, ask yourself:

If it's the latter, save your money. Put it toward features your users actually see.

Why Not Self-Host?

"Just implement auth yourself" is advice I hear often. Here's why I'm staying with Auth0:

Auth0 handles:

Password hashing (bcrypt/argon2)
Password reset flows
Email verification
Brute force protection
Account lockout
Breach detection
Compliance (SOC2, HIPAA options)

One auth mistake = security incident. Auth0's free tier is free insurance.

The value isn't the login page. It's not storing passwords in your database.

What's your auth setup? Self-hosted, Auth0, Clerk, something else? I'm curious what other indie hackers are using.

Building jo4.io - a URL shortener that definitely doesn't store your passwords.

Publishing an Expo App to the App Store: The Parts Nobody Warns You About

Anand Rathnas — Thu, 07 May 2026 01:36:17 +0000

"Just run eas build --platform ios --auto-submit and you're done!"

Famous last words.

The Problem

I had a React Native app built with Expo. Android was already live on the Play Store. iOS should be the same process, right?

Here's what actually happened over the next 4 hours.

Part 1: The Provisioning Profile Dance

First build attempt:

❌ Provisioning profile doesn't support the App Groups capability

My app has a Share Extension (for sharing URLs from other apps). Share Extensions need their own bundle ID, their own provisioning profile, and their own set of capabilities.

The fix:

Go to Apple Developer Portal → Identifiers
Find both your main app ID AND the ShareExtension ID
Enable "App Groups" capability on BOTH
Go to Profiles → Delete the old profiles
Let EAS regenerate them

EAS will ask to create new profiles. Say yes. It knows what it's doing (mostly).

Part 2: Sign in with Apple - The Checkbox That Wasn't

Apple requires apps with third-party login to also offer Sign in with Apple. My app uses Auth0, which supports Apple auth. Should be simple.

Build attempt #2:

❌ Disabled: Sign In with Apple

The app.config.js was missing one line:

ios: {
  // ... other config
  usesAppleSignIn: true  // This one. This is the line.
}

Added it, rebuilt. Profile regenerated with the capability. Build succeeded.

Part 3: The "invalid_client" Mystery

App built. App ran. Tapped "Sign in with Apple."

invalid_client

Checked Auth0 config. Everything looked right:

Client ID: io.jo4.mobile ✓
Team ID: correct ✓
Key ID: correct ✓
Private key: pasted from .p8 file ✓

Spent 30 minutes rechecking these values.

Turns out, the Apple Sign in Key I created had empty "Enabled Services". The key existed but wasn't actually configured for Sign in with Apple.

The fix:

Apple Developer → Keys → Click your key → Edit
Check "Sign in with Apple"
Click Configure → Select your app as Primary App ID
Save

Tried again:

invalid_request
Invalid client id or web redirect url

Different error. Progress.

Part 4: Services ID - The Thing Auth0 Docs Bury

Here's what I didn't understand: Auth0 uses a web-based OAuth flow for Apple Sign in (via Universal Login). This means Apple sees it as a web app, not a native app.

Web apps need a Services ID, not just an App ID.

The fix:

Apple Developer → Identifiers → Create Services ID
Name it something like io.jo4.mobile.auth0
Enable "Sign in with Apple"
Configure with:
- Primary App ID: Your main app
- Domains: your-tenant.us.auth0.com
- Return URLs: https://your-tenant.us.auth0.com/login/callback
Update Auth0's Apple connection to use the Services ID as the Client ID

Finally:

✅ Sign in with Apple works

The Complete Checklist

For anyone doing this in the future:

Apple Developer Portal

[ ] App ID has "Sign in with Apple" capability
[ ] App ID has "App Groups" capability (if using extensions)
[ ] ShareExtension ID has matching capabilities
[ ] Key created with "Sign in with Apple" enabled
[ ] Key configured with correct Primary App ID
[ ] Services ID created (for Auth0/web-based flows)
[ ] Services ID configured with Auth0 domain and callback URL

app.config.js (Expo)

ios: {
  bundleIdentifier: "your.bundle.id",
  usesAppleSignIn: true,
  entitlements: {
    "com.apple.security.application-groups": [
      "group.your.bundle.id"
    ]
  }
}

Auth0

[ ] Apple connection uses Services ID as Client ID (not App ID)
[ ] Team ID, Key ID, and private key are correct

EAS

[ ] Delete old provisioning profiles if capabilities changed
[ ] Let EAS regenerate profiles with new capabilities

Lessons Learned

EAS is magic, until it isn't. The happy path is genuinely one command. The unhappy path is a maze of Apple portals.
Capabilities cascade. If your main app needs a capability, your extensions probably do too.
Auth0 + Apple = Services ID. This isn't obvious from either company's docs. Web-based OAuth flows need a Services ID, not an App ID.
Apple's error messages lie. "invalid_client" can mean the key isn't configured. "invalid_request" can mean you need a Services ID. Neither error tells you this.
The App Store submission is the easy part. Once EAS builds successfully with --auto-submit, it just... works. The hard part is getting that first successful build.

Building a mobile app? Save yourself the debugging session and bookmark this checklist.

Building jo4.io - a URL shortener with a mobile app that now actually exists on the App Store.

Why We Killed Hold Windows in Our Affiliate Marketplace

Anand Rathnas — Sat, 02 May 2026 01:35:40 +0000

We spent weeks building a settlement system for our affiliate marketplace. Hold windows. Clawbacks. Carry-forwards. Commission auto-approval schedulers. The works.

Then we deleted it all.

What We Built (and Why)

The idea was straightforward: when an affiliate drives a conversion, don't pay them immediately. Hold the commission for X days. If the customer refunds, claw back the commission. If there's a remainder below the payout threshold, carry it forward to next month.

Sounds reasonable, right? Every major affiliate network does something like this.

So we built:

Hold windows — configurable per campaign (7, 14, 30 days)
Clawback logic — refunds during hold period reduce the affiliate's balance
Carry-forwards — sub-threshold amounts roll to next settlement period
Auto-approval scheduler — commissions move from HELD → APPROVED after the hold window

What Went Wrong

Legal review flagged it.

The problem wasn't technical — it was regulatory. Holding affiliate funds creates obligations:

Money transmission concerns — holding and releasing funds on a schedule starts to look like money transmission in some jurisdictions
Dispute resolution requirements — clawbacks need a formal dispute process, not just an automatic deduction
Accounting complexity — carry-forwards create accrued liabilities that need proper bookkeeping
Tax reporting — when was the income earned? When the conversion happened, when the hold expired, or when the payout was made?

We're a URL shortener that added an affiliate marketplace. We're not a payment processor. Building the compliance infrastructure for hold windows was going to cost more than the feature was worth.

What We Did Instead

Deleted it. All of it.

- CommissionAutoApprovalScheduler.java (deleted)
- holdWindowDays field (removed from campaigns)
- clawbackAmount, previousCarryForward (removed from settlements)
- HELD commission status (removed)

Replaced with:

Firm offers — brands mark campaigns as non-negotiable. Publishers accept the commission as-is. No back-and-forth.
Immediate settlement — conversions are confirmed by Stripe webhooks. When Stripe says the charge succeeded, the commission is earned. Period.
Monthly payouts — simple monthly settlement with no holds. If there's a refund, the brand eats it (they can adjust their commission rates accordingly).

What We Added

The simplification freed up time for features that actually matter:

Partnership lifecycle — pause, resume, terminate partnerships with full event tracking
Multi-channel notifications — email, in-app, and push notifications for partnership events
Campaign budgets and expiry — brands set a maximum spend and end date, campaigns auto-pause when limits are hit
Firm offers — skip the negotiation dance when the brand knows what they want to pay

The Numbers

Metric	Before	After
Settlement-related DB tables	5	2
Commission statuses	6 (PENDING, HELD, APPROVED, CLAWED_BACK, PAID, FAILED)	3 (PENDING, APPROVED, PAID)
Settlement logic (lines)	~800	~200
Legal questions	Many	Few

Lessons Learned

Legal review before building, not after — we should have asked "can we hold affiliate funds?" before writing a single line of code. Would have saved weeks.
Complexity is a liability — every line of settlement logic was a potential bug, a potential legal issue, and a potential support ticket. Less code = less risk.
Copy the leader carefully — "Amazon Associates does hold windows" doesn't mean you should. Amazon has a legal team. You have a Notion doc.
Simpler products attract more users — publishers don't want to learn about hold windows and carry-forwards. They want to drive traffic and get paid.
KISS isn't lazy, it's strategic — deleting working code feels wrong. It's not. It's the highest-ROI engineering decision you can make.

Ever deleted a feature you spent weeks building? What was the hardest "kill your darlings" moment in your product? Share below.

Building jo4.io — a URL shortener with an affiliate marketplace that pays publishers without the complexity.

3 Auth Bugs We Shipped to Production (Spring + Auth0)

Anand Rathnas — Fri, 01 May 2026 01:37:02 +0000

We found three authentication bugs in production. Not from penetration testing. Not from a security audit. From a single user saying "I can't log in sometimes."

All three bugs were interconnected. Fixing one revealed the next. We shipped the fix in a single commit because pulling on one thread unraveled the whole chain.

Here's each bug, why it existed, and how we fixed it.

Bug 1: The 405 That Shouldn't Exist

Symptom: Sentry alerts showing HttpRequestMethodNotSupportedException — HTTP 405 "Method Not Allowed" — on endpoints that absolutely accept the methods being used.

Investigation: The stack traces pointed at bot traffic. Scanners probing random paths with random HTTP methods. PROPFIND /admin. OPTIONS /api/v1/protected/users. TRACE /oauth/token.

These should return 404 or be handled gracefully. Instead, they were hitting our impersonation filter, which assumed any request reaching it was a valid authenticated request. When the filter tried to process a PROPFIND request on a path that only accepts GET, Spring threw a MethodNotAllowed before our error handler could catch it.

The fix: Add HttpRequestMethodNotSupportedException to our global exception handler:

@ExceptionHandler(HttpRequestMethodNotSupportedException.class)
public ResponseEntity<ErrorResponse> handleMethodNotAllowed(
        HttpRequestMethodNotSupportedException ex) {
    return ResponseEntity.status(HttpStatus.METHOD_NOT_ALLOWED)
            .body(ErrorResponse.of("Method not allowed"));
}

Simple. But finding it required understanding that our filter was letting garbage requests through to the controller layer.

Which led us to Bug 2.

Bug 2: The Filter That Ran Too Early

Symptom: Admin impersonation — a feature that lets support staff act as a specific user — worked sometimes. Other times it silently failed and the admin saw their own account instead of the target user.

The architecture: We have an ImpersonationFilter that checks for an X-Impersonate-User header. If present and the caller is an admin, it swaps the security context to the target user.

The problem: The filter executed before our user sync filter.

In our Auth0 integration, the first request from a new Auth0 user triggers a "sync" — we look up the Auth0 subject in our database and create a local user record if one doesn't exist. This happens in Auth0UserSyncFilter.

The filter chain looked like this:

Request → ImpersonationFilter → Auth0UserSyncFilter → Controller

When an admin's first request included the impersonation header:

ImpersonationFilter runs. Tries to look up the admin user. But the admin hasn't been synced yet. Lookup returns null. Impersonation silently fails.
Auth0UserSyncFilter runs. Creates the admin user record.
Controller runs. Admin sees their own account, not the target.

On the second request, the admin user exists. Impersonation works. Hence "works sometimes."

The fix: Reorder the filters:

Request → Auth0UserSyncFilter → ImpersonationFilter → Controller

The sync must happen before any filter that depends on the user existing in the database. We enforced this with explicit @Order annotations:

@Order(1)  // Runs first — ensures user exists
public class Auth0UserSyncFilter extends OncePerRequestFilter { ... }

@Order(2)  // Runs second — can now look up the user
public class ImpersonationFilter extends OncePerRequestFilter { ... }

Spring Security's filter chain doesn't guarantee ordering by default. If you register filters without explicit ordering, you're at the mercy of component scanning order, which can vary between environments.

Bug 3: The Race Condition in User Creation

Symptom: Intermittent DataIntegrityViolationException — duplicate key constraint on the users table — during peak traffic.

Root cause: The Auth0 user sync had a classic check-then-act race condition:

// Thread A                         // Thread B
user = findByAuth0Sub(sub);         user = findByAuth0Sub(sub);
// user is null                     // user is null
user = createUser(sub, email);      user = createUser(sub, email);
// SUCCESS                          // DataIntegrityViolationException!

Two concurrent requests from the same user (common on app startup — the mobile app fires multiple API calls simultaneously) both see "user doesn't exist" and both try to create the record. One succeeds. One hits the unique constraint.

The fix: Catch the constraint violation and retry the lookup:

UserEntity syncUser(String auth0Sub, String email) {
    UserEntity existing = userRepository.findByAuth0Sub(auth0Sub);
    if (existing != null) {
        return existing;
    }

    try {
        return createNewUser(auth0Sub, email);
    } catch (DataIntegrityViolationException e) {
        // Another thread created the user between our check and insert.
        // Just fetch the record they created.
        UserEntity raced = userRepository.findByAuth0Sub(auth0Sub);
        if (raced != null) {
            return raced;
        }
        throw e;  // Genuine constraint violation, not a race
    }
}

This is the optimistic concurrency pattern. Instead of acquiring a lock before the check (pessimistic), we let the race happen and recover from the loser's exception. It's cheaper under normal load (no locking overhead) and handles the edge case gracefully.

Why All Three Were Connected

The 405 errors drew attention to our filter chain. Investigating the filter chain revealed the ordering bug. Fixing the ordering bug and putting more load on the sync path exposed the race condition.

It's a common pattern in production debugging: the bug you're investigating isn't the bug that matters. It's the thread that leads you to the real problem.

Lessons Learned

Handle every HTTP method in your exception handler. Bots send PROPFIND, TRACE, PATCH to paths that don't support them. Don't let these bubble up as unhandled exceptions.
Spring filter ordering is not implicit. If Filter B depends on state created by Filter A, use @Order to guarantee A runs first. Don't rely on component scan order — it varies.
Check-then-act is a race condition. If two threads can execute the "check" simultaneously, they'll both proceed to "act." Use optimistic concurrency (catch + retry) or pessimistic locking (SELECT FOR UPDATE).
Mobile apps create concurrent requests on startup. When the app opens, it often fires 3-5 API calls in parallel (user profile, notifications, config). If your user sync runs per-request, you will hit the race condition.
One bug leads to another. Don't stop when you fix the surface issue. Ask: "Why did this request reach this code path in the first place?"

What's the most interconnected set of bugs you've found in production? Share the debugging chain in the comments.

Building jo4.io — a multi-tenant platform where auth bugs are never "just" auth bugs.

The One-Character OAuth Bug That Broke Our API

Anand Rathnas — Fri, 01 May 2026 01:36:58 +0000

Our OAuth implementation worked perfectly. Every test passed. Users authorized apps, got tokens, refreshed them. Textbook OAuth 2.0.

Then a Pipedream integration broke.

The Problem

A user reported that their Pipedream workflow couldn't access certain API endpoints. The token was valid, the scopes were granted — but the API returned 403 Forbidden.

The error logs showed the token had zero scopes. That's impossible — we confirmed the user authorized read:urls write:urls during the consent flow.

The Root Cause

OAuth 2.0 (RFC 6749) defines scopes as space-delimited:

scope = "read:urls write:urls"

But some OAuth clients send them comma-delimited:

scope = "read:urls,write:urls"

Our scope parser split on spaces. Pipedream sent commas. The parser saw "read:urls,write:urls" as a single unknown scope, which mapped to zero valid scopes.

One character. Comma vs space.

// Before: only splits on space
String[] scopes = scopeString.split(" ");

// After: splits on comma OR space
String[] scopes = scopeString.split("[,\\s]+");

That's the fix. One regex character class. The rest of this post is about making sure it never happens again.

The Test Suite

We wrote a full end-to-end OAuth integration test: 1,605 lines covering the complete flow.

The test covers:

Authorization code request — with various scope formats
Token exchange — authorization code → access token
Token refresh — refresh token → new access token
Scope validation — comma-delimited, space-delimited, mixed, duplicates
Error cases — invalid codes, expired tokens, revoked grants
Real API calls — using the token against actual protected endpoints

The scope parsing tests specifically:

// Space-delimited (RFC 6749 standard)
assertScopeParsed("read:urls write:urls", Set.of("read:urls", "write:urls"));

// Comma-delimited (common in practice)
assertScopeParsed("read:urls,write:urls", Set.of("read:urls", "write:urls"));

// Mixed (yes, this happens)
assertScopeParsed("read:urls, write:urls", Set.of("read:urls", "write:urls"));

// Duplicates
assertScopeParsed("read:urls read:urls", Set.of("read:urls"));

Lessons Learned

RFCs are prescriptive, clients are creative — the spec says space-delimited, but real clients do whatever they want. Parse generously.
E2E tests catch what unit tests miss — our unit tests for scope parsing passed because they all used space-delimited scopes. The integration path through the actual OAuth flow with a real client exposed the mismatch.
One-character bugs hide in plain sight — the scope string looked correct in logs. You had to know that read:urls,write:urls was one scope, not two, to spot the problem.
Test the integration, not the unit — for auth flows especially, the value is in testing the full chain: consent → code → token → API call. Mocking any part of that chain hides bugs like this one.

Ever been bitten by a delimiter bug? What's the smallest change that broke your production? Drop it in the comments.

Building jo4.io — a URL shortener with a developer API that actually works.

The Idempotency Bug That Spammed dev.to's API for Weeks

Anand Rathnas — Sat, 25 Apr 2026 01:34:40 +0000

We built a small tool to keep our dev.to posts in sync with our markdown source files. Write locally, push to Git, and the tool updates dev.to if anything changed. Simple.

One morning, we noticed dev.to showing "Updated 2 hours ago" on an article we hadn't touched in weeks.

Then we checked the logs. Every article with an updatedAt field in its frontmatter was being republished. Every. Single. Day.

How the Sync Works

The tool is straightforward:

Read markdown posts with frontmatter (title, publishAfter, updatedAt, etc.)
For each post already on dev.to, check: "Has the local version changed since last sync?"
If isUpdateNeeded() returns true, PUT the latest content to dev.to's API

The check logic:

function isUpdateNeeded(localPost, devtoArticle) {
  // If local content changed after dev.to publish date, update needed
  const localDate = localPost.updatedAt || localPost.publishAfter;
  const devtoDate = devtoArticle.published_at;
  return new Date(localDate) > new Date(devtoDate);
}

Looks reasonable. If the local post was updated after it was published on dev.to, push the update.

The Bug

Here's a timeline of what actually happens:

Day 1: Post published with publishAfter: "2026-03-01", no updatedAt
Day 1 sync: Script creates article on dev.to. published_at = 2026-03-01T01:00:00Z
Day 5: We fix a typo. Set updatedAt: "2026-03-05" in frontmatter
Day 5 sync: isUpdateNeeded() → 2026-03-05 > 2026-03-01 → true. Updates dev.to. Correct.
Day 6 sync: isUpdateNeeded() → 2026-03-05 > 2026-03-01 → true. Updates dev.to again. Wrong.
Day 7 sync: Same thing. And Day 8. And Day 9. Forever.

The problem: updatedAt in the frontmatter is a static value. It doesn't change after Day 5. But published_at on dev.to reflects the original publish date, not the last update. So updatedAt > published_at is permanently true.

Every sync run thinks the article needs updating because the local update date is after the original publish date. It will never become false.

Why This Is an Idempotency Failure

An idempotent operation produces the same result whether you run it once or a hundred times. Our sync was not idempotent because:

The comparison updatedAt > published_at doesn't account for "has this update already been pushed?"
There's no record of "we already synced this version"
The trigger condition never resets

This is the classic state management trap in automation: comparing a static input timestamp against a fixed reference point creates a permanently true condition.

The Fix

We needed the sync to know: "Have I already pushed this update?" The answer was to compare against dev.to's edited_at field (which reflects the last API update), not published_at:

function isUpdateNeeded(localPost, devtoArticle) {
  const localDate = localPost.updatedAt || localPost.publishAfter;
  // Compare against last edit, not original publish
  const devtoDate = devtoArticle.edited_at || devtoArticle.published_at;
  return new Date(localDate) > new Date(devtoDate);
}

Now the timeline works:

Day 5 sync: 2026-03-05 > 2026-03-01 → true. Updates dev.to. edited_at = 2026-03-05T01:00:00Z
Day 6 sync: 2026-03-05 > 2026-03-05 → false. No update. Done.

The second piece was handling the null propagation. When there's no update and we sync metadata, the script was using Object.assign() to merge frontmatter. But Object.assign skips undefined values — so when updatedAt wasn't set, the old value persisted instead of being cleared:

// Before: Object.assign ignores undefined, so stale updatedAt persists
const merged = Object.assign({}, defaults, frontmatter);

// After: explicitly handle null/undefined fields
const merged = { ...defaults, ...frontmatter };
if (!frontmatter.updatedAt) {
  delete merged.updatedAt;  // Don't carry forward stale dates
}

The Broader Lesson

Every automation system that syncs state between two systems needs to answer this question: "How do I know this sync already happened?"

Common patterns:

Approach	Pros	Cons
Compare timestamps (what we did, fixed)	Simple, no extra storage	Must compare correct timestamps
Store sync hash	Deterministic, content-based	Extra storage/state to manage
Idempotency key per sync	Guarantees exactly-once	Complex, needs key generation
Event sourcing	Full audit trail	Heavy for simple use cases

For content crossposting, timestamp comparison is the right level of complexity. You just need to compare against the right timestamp — the one that reflects "when was this last synced?" not "when was this first published?"

How We Caught It

Honestly? By accident. We noticed articles on dev.to showing "Updated recently" when we knew we hadn't changed them. A quick look at the sync logs confirmed it — the same articles being pushed on every run. The fix was five lines of logic. The debugging was thirty minutes of reading logs.

The embarrassment of silently spamming dev.to's API for weeks? Immeasurable.

Takeaways

Idempotency isn't optional in automation. If your sync can run twice and produce different results (or the same unnecessary result), it's broken.
Test your sync with unchanged content. Run your pipeline twice in a row. Does the second run do nothing? If not, you have a bug.
published_at and edited_at are different things. Most APIs have both. Use the right one for your comparison.
Object.assign doesn't propagate undefined. If you're merging objects where "missing" is meaningful state, handle it explicitly.
Monitor your automation output, not just success/failure. Our script returned 200 every time. It was "succeeding" at doing unnecessary work.

Have you been bitten by an idempotency bug in your automation? What was the trigger? Drop it below.

Building jo4.io — a URL shortener with analytics, bio pages, and an affiliate marketplace for creators.

DEV Community: Anand Rathnas

Why Our Android Build Was Signed with the Wrong Key (A Regex Cautionary Tale)

The Setup

The Symptom

The Buggy Regex

The Fix

Bonus Bug: versionCode Stuck at 1

Lessons Learned

The Meta-Lesson

CDN Cache Invalidation: Why Deleted URLs Still Redirect (And How We Fixed It)

The Problem

The Root Cause: Layered Caching, Partial Invalidation

The Fix: Purge Both Layers on Every Mutation

Step 1: Add purgeUrls() to CloudflareService

Step 2: Build the List of Cacheable URLs

Step 3: Wire Into Every Mutation Path

Why @Async Is the Right Call

Lessons Learned

How to Track Link Clicks with Meta Pixel for Facebook Retargeting

How It Works

Prerequisites

Step 1: Get Your Meta Pixel ID

Step 2: Add Pixel to Your Link

Step 3: Verify It's Working

Advanced: Track Multiple Pixels

Advanced: Combine with UTM Parameters

What Events Are Tracked?

Cost Comparison

Common Pitfalls

Result

iOS App Store Screenshots and Compliance: The Gotchas After Your Build Succeeds

The Problem

Part 1: Screenshot Dimensions

Part 2: iPad Screenshots - The Stretching Disaster

Part 3: The Screenshot Content Problem

Part 4: Export Compliance - The France Question

Part 5: Privacy Declarations

The Complete Screenshot Workflow

Step 1: Capture iPhone Screenshots

Step 2: Resize to App Store Dimensions

Step 3: Capture iPad Screenshots Separately

Step 4: Compliance Declarations

Lessons Learned

One Push, Two App Stores: Parallel iOS and Android Builds with GitHub Actions

Why We Removed Ads from Our Free Tools (And Put Them Only on Blog Posts)

The Original Plan

What Actually Happened

The Problem with Ads on Utility Pages

Blog Posts Are Different

The Fix

The Results

The Principle

What We Do Instead on Utility Pages

The Takeaway

The Auth0 Pricing Trap: Why Upgrading to Paid Gives You Less

The Setup

The Math That Doesn't Math

The Real Pricing Table

What You Actually Get on Free

When to Actually Upgrade

The Alternative: Don't Upgrade

The Real Question

Why Not Self-Host?

Publishing an Expo App to the App Store: The Parts Nobody Warns You About

The Problem

Part 1: The Provisioning Profile Dance

Part 2: Sign in with Apple - The Checkbox That Wasn't

Part 3: The "invalid_client" Mystery

Part 4: Services ID - The Thing Auth0 Docs Bury

The Complete Checklist

Apple Developer Portal

app.config.js (Expo)

Auth0

EAS

Lessons Learned

Why We Killed Hold Windows in Our Affiliate Marketplace

What We Built (and Why)

What Went Wrong

What We Did Instead

What We Added

Step 1: Add `purgeUrls()` to CloudflareService

Why `@Async` Is the Right Call