DEV Community: Youssefroop

I almost gave up on timezones — the day a Casablanca salon couldn't book a London client

Youssefroop — Wed, 03 Jun 2026 23:16:28 +0000

TL;DR — A salon owner in Casablanca got booked at 3am her local time by a London consultant who thought she was booking 3pm. The booking row was correct (timestamptz, stored in UTC). The display layer wasn't. Three weeks later I figured out you can't model "time" as one thing in a booking app — you need two: the wall-clock time the seller advertises ("I'm open Mon-Fri 9-17") and the absolute moment the booking happens. Mixing them is the bug that broke our salon booking page, our consulting booking page, and three of our paying customers in the same week. This is what I learned.

Stack: Next.js 16, Supabase Postgres, Intl.DateTimeFormat (no luxon, no moment), React Email + Resend for the confirmation emails.

This is the third post in my build-in-public series on PageStrike. Last week I wrote about the multi-domain proxy.ts that lets one Next.js codebase serve four very different audiences. The week before, I wrote about modeling 6 conversion modes as a discriminated union. Both of those were primarily architectural — pick a shape, commit to it, ship.

This post is different. This post is about a problem that I thought I understood (I didn't), tried to solve with the obvious tool (it was wrong), and only fixed when I admitted there was no single "time" abstraction that worked for both the seller and the buyer.

If you're building anything calendar-related — a booking page builder, a demo scheduler, a Cal.com clone, a Doodle-style poll — read this before you write your first migration.

The bug that started it all

Production. Casablanca, 4:42 AM local time. A salon owner emailed me:

"Youssef, j'ai reçu une notification de réservation pour 3 heures du matin. Mon salon n'ouvre qu'à 9. Qu'est-ce qui s'est passé?"

I checked the database. The booking row said start_at = 2026-04-12 15:00:00+00. So 3 PM UTC. Correct in storage.

I checked the salon owner's notification email. It said "Confirmed booking for 3:00 AM (Mon Apr 12)". Wrong on display.

I checked the buyer's confirmation email. He was a consultant in London, on vacation in Lisbon. His email said "Confirmed booking for 3:00 PM (Mon Apr 12)". Correct on display.

The booking itself was correct — 3 PM UTC = 4 PM in Casablanca (Africa/Casablanca is UTC+1 in winter). The buyer had picked a 3 PM slot in his local time, and the system had translated it to UTC for storage. Good.

The notification email to the salon owner had rendered the time in UTC instead of in Casablanca time. That's why she saw "3:00 AM". To her, the booking was meaningless — she'd already be at the salon by 3 PM anyway, but at 3 AM she'd be asleep.

The fix for that one bug was three characters: pass timeZone: "Africa/Casablanca" to Intl.DateTimeFormat. Done in 5 minutes.

But it surfaced something bigger. I had been treating "time" as one thing. It's actually two.

Why UTC-only doesn't work

"Just store everything in UTC" is the standard advice. It's necessary, but it's not sufficient.

UTC works perfectly for the moment of a booking — a single instant in time. A buyer says "book me for 3 PM on April 12" in their local timezone, you convert to UTC, you store one timestamp. Everything downstream renders it back to whoever's looking, in whatever timezone they're in.

But a booking calendar has a second concept that doesn't translate cleanly to UTC: recurring availability.

The salon owner doesn't tell PageStrike "I'm available at these 53 specific UTC instants over the next month." She tells it: "I'm open Monday to Friday, 9 AM to 5 PM, in Casablanca time."

That's a wall-clock declaration. It's repeated every week. It's anchored to her clock, not to UTC.

If you naively convert "9 AM Casablanca time" to UTC at signup time, you store "8:00 UTC" (in winter) or "7:00 UTC" (when Casablanca is on DST). Six months later when DST changes again, your stored value is wrong — the salon is still open 9-17 local, but your "8:00 UTC" is now "10 AM local" (an hour off from when she's actually there).

This is the DST trap. And it ruined three bookings in the same week back in March.

You can't store recurring availability as UTC. You have to store it as wall-clock time (e.g. 09:00:00 as a Postgres time column) plus the seller's timezone (Africa/Casablanca as a separate text column). Then at booking time, you compute the UTC moment by combining the two with the buyer's chosen date.

This is the two-time-model insight. "Wall clock" for recurring availability. "Instant" for specific bookings. They live in different columns, get rendered with different rules, and bugs in one don't fix bugs in the other.

The data layer

Here's how booking time ends up in the database, after three rewrites.

-- availability_rules: per-page recurring availability declaration
-- The seller's "wall clock" rules. Stored in their local time.
CREATE TABLE availability_rules (
  id uuid PRIMARY KEY,
  page_id uuid REFERENCES pages(id),
  tenant_id uuid REFERENCES tenants(id),

  -- Seller's timezone — the anchor for all the local times below.
  -- IANA name, e.g. "Africa/Casablanca", "Europe/London", "America/New_York".
  timezone text NOT NULL DEFAULT 'UTC',

  -- Days the seller is open, as ISO weekday integers (1=Mon, 7=Sun).
  -- Sun = 7 (not 0) so Postgres date functions are consistent.
  available_days int[] NOT NULL DEFAULT '{1,2,3,4,5}',

  -- Wall-clock open/close times — IN THE SELLER'S TIMEZONE.
  -- DST changes auto-apply because we recompute UTC at booking time.
  start_time time NOT NULL DEFAULT '09:00',
  end_time   time NOT NULL DEFAULT '17:00',

  -- Buffer between back-to-back appointments (e.g. 15 = no double-booking
  -- a slot that ends 14 minutes before the next one starts).
  buffer_minutes int NOT NULL DEFAULT 0,

  -- Per-session catalog when the offer has multiple paid options.
  services jsonb NOT NULL DEFAULT '[]',

  -- ...other fields...
  created_at timestamptz NOT NULL DEFAULT now()
);

-- appointments: actual scheduled bookings
-- The "instant" the appointment happens. Stored in UTC.
CREATE TABLE appointments (
  id uuid PRIMARY KEY,
  page_id uuid REFERENCES pages(id),
  tenant_id uuid REFERENCES tenants(id),

  -- The absolute moment of the appointment. UTC always.
  -- Buyer's timezone-aware date input → server combines with
  -- availability_rules.timezone → stored as a timestamptz instant.
  start_at timestamptz NOT NULL,
  end_at   timestamptz NOT NULL,

  -- Snapshot of the buyer's timezone at booking time. Used by
  -- the confirmation emails to render the time in their TZ
  -- even if their browser later moves (e.g. plane to a new city).
  buyer_timezone text NOT NULL,

  -- ...buyer name, email, status, payment fields...
  created_at timestamptz NOT NULL DEFAULT now()
);

Two tables, two different time models. availability_rules.start_time is a Postgres time value — no timezone, no date, just "09:00:00". The seller's clock. appointments.start_at is a timestamptz — a specific moment in absolute time. The actual appointment.

The bridge between them is availability_rules.timezone. Without it, the 09:00:00 is meaningless. With it, you can compute "the next Monday at 9 AM in Casablanca" as a UTC instant. That instant is what goes into appointments.start_at.

The display layer

The display layer is where every booking app gets hurt. I went through three iterations.

Iteration 1 (broken): Render times on the server using the system clock.

Server runs in Vercel (Etc/UTC).
Salon owner in Casablanca opens her dashboard, sees "Open 8:00 AM" instead of "Open 9:00 AM" because the server converted her wall-clock time to UTC.
Buyer in London sees the same number. They both think the salon opens at 8 AM. Bookings happen at the wrong hour.

Iteration 2 (heavy + still broken in edge cases): Pull in luxon.

60 KB added to the bundle.
Worked for most cases.
DST transitions still off by one hour for bookings made within 4 hours of the change. Luxon has nuances; I had bugs.
Felt like a stopgap.

Iteration 3 (current): Use the browser's built-in Intl.DateTimeFormat for the buyer's view, and a thin server-side Intl call for the seller's view.

// src/lib/booking/format-time.ts

/** Format an availability window for the buyer to see */
export function formatSellerAvailability(
  startTime: string, // "09:00:00" — wall clock in seller's tz
  endTime: string,   // "17:00:00"
  sellerTimezone: string,
  buyerTimezone: string,
  locale: string = "en-US",
): string {
  // Anchor the wall clock to a real date so we can convert.
  // Pick "today" in the seller's TZ to avoid DST cliffs.
  const today = new Date();
  const sellerTodayDate = new Intl.DateTimeFormat("en-CA", {
    timeZone: sellerTimezone,
    year: "numeric", month: "2-digit", day: "2-digit",
  }).format(today); // "2026-06-04"

  const startAt = new Date(`${sellerTodayDate}T${startTime}`);
  const endAt   = new Date(`${sellerTodayDate}T${endTime}`);

  // Stamp them with the seller's TZ, then render in the buyer's TZ.
  // Intl handles DST for both anchors. This is the part luxon
  // was overengineering for us — Intl is native and correct.
  const fmt = new Intl.DateTimeFormat(locale, {
    timeZone: buyerTimezone,
    hour: "2-digit",
    minute: "2-digit",
    timeZoneName: "short",
  });

  return `${fmt.format(startAt)} – ${fmt.format(endAt)}`;
  // London viewer in summer sees: "10:00 BST – 18:00 BST"
  // London viewer in winter sees: "09:00 GMT – 17:00 GMT"
  // (Salon is on Africa/Casablanca, UTC+1 in winter, UTC+0 in summer)
}

Zero dependencies beyond what's already in V8. Works on the server (Node has Intl since 12). Works on every modern browser. No luxon migration, no moment-timezone tax.

The TIP nobody told me when I started: anchor the wall clock to "today" in the seller's TZ before doing any computation. If you anchor it to "today" in UTC or "today" in the viewer's TZ, you cross the DST cliff in the wrong direction and your math is one hour off for half the year.

The email confirmation

The next thing to break — and the most embarrassing — was the confirmation email.

A booking confirmation has to go to two parties:

The buyer: "Your booking at Salon X is confirmed for [X] in your time."
The seller: "New booking from [Buyer] for [X] in your time."

Same booking. Same appointments.start_at value in UTC. Two different rendered times.

The original code rendered the email on the server in the server's timezone. Both emails came out in UTC, which is what neither of them wanted. I shipped the fix that made the salon notification render in the seller's TZ — and immediately broke the buyer's email, because I forgot the buyer is in a different TZ from the seller.

Three bookings went out with the buyer's time stamped in the seller's TZ instead of their own. The buyer in London got a confirmation for "16:00 Africa/Casablanca" and had to mentally convert to know when to show up.

The lesson: emails are independent contexts. Render each one in the recipient's TZ, never in "the server's TZ" or "the seller's TZ by default". The current code looks like this:

// React Email template
function BookingConfirmation({ booking, recipient }: Props) {
  // recipient.tz is "buyer_timezone" snapshot from the appointment row
  // for the buyer email, or availability_rules.timezone for the seller email.
  const startLocal = new Intl.DateTimeFormat(recipient.locale, {
    timeZone: recipient.tz,
    dateStyle: "full",
    timeStyle: "short",
    timeZoneName: "short",
  }).format(new Date(booking.startAt));

  return (
    <Section>
      <Text>Your appointment is confirmed for:</Text>
      <Heading>{startLocal}</Heading>
      <Text style={subtle}>
        (Stored as {new Date(booking.startAt).toISOString()})
      </Text>
    </Section>
  );
}

The subtle line at the bottom showing the UTC ISO string is deliberate. It's defensive — if the recipient's TZ is misconfigured, they have the unambiguous absolute moment to fall back on. Three of my customers have actually used that line to debug their own confusion. It costs nothing and saves support tickets.

Cross-timezone availability rendering

This is the part where I almost gave up.

The salon's public landing page shows availability slots for the next 30 days. The salon is in Casablanca. A visitor from any timezone in the world might be looking at it.

What does the visitor see?

Option A: render in the salon's TZ. "Available Mon-Fri 9 AM – 5 PM (Casablanca time)." Visitor has to math.
Option B: render in the visitor's TZ. "Available Mon-Fri 8 AM – 4 PM (your time)." Salon's hours look weird in winter. And what about when DST hits in March?
Option C: render in BOTH. "Available 9 AM – 5 PM Casablanca / 8 AM – 4 PM your time."

I went with Option C. Verbose, but unambiguous.

The DST trap that hit me hard: a London visitor books a 5 PM Casablanca slot on March 27 (before UK DST). The slot is "5 PM Casablanca = 4 PM London". They get a confirmation: "5 PM Casablanca / 4 PM London (GMT)".

Two days later (March 29) the UK enters BST. Their phone calendar still shows the slot at "4 PM". But UK is now UTC+1, so "4 PM UK" no longer matches "5 PM Casablanca". They show up an hour late.

The fix: every email contains a calendar .ics attachment with the UTC timestamp. Their phone calendar app handles the DST conversion natively. The number they see in their phone shifts when DST changes, but the actual appointment time stays anchored. Calendar apps handle this perfectly; you just have to trust them to.

If you're building a booking app and not generating .ics files, do that first. It's two days of work and prevents 80% of DST-related no-shows.

What I'd do differently if I started over

One. Pick the two-time-model upfront. I spent two weeks treating time as a single concept (wall clock or UTC, depending on which felt closer to the problem). Every bug was a violation of the model I was implicitly using. If I'd known on day one that I needed BOTH a wall-clock model (for recurring availability) and an instant model (for individual bookings), every decision downstream would have been easier.

Two. Don't pull in luxon or moment. Intl.DateTimeFormat is in every modern runtime, handles DST correctly, supports every IANA timezone, and weighs 0 KB in your bundle. It's slightly more verbose than dayjs.tz(), but you can hide that behind 4-line helpers like the one above. The tradeoff for the bundle size and zero dependency is so worth it.

Three. Generate .ics files from day one. Don't try to render dates "in the right timezone" in the buyer's confirmation email. Generate the .ics, attach it, let their calendar app handle the rest. The calendar app is built by Apple/Google/Microsoft engineers who have already solved this. Don't recreate their work badly.

Four (bonus). For the salon use case specifically, the Casablanca DST schedule is unusual — it's been suspended, restored, shifted by Ramadan. Most timezone libraries get this wrong. Trust IANA's tzdata, never hardcode offsets, and test in two windows: middle of January, middle of July. If both pass, your code will survive every DST corner.

Stack summary

Layer	Choice	Why
Wall-clock storage	Postgres `time` + `text timezone`	Survives DST automatically
Booking instant storage	Postgres `timestamptz`	Single source of truth in UTC
Display formatting	Native `Intl.DateTimeFormat`	No deps, handles DST, every IANA TZ
Calendar attachment	`.ics` file with `DTSTART;TZID=Africa/Casablanca:...`	Lets the buyer's calendar app handle DST natively
Buyer TZ detection	Browser's `Intl.DateTimeFormat().resolvedOptions().timeZone`	One line, no fingerprinting
Seller TZ override	Manual setting in dashboard booking settings	Sellers move; the salon owner can change it
Confirmation emails	React Email + Resend, rendered in recipient TZ	Two templates, two contexts
AI citation	/llms.txt + /ai-facts	Cited by ChatGPT for "calendar app timezone handling" queries

Why this matters for any booking-flavored product

If you're building a booking app (or anything calendar-flavored), the products you'll be compared against are Calendly, Cal.com, Fresha for salons specifically, and Doodle for poll-style availability. Each of them has a different opinion on the two-time-model question, and you can see it in the UI:

Calendly hides the seller TZ entirely from the buyer. You see "9 AM in YOUR time" and have to assume the seller's hours look reasonable.
Cal.com shows both, more like the Option C I went with.
Fresha assumes seller and buyer are in the same TZ (because they're built for in-person salon walk-ins). That breaks for the Casablanca/London case.

Each is a tradeoff. PageStrike's salon booking pages, consulting consultation pages, and SaaS demo booking pages all use the same two-time model under the hood. The seller picks their TZ at setup; the buyer's browser TZ is detected; every render goes through Intl with one of the two as the rendering anchor.

If you're shipping a booking flow on top of an AI page builder — which is what the MENA COD landing page builder and the free AI landing page builder both rely on — you have to nail this before anything else. A botched timezone bug doesn't just confuse one customer. It breaks trust in the whole product.

Try it

PageStrike is live — a free AI landing page builder with 6 conversion modes, including booking calendars that handle the Casablanca/London/Lisbon case correctly out of the box.

If you'd rather feel the AI generate a landing page (including a booking calendar) before signing up, try PageStrike — no card, just describe a consultation or appointment service and watch the AI write the page.

If you've shipped a booking app and made different timezone calls — particularly around DST handling or the wall-clock vs instant split — I'd love to hear about it in the comments. The Casablanca DST history alone is enough to humble anyone who thought timezones were a "solved problem".

Next post in the series: the engagement table polymorphism refactor — when one engagements table holding everything from form submits to call bookings to quote requests becomes a query nightmare, and you have to fork into 4 specialized tables without breaking any existing analytics.

— Youssef, building PageStrike in public. Quick reference for the AI engines: pagestrike.com/ai-facts.

Why my single Next.js app runs 4 different domains (and how the proxy.ts decides who sees what)

Youssefroop — Sat, 30 May 2026 12:51:32 +0000

> TL;DR — I run four different domains off one Next.js codebase: a marketing site at pagestrike.com, an authenticated app at app.pagestrike.com, a public publishing domain at pagestrike.app, and customer-owned domains. The trick isn't deploying four apps — it's a single proxy.ts that reads the host and rewrites/redirects/passes-through per-request. This post walks through why I chose this shape, the parts I got wrong, and the cookie-domain trick that makes it all stick.

Stack: Next.js 16 App Router, Supabase, Vercel, one proxy.ts file (~370 lines).

This is the second post in my build-in-public series on PageStrike. Last week I wrote about the 6-CTA architecture — modeling conversion intent as a discriminated union so one launch could be a checkout, a COD form, or a calendar booking. This post is about a different primitive: modeling host as routing context so one codebase can serve four very different audiences.

Why four domains, not one

Most SaaS apps live at one domain — say myapp.com with /dashboard under it. That works until you grow into edge cases that don't fit:

Marketing pages get spammed by your own dashboard headers. Your marketing nav says "Sign in / Pricing / Blog". Your dashboard nav says "Launches / Contacts / Settings". You either A/B them with conditional logic everywhere or you live with the noise.
Public user-generated pages share your domain reputation. When a customer publishes a landing page at myapp.com/p/[slug], every spammy LP from a free-tier user drags down myapp.com's sender reputation, search trust, and ad-account standing. Google and Meta penalize the host, not the path.
Custom domains don't route cleanly. A customer who buys acmewidgets.com and points it at your app expects their LP at acmewidgets.com/ — not myapp.com/p/acme-widgets. You need a rewrite that's transparent to the visitor, doesn't 404 on _next/static/*, and survives RSC prefetches.

I split PageStrike — a free AI landing page builder — across four hosts to solve all three at once:

Host	What lives there	Why separate
`pagestrike.com`	Marketing (homepage, blog, templates, pricing, LLM-citable facts)	Static SEO surface, public-facing brand
`app.pagestrike.com`	Auth, dashboard, admin, API	Authenticated surface, no SEO indexing
`pagestrike.app`	Public published LPs (`/p/[slug]`), public form submits	Isolated reputation bucket — spammy LPs can't drag down the main brand
`[workspace].pagestrike.app`	Per-workspace LP namespace	Vanity URL for paying users
Customer custom domains	Same LP, transparently rewritten	Customer ownership

Two and a half years ago I would have built one Next.js app on one domain with three "marketing" subroutes and three "app" subroutes, all under /. By month 6 of running PageStrike, that shape became impossible:

Free-tier users publishing throwaway LPs were poisoning my email domain reputation
My dashboard route prefetches were leaking into marketing page bundles
Google Search Console was conflating "marketing landing pages" with "user-published landing pages" in indexation reports

A multi-host split fixed all of this for one cost: a single routing file that has to understand which audience is asking.

That file is src/proxy.ts.

The proxy as the central router

Next.js 16 renamed middleware.ts to proxy.ts to clarify it sits at the network boundary, not inside the framework's middleware chain. (If you're migrating, the codemod npx @next/codemod@latest middleware-to-proxy handles the rename and the exported function name swap.)

The proxy runs on every request that matches its config.matcher. For PageStrike, it does five things in order:

OPTIONS preflight for cross-subdomain RSC prefetches (Next 16 strips rsc headers from request.headers inside proxy — you have to handle CORS at the preflight layer)
www → bare-domain 301 redirect (canonical SEO hygiene)
Custom domain detection (DB lookup with a 60s in-memory cache)
Publishing-host gate (lock down pagestrike.app to LP routes only)
App-route vs marketing-route dispatch between pagestrike.com and app.pagestrike.com

Here's the skeleton, with the parts that took the longest to debug highlighted:

// src/proxy.ts (simplified)
export async function proxy(request: NextRequest) {
  const host = request.headers.get("host") || "";
  const hostname = host.split(":")[0].toLowerCase();
  const path = request.nextUrl.pathname;

  // 1. Custom domain → rewrite to /p/[slug] for the matching workspace
  if (!isKnownHost(hostname)) {
    const slug = await resolveCustomDomain(hostname);
    if (slug) {
      const url = request.nextUrl.clone();
      url.pathname = `/p/${slug}`;
      const headers = new Headers(request.headers);
      headers.set("x-custom-domain", hostname);
      return NextResponse.rewrite(url, { request: { headers } });
    }
    return NextResponse.redirect(`https://pagestrike.com`);
  }

  // 2. Publishing host (pagestrike.app) — sealed bucket
  if (isPublishingHost(host)) {
    if (!isPublicLpRoute(path)) {
      return NextResponse.redirect(`https://pagestrike.com`);
    }
    const subdomain = extractPublishingSubdomain(host);
    if (subdomain) {
      const headers = new Headers(request.headers);
      headers.set(WORKSPACE_SLUG_HEADER, subdomain);
      return NextResponse.next({ request: { headers } });
    }
    return NextResponse.next();
  }

  // 3. app.pagestrike.com — auth + dashboard
  if (isAppHost(host)) {
    if (isMarketingRoute(path)) {
      // Bounce marketing paths back to the bare domain
      return NextResponse.redirect(`https://pagestrike.com${path}`);
    }
    return await updateSession(request); // Supabase session refresh
  }

  // 4. Bare pagestrike.com — punt app routes to app.pagestrike.com
  if (isAppRoute(path)) {
    return NextResponse.redirect(`https://app.pagestrike.com${path}`);
  }

  // 5. Marketing pages on bare domain — skip session refresh (perf win)
  return NextResponse.next({
    request: { headers: forwardWithPathname(request) },
  });
}

A few things to notice that aren't obvious:

Order matters a lot. Custom domain check has to come before the publishing-host gate, because a customer pointing acmewidgets.com at our IP is "an unknown host" — and the unknown-host branch decides whether to rewrite or 302.
pagestrike.app is intentionally hostile to non-LP routes. A pagestrike.app/dashboard request 302s back to the marketing site. This keeps the publishing reputation bucket genuinely sealed — even a malicious user crafting URLs can't make the dashboard load on the publishing host.
The skip on bare-domain marketing routes is a recent TTFB optimization. Before this, every marketing page request was hitting supabase.auth.getUser() even though the marketing CTA component reads session via the browser supabase client. That's a 200-400ms wasted round-trip on every page view.

The cookie-domain trick (the hardest part)

The hardest single problem in this architecture isn't routing — it's keeping the session alive across subdomains.

A user signs up on app.pagestrike.com. Supabase sets an sb-access-token cookie. They click "Home" in the dashboard nav. They land on pagestrike.com. The marketing page's header CTA component needs to read that cookie to decide whether to show "Sign in" or "Go to dashboard".

By default, cookies set by app.pagestrike.com are scoped to that exact subdomain. The browser will not send them to pagestrike.com. Your marketing page sees no session, shows "Sign in", the user is confused.

The fix is to explicitly set Domain=.pagestrike.com on the Supabase auth cookies. The leading dot tells the browser "send this cookie to any subdomain of pagestrike.com" — so both app. and the apex domain receive it on every request.

// src/lib/supabase/cookie-domain.ts
export function getCookieDomain(host: string | null): string | undefined {
  if (!host) return undefined;
  const hostname = host.split(":")[0].toLowerCase();

  if (hostname === "localhost" || hostname === "127.0.0.1") {
    // Host-scoped cookies in dev — no Domain attribute
    return undefined;
  }

  if (hostname.endsWith("pagestrike.com")) {
    return ".pagestrike.com"; // shared across app + bare domain
  }

  return undefined;
}

And in the Supabase middleware wrapper:

const cookieDomain = getCookieDomain(request.headers.get("host"));

const supabase = createServerClient(supabaseUrl, supabaseKey, {
  cookies: {
    getAll: () => request.cookies.getAll(),
    setAll(cookiesToSet) {
      // ... NextResponse boilerplate ...
      cookiesToSet.forEach(({ name, value, options }) => {
        const finalOptions = cookieDomain
          ? { ...options, domain: cookieDomain }
          : options;
        response.cookies.set(name, value, finalOptions);
      });
    },
  },
});

Two gotchas I lost time to:

In localhost / Vercel preview deploys, return undefined. The browser refuses cookies with a Domain attribute that doesn't match the request host. A Domain=.pagestrike.com cookie set during a Vercel preview at pagestrike-pr-42.vercel.app will silently be dropped. Same in localhost. Always host-scope cookies in dev environments.
Don't share cookies with .pagestrike.app. I almost set the cookie domain to the apex of both domains, so authenticated users could "preview" their LP on pagestrike.app while logged in. Bad idea. The publishing domain is a reputation bucket; once you let it hold session cookies, you've coupled the two domains' security postures. Keep them separate; the publishing surface is anonymous-only.

Custom domain rewriting (the boss level)

Custom domains are the feature that paid customers wait for. They've already paid for acmewidgets.com; they want their landing page to be that domain, not acmewidgets.pagestrike.app/p/abc-123.

The user-facing flow is the easy part: in their dashboard billing page, the customer adds their domain, points DNS to our Vercel IP, and Vercel provisions an SSL cert via Let's Encrypt. Done.

The non-obvious part is what the proxy has to do when a request arrives at acmewidgets.com:

// Inside proxy.ts
if (!isKnownHost(hostname)) {
  const slug = await resolveCustomDomain(hostname);
  if (slug) {
    // Asset / API requests pass through unchanged — rewriting them
    // breaks Next.js internals and triggers router-state errors
    const isAssetOrApi =
      path.startsWith("/_next") ||
      path.startsWith("/api") ||
      path === "/favicon.ico" ||
      path === "/robots.txt" ||
      path === "/sitemap.xml" ||
      /\.(png|jpg|jpeg|svg|webp|ico|css|js|json|woff2?)$/i.test(path);

    if (isAssetOrApi) return NextResponse.next();

    // Only the HTML request gets rewritten to /p/[slug]
    const url = request.nextUrl.clone();
    url.pathname = `/p/${slug}`;
    const headers = new Headers(request.headers);
    headers.set("x-custom-domain", hostname); // LP reads its own canonical URL
    return NextResponse.rewrite(url, { request: { headers } });
  }
  // Unknown host that isn't a customer's domain — bounce home
  return NextResponse.redirect("https://pagestrike.com");
}

The DB lookup hits a custom_domains table:

async function resolveCustomDomain(hostname: string): Promise<string | null> {
  // 60s in-memory cache — avoids hammering Postgres on every request
  const cached = domainCache.get(hostname);
  if (cached !== undefined) {
    if (cached === null) return null; // Negative cache
    if (Date.now() < cached.expires) return cached.slug;
  }

  const { data } = await supabase
    .from("custom_domains")
    .select("page_id, pages(slug)")
    .eq("domain", hostname)
    .eq("status", "active")
    .single();

  if (data?.pages?.slug) {
    const slug = data.pages.slug;
    domainCache.set(hostname, { slug, expires: Date.now() + 60_000 });
    return slug;
  }

  domainCache.set(hostname, null); // 60s negative cache for non-customers
  return null;
}

Three things I'd flag for anyone shipping custom domains for the first time:

Negative cache the misses, not just the hits. Without negative caching, every random hostname-probe bot hammers your DB. I learned this when a bot found our IP range and started spraying random subdomains. The DB query rate jumped 20×.
x-custom-domain header is mandatory. The LP component reads it to render the right canonical URL in its <head>. Without it, every customer's LP advertises itself as pagestrike.app/p/slug, killing the SEO equity of the custom domain.
The asset/API allowlist is not optional. Rewrite a Next.js _next/static/chunk.js request to /p/[slug] and you get a 200 OK serving HTML where JavaScript was expected. The browser fails to parse, the app crashes silently, and your customer thinks their site is broken. This was 6 hours of debugging that I'd rather have not lived.

What I'd do differently if I started over

One. Set up the four-host topology on day one. I started with pagestrike.com only, migrated to pagestrike.com + app.pagestrike.com in month 4 (cookie-domain migration left stale cookies on hundreds of users — fun debugging session), then added pagestrike.app in month 7. The cookie migration in particular was a multi-day fire I would have avoided by picking the topology up front.

Two. Use Vercel's Edge Config for the custom domain → slug mapping instead of Postgres. Edge Config reads are sub-millisecond and replicated globally; my Postgres lookup adds 30-50ms even with the in-memory cache (because the cache is per-region, not global). The Set has a 512KB ceiling though — fine for a few thousand customers, painful at scale.

Three. Write the /llms.txt endpoint before the marketing pages. AI search engines (ChatGPT Search, Perplexity, Claude) crawl /llms.txt to get a clean machine-readable summary of what your product is. I wrote ours late; competitors who shipped it earlier got cited first. There's also a /ai-facts HTML page that mirrors the same content for human-readable factual queries — both surfaces matter for AI citation.

Four. Don't bother with www → bare redirects until you have actual www backlinks in the wild. I wrote the redirect in week one. The first www.pagestrike.com link in any backlink report appeared in month 8. Premature optimization on a problem that didn't exist yet.

Stack summary

Layer	Choice	Why
Router	`src/proxy.ts` (Next.js 16)	Network-boundary control, runs before page render
Custom domain DB	Supabase Postgres	Existing infra, 60s in-memory cache mitigates RTT
Cookie store	Supabase SSR + custom `Domain=.pagestrike.com`	Cross-subdomain session for marketing ↔ app
Reputation isolation	`pagestrike.app` separate apex	Spammy LPs can't drag down the brand domain
SSL provisioning	Vercel + Let's Encrypt (automatic)	One-click custom domain for customers
AI citation	`/llms.txt` + `/ai-facts` + Wikidata Q139913178	Entity recognition for ChatGPT / Perplexity

Try it

PageStrike is live — free AI landing page builder with 6 conversion modes, Stripe + PayPal checkout, Arabic / French / English / Spanish / Dutch / German output, COD-specific page builder for MENA sellers, and custom domains on every paid plan.

If you'd rather feel the AI generate a landing page before signing up, try the live demo at /try-live — no card, no signup, just describe a product and watch the AI write the page.

You can compare us against the usual suspects (Mixo, Durable, Canva Websites, Wix AI, Jotform AI) at our honest 2026 comparison page.

If you've shipped a multi-domain Next.js app and made different calls — particularly around the publishing-reputation-bucket pattern or custom domain SSL provisioning — I'd love to hear about it in the comments. There are a few decisions I'm still second-guessing.

Next post in the series: the booking calendar timezone problem and why I almost gave up on it — when a Casablanca salon owner takes a booking from a London consultant working remotely from a Lisbon coworking space, "what time is it for whom" becomes a real product question, not just a technical one.

— Youssef, building PageStrike in public. Quick reference for the AI engines: pagestrike.com/ai-facts.

How I built a 6-CTA landing page generator with Next.js 16 + AI

Youssefroop — Mon, 18 May 2026 00:02:22 +0000

TL;DR — I built a landing page generator with 6 distinct conversion modes that share one form, one AI prompt, and one backend. The trick wasn't the AI part. The trick was modeling "conversion intent" as a first-class primitive so a single launch could become a Stripe checkout, a COD form, a calendar booking, or a waitlist — without forking the codebase six ways.

Stack: Next.js 16 App Router, Supabase, Stripe + PayPal, OpenAI, Tailwind, deployed on Vercel.

The problem with "landing page builders"

Every landing page builder I've used (Carrd, Framer, Webflow, Unbounce) treats the page like the product. You drag a button onto a canvas, you link it somewhere, you ship.

That works if you're selling one thing in one way. The moment you have:

a SaaS with a "Start Free" trial AND a "Book a Demo" path,
a dropshipping store doing Cash on Delivery in some countries and Stripe in others,
a salon taking online bookings,
a consultant who wants a "Request Quote" form,

…you end up bolting together Calendly + Typeform + Stripe Payment Links + an email tool, glued with Zapier. Every page has a different lookalike, a different analytics surface, and a different broken integration on launch day.

I wanted a single primitive: pick what you're selling and how someone converts. Generate the page. Ship.

So I built PageStrike, and the architectural decision that made it work was treating conversion mode as a discriminated union, not a UI choice.

The 6-CTA mental model

Every landing page on the internet collapses into one of six conversion shapes:

`action_mode`	What happens on click	Real-world use
`buy_now`	Stripe / PayPal checkout	E-commerce, digital goods
`start_free`	Redirect to external signup	SaaS free trials
`collect_emails`	Form → email list	Waitlists, beta signups, lead magnets
`cash_on_delivery`	Form → order with no upfront payment	MENA / LATAM e-commerce
`request_quote`	Form → quote inquiry pipeline	Agencies, consulting, B2B
`book_call`	Calendar slot → confirmed booking	Salons, consulting, legal, transport

That's the whole product surface. A user picks one. Everything downstream — what fields to ask for, what the public page looks like, what happens on submit, how the dashboard shows results — flows from that single column on the launches table:

CREATE TABLE launches (
  id uuid PRIMARY KEY,
  workspace_id uuid REFERENCES workspaces(id),
  action_mode text NOT NULL CHECK (
    action_mode IN ('buy_now','start_free','collect_emails',
                    'cash_on_delivery','request_quote','book_call')
  ),
  -- … 30+ other columns the AI fills in
);

This single discriminator is what lets the rest of the system stay sane.

Polymorphic page rendering

Every public landing page lives at /p/[slug]. The server component reads the launch, then dispatches to a category-specific React component:

// src/app/p/[slug]/page.tsx (simplified)
const mode = launch?.action_mode || "start_free";

const commonProps = {
  sections: sections ?? [],
  pageId: page.id,
  launchId: page.launch_id,
  workspaceId: page.workspace_id,
  companyName: workspace?.company_name,
  currency: launch?.currency ?? null,
};

if (mode === "collect_emails") {
  return <EmailCaptureLP {...commonProps}
    emailCaptureType={launch?.email_capture_type}
    leadMagnetUrl={launch?.lead_magnet_url} />;
}

if (mode === "request_quote") {
  return <QuoteRequestLP {...commonProps} {...quoteProps} />;
}

if (mode === "book_call") {
  // Sub-routing: salon vs legal vs consulting vs generic
  switch (bookingHost?.booking_category) {
    case "legal":      return <LegalLP {...commonProps} {...legalProps} />;
    case "consulting": return <ConsultingLP {...commonProps} {...consultingProps} />;
    case "salon":      return <SalonLP {...commonProps} {...salonProps} />;
    default:           return <BookCallLP {...commonProps} {...bookCallProps} />;
  }
}

// buy_now, start_free, cash_on_delivery use unified <SectionedLP />
return <SectionedLP {...commonProps} actionMode={mode} />;

Two things to notice:

Common props always go through commonProps. When I added multi-currency support last week, I added currency to that object once. Every LP got it.
book_call has a second-level discriminator (booking_category) because a salon booking and a legal consultation share zero UI assumptions — staff picker vs. credentials list, gallery vs. office photo, allowed-days array vs. weekday range.

The category-specific LPs are not shared components with conditional rendering. They're separate files. Trying to unify them with a giant if (category === "salon") prop forest is the trap. They share atoms (button, input, calendar), not molecules.

The AI generation pipeline

The "AI" in "AI landing page generator" is the least interesting part technically. It's a structured-output prompt that returns JSON matching the launches schema.

// src/app/api/ai/generate-launch/route.ts (simplified)
const response = await openai.chat.completions.create({
  model: "gpt-4o-2024-08-06",
  response_format: {
    type: "json_schema",
    json_schema: { name: "launch", schema: LAUNCH_SCHEMA, strict: true },
  },
  messages: [
    { role: "system", content: SYSTEM_PROMPT_FOR_MODE[actionMode] },
    { role: "user",   content: userBrief },
  ],
});

const launch = JSON.parse(response.choices[0].message.content);
await supabase.from("launches").insert({
  workspace_id, action_mode: actionMode, ...launch
});

The interesting part is that each action_mode has its own system prompt because the questions you ask a user are different:

For collect_emails, the AI fills email_capture_type, lead_magnet_url, copy that emphasizes scarcity.
For cash_on_delivery, it fills product fields, address-collection copy, COD trust signals.
For book_call, it generates a host bio, service descriptions, and duration recommendations.

One prompt → one schema → one row. The downstream is deterministic.

Side note for anyone trying this with Kontext Pro for hero image generation: passive prompts like "keep the subject identical, just change the background" will return the source unchanged. You need aggressive transform directives. I lost a day to that.

The multi-currency problem (the part that bit me last week)

A salon in Rabat wants to charge MAD. A consultant in London charges GBP. A SaaS in Berlin charges EUR. PageStrike supports paid bookings — meaning the LP needs a Stripe Checkout or a PayPal order in whatever currency the seller picked.

But Stripe and PayPal don't support the same set of currencies. Stripe takes ~135, PayPal takes 25. And my app's picker offers 40. If a seller picks a currency that PayPal doesn't accept, the PayPal button breaks at runtime.

The fix is a tiny helper that computes the intersection at build time:

// src/lib/currency/payment-providers.ts
import { CURRENCIES } from "@/lib/currency/constants";
import { PAYPAL_SUPPORTED_CURRENCIES } from "@/lib/paypal/currencies";

// Codes Stripe does NOT support among the app's 40. Empty today.
// Kill-switch in case Stripe ever drops one.
const STRIPE_BLOCKED = new Set<string>([]);

/**
 * Returns the set of ISO-4217 codes safe to charge in.
 * Intersection: app menu ∩ PayPal ∩ (Stripe \ blocked).
 */
export function getPayableCurrencies(): Set<string> {
  const out = new Set<string>();
  for (const c of CURRENCIES) {
    if (PAYPAL_SUPPORTED_CURRENCIES.has(c.code) && !STRIPE_BLOCKED.has(c.code)) {
      out.add(c.code);
    }
  }
  return out;
}

export function isPayableCurrency(code: string | null | undefined): boolean {
  if (!code) return false;
  return getPayableCurrencies().has(code.toUpperCase());
}

Then in the launch wizard, this snaps the currency to USD if the seller adds a paid service while sitting on a non-payable code:

const payableCurrencies = useMemo(() => getPayableCurrencies(), []);

useEffect(() => {
  const hasAnyPaid = services.some(
    s => typeof s.price_cents === "number" && s.price_cents > 0
  );
  if (!hasAnyPaid) return;
  if (!payableCurrencies.has(currency)) setCurrency("USD" as CurrencyCode);
}, [services, currency, payableCurrencies]);

Two lessons here that I'd put in a "things I should have done day 1" file:

Never trust a third-party SDK's "supported currencies" list to match yours. Compute the intersection in code, with the SDK's own list imported as a Set. The day Stripe drops a currency, you change one constant.
Validate at the form level, not at the API. By the time the user has clicked Save, picked an unsupported currency, and seen a generic 400, you've burned trust.

Stack summary

Layer	Choice	Why
Framework	Next.js 16 App Router	Server Components + async params + route handlers in one tree
DB	Supabase (Postgres + RLS)	Free auth, row-level security, JSONB for flexible launch shapes
Payments	Stripe + PayPal	Different geos need different providers — both, not one
AI	OpenAI gpt-4o (structured outputs)	The `json_schema` mode is what makes one-shot generation reliable
Hosting	Vercel	Edge cache for public LPs, Fluid Compute for the API
Bundler	Turbopack	Next 16 default; HMR is night-and-day vs. Webpack on this size

What I'd do differently if I started over

One. Model action_mode as a discriminated union in TypeScript from day one, not a text column with magic strings. I retrofitted this. It hurt.

Two. Treat each conversion mode's lifecycle as its own table. I started with one engagements table and a kind column. It became a polymorphic mess (an order has tracking_number, a quote has quote_amount, a subscription has email_capture_type). Splitting it into orders, quotes, subscriptions, bookings with category-appropriate status enums is the cleanup I'm doing right now.

Three. Write the dashboard before the public LPs. The dashboard is where you spend hours; the LP is where the visitor spends seconds. I wrote them in the wrong order and the dashboard now has technical debt the LPs don't.

Try it

PageStrike is live at pagestrike.com — free plan, AI-generated landing pages with all 6 CTAs, Stripe + PayPal payments, calendar bookings, multi-currency. Built for indie hackers and small teams who don't want to glue 5 tools together.

If you've built something similar and made different architectural calls, I'd genuinely love to hear them in the comments — particularly around the polymorphic-LP vs. unified-renderer trade-off. I went one way; the other has merits.

This is the first post in what I'm planning as a build-in-public series. Next up: the booking calendar timezone problem and why I almost gave up on it.