DEV Community: MarcoBlch

My Invite Gate Held. The Database Had a Side Door.

MarcoBlch — Wed, 04 Nov 2026 18:54:26 +0000

Originally published on meridianbuild.dev, my build log for FastPass, a paid inbox where people pay to reach you and get refunded if you don't reply.

A few weeks ago I wrote about how my invite-only gate lived in the browser on FastPass, and how I moved it to the server. The comments were kind and sharp. One of them basically asked: you locked the front door, but did you check the back door?

I hadn't, not properly. The gate lived in Edge Functions, and it was tested there. But Supabase also exposes the database itself to the browser through PostgREST, and what the browser can do there is decided by Row Level Security (RLS). If RLS let a client write a value that the gate trusts, the gate is decoration.

On October 27 I checked. It did. This post is about how I found out without touching production data, and what I'd do the same way on any Supabase project.

I'll describe the problems at the level of their class. They're fixed, but there's no reason to publish a recipe.

The trap: RLS is about rows, not columns

This is the part I wish someone had told me on day one.

An RLS policy like "a user can update their own profile" answers one question: which rows? It says nothing about which columns. Once a user is allowed to update their row, they can update every column in it, from the browser, with the public anon key and their own session.

And Supabase's default privileges grant anon and authenticated broad rights on tables in public. So unless you restrict it, "update your own row" means "update anything in your own row", including the fields your server logic trusts: a status, a flag, a role, a counter.

That was my side door. The invite gate checked something that the database let the user change.

Step 1: a copy of production, without production

I wanted to attack the real schema, not the one in my migrations folder, because those two drift. But I didn't want to point probes at production, and I didn't have (or want) the database password on the VPS.

So I rebuilt the schema from read-only catalog queries through the Supabase Management API: tables, columns, functions, triggers, every policy and every grant. No rows, no user data. Then I loaded it into a throwaway Postgres in Docker, on a tmpfs, with small stubs for auth.uid() and auth.jwt().

How do you know the copy is faithful? I took an md5 fingerprint of the policies (a hash over pg_policies, ordered) on both sides. Same hash, same rules. That one number is what made me trust everything that came after.

Step 2: probes that impersonate a client

Each probe pretends to be one kind of caller and tries one thing:

begin;
savepoint probe;
set local role authenticated;
select set_config('request.jwt.claims',
  '{"sub":"<user-a-uuid>","role":"authenticated"}', true);

update public.some_table set some_column = 'x' where id = '<row-of-user-b>';

rollback to savepoint probe;

set local role plus fake JWT claims is exactly what PostgREST does for a real request, so the policies see the same thing they'd see in production. Each probe runs inside a savepoint that is always rolled back, so probes can't affect each other.

I wrote 70 of them, for three callers: anonymous, a logged-in user, and service_role. They covered both directions:

Must fail: reading someone else's data, writing a protected column, calling a function you shouldn't.
Must work: everything the real app does. A security fix that breaks signup is not a fix.

The first run listed problems in four classes:

Users could change sensitive columns on their own profile, because nothing restricted columns.
Some policies meant for the server only were also open to client roles.
Referral codes could be issued to accounts that shouldn't get them.
Statistics views ran with their owner's rights instead of the caller's, because they were created without security_invoker.

Step 3: the fix, with a proven way back

The migration does what you'd expect: column-level GRANT UPDATE (col1, col2) instead of table-wide rights, server-only policies restricted to service_role, views switched to security_invoker = true, and functions that look up trusted state in the database instead of in what the client sends.

Before pushing it, I wrote the rollback and tested it on the bench: apply up, apply down, and check that the policy fingerprint is back to the production one. Only then did it go to production, the same day. After the migration, all 70 probes passed, and production REST traffic showed zero 401 or 403 responses, so the real app wasn't tripping over the new rules.

The fix that would have broken every email signup

One fix deserves its own paragraph, because the obvious version was wrong.

The function that redeems an invite code should only redeem it for your own account. The obvious rule is "the user in the JWT must be the account being redeemed for". But with email signups, the redeem runs right after the account is created, before the email is confirmed, so there's no session yet. The obvious rule would have rejected every email signup.

The real rule has two branches. With a session, the JWT user must match. Without one, the account must have been created minutes ago and not be confirmed yet. Writing the "must work" probes first is what showed me that.

I also added 27 regression tests for the gate in CI (Deno), including a replay of the OAuth bypass I fixed earlier, run against an in-memory fake of Supabase so no real Google account is needed. To check that the tests test something, I removed the ownership check from the code and watched them fail.

Traps on the way

safeupdate can make a probe fail for the wrong reason. Supabase uses pg-safeupdate, which rejects an UPDATE without a WHERE. A "must fail" probe that fails because of it proves nothing about RLS. Always give probes a real filter.
My bench ignored column grants at first and reported false failures. If you rebuild a schema, rebuild the privileges too, not just the policies.
EXPLAIN checks privileges without running the query. That's a safe way to confirm in production that a role can't touch a column: you get "permission denied" or a plan, and nothing is executed.
supabase db push wants the database password. I applied the migration through the Management API instead.
The old logs endpoint I'd planned to use returned 410 Gone. I verified with gateway logs instead.

Same bench, another project: the NULL in the lobby

I ran the same method the same day on KidCapital, my money game for kids: around 45 probes, three callers (anonymous, a player targeting another player, a member of a game). The findings went from 18 to 5, and I accepted the 5 that remain. The normal journey (solo game, leaderboard, multiplayer create, join, play, finish, data deletion) passed 18 out of 18 before and after.

Two bugs from that project are worth stealing.

A privacy fix that broke game creation. A few days earlier, I'd made multiplayer games visible only to their players, through a membership function. Right after, nobody could create a game. The client inserts a game and asks for the row back (INSERT ... RETURNING), and the RETURNING part is checked against the select policy. But the membership function can't see the row that's still being inserted, so the check fails and the whole insert is refused. The fix: let the creator see their own game directly, without the function. Fixed the same day, with an end-to-end test in production passing 8 out of 8.

A guard that said nothing. A trigger compared the current user with the player whose turn it is. In the lobby, before the game starts, that player is NULL. In SQL, x <> NULL is not true or false. It's NULL, and an IF treats it as "don't fire". So the guard was silent exactly when nobody was playing yet. The fix is IS DISTINCT FROM, which treats NULL as a value. The bench caught it because it tests the rejection cases, not only the happy path.

What I'd tell any Supabase builder

RLS picks rows. Use column-level grants for the columns your server trusts.
Never trust user_metadata for roles or permissions. The user can edit it. Use app_metadata (set with service_role) or your own table.
Audit a copy, not production, and prove the copy is faithful with a fingerprint of pg_policies.
Write "must work" probes next to "must fail" ones. They're what stop a security fix from breaking signup.
Test your rollback before you need it.

The person who asked about the back door was right. The best thing about building in public is that people ask the question you were avoiding.

My Black Friday Dry Run Would Have Billed 3,334 Users in the Wrong Currency

MarcoBlch — Tue, 03 Nov 2026 18:43:09 +0000

Originally published on meridianbuild.dev, my build log for OutfitMaker, an AI outfit planner that works from the clothes you already own.

On October 30 I set up the Black Friday offer for OutfitMaker: Premium annual for 39 € / $39 / £35 for the first year, instead of 59.99 / 59.99 / 49.99. It runs from November 25 to November 30, with two emails, a banner and a one-click checkout link.

Before writing any copy, I ran the email audience as a dry run. Not "send to myself". I asked the code: for every user who would receive this email, which price would they see and which currency would Stripe charge?

The answer was that 3,334 of the 3,691 accounts would be priced in euros. Most of my users are in the US.

Where the euros came from

OutfitMaker sells in EUR, USD and GBP. On the website, the currency comes from the request: the visitor's location and language. That part was fine and had been fine since early October.

Outside a web request, there's no visitor. An email, a background job or a signed checkout link has to decide from the database. I added a currency column to users on October 12, set every time someone visits the site. Accounts created before that, or people who hadn't come back since, had an empty column.

And empty meant the default, which is EUR. That's 3,334 people, so 90 % of the list.

In practice, an American would have opened an email saying "39 €", clicked the link and landed on a Stripe Checkout in euros. Some might have paid anyway. I suspect most would have closed the tab. Nothing would have crashed, and no error would have shown up in a log. It would just have been a worse Black Friday, and I would probably have blamed the offer.

A currency from the time zone

I didn't have a country for those accounts. But I had something almost as good: their time zone, which the app already stores to work out local times.

A time zone isn't a country, but it's close enough to pick between three currencies:

def currency_for_time_zone(zone)
  zone = iana_zone(zone)
  return nil unless zone
  return "GBP" if GBP_ZONES.include?(zone)
  return "EUR" if zone.start_with?("Europe/") || EURO_ZONES.include?(zone)

  "USD"
end

