DEV Community: Anand Rathnas

We Built a Referral Program Tool Inside Our URL Shortener. Here's Why.

Anand Rathnas — Mon, 01 Jun 2026 01:55:21 +0000

Every SaaS founder eventually asks the same question: "How do I get my existing users to bring me new ones?"

The answer is referral programs. The problem is the tools.

The Problem with Referral Tools

I spent a week evaluating referral platforms for jo4. Here's what I found:

Tool	Price	What's Missing
Rewardful	$29-299/mo	No link analytics, Stripe-only payouts
FirstPromoter	$49-149/mo	Complex setup, steep learning curve
ReferralCandy	$47-299/mo	E-commerce only, no API

Every single one required a separate URL shortener for tracking. Every one locked you into Stripe for payouts. And the cheapest option started at $29/mo for basic features.

Meanwhile, I was already running a URL shortener with click analytics, device tracking, and geo-location built in. The referral link infrastructure was already there. I just needed to add programs, referrers, and reward tracking on top.

What Referral Kit Actually Does

The pitch is simple: create a referral program in 10 minutes, not 10 days.

For Program Owners

You create a program at /rk with a name, reward structure, and destination URL. You choose between two reward types:

Fixed Points — every conversion earns the referrer the same amount. "Refer a friend, earn 100 points."

Percentage — referrers earn a cut of the conversion value. "Earn 10% of every purchase your referral makes."

You get a public landing page at /rk/{your-program-slug} where anyone can sign up as a referrer. They pick a custom referral code (like JOHN20), enter their payout email, and get a unique tracking link.

For Referrers

After enrolling, you get a link like https://jo4.io/r/{shortUrl}. Share it anywhere. Every click is tracked with the same analytics jo4 already provides — device, location, referrer source, timestamp.

When someone converts (buys something, signs up, whatever your program defines as a conversion), you earn points. Your dashboard shows clicks, conversions, conversion rate, and pending/approved/paid points across all programs you're in.

The Conversion Flow

This is where it gets interesting. Program owners trigger conversions via API:

curl -X POST https://jo4-api.jo4.io/api/v1/public/referral/conversion \
  -H "X-Jo4-Conversion-Key: your_secret_key" \
  -H "Content-Type: application/json" \
  -d '{
    "programSlug": "summer-referral",
    "referralCode": "JOHN20",
    "conversionValue": 99.00,
    "externalId": "order_12345"
  }'

The API attributes the conversion to the referrer, calculates the reward (fixed or percentage), and creates a pending reward. The program owner reviews and approves. The referrer requests payout. The owner pays (offline — no Stripe lock-in) and marks it done.

Status flow: PENDING → APPROVED → PAYOUT_REQUESTED → PAID

No payment processor dependency. No percentage-of-a-percentage. You pay your referrers however you want — PayPal, Venmo, bank transfer, gift cards, crypto. We just track the state.

Why Points Instead of Cash

Most referral tools deal in dollars. We deal in points.

Points are flexible. "100 points = $10" works. So does "100 points = 1 free month" or "100 points = a t-shirt." The program owner defines what points mean. We track the math.

This matters for non-SaaS businesses. A nail salon running a referral program doesn't want to wire $10 to a customer's bank account. They want to give them a free manicure. Points let you do that.

The Technical Bits

Attribution Window

Every program has a configurable attribution window (default: 30 days). If someone clicks a referral link and converts within that window, the referrer gets credit. After the window closes, the conversion is organic.

Event Deduplication

The conversion API uses externalId for idempotency. Send the same order ID twice, and we only credit the referrer once. This matters when your payment webhook fires multiple times (and it will).

Test Mode

Prefix your externalId with test_ and the conversion validates against your API secret but doesn't persist. Test your integration without polluting production data.

Webhooks

Every state change fires a webhook if you've configured one:

referral.signup — new referrer enrolled
referral.conversion — conversion attributed
referral.reward.approved — reward approved by owner
referral.reward.paid — payout completed

Pipe these into Zapier, Slack, your CRM — whatever your workflow needs.

What I Got Right

Building on existing infrastructure. The URL shortener already had click tracking, device fingerprinting, and geo-location. Referral links are just URLs with attribution metadata. We didn't rebuild tracking — we extended it.

Offline payouts. Forcing Stripe integration would have narrowed our market to SaaS-only. The confirm-payout workflow is more manual, but it works for salons, clinics, restaurants, freelancers — anyone who pays referrers in-person or via their preferred method.

Points abstraction. Cash rewards sound simpler, but they're actually harder. Currency conversion, tax implications, minimum payout thresholds — points sidestep all of that. Let the program owner decide what points are worth.

What I Got Wrong

Underestimating the UI complexity. The /rk page serves three audiences: program owners viewing their programs, referrers viewing their enrolled programs, and new users discovering programs. Getting the information hierarchy right took more iterations than the entire backend.