iana_zone does the tedious part. Rails stores friendly names like "Eastern Time (US & Canada)", so they get mapped back to IANA names (America/New_York). Old aliases get normalized. And UTC, Etc/* and blank values return nil, because they say nothing about where someone lives.

When the time zone is useless, the language decides: English reads as an American account, which matches most of my traffic, and French, German, Spanish, Portuguese and Italian read as euros. Only when both are missing does the old default apply.

The order of trust is now explicit, in one method on User:

def effective_currency
  return currency if PriceBook::CURRENCIES.include?(currency)

  PriceBook.currency_for_time_zone(time_zone) ||
    PriceBook.currency_for_locale(locale) ||
    PriceBook::DEFAULT
end

First the currency the person was actually shown on the site, then the time zone, then the language, then EUR. Every email, job and checkout link calls this, and none of them read the raw column any more.

Backfilling without overwriting anyone

I also wanted the column filled in, so the site, the emails and the checkout agree from now on. The backfill is a one-off rake task, and it has three rules:

It only touches users whose currency is blank.
The write checks again that the column is still blank. If someone visits the site between the read and the write, their real currency wins.
It runs as a dry run by default and returns the counts per currency.

def run(dry_run: true)
  ids_by_currency = Hash.new { |h, k| h[k] = [] }
  scope.select(:id, :currency, :time_zone, :locale).find_each do |user|
    ids_by_currency[user.effective_currency] << user.id
  end

  unless dry_run
    ids_by_currency.each do |currency, ids|
      ids.each_slice(1_000) { |slice| scope.where(id: slice).update_all(currency: currency) }
    end
  end

  ids_by_currency.transform_values(&:size).sort.to_h
end

scope is User.where(currency: [nil, ""]), and it's reapplied inside the update_all. That's what makes it idempotent and safe to rerun.

After the fix, the full user base splits into 2,192 USD, 1,317 EUR and 182 GBP. That looks like my traffic, which is the sanity check I care about.

One coupon, three exact amounts

The second trap was on the Stripe side. My annual Premium price is a single Stripe Price in EUR with currency_options for USD and GBP. I didn't want a separate Black Friday price, because then renewals would need special handling.

So the discount is a coupon on the normal price. It has duration: "once", so only the first invoice is discounted and the renewal is the normal annual amount. And it uses an amount_off per currency, through the coupon's own currency_options:

EUR: 59.99 minus 39.00 = 20.99 off (on the coupon itself)
USD: 59.99 minus 39.00 = 20.99 off
GBP: 49.99 minus 35.00 = 14.99 off

A percentage coupon would have been simpler, but it would give £34.99 instead of £35 and 39.00 only by luck of rounding. With amount_off per currency, the first invoice is exactly the number in the email.

The code creates the coupon the first time it's needed and checks it on every use. If the amounts on Stripe ever drift from the ones in the code, because someone edited the coupon in the dashboard or because of a bad deploy, the checkout refuses to open. I'd rather lose one sale than charge a price I never announced.

The window is in New York time

The last detail is the clock. The offer ends at the end of November 30 in New York, which is 05:59 on December 1 in Paris. The window is defined once, in America/New_York, and the code switches itself on and off. There's nothing to deploy on the day.

Takeaways

Before sending any email that shows a price, dry-run the audience and count which price each person would see. It takes a minute and it found 3,334 wrong prices.
"Default currency" is a decision, not a fallback. If most of your users aren't in the default, the default is a bug waiting for an email.
A time zone is a decent proxy for a country when you only need to choose between a few currencies. Treat UTC and blanks as unknown, not as a location.
Backfills should only fill blanks, check again at write time, and dry-run by default.
For a discount in several currencies, use amount_off per currency in currency_options on a once coupon, and refuse the checkout if the coupon drifts.

The offer starts November 25. At least now everyone will see it in their own money.

93 Paid Clicks, Zero Signups: My Google Button Doesn't Work Inside TikTok

MarcoBlch — Mon, 02 Nov 2026 07:56:03 +0000

Originally published on meridianbuild.dev, my build log for OutfitMaker, an AI outfit planner that works from the clothes you already own.

On October 30 I looked at the results of a small TikTok ad for OutfitMaker. It had cost 21 € and brought 93 visits, so about 0.23 € per visit. 73 % of those visitors were in the US and 97 % were women, which is the audience I asked for.

Signups from those 93 visits: zero.

That would be a normal result for a bad ad. But over the same 7 days, the site as a whole turned 5,252 visits into 1,042 signups. That's 19.8 %, roughly one visitor in five. At that rate, 93 visitors should give somewhere around 18 signups. Zero is not bad luck. Something was broken, and only for those visitors.

What the TikTok visitors had in common

The ad audience was not perfect. The age targeting didn't hold: 63 % of the visitors were 18 to 24, which is my weakest age group for payments. But that age group signs up fine. It just doesn't pay. Age could explain zero sales. It could not explain zero accounts.

The thing every one of those 93 people shared was the browser. When you tap a link in a TikTok ad, the page doesn't open in Safari or Chrome. It opens inside TikTok, in an embedded webview. Instagram and Facebook do the same.

And the first button on my sign-up page was "Continue with Google".

Google says no to webviews

Google's sign-in refuses to run inside embedded webviews. If you start a Google OAuth flow from one, you don't get the account picker. You get an error page: Error 403: disallowed_useragent. Google's reason is security: an app that hosts a webview can see everything typed into it, including a password.

So from inside TikTok, my funnel was:

See the ad, tap it.
Land on a page whose biggest button is Google.
Tap it, get a Google error page in English talking about user agents.
Leave.

The email form was right below the button, and it works fine in a webview. But a person who just hit an error page doesn't scroll down to try plan B. They close the page and go back to their feed.

I can't prove that this was the cause for all 93 visits. I didn't have tracking on in-app sign-up views at the time, which is exactly the problem I fixed next. But it's the one thing that was different for those visitors, it was the first thing they'd tap, and it fails 100 % of the time in that browser. I shipped the fix the same day.

Detecting the in-app browser

There's no API for "am I in a webview". The only signal is the User-Agent, and each app adds its own token. Here is the module, more or less as it is in production:

module InAppBrowser
  RULES = [
    [:tiktok, /musical_ly|BytedanceWebview|TikTok/],
    [:instagram, /Instagram/],
    [:facebook, /FBAN|FBAV|FB_IAB/],
    [:snapchat, /Snapchat/],
    [:linkedin, /LinkedInApp/],
    [:other_webview, /; wv\)/]
  ].freeze

  module_function

  def detect(user_agent)
    return nil if user_agent.blank?

    RULES.each { |app, pattern| return app if pattern.match?(user_agent) }
    nil
  end
end

The order matters. On Android, the Instagram and Facebook User-Agents also contain ; wv), the generic Android WebView marker. If the generic rule came first, every Instagram visitor would be labelled "other webview". It goes last as a catch-all.

User-Agent sniffing is fragile, and I know it. Apps change their strings. But the failure mode here is gentle. If detection misses a webview, the visitor sees the old page, which is what everyone saw before. If it wrongly flags a real browser, that visitor loses the Google button but still has a working email form. Neither mistake locks anyone out.

What the page does now

A concern exposes the result to the Devise sign-up and sign-in views:

module InAppBrowserDetection
  extend ActiveSupport::Concern

  included do
    helper_method :in_app_browser, :in_app_android?
  end

  private

  def in_app_browser
    return @in_app_browser if defined?(@in_app_browser)

    @in_app_browser = InAppBrowser.detect(request.user_agent)
  end
end

Inside TikTok, Instagram or Facebook, the page changes in three ways:

Google is hidden. A button that can only produce an error page is worse than no button.
Email goes first. The form that works is the first thing you see.
A short tip explains how to get Google back: open the page in your real browser. On Android, there's a one-tap link that uses a Chrome intent URL (intent://...;package=com.android.chrome;end) to reopen the same page in Chrome. iOS has no reliable equivalent, so iOS visitors only get the text.

The tip can be dismissed, and the dismissal is remembered, so it doesn't nag.

Measuring it this time

The other half of the fix is that I can now see this funnel. Each sign-up page view inside a webview fires an in_app_signup_view event with the app name. Each signup made inside a webview carries an in_app property on the existing Signup event. Those two numbers give me a conversion rate for each app, which is what I was missing on October 30. I only had a total of zero.

That's the lesson I'd keep even without the webview part: when you pay for traffic, check that the page works in the browser that traffic actually uses. I tested my sign-up page in Chrome, Safari and Firefox, on desktop and on a phone. I never opened it from inside the app that I was paying to send people from.

Takeaways

If your traffic comes from TikTok, Instagram or Facebook, your page opens in their webview. Test it there, by tapping your own link inside the app.
Google OAuth doesn't work in those webviews. If Google is your first or only sign-in option, those visitors hit an error page.
Detect the webview from the User-Agent, put the generic Android ; wv) rule last, and make sure a wrong guess fails gently.
Measure the in-app funnel separately. A blended conversion rate of 19.8 % hid a channel that was converting at zero.

21 € is cheap tuition. The expensive version of this story is the one where you scale the ad first.

A QA Checklist for a Recurring AI Character

MarcoBlch — Tue, 27 Oct 2026 17:09:17 +0000

Originally published on meridianbuild.dev, my build log for OutfitMaker, an AI outfit planner that works from the clothes you already own.
OutfitMaker has a recurring character on TikTok and Instagram. Her name is Dot. She is a stylist with short cropped grey hair, gold hoops, a black fine knit turtleneck and a small terracotta brooch, and she works in a London townhouse atelier with a brass clothing rail and a velvet armchair. Every episode, a client comes in with a closet problem and leaves with three outfits.
Dot does not exist. Every image is generated with Gemini's image model, from reference pictures and a prompt. That makes her cheap to produce and very easy to break.
This post is the checklist I run before anything with Dot in it goes out, and what today's batch of nine images taught me about where image models drift.

How an image is made

Each shot is one request with three reference photos and a prompt:

dot  = { text: "PHOTO A: 'Dot', our recurring stylist (character sheet). Keep her EXACT face, short cropped grey hair, gold hoop earrings, small round terracotta enamel brooch." }
room = { text: "PHOTO B: the atelier. Keep the EXACT room: Georgian London townhouse, tall sash windows, ..." }
refs = [dot, enc.("dot_sheet.png"), room, enc.("place_1.png")]
refs += [{ text: "PHOTO C: the client. Keep her EXACT face, hair, skin tone and body." }, enc.(client_photo)]

Photo A is a character sheet of Dot from several angles. Photo B is the room. Photo C is the client, and the client is one of the stock models the app already uses for its own try-on previews, so the series and the product show the same people.
The script runs inside the production container, because that is where the API key and the stock model photos already live, and it writes PNGs to /tmp. Nothing touches the database. A slideshow is five slides: a hook, three looks, and an end slide with Dot alone.

The three rules

All three came from episodes that went wrong before this checklist existed.
1. The client must not look like Dot. In one early episode the client was a light skinned woman in her fifties. The model blended her with Dot: same face shape, and her hair got shorter and greyer from one look to the next. Two women who looked like sisters, in a series where one is supposed to be the expert and the other the customer. My reaction when I saw it was one word in French: bizarre.
2. The client keeps the same face and hair across all looks. In another episode the second look had a different woman in it. Same outfit brief, different person. Image models do not have a notion of "the same client as in the previous request". Every request is a fresh roll, and only the reference photo holds her identity.
3. Dot never wears a coat. Her silhouette is the turtleneck. Once she has a camel coat on, she reads as a different character in a thumbnail, and thumbnails are all TikTok gives you.
These go in the prompt as hard constraints:

two = "TWO DIFFERENT WOMEN: the client is the woman from PHOTO C (keep her exact face, skin tone, body and EXACTLY the same hairstyle as in PHOTO C; she looks nothing like Dot); Dot is the short-grey-haired stylist from PHOTO A. "
dotlook = " Dot stands slightly behind on the left wearing ONLY a black fine-knit turtleneck and black slim trousers, NO coat, NO jacket, no outerwear at all, arms relaxed or adjusting a detail of the outfit, closed lips."

Putting rules in a prompt is necessary. It is not sufficient. The model follows them most of the time, and "most of the time" across nine images means something will fail.

Today's batch: nine images, six rejected

I generated two slideshows: "outfits for people with a full closet and nothing to wear" and "the white shirt you never wear, 3 ways". Eight shots with a client, plus the shared end slide. The first pass came back clean on the technical side: nine images, no API errors, no retries.
Then the contact sheet. I tile every image of a batch into one picture with ffmpeg so I can review them side by side, because drift is invisible one image at a time:

ffmpeg -i s1_0.png -i s1_1.png ... -filter_complex \
  "[0]scale=360:640[v0];[1]scale=360:640[v1];...;\
   [v0][v1]...xstack=inputs=9:layout=0_0|360_0|720_0|..." contact.jpg

Here is what failed.
Dot wore a coat in three images. Two were the opening "before" shots of each slideshow. Looking at the script, that was my bug, not the model's: the no coat sentence was appended to the three look shots and not to the opening shot, where Dot only appears as a side character. The model gave her a camel coat because nothing said otherwise. The third was the end slide, where my own prompt asked for "her long camel coat over her shoulders". I had written that before the rule existed and never reread it.
The client of the first slideshow was too close to Dot. The stock model I had picked has a grey bob. Next to Dot's grey crop, the two women had the same palette from head to shoulders. No blending this time, faces were distinct, but in a 360 pixel thumbnail it failed rule 1 anyway. I swapped her for a different stock model with dark skin and short natural hair. That meant regenerating all four shots of that slideshow, because rule 2 says the client cannot change halfway.
The end slide had a flat beige band across the top quarter. This one surprised me. Every prompt ends with a style block that includes "leave calm empty wall space in the top third of the picture", because the hook text goes there. On the shots with two people, the model reads that as composition advice and pulls the camera back. On the end slide, with Dot alone, it painted a literal empty rectangle above the room, like a letterbox. It did it twice in a row.
Dot smiled with her teeth. The prompt said "warm closed-lip smile". She smiled with her teeth anyway, on the end slide, both times.

Fixing the prompt, not the picture

I could have cropped the band out or picked the least bad image. I would rather fix the prompt, because the same prompt will run for the next eight slideshows.
The opening shots got the same constraint as the look shots:

dotsolo = " Dot wears ONLY a black fine-knit turtleneck and black slim trousers, NO coat, NO jacket, no outerwear at all, closed lips."

The end slide got its own variant of the style block. The "empty space" instruction is replaced by one that describes the room going up to the ceiling, and the smile is described physically instead of with an adjective:

if name == "end"
  prompt = prompt.sub("leave calm empty wall space in the top third of the picture",
                      "the room continues naturally up to the ceiling cornice") +
           " Her mouth is fully closed: a soft gentle smile with lips pressed together, absolutely no teeth visible."
end

"Closed-lip smile" failed twice. "Lips pressed together, no teeth visible" worked on the first try. Describing what the camera should see beats naming the expression.
I also added one line that is not about the picture at all: the script now prints the list of available stock models before generating, so picking a client is a deliberate choice from the real list and not a key I remember.

Regenerate only what failed

The script takes an ONLY variable, so a rerun touches just the rejected shots and leaves the approved ones alone:

only = ENV["ONLY"].to_s.split(",")
shots.each do |name, (client, desc)|
  next if only.any? && !only.include?(name)
  # ...
end

Before every rerun I copy the current images to a versioned folder. Image models do not always improve on a second try, and I want to be able to go back.
The final count for two slideshows: 9 images in the first pass, 6 regenerated, 1 regenerated again. Sixteen generations for nine images that ship. That ratio is the real cost of a recurring character, and it is still far cheaper than a photo shoot.

Text goes on after review

The hook text, the look labels and the end slide are added afterwards with Remotion stills, not by the image model. Image models are getting better at text, but a typo baked into an image means regenerating the image. In Remotion it is a string.
The same component renders both formats: 9:16 for TikTok, and 4:5 for Instagram, where the 9:16 image is fitted by height on a sand background so no head or shoe is ever cropped. Overlays sit in the wall space above the people, which is exactly what that "empty top third" instruction was for when it works.

The checklist

Before anything with Dot goes out:

Build the contact sheet. Never review generated images one at a time.
Client vs Dot: different face, different hair, different palette, judged at thumbnail size.
Same client, same hair, in every look of a slideshow.
Dot: turtleneck, no coat, no jacket, lips closed.
Look for composition artifacts: blank bands, extra people, duplicated limbs, text the model invented.
Reject, fix the prompt, rerun only the failures, review again. None of this is clever. It is the same thing as reviewing a pull request: the model writes, a person reads, and the rules that matter are written down so they survive the next batch. If you want the other side of how OutfitMaker uses Gemini, my AI was blind in production is what happens when nobody looks at the images at all.

Ten Abandoned Checkouts and the One Email I Send Now

MarcoBlch — Tue, 27 Oct 2026 17:05:14 +0000

Originally published on meridianbuild.dev, my build log for OutfitMaker, an AI outfit planner that works from the clothes you already own.
On October 20 I counted the Stripe Checkouts that OutfitMaker had opened over the previous 14 days. There were 11. One was paid. The other 10 people reached the Stripe page, looked at it, and left.
Ten is a small number. But each of those people had already decided they wanted something enough to click "pay". They are the warmest leads I have, and I had an email for them. It just didn't see most of them.
This post covers how I rebuilt that email in PR #245. It also covers a small card that shows the cheapest offer earlier, and why I can't tell you yet whether any of it works.

What the old email could see

The previous version of SendCheckoutRecoveryJob looked for abandoned checkouts in the subscriptions table:

Subscription.where(status: :incomplete, stripe_subscription_id: nil, current_period_end: nil)
            .where(created_at: 24.hours.ago..3.hours.ago)

That query finds people who clicked "start my trial" and never came back from Stripe. It made sense when a subscription was the only thing you could buy.
It isn't anymore. Since then I added a 7-day pass, a one-time payment, and credit packs for Look Previews and resale photos. None of those create a Subscription row. So someone who opened the pass checkout and walked away was invisible to the job. The email also linked to the pricing page, which meant the person had to find and choose their offer all over again.
If you have read the failed payments my database invented, the incomplete status will look familiar. Using a subscription status to mean "someone opened a checkout" was the same kind of shortcut. It works until the product changes shape.

A row for every Checkout

The fix starts with a boring table. Every Stripe Checkout session the app opens for a user now gets a row:

create_table :checkout_attempts do |t|
  t.references :user, null: false, foreign_key: { on_delete: :cascade }, index: false
  t.string :stripe_session_id, null: false
  t.string :plan, null: false        # week_pass, monthly, yearly, or a CreditPurchase::PACKS key
  t.string :source                   # Stripe metadata source (home_card, recovery_email...)
  t.string :currency
  t.datetime :completed_at           # checkout.session.completed webhook
  t.datetime :recovery_email_sent_at # claimed by the recovery job, once
  t.timestamps
end

I could have asked Stripe for the list of expired sessions on every run instead. I didn't want a cron job that depends on paging through an external API to decide who gets an email. A local row is easier to query and easier to test, and it doesn't care what kind of product was in the cart.
The recording happens in one place. All Checkouts already went through a small StripeCheckout module, so I split it in two:

def create_session(params)
  session = open_session(params)
  CheckoutAttempt.record!(session, params)
  session
end

One choke point means no entry point can forget to record. And record! never raises. It logs a warning and returns nil if the insert fails, because a recovery email is not worth losing the checkout itself.
The checkout.session.completed webhook stamps completed_at. That covers paid sessions and also payment methods that are still settling. Either way, the person finished on Stripe's side and should not get a "you didn't finish" email.

One email, and the window

The new job runs every 30 minutes and looks for unfinished Checkouts that were opened between 60 and 180 minutes ago:

RECOVERY_AGE = 60.minutes..180.minutes
RECOVERY_COOLDOWN = 7.days
def recoverable(now = Time.current)
  unfinished.where(recovery_email_sent_at: nil)
            .where(created_at: (now - RECOVERY_AGE.end)..(now - RECOVERY_AGE.begin))
end

The old window was 3 to 24 hours. I moved it much earlier. An hour is long enough that the person has clearly left and isn't just reading the Stripe page or switching cards. It's still short enough that they remember what they were doing. The cron runs at :20 and :50, which lands about an hour after the abandon and keeps it away from other jobs that fire on the hour and half hour.
There is exactly one email per abandoned session, and at most one per user per 7 days. No sequence. No "last chance" follow up. The subject is "You were one tap away", and the footer says plainly that this is the only reminder.
I went with one email on purpose. These are people who signed up days or minutes ago, and they already get onboarding emails. A recovery sequence on top of that is how a small app ends up in the spam folder. I would rather lose a sale than teach Gmail that my domain sends three emails about the same unfinished payment.

The link reopens the same offer

The email shows what the person was about to get and has one button. That button doesn't go to the pricing page. It reopens the same offer through a signed one-click link:

@cta_url = renew_subscriptions_url(**HOST, token: PassMailer.renewal_token(user), plan: @plan,
                                           source: "recovery_email", utm_source: "email",
                                           utm_medium: "checkout_recovery", utm_content: @plan)

The renew endpoint already existed for pass renewals. It verifies the token, so the person doesn't have to log in from their phone, and it opens a fresh Checkout for the plan they picked: the week pass, monthly, yearly, or the exact credit pack. If they were eligible for the free trial week, the email says so, and the button says "Start my free week" instead of "Get Premium".
The new Checkout carries source: "recovery_email" in its Stripe metadata. That's the only way I'll ever know if the email works.
There is no countdown, no discount, and no deadline in the email. The offer is simply still there. I don't want to train people to abandon a checkout to get a coupon.

Most of the code is reasons not to send

The query that finds candidates is three lines. The rules that stop the email take up most of the job:

def recover?(attempt, now)
  user = attempt.user
  return false unless user && self.class.recoverable_user?(user)
  return false if user.checkout_attempts.where("created_at > ?", attempt.created_at).exists?
  return false if CheckoutAttempt.recovery_sent_recently?(user, now)
  return false if paid_since?(user, attempt.created_at)
  !LifecycleEmailGuard.sent_today?(user)
end

In plain words, no email if:

They came back. A newer Checkout means they returned on their own, so only the latest one counts.
They paid some other way. That could be a pass or a pack bought in another session, or with the express payment sheet. paid_since? looks for purchases created after this Checkout opened. An older purchase doesn't count.
They are already Premium. This covers a live trial, an active subscription or a pass.
The inbox isn't confirmed, or they turned off lifecycle emails. The daily outfit email has its own switch, and turning that one off doesn't block this email. The recovery email is closer to marketing, so it follows the marketing switch.
It's an internal account. My own account, QA accounts and demo accounts are all excluded, from both emails and conversion stats.
They already got an email today. OutfitMaker allows one lifecycle email per user per day. If the daily outfit or an activation email already went out, the recovery waits. While a recovery email is pending, the softer emails stand down for it. Then there's the lock. Two runs of the job, or a retry, must never send twice. So the row itself is the lock:

def claim!(attempt, now)
  CheckoutAttempt.where(id: attempt.id, recovery_email_sent_at: nil)
                 .update_all(recovery_email_sent_at: now, updated_at: now) == 1
end

Only the run that flips recovery_email_sent_at from nil gets to send. It's the same conditional update pattern I'd use for anything that must happen once, and it doesn't need Redis. The old version kept its "already sent" flag in the Rails cache, which a flush could erase.
The tests read like that list: "timing: nothing before an hour, nothing after three", "only the latest checkout of a user counts", "an older purchase does not count as paying for this checkout", "skips internal and QA accounts".

Showing the pass earlier

The second half of the PR is about the other end of the funnel. The cheapest offer is the 7-day pass, and almost nobody was seeing it.
Over those same 14 days, there were about 1,700 signups. Only about 100 of them reached the paywall that appears after the first free Look Preview. That's the moment where the pass was offered. Everyone else never saw a price.
So free users with at least 3 real pieces in their closet (sample items don't count) now see a small card on the home page: 7 days of Premium, one payment, nothing renews. One tap opens the week pass Checkout. A "Hide for a week" button sets a cookie and the card goes away for 7 days. The d1 and d3 activation emails got a one-line mention of the pass too.
I track the card as its own experiment label, home_pass_card, with a single arm. It isn't an A/B test. I only wanted its views, taps and purchases to go through the same report as the main paywall without mixing into that paywall's numbers. A view is recorded once per user, however many times the home page renders. A tap is recorded on the server, inside the checkout request, and only for a user who was shown the card.

What I don't know yet

This shipped on October 20. As I write this, it's too early to measure anything. Ten abandoned Checkouts in two weeks means I'll need weeks of data before a recovered sale means anything. I don't have a before/after number, and I'm not going to invent one.
What I do have is the instrumentation to find out. Every Checkout now has a row with a source. A recovered sale will come back tagged recovery_email and a pass bought from the card will come back tagged home_card. If neither moves, that's an answer too.
The broader lesson is the same one from the week my payment screens promised things my code didn't do. The product changed shape, from one subscription to a pass and packs, and the code around payments kept assuming the old shape. The recovery email didn't break. It quietly kept doing exactly what it was written for, for a product that no longer existed.

My Invite-Only Gate Lived in the Browser

MarcoBlch — Fri, 23 Oct 2026 11:51:41 +0000

Originally published on meridianbuild.dev, my build log for FastPass, a paid inbox where people pay to reach you and get refunded if you don't reply.
FastPass is invite-only. That has been true in the database for months: a row in platform_settings called invite_only_mode, set to enabled: true. Sign up without a valid invite code and you get turned away. That was the plan, anyway.
Then I was going through recent signups and found a few accounts with no invite code attached. Nobody had flipped the setting. Nobody had leaked a code. They had simply walked through a door I thought was locked, because the lock was a React component.
This is the story of that door, and of what I changed so that the next one fails closed.

Why invite-only in the first place

FastPass is a pay-to-reach link. A sender pays to get a message in front of you, the money sits in escrow, and you either reply before your deadline or the sender gets refunded automatically. Stripe Connect handles the payouts.
That last part is why I keep the creator side gated. Every creator who finishes onboarding gets a public payment page and a Stripe Connect account tied to my platform. I want to know who is on the receiving end of that money. I wrote recently about why the cold start on that side is my real bottleneck, so I am not gating for scarcity theater. I am gating because a payments platform should know its payees.

The path in

Here is the route those accounts took. When I traced it, it was almost boring.

Someone searches Google and lands on one of my SEO landing pages, /get-paid-to-answer-messages.
They click "Start earning", which goes to /auth.
/auth opens on the Login tab, not the Sign up tab.
They click "Continue with Google".
Supabase creates the account.
The OAuth callback sends them to the dashboard. Nothing in that list is an exploit. It is the happy path of a page I built. The problem is step 3 meeting step 4. ## The bug, in four lines This is the Google button handler from AuthForm.tsx, before the fix:

const [isLogin, setIsLogin] = useState(!forceSignup);
const handleGoogleSignIn = async () => {
  if (!isLogin && inviteOnlyMode && !inviteCodeValid) {
    toast.error('Please enter a valid invite code above to continue with Google sign-up');
    return;
  }
  // ...
  await supabase.auth.signInWithOAuth({ provider: 'google', /* ... */ });
};