The reward approval workflow. My first implementation auto-approved everything. Turns out program owners want to verify conversions before committing to payouts. Fraud is real, even in referral programs. Adding the PENDING → APPROVED step was the right call, but I should have started there.

The Numbers

The whole feature is:

1,084 lines of referral program service (Java)
3 new database tables with proper indexes and constraints
15+ API endpoints (public + protected)
6 new frontend pages
Full webhook integration
Test mode for safe integration development

And it ships with every jo4 plan. No add-on pricing. No "referral features start at Enterprise tier."

Running a referral program or thinking about adding one to your product? I'd love to hear what's working (or not) for you. Drop your experience in the comments.

Building jo4.io - URL shortener with analytics, QR codes, and now referral program management. Because your links should do more than redirect.

RevenueCat Integration for Indie SaaS: The Apple Tax Nobody Prepares You For

Anand Rathnas — Fri, 29 May 2026 01:47:54 +0000

I had Stripe working perfectly. Web dashboard payments, team billing, subscription upgrades and downgrades - all handled. Users happy. Revenue flowing.

Then I submitted my React Native app to the App Store.

The Problem

Apple's App Store Review Guideline 3.1.1 is clear: if your app offers subscriptions and the user can subscribe in the app, you must use Apple's In-App Purchase system. No exceptions. No "just link to your website." If you show a paywall, it goes through Apple.

This means:

Apple takes 15-30% of every transaction
You can't use your existing Stripe flow on iOS
You need a second billing system running in parallel
Both systems must keep the same user's subscription state in sync

I'd heard of RevenueCat as the standard way to handle this. What I hadn't heard was how many moving parts are involved when you already have a working billing system.

The Architecture Decision

The core question: where does the source of truth live?

Option A: RevenueCat is the source of truth, and your backend reads from it.

Option B: Your backend database is the source of truth, and RevenueCat sends webhooks to update it.

I went with Option B. Here's why:

I already had subscriptionTier, subscriptionStatus, and subscriptionExpiry on my UserEntity
All my API authorization logic checked these fields
Stripe webhooks already wrote to these same fields
I wasn't about to rewrite every @PreAuthorize check to call RevenueCat's API

So the plan: RevenueCat sends webhook events to my backend, and my backend updates the database. Same pattern as Stripe. How hard could it be?

The Implementation

Step 1: The Webhook Handler (Spring Boot)

RevenueCat sends a POST with a JSON payload containing an event object. The event has a type (like INITIAL_PURCHASE, RENEWAL, CANCELLATION) and an app_user_id that you set when the user logs in on mobile.

The key insight: use your database user ID as RevenueCat's app_user_id. This makes the webhook handler trivial - you get the user ID directly from the event, look up the user, and update their subscription.

// On mobile login, after getting the backend user profile:
await Purchases.logIn(String(profileData.response.id));

// In the webhook handler, the app_user_id IS your database ID:
Long userId = Long.parseLong(event.path("app_user_id").asText());
UserEntity user = userRepository.findById(userId).orElseThrow();

No mapping tables. No secondary lookup. Clean.

Step 2: Product ID Conventions

RevenueCat doesn't tell you the subscription tier directly. You infer it from the product ID you configured in App Store Connect. I used a simple convention:

// Product IDs: "jo4_pro_monthly", "jo4_proplus_yearly", etc.
SubscriptionTier determineTierFromProductId(String productId) {
    String lower = productId.toLowerCase();
    if (lower.contains("proplus")) return SubscriptionTier.PRO_PLUS;
    if (lower.contains("pro")) return SubscriptionTier.PRO;
    return SubscriptionTier.FREE;
}

Order matters - check proplus before pro, otherwise every Pro+ user gets classified as Pro. Ask me how I found that one.

Step 3: Event Deduplication

RevenueCat can send the same event multiple times (retries, network issues). Without deduplication, a single purchase could reset a user's URL count twice.

Redis made this straightforward:

private boolean tryMarkEventAsProcessed(String eventId) {
    String key = "revenuecat:webhook:event:" + eventId;
    Boolean wasSet = redisTemplate.opsForValue()
        .setIfAbsent(key, "processed", Duration.ofHours(24));
    return Boolean.TRUE.equals(wasSet);
}

Atomic setIfAbsent with a 24-hour TTL. If it returns false, we've already processed this event. Done.

Step 4: The Seven Lifecycle Events

This is where the complexity lives. RevenueCat sends seven different event types, and each one needs different handling:

Event	What Happens	Tier Change?	Reset URL Count?
`INITIAL_PURCHASE`	New subscriber	Yes - set tier	Yes
`RENEWAL`	Auto-renewal succeeded	Yes - confirm tier	Yes
`CANCELLATION`	User cancelled (but still has access until expiry)	No - keep tier	No
`EXPIRATION`	Access period ended	Yes - back to FREE	No
`BILLING_ISSUE`	Payment failed, grace period	No - pause status	No
`PRODUCT_CHANGE`	Upgrade or downgrade	Yes - new tier	No
`UNCANCELLATION`	User re-enabled auto-renew	No - restore ACTIVE status	No