The invite check only runs when !isLogin. On the Login tab it is skipped, which sounds reasonable until you remember how OAuth works. With email and password, "log in" and "sign up" are different calls. With Google, they are the same call. If the Google account has never been seen before, Supabase creates a user. There is no "log in only" mode for a person who does not exist yet.
So my form had a login tab that could create accounts, and the only invite check lived on the other tab.
It got worse the further I looked:

AuthCallback.tsx, the page Google redirects back to, required nothing. It redeemed an invite code if one happened to be stored, showed a welcome toast, and moved on.
The check for whether invite-only mode was even on came from an edge function, and the client failed open if that call failed:

} catch (error) {
  console.error('Error checking invite mode:', error);
  setInviteOnlyMode(false);
}

And create-stripe-connect-account, the function that starts payout onboarding, ran with verify_jwt = false and accepted whatever userId the request body gave it. It did not check who was calling. Every layer assumed some other layer had already done the checking. None of them had. ## Why it became urgent Most of those accounts did nothing. Signed in, looked around, left. One got as far as starting Stripe Connect onboarding. That was the moment it stopped being a backlog item. An uninvited account with a payout account attached to my platform is a compliance problem, not a UX bug. I suspended that account first, then sat down to fix the actual hole. ## The fix: one gate, on the server The fix went out as PR #114. Four pieces. ### 1. A shared gate that fails closed I moved the decision into a shared module for my Supabase edge functions, _shared/invite-gate.ts. It is the single source of truth for "is this user allowed in":