The tricky one is CANCELLATION. Your instinct says "downgrade them." But no - they've already paid for the current period. You mark them as CANCELLED but keep their tier until EXPIRATION fires.

Step 5: The Mobile Side

On the React Native side, RevenueCat's SDK handles the App Store / Play Store payment sheets. You wrap it in a hook:

export function useSubscription(): SubscriptionState {
  const [offerings, setOfferings] = useState(null);
  const [customerInfo, setCustomerInfo] = useState(null);

  // Derived state from entitlements
  const isPro = customerInfo?.entitlements.active['pro'] !== undefined;
  const isProPlus = customerInfo?.entitlements.active['pro_plus'] !== undefined;

  const purchasePackage = async (pkg) => {
    const { customerInfo } = await Purchases.purchasePackage(pkg);
    setCustomerInfo(customerInfo);
    return true;
  };
  // ...
}

The subscription screen needs three states:

Web subscriber - they subscribed via Stripe on the web. Show "Managed on Web" with a link to the dashboard.
Active IAP subscriber - they subscribed through the app. Show "Manage in App Store/Play Store."
Free user - show the paywall with Pro and Pro+ packages.

Getting state 1 right was the part I almost missed. If a user has a Pro tier in the backend but no active RevenueCat entitlements, they're a web subscriber. Don't show them a paywall. Don't let them accidentally buy a duplicate subscription through Apple.

The Security Gotchas

Webhook Authentication

RevenueCat lets you set an authorization token in their dashboard. Your webhook endpoint verifies it:

if (webhookAuthToken == null || webhookAuthToken.isBlank()) {
    log.error("SECURITY: webhook auth token not configured");
    throw new AppException(UNAUTHORIZED, "Webhook processing unavailable");
}

Fail closed. If the auth token isn't configured (deployment mistake, missing env var), reject everything. Don't silently accept unverified webhooks.

Return 200 for Unknown Events

RevenueCat retries on non-200 responses. If you throw a 500 for an event type you don't handle, RevenueCat will retry it forever. Return 200 and log it:

default -> log.info("Unhandled event type: {}", eventType);
// ...
return ResponseEntity.ok().build();

The Deployment Lesson

The webhook auth token is a secret. I stored it in GitHub Secrets and injected it at deploy time through the workflow:

# In the deployment workflow .env template
REVENUECAT_WEBHOOK_AUTH_TOKEN=${{ secrets.REVENUECAT_WEBHOOK_AUTH_TOKEN }}

I initially had it in GitHub variables (not secrets) because "it's just a webhook token, not a database password." Nope. Any token that gates financial transactions is a secret. Period.

What I'd Do Differently

Start with the webhook handler first. I built the mobile paywall UI first, which meant I had a "Buy" button that worked but no backend to receive the purchase event. Webhook-first lets you test with RevenueCat's webhook tester before touching mobile code.
Use the same product ID naming convention across platforms. I initially had different Android and iOS product IDs. The determineTierFromProductId logic doesn't care about platform, so matching conventions saves headaches.
Test cancellation and expiration separately. These are different events with different behaviors. My first implementation treated CANCELLATION as EXPIRATION and immediately downgraded users. They were not thrilled.

The Result

Two billing systems (Stripe for web, RevenueCat for mobile) writing to the same user record. The user doesn't know or care which one is active. They just see their subscription tier reflected consistently across web, iOS, and Android.

Total implementation: ~250 lines of Java backend, ~120 lines of React Native hooks, ~350 lines of paywall UI. Plus 580 lines of tests, because the one thing worse than two billing systems is two untested billing systems.

Have you dealt with the Apple IAP mandate on an existing SaaS? I'd love to hear how you handled the dual-billing complexity. Drop your war stories in the comments.

Building jo4.io - a URL shortener with analytics for developers who'd rather not give Apple 30% but don't have a choice.

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.

DEV Community: Anand Rathnas

We Built a Referral Program Tool Inside Our URL Shortener. Here's Why.

The Problem with Referral Tools

What Referral Kit Actually Does

For Program Owners

For Referrers

The Conversion Flow

Why Points Instead of Cash

The Technical Bits

Attribution Window

Event Deduplication

Test Mode

Webhooks

What I Got Right

What I Got Wrong

The Numbers

RevenueCat Integration for Indie SaaS: The Apple Tax Nobody Prepares You For

The Problem

The Architecture Decision

The Implementation

Step 1: The Webhook Handler (Spring Boot)

Step 2: Product ID Conventions

Step 3: Event Deduplication

Step 4: The Seven Lifecycle Events

Step 5: The Mobile Side

The Security Gotchas

Webhook Authentication

Return 200 for Unknown Events

The Deployment Lesson

What I'd Do Differently

The Result

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

Step 1: Add `purgeUrls()` to CloudflareService

Why `@Async` Is the Right Call