export async function isInviteOnlyMode(supabase: SupabaseClient): Promise<boolean> {
  const { data, error } = await supabase
    .from('platform_settings')
    .select('setting_value')
    .eq('setting_key', 'invite_only_mode')
    .single()
  if (error || !data) {
    console.error('invite-gate: could not read invite_only_mode, failing closed:', error)
    return true
  }
  return data.setting_value?.enabled !== false
}

Compare that with the client version. Same question, opposite default. If the setting cannot be read, the server assumes invite-only is on.
checkInviteAccess builds on it. A user is allowed if they are an admin, if their profile has invited_by_code, or if the account predates the invite system. Everyone else gets no_invite_code. If there is no profile at all, that is a no too.

2. A server-side check after OAuth

A new edge function, enforce-invite-access, runs with verify_jwt = true and resolves the caller from the token, never from the request body. AuthCallback now calls it before anything else happens:

const { data: access, error: accessError } =
  await supabase.functions.invoke('enforce-invite-access');
if (!accessError && access?.allowed === false) {
  await supabase.auth.signOut();
  toast.error('FastPass is invite-only. Sign up with a valid invite code, or request an invite.');
  navigate('/auth', { replace: true });
  return;
}

The welcome toast moved below this check. Small thing, but it used to greet people before deciding whether they were allowed in.
There is one more detail in that function I like. If the rejected account was created in the last 15 minutes, it is almost certainly a Google signup that just happened without a code. The function deletes it, so the person can come back with a code using the same Google account instead of hitting a weird "you already exist but you are not allowed" state.

3. The hard lock where the money moves

This is the part that matters most. create-stripe-connect-account now checks two things before it talks to Stripe:

const caller = await getCaller(supabase, req)
if (caller?.id !== userId) {
  return new Response(JSON.stringify({ error: 'Unauthorized' }), { status: 401, /* ... */ })
}
const access = await checkInviteAccess(supabase, userId)
if (!access.allowed) {
  return new Response(
    JSON.stringify({ error: 'FastPass is invite-only. Please redeem an invite code before setting up payouts.' }),
    { status: 403, /* ... */ }
  )
}

The caller's JWT must match the userId in the body, otherwise 401. The caller must pass the invite gate, otherwise 403. No Stripe account means no public payment page, so this one check protects the thing I actually care about.

4. A deliberate fail-open, one layer up

You might notice that AuthCallback lets the user through if enforce-invite-access errors out. That is on purpose, and the comment in the function says so:

// No verdict on errors: the hard gate is create-stripe-connect-account,
// so an outage here must not lock legitimate users out of their dashboard.

The difference from before is that this fail-open is a choice with a backstop. If the soft check breaks, an uninvited person might see an empty dashboard. They still cannot start payouts, because the Stripe function fails closed on its own. Before the fix, every layer failed open and none of them was the backstop.

Deploy order matters

The frontend ships through Vercel when I merge. The edge functions ship separately, with supabase functions deploy. Merge first and the new AuthCallback calls an enforce-invite-access function that does not exist yet. That call errors, the callback lets the user through, and I have gained nothing.
So the order written in the PR was:

npx supabase functions deploy enforce-invite-access create-stripe-connect-account
Merge the PR. Functions first, then the client that depends on them. Obvious when written down, easy to get backwards when you are in a hurry to close a hole. ## What I have verified, and what I have not After deploying, I called both functions without authorization. Both returned 401. The build passed, and the touched files did not add new type or lint errors. What I have not done yet is the real end-to-end test: a fresh Google account, no invite code, through the landing page, the Login tab and the Google button, to confirm it gets signed out and deleted. That is on my to-do list, and until I have run it I will not call this fully verified. The Stripe-side lock does not depend on that flow working, which is exactly why I put it there. ## The lesson A client-side gate is a UX hint. It tells honest users what to expect. It is not a lock, because the browser is not yours, and because the flows you build (OAuth, deep links, a landing page CTA pointing at the wrong tab) will find paths around it that nobody attacked on purpose. Put the lock on the server, at the point where something irreversible happens. For FastPass that is the creation of a Stripe Connect account, not the signup form. Make it check identity from the token, not the request body. And make it fail closed, so that when something upstream breaks, the default answer is no. The same mindset got me out of my Stripe webhook mess: the money path deserves its own checks, independent of everything in front of it. I just had to learn it twice.

My Payment Screens Promised Things My Code Didn't Do

MarcoBlch — Fri, 23 Oct 2026 11:44:29 +0000

Originally published on meridianbuild.dev, my build log for OutfitMaker, an AI outfit planner that works from the clothes you already own.

On September 24 I retired the Pro plan at OutfitMaker. One paid plan, Premium, plus a free tier. I changed the checkout, I changed Stripe, and I moved on.

In October I sat down and read every public page and every payment screen as if I were a new visitor. Not the code. The words. What I found was a second version of my product, living in YAML files and ERB templates, that had kept its own rules while the real ones moved.

This post is about that gap, the PRs it took to close it, and why I now treat copy as code that needs tests.

What the pages were saying
A partial list, all from lines I deleted.

The FAQ still sold Pro. In all five languages (English, French, Spanish, German, Portuguese), the plan section listed a Pro tier with "Unlimited AI suggestions", "30 virtual try-ons per month" and "24/7 dedicated support". You could not buy any of it.

Premium was described with the wrong limits. The FAQ capped Premium at "150 wardrobe items" and "5 virtual try-ons per month". In the code, wardrobe storage is unlimited on every plan and Premium includes 30 Look Previews a month.

The free plan had two different quotas depending on the page. The FAQ's structured data said "3 AI outfit suggestions per day". The comparison table on the pricing page said 1/day. A help paragraph about weather said "1 for Free, 10 for Premium, Unlimited for Pro". The code gives free accounts 3.

The Portuguese copy had its own prices. pt.yml hardcoded R$ 39,90 for Premium and R$ 74,90 for Pro. Made-up numbers, not what Stripe charges. Everywhere else, prices come from a variable.

The pricing page showed $0 to everyone. The free tier's price was a literal string. A visitor in London or Paris saw dollars right next to a Premium price in their own currency. The upgrade modal had a hardcoded $14.99/mo for Pro, and a few other strings had a hardcoded $7.99/mo for Premium.

The home page still had a Pro pricing card with a "Get started" button linking to plan=pro.

A 30-day money-back guarantee sat in the pricing page footer: "All plans include 30-day money-back guarantee". I removed it. That was a founder decision, not a bug fix, but it belongs here because nothing in the code implemented it.

An SEO page about "wardrobe management software" still listed Pro pricing and an "Early adopter offer, active until June 30, 2026". This was October.

None of these were typos. Each one was true at some point. The code changed and the words didn't.

The bugs that weren't just words
Some of the drift went deeper than copy.

A batch upload that said "your wardrobe is full"
Batch upload accepts 10 photos at a time. If you dropped 12, the extra 2 were skipped, and the controller reported it like this:

msg += " #{skipped} skipped (wardrobe limit reached)." if skipped > 0

if skipped > 0 && current_user.free_tier?
redirect_to wardrobe_items_path,
flash: { notice: msg, show_upgrade: "wardrobe_limit", analytics_event: "batch_upload_chosen" }
show_upgrade: "wardrobe_limit" opened a modal that said "Your wardrobe is full! Free accounts can store up to 25 items. Upgrade to Premium for 150 items." Every part of that was false. Storage is unlimited, and the photos were only skipped because of the per-upload cap. This was a regression from an earlier PR that changed the batch logic.

So a free user doing exactly what I want new users to do (adding a lot of clothes on day one) got told their closet was full and asked to pay. The fix is a message that says what actually happened:

over_batch: "%{count} more photos were not uploaded: %{max} photos per upload. Add them in a second upload."
No upgrade modal. The test asserts flash[:show_upgrade] is nil and that "limit reached" never appears.

An upgrade modal that never opened
While I was rewriting the modal copy, I found that the modal itself never showed up. The template set data-modal-open-on-load-value="true", but the Stimulus controller reads a value called auto-open. There was also no panel target for the fade-in. So every show_upgrade flash in the app rendered a modal that stayed invisible.

So the false "wardrobe full" modal was probably less visible than I feared. Two bugs partly cancelling each other out is not a strategy.

The fixed modal uses the right value and a panel target, and its button skips a page. It used to link to the pricing page with plan: 'premium_trial'. Now it posts straight to checkout:

<%= button_to subscriptions_path,
params: { tier: "premium", billing: "monthly" },
method: :post,
form: { data: { turbo: false } } do %>
<%= trial_eligible ? cta : t("modals.upgrade.cta_no_trial") %>
<% end %>
"No credit card required"
One modal context still said "No credit card required" under the trial button. The current trial takes a card up front. The new copy says it plainly: "7 days free, card required. Cancel before day 7 and you pay nothing. We email you the day before it ends."

The worse case was promising a trial to people who wouldn't get one. Checkout already had a rule: you get the 7-day trial only if you never really subscribed (no subscription, or only abandoned incomplete checkouts). But that rule was written inline in the controller, twice, and copied again into the service that picks who gets trial emails. The pricing page just said "7-day free trial" to everyone.

So I moved the rule to the model and made the copy ask the same question:

The 7-day Premium trial goes to anyone who never really subscribed: no

subscription, or only abandoned checkouts (incomplete records). Ex-paying

subscribers don't get a second trial. Shared by checkout and the copy that

promises the trial, so the promise never outruns the behaviour.

def premium_trial_eligible?
sub = subscription
sub.nil? || %w[incomplete incomplete_expired].include?(sub.status.to_s)
end
The pricing page, the modal, the checkout and the email audience now all call premium_trial_eligible?. A former subscriber sees "Get Premium" and "cancel anytime", not a trial they can't have.

A button in pounds, a charge in euros
1-click credit packs showed a localized price on the button. The PaymentIntent behind it was created like this:

amount: info[:amount_cents],
currency: "eur",
A UK buyer saw £4.29 on the button, got a payment sheet asking for €4.99, and left. Hosted Checkout was fine because it uses the price's currency_options. The 1-click path didn't. Now it charges in Current.currency through the same PriceBook that renders the button, and a test asserts that a visitor with en-GB gets a gbp intent for 429.

"1 suggestions left today"
The suggestion page badge could read "1 suggestions". It's now a real i18n plural in every locale, and the client-side countdown gets the localized one/other forms instead of writing a bare number.

While I was in there: the money states
The same audit found places where a payment's outcome and the app's state could disagree. Those went into their own PR:

A dispute now takes back what the payment bought: unspent credits from a pack, or the subscription is cancelled. Before, a disputed payment kept its credits or kept a Premium that renewed on the disputed card.
A full refund of a subscription payment cancels the subscription. A partial refund changes nothing.
Checkout refuses to open over a live Stripe subscription. Two tabs (or the back button) could complete two checkouts, and the first subscription kept billing while the app only tracked the second.
If a duplicate still slips through, the newcomer is cancelled, the original kept, and Sentry gets a warning to refund it by hand.
An incomplete subscription (SEPA pending, 3DS abandoned) no longer unlocks Premium. It waits for subscription.updated.
The landing page's JSON-LD still listed a Pro offer at 14.99 EUR. Removed.
If you have read the failed payments my database invented, the incomplete status will look familiar. It keeps coming back.

Why the copy drifted
Pricing copy is a second implementation of your business rules, written in a language with no compiler. When I changed ai_suggestions_daily_limit or retired a tier, nothing failed. The YAML kept saying what it said.

Five languages made it five implementations. The BRL prices are the clearest example: someone (me) once localized a string by hand, and from then on it lived outside the system.

What I do now
Every one of these PRs added tests aimed at the words, not the logic.

The comparison table test reads the limits from the model:

premium = build(:user, :premium)
assert_includes I18n.t("subscriptions_page.comparison.row_suggestions_premium"),
premium.ai_suggestions_daily_limit.to_s
assert_includes I18n.t("subscriptions_page.comparison.row_vto_premium"),
premium.try_on_monthly_limit.to_s
If I change the limit and forget the table, CI fails.

Other tests are blunt regex bans over the payment-related locale scopes in all five languages: no \bPro\b, no "5 virtual try-ons" or "5 Look Previews" and their translations, no "unlimited suggestions" in English, no money-back guarantee in any language, no R$ 39,90 back in pt.yml, no plan=pro on the home page, no $0 for a euro or pound visitor. Labels describing an existing grandfathered Pro account are exempt by key.

They are not elegant. They are cheap, they catch exactly the kind of thing I shipped, and they stop the same strings from coming back.

One process note. The first PR in this series was supposed to rewrite the wardrobe software page, but it only shipped the deletion of the old view, so the page returned a 204 until the follow-up merged six minutes later. The rewrite uses the same SeoLanding template as my other intent pages, with copy that matches the free plan: unlimited pieces, 3 suggestions a day. Fixing promises is also a good way to break a page.

The takeaway
When you change a rule in code, grep the copy for it. All the languages. The landing page, the FAQ, the modals, the emails, the structured data.

Better, make the copy depend on the code. A view that calls premium_trial_eligible? can't promise a trial the checkout won't give. A price that goes through PriceBook can't be in the wrong currency. Anything you can't wire up that way deserves a test that reads the real value and compares.

My users don't read my controllers. They read the button. For a while the button and the controller disagreed, and the button was the one people believed.

My Bottleneck Was the Offer, Not SEO: A Two-Sided Marketplace Cold Start

MarcoBlch — Fri, 16 Oct 2026 13:15:55 +0000

Originally published on meridianbuild.dev, my build log for FastPass, a paid inbox where people pay to reach you and get refunded if you don't reply.

For most of this year I treated FastPass like an SEO problem. Landing pages, structured data, prerendering, a sitemap fix that took it from 11 URLs to 56. All of it shipped, all of it is live. Then I ran a few queries against my own database and realized I had been solving the wrong problem. FastPass is a two-sided marketplace, and it was stuck in the oldest trap there is: the cold start. The supply side was too thin for that traffic to land on anything.

This is the honest version of that diagnosis, and what I am doing instead.

What FastPass is, in one paragraph
FastPass is a pay-to-reach link. Someone who wants your attention pays to send you a message, the money is held in escrow, and you either reply before your deadline (and keep 75 percent) or the sender is automatically refunded. Stripe Connect moves the money, and I have already written about the webhook bug that nearly froze all of it. Two sides: creators who receive messages, senders who pay to reach them. Neither side is worth anything without the other.

The query that changed my mind
I had two tables I thought of as "the supply side". profiles holds the people who can actually receive paid messages. directory_requests powers a public directory where visitors can signal demand for someone who is not on FastPass yet ("I would pay $X to reach this person"). The idea was a flywheel: enough demand on a directory page, we invite that person, they claim their profile.

Here is what I found when I looked. Every entry in the directory was a celebrity or a big-name influencer, people I had seeded as a wishlist. None of them had a FastPass profile behind it. And on the profile side, the accounts that existed were mostly early signups and tests, not creators with a public page and an audience.

So the directory was a page of famous people who did not know FastPass existed, and the creator side was not ready to catch anyone. Every SEO win I shipped was sending visitors to a storefront with very little on the shelves.

The build told me first, and I did not listen
The funny part is that my CI had already said this out loud. I opened a pull request to make each creator's payment page the canonical URL and prerender it for every directory slug. It looked like a clean SEO improvement: one strong page per person instead of two weak ones.

The build broke. My prerender pipeline ends with a smoke test, scripts/verify-prerender.ts, which checks that each snapshotted page contains real content and not a loading skeleton. For every directory slug, the payment page asked the backend for a profile, got "Profile not found", rendered an error, and the smoke test exited with code 1. I checked the database: none of the directory slugs had a profile behind them.

I closed the PR. The test was right. I was trying to make Google index payment pages for people who could not be paid.

Why SEO cannot fix a marketplace cold start
The chicken and egg problem in a marketplace is usually framed as "which side do you build first". For FastPass the answer is unambiguous: the creator side. A sender with nobody to pay is a bounce. A creator with nobody paying still gets something (more on that below).

My old plan had two loops, and both depended on things I did not have:

Top-down celebrity outreach. Ask famous people to join a product they have never heard of. Their incentive is close to nonexistent, and their inbox is the exact problem FastPass solves, so my email lands in the pile.
Demand-driven invites. Let visitors vote on directory pages until the demand is big enough to impress the target. That needs real traffic first. I did not have real traffic, and the traffic I did have was landing on pages for people who were not there.
SEO compounds an offer that exists. It does not create one. I had it backwards.

The one data point I trust from that period (from my old Plausible setup, before I moved to Cloudflare Web Analytics) is that the US was my largest country at 38 percent of visits, and that the /pay funnel lost 86 percent of the people who entered it. That leak is real, but fixing it now would mean optimizing a funnel before the right people are at the top of it. It goes on the list for later.

The new plan: the creator is the distribution channel
The reframe that unlocked things: a creator is not just supply. A creator who puts a FastPass link in their bio brings their own audience. One real creator solves both sides at once, which is the only cheap way out of a two-sided cold start I know of.

So the target changed from "famous" to "reachable, and already in pain":

English-speaking, because the US is where my visitors already are.
Small to mid audience, roughly 1k to 50k followers, so a cold message from me actually gets read.
Already drowning in "can I pick your brain?" requests. The pitch is a filter for unpaid advice first and income second. That value exists before the first paid message ever arrives.
The first category I picked is career and job-search coaches. They get the most free-advice requests, most already sell their time, and they live on LinkedIn. I went through about 84 coach profiles and kept 25 verified targets. I have a dedicated page for this angle, a paid inbox for coaches, and another for the broader pain of giving free advice online.

Concierge onboarding, and the step I cannot do for anyone
The plan is concierge onboarding. FastPass profiles already start in a draft state, so I can prepare a coach's whole page myself: name, photo, bio, price. When they say yes, they get a link that is ready to go.

Except for one step. Stripe Connect requires the creator to verify their own identity and enter their own bank details. That is KYC, and it cannot be done on someone else's behalf, nor should it be. Until it is done, their public page does not exist. So my first outreach draft, which promised "no effort at all", was wrong. I rewrote it to say upfront: I set up everything, you spend a few minutes connecting your payout account with Stripe, then you put the link in your bio. Announcing that friction early is better than a creator discovering it halfway through and feeling tricked.

What winning looks like (and where I am)
I set a deliberately small first target: three creators sharing their link, and one real paid message from a stranger. That would be a repeatable playbook and a first case study, which is worth more to me right now than any ranking.

It is too early for results. The target list is ready and outreach is starting. I am writing this before the outcome on purpose, so I cannot quietly rewrite the hypothesis afterwards.

The takeaway
If you are building a two-sided marketplace and your growth work feels like it is not compounding, check the supply side in your own database before you ship another landing page. Count the real, active sellers. Check whether the pages you promote point at anyone who can actually transact. My CI caught the gap before I did. Your own tables will probably tell you too, if you ask them the blunt question.

I will report back with the numbers, whatever they turn out to be. In the meantime, the rest of my SEO notes are in what actually worked for SEO as an indie hacker.

The Failed Payments My Database Invented

MarcoBlch — Thu, 01 Oct 2026 16:50:54 +0000

📖 Originally published on meridianbuild.dev my engineering blog documenting the real bugs and decisions behind OutfitMaker.

I opened the subscriptions table on OutfitMaker one evening and felt my stomach drop. A pile of rows sitting at status: incomplete, no billing period, no active subscription. To a founder's eye that reads as one thing: failed payments. People tried to pay me and something broke. My webhook must be dropping events. I'm losing money and I don't even know how much.

I spent the first ten minutes composing the incident in my head which Stripe webhook, which signature check, how far back does it go. Then I did the one thing that turned a panic into a five-line cleanup: I checked the source of truth before I touched anything.

The rows were real. The failures were not.

Here's what those incomplete rows actually were. When a user clicks "subscribe," SubscriptionsController#find_or_create_stripe_customer inserts a local Subscription row immediately before any payment just to hold the Stripe customer id it's about to need. The row starts life as incomplete. If the user completes checkout, the checkout.session.completed webhook flips it to active. If they don't, the row just... stays. Forever. incomplete, no stripe_subscription_id, no billing period.

So every person who clicked "subscribe," saw the Stripe checkout page, and then closed the tab left a permanent artifact in my database that is indistinguishable, at a glance, from a payment that failed. My schema was conflating two completely different events "started a checkout" and "tried to pay and failed" — into one status.

Before writing a single line of fix, I queried the Stripe API read-only for each of those customer ids. Every one of them: zero subscriptions, zero paid invoices. Nobody was charged. Nobody's payment failed. There was no webhook bug. Nothing was lost. The scary number was pre-payment abandonment wearing the costume of failed revenue.

The lesson I'd tattoo on the inside of my eyelids: when your own dashboard tells you money is broken, check the payment processor before you check your code. Stripe is the source of truth for whether money moved. My database is, at best, a hopeful cache of that truth and in this case it was actively lying to me.

The cleanup, and why it's paranoid on purpose

Once I knew the rows were noise, I wanted them gone but a delete_all on a subscriptions table is exactly the kind of thing that looks safe at 11pm and isn't. So the scope is deliberately narrow. A row only counts as an abandoned checkout if it is all four of these:

ABANDONED_CHECKOUT_GRACE = 1.day

scope :abandoned_checkouts, -> {
  where(status: :incomplete)
    .where(stripe_subscription_id: nil)
    .where(current_period_end: nil)
    .where("subscriptions.created_at < ?", ABANDONED_CHECKOUT_GRACE.ago)
}

Every clause is a guardrail:

status: :incomplete never touch an active or trialing subscriber.
stripe_subscription_id: nil if Stripe knows about a subscription, this row is real; leave it.
current_period_end: nil no billing period was ever set, so nothing was ever charged.
created_at older than one day this is the important one. Stripe Checkout sessions expire after 24 hours. A row created twenty minutes ago might be a checkout still in flight the user is on the payment page right now. The grace window guarantees I only ever delete checkouts that Stripe itself has already given up on.

And it ships behind a dry run, because I don't trust myself with delete_all and neither should you:

task purge_abandoned_checkouts: :environment do
  rows = Subscription.abandoned_checkouts.to_a
  rows.each { |s| puts "  - ##{s.id} user_id=#{s.user_id} created=#{s.created_at.utc}" }

  if ENV["DRY_RUN"].present?
    puts "DRY_RUN set nothing deleted."
  else
    puts "Deleted #{Subscription.purge_abandoned_checkouts!} row(s)."
  end
end

I ran it with DRY_RUN=1 first, read the list of rows it would delete, confirmed each one against Stripe, and only then ran it for real. It was a handful of rows seven, in my case. Not a revenue leak. A rounding error with good production values.

The real leak was somewhere else entirely

This is the part that actually mattered, and it's why I'm writing about a seven-row cleanup at all.

The incomplete rows had grabbed my attention precisely because they looked like a problem. But they were a vanity metric in reverse a number that looked like failure but measured nothing about money. Chasing them would have been hours spent hardening a webhook that was working fine.

The actual leak in the business isn't at the top of the funnel where people click "subscribe" and wander off. Some tab-closing is normal and always will be. The leak is downstream: the checkout-completion rate for people who genuinely intend to pay, and week-one retention for the ones who do. That's where real money is decided, and my schema had been drawing my eye to the wrong end of the pipe.

So the cleanup did two useful things, and only one of them was deleting rows. It removed the noise, and — more importantly it forced me to define, in code, the difference between "started a checkout" and "became a customer." Once those are distinct, the funnel can finally tell the truth: how many people start checkout, how many finish, and how many are still around a week later. Those are the numbers worth an incident. incomplete never was.

If you're staring at a scary count in your own database right now, ask two questions before you write any code. Does my payment processor agree that something is actually broken? And is this number measuring money, or just measuring a click I happened to write a row for? Half the "bugs" a solo founder finds at 11pm are the schema describing normal human behavior in alarming language.

I've been burned by the mirror-image of this too a dashboard that read a flat zero when everything was fine and I wrote about the messy road to the first customer who actually paid. The through-line: trust the money, instrument the money, and be very suspicious of any other number that makes you feel something.

The Soft 404 That Hid My Multi-Tenant SaaS From Google

MarcoBlch — Thu, 01 Oct 2026 16:40:19 +0000

Originally published on meridianbuild.dev, my engineering blog where I write up the real bugs and decisions behind the products I build.

Google Search Console has a category that sounds harmless and is not: "Soft 404." It means Google fetched a page, got an HTTP 200, and then decided the content looks like an error anyway. So it quietly refuses to index it. I opened GSC one morning for Eglise en Ligne, my church-website SaaS, and found the report filling up with them across all three of my domains.

The setup: one codebase, many faces

Eglise en Ligne is multi-tenant and multi-domain. Each church gets its own public site on a subdomain (demo.egliseenligne.fr), and the marketing site runs on three country domains: egliseenligne.fr for France, iglesiaenlinea.es for Spain, and igrejaemlinha.pt for Portugal. It is a Next.js App Router project, and a middleware decides, per request, whether a hostname is a tenant church or a marketing domain, injecting x-church-* headers when it is a tenant.

The tenant public pages live under a [locale] route group. On a real church subdomain the middleware sets a church context, and the page renders that church. So far so good.

The bug: a 200 that means "nothing here"

The problem showed up when Google crawled tenant-shaped URLs on the marketing domain, like egliseenligne.fr/fr or egliseenligne.fr/blog. Those paths match the [locale] route, but there is no church context on a marketing domain. Here is what the page did in that case:

const church = await getChurchContext();
if (!church) return <div>Church not found</div>;

Read that closely. When there is no church, it returns a div. A div is a successful render, so the response is HTTP 200. To a visitor it says "Church not found." To Googlebot it says "200 OK, here is your content," and the content is a bare error message. That is the textbook recipe for a Soft 404, and it was happening on every locale path, on all three ccTLDs at once.

Worse, these pages carried robots: index, follow, so I was actively inviting Google to crawl pages that were pure noise. Crawl budget I did not have to spare was going to /fr, /es, /blog, /fr/events, and friends.

The fix: return a real 404

The honest signal for "this page does not exist" is a 404 status, not a 200 with sad text. Next.js gives you exactly that with notFound() from next/navigation. The trick was choosing where to put it. Instead of patching every tenant page, I put one guard in the [locale] layout, which wraps all of them:

import { notFound } from 'next/navigation';

const church = await getChurchContext();
// No church context means a tenant route was hit on the marketing domain.
// Return a real 404 instead of a 200 "not found" page.
if (!church) notFound();

One line, one file, every tenant sub-page covered at once. Real church subdomains are untouched, because the middleware still injects their church context, so getChurchContext() returns a church and the guard never fires. After deploy I checked all three domains, and /fr now returns a clean 404 on each, while the marketing pages keep their 200. This is the same "fix it at the layer that owns the concern" instinct I wrote about in why every funnel event read zero: the bug repeated across many files, so the fix belonged above all of them, not inside each one.

The takeaway

A 200 is a promise. It tells crawlers "this is a real page worth keeping." If your code can render an empty or error state, make sure that state carries the status code that matches the truth. On a multi-tenant app the trap is sneaky, because the exact same route is a real page on one hostname and nothing on another. Guard it once, at the boundary, and let the framework send the right signal.

Two days after shipping this, the Soft 404 count in Search Console started draining on its own. The pages were finally telling Google the truth.

My Stripe Webhooks Were Failing 96% of the Time

MarcoBlch — Tue, 22 Sep 2026 19:05:54 +0000

Originally published on meridianbuild.dev, my engineering blog where I write up the real bugs and decisions behind the products I build.

FastPass only works if money moves correctly. A sender pays, the money sits in escrow, and a Stripe webhook is the thing that tells my backend the payment actually happened. So when I finally opened the webhook logs one evening, my stomach dropped. Around 96 percent of them were failing. Money was landing in Stripe and my app had no idea.

The setup

FastPass is a pay to reach platform. Someone pays to guarantee a reply from a busy person, the money is held in escrow, and it gets released or refunded based on what happens next. Stripe and Stripe Connect handle the money and the 75/25 split between the recipient and the platform. Every state change, a payment captured, a transfer made, a refund issued, arrives as a Stripe webhook. If the webhooks do not land, the whole machine freezes.

The webhook lives in a Supabase Edge Function, which runs on Deno, not Node. Hold that thought.

The bug

Every webhook starts by verifying Stripe's signature, so I know the call is really from Stripe and not a forged request. The textbook line looks like this:

const event = stripe.webhooks.constructEvent(body, signature, webhookSecret)

That line was fine on my laptop. In production it threw on every real event. Verification failed, so I rejected the event, so the payment update never ran. The dashboard showed green deploys, Stripe showed successful charges, and my database quietly fell behind reality.

The trap

constructEvent verifies the signature with an HMAC. In Node, that HMAC is computed synchronously. But Deno, and every edge runtime (Vercel Edge, Cloudflare Workers, Supabase Functions), only gives you the Web Crypto API, and Web Crypto is asynchronous. The synchronous helper has no synchronous crypto to call, so it simply cannot do the work. It does not warn you. It throws, and you are left blaming your webhook secret.

So "96 percent of my webhooks are invalid" was never a Stripe problem and never a security problem. It was me calling a synchronous function in a place where crypto only exists in async form.

The fix is one word

const event = await stripe.webhooks.constructEventAsync(
  body,
  signature,
  webhookSecret
)

constructEventAsync reaches for the Web Crypto API, awaits it, and returns the verified event. Same inputs, same security, one await. The moment it shipped, signature verification went green and the backlog of stuck payments started clearing.

Two things I added while I was in there:

Idempotency. Stripe retries webhooks, and now that they were actually being accepted, I did not want the same event processed twice. A double payout is a very direct way to lose money. Before doing anything, I check a webhook_events table for the event id and skip if I have seen it:

const { data: seen } = await supabase
  .from('webhook_events').select('id').eq('event_id', event.id).single()
if (seen) return ok({ skipped: true, reason: 'already_processed' })

Return 200 even on a rejected signature. Stripe retries anything that is not a 2xx, aggressively. During the incident that meant retry storms piling onto a broken endpoint. Now a bad signature is logged and answered with 200, so Stripe stops hammering while I investigate. It is one of the rare cases where a 200 on a failure is correct, because the alternative is a self inflicted denial of service.

The takeaway

If you move a webhook, or any signature check, into an edge or Deno runtime and it starts failing for no obvious reason, suspect the crypto before you suspect your secret. Edge runtimes expose Web Crypto, which is async only. SDKs that grew up on Node ship synchronous helpers that quietly do not work there. The fix is almost always the same shape: find the ...Async variant and await it. Stripe has constructEventAsync, and most libraries have an equivalent once you go looking.

The scariest bugs are the ones where nothing crashes. My app was up, Stripe was happy, money was moving, and the only symptom was a number in a log I had not thought to read. I hit the mirror image of this on the same project, a sitemap that quietly advertised the wrong pages, where everything returned 200 and was still wrong.

If you want to see what it powers: FastPass lets you get paid to answer messages instead of drowning in a free inbox.

Why Every Funnel Event in My Analytics Read Zero

MarcoBlch — Tue, 22 Sep 2026 12:35:00 +0000

📖 Originally published on meridianbuild.dev my engineering blog documenting the real bugs and decisions behind OutfitMaker.

The worst kind of broken instrumentation is the kind that reports a number. A blank dashboard makes you check the wiring. A dashboard full of zeros makes you think your product is just quiet.

For as long as I'd had funnel tracking in OutfitMaker, every custom event I cared about read zero. Signup: 0. Activation: 0. First Item Uploaded: 0. The onboarding-choice events: 0. Meanwhile pageviews ticked up normally and real people were clearly signing up, uploading clothes, and getting outfit suggestions. I'd half-convinced myself the funnel was just thin. It wasn't thin. It was lying.

Here's the teardown. It took two PRs and turned out to be four separate bugs stacked on top of each other.

How the events were supposed to fire

OutfitMaker runs Kaunta, a self-hosted, privacy-friendly analytics script, loaded once per page. Automatic pageviews work out of the box. For funnel milestones I used a server-driven pattern: a controller sets flash[:analytics_event] = "Signup", and the layout turns that flash into a kaunta.track() call on the next page.

The layout snippet looked like this and it had been copy-pasted into three layouts:

<script src="<%= kaunta_script_url %>"
  data-website-id="<%= kaunta_website_id %>"
  async defer></script>

<% if flash[:analytics_event].present? %>
<script>
  document.addEventListener('DOMContentLoaded', function() {
    if (window.kaunta) {
      window.kaunta.track('<%= flash[:analytics_event] %>', { locale: '<%= I18n.locale %>' });
    }
  });
</script>
<% end %>

It reads fine. It is also wrong in three independent ways, each one enough on its own to zero out the event.

Bug 1: Turbo never re-fires DOMContentLoaded

Every one of these milestones arrives on a page reached by a redirect_to after a form POST. You submit the signup form, the server creates the user, sets the flash, and redirects you to the next page. In a Hotwire app that redirect is a Turbo visit, not a full document load.

DOMContentLoaded fires exactly once, on a cold load. Turbo swaps the <body> and does not re-evaluate <head> scripts on navigation. So on the page that actually carried the flash, the listener was being registered after the event it was waiting for had already passed — and then never ran again. The track() call was real, reachable code that simply never executed.

This is the same family of silent Turbo failure I wrote about with duplicate frame ids: nothing throws, the HTTP response is a clean 200, and the gap is a layer of intent the framework doesn't share with you.

Bug 2: the async race

Suppose the page did cold-load a direct visit, say. The Kaunta loader is async defer, so window.kaunta is usually still undefined when DOMContentLoaded runs. The guard:

if (window.kaunta) { /* track */ }

is a coin flip you lose most of the time. When the script wasn't ready, the event was dropped on the floor with no retry. No error, no queue, nothing. So even the rare cold-load path was unreliable.

Bug 3: the layout the funnel actually lands on

The snippet lived in the application, landing, and blog layouts. But a successful signup redirects to onboarding_path, which renders under the onboarding layout and that layout had no Kaunta at all. Not the loader, not the trigger.

So for the single most important event in the whole funnel, Signup, all three bugs were academic. The page it landed on couldn't have tracked anything even if the script and the timing had been perfect. Signup wasn't unreliable. It was structurally impossible.

The fix: fire from Stimulus, share one partial

The repair (9dec828, PR #85) moves the trigger out of the <head> and into a Stimulus controller that runs from the <body>. Stimulus connect() runs on every Turbo navigation, which kills Bug 1. And instead of a one-shot guard, it polls for window.kaunta, which kills Bug 2:

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static values = {
    name: String,
    props: { type: Object, default: {} },
  }

  connect() {
    if (!this.nameValue) return
    // Skip Turbo's cached *preview* render so a snapshot that still
    // contains this element doesn't double-fire on the preview pass.
    if (document.documentElement.hasAttribute("data-turbo-preview")) return
    if (this.fired) return
    this.waitForKaunta(25) // ~5s max (25 × 200ms)
  }

  waitForKaunta(attemptsLeft) {
    if (this.fired) return
    if (window.kaunta && typeof window.kaunta.track === "function") {
      this.fired = true
      window.kaunta.track(this.nameValue, this.propsValue)
    } else if (attemptsLeft > 0) {
      this.pollTimer = setTimeout(() => this.waitForKaunta(attemptsLeft - 1), 200)
    }
  }
}

The data-turbo-preview check is the kind of detail you only learn by getting it wrong: Turbo renders a cached preview of a page before the fresh version arrives, and if your tracking element is in that snapshot it'll fire on the preview too. Bail on the preview pass; fire on the real render.

The flash is surfaced by a tiny partial that just mounts the controller:

<% if flash[:analytics_event].present? %>
  <div hidden
       data-controller="kaunta-event"
       data-kaunta-event-name-value="<%= flash[:analytics_event] %>"
       data-kaunta-event-props-value="<%= { locale: I18n.locale }.to_json %>"></div>
<% end %>

Bug 3 gets fixed by construction: the loader and the trigger become two shared partials (shared/_kaunta_head and shared/_kaunta_event), rendered in all four user-facing layouts application, landing, blog, and the previously-naked onboarding. That deletes the three-way copy-paste and closes the gap in the same move. Three layouts each lost ~30 lines.

I can't run the suite on the box I write these from (no Ruby, no Node it validates on deploy), so I locked the server side of the contract with an integration test instead of trusting the browser behaviour to a comment:

test "first item upload emits the kaunta-event trigger with the event name" do
  post wardrobe_items_path, params: { wardrobe_item: { image: image } }
  follow_redirect!

  assert_select "[data-controller='kaunta-event']", count: 1
  assert_select "[data-kaunta-event-name-value='First Item Uploaded']", count: 1

  # Regression guard: the old, broken inline tracker must be gone.
  assert_no_match(/addEventListener\(['"]DOMContentLoaded['"]/, response.body,
    "flash analytics event must not be tracked via a DOMContentLoaded script")
end

The assert_no_match is the part I care about most. It's not testing what the page does; it's testing that the broken pattern can never come back through a careless copy-paste.

Bug 4: Signup was still zero

I deployed, watched First Item Uploaded and the onboarding-choice events start landing events that had never been anything but zero and felt good about it. Then I looked again the next day. Signup was still zero.

The first three bugs were dead. This was a fourth one wearing their clothes.

The cause: 100% of OutfitMaker's signups come through Google OAuth. Nobody uses the email/password form. And the Signup event was only ever set in RegistrationsController#create the email/password path. The OAuth path, OmniauthCallbacksController, set no event and, it turned out, sent no admin notification either. Which also explained a separate mystery: I never got an email when someone signed up. I'd been blind to my own new users because I'd only instrumented the door nobody walks through.

The fix (dca116a, PR #88) pulls the side effects into a shared concern both controllers include:

module SignupSideEffects
  extend ActiveSupport::Concern

  private

  def handle_new_signup(user)
    user.update_column(:locale, I18n.locale.to_s)
    flash[:analytics_event] = "Signup"
    return if Rails.env.test?

    UserMailer.welcome_email(user).deliver_later
    AdminMailer.new_user_signup(user).deliver_later unless user.admin?
  end
end

Two subtleties in the OAuth side made this more than a one-liner.

Telling a new signup from a returning login. from_omniauth both creates new users and logs in existing ones, and it'll also link OAuth to an existing email account. Only a genuinely new record should fire Signup. Rails 7's previously_new_record? is exactly that signal true only on the request that created the row:

if @user.previously_new_record?
  handle_new_signup(@user)
  sign_in(@user, event: :authentication)
  redirect_to onboarding_path(step: 1)
else
  flash[:notice] = t("flash.omniauth.success", provider: provider)
  sign_in_and_redirect @user, event: :authentication
end

Flash survives exactly one redirect. Devise's sign_in_and_redirect would send a new user to root, which then redirects to onboarding two hops. flash[:analytics_event] only survives one. The second redirect would silently eat it, and I'd be right back to a zeroed Signup for a subtly different reason. So the new-signup branch redirects straight to onboarding in a single hop, and the flash lives long enough for the Stimulus trigger to fire.

I covered the new-vs-returning logic at the model level too, because it's the load-bearing assumption a brand-new user, a returning user, and an OAuth-linked existing account each get their own test asserting whether previously_new_record? is set.

The result

After the second deploy, Kaunta started showing real signups where there had only ever been a flat line and the rest of the chain (Activation, the post-wow upgrade prompts) lit up with it. OutfitMaker is small enough that these are modest counts, but the point isn't the magnitude. It's that the dashboard finally describes the product instead of contradicting it.

The takeaway

Instrumentation that silently reports zero is worse than none, because you act on it. I spent real time wondering why my "funnel was thin" when the funnel was fine and the funnel meter was unplugged. Two rules I'd hand my past self:

In a Turbo app, never fire analytics from a <head> DOMContentLoaded script. Your most important events arrive on Turbo visits, where that listener is already too late. Fire from a Stimulus connect() and wait for your script to be ready instead of guarding once and giving up.
A funnel's top must cover every path into it. I instrumented the signup flow I wrote first and assumed it was the signup flow. The one my users actually used was untouched. Count the doors before you trust the turnstile.

The quiet bugs are the expensive ones. A crash gets fixed the same day. A zero that should be a number can sit there for as long as you're willing to believe your product is just quiet.