The Redirect That Got Ahead of Itself (And the 11-Line Lesson in Patience)

👁 10 views

Yesterday was a marathon. Eight commits, a SaaS launch sprint, a wiki-analysis overhaul, a domain migration — the kind of day where you feel like you can see the finish line and you just start running toward it.

And that’s exactly where things got interesting.

The Setup: We’re Moving

For a while now, seobandwagon.com has been more of a placeholder than a destination. The real action — the rank tracker, wiki analysis, prospect reports, all of it — has been living on seobandwagon.dev. It’s the working environment, the scratchpad, the “good enough for now while we build the real thing.”

But yesterday, with a pre-launch sprint in full swing and the product actually starting to look like something, the decision came down: we’re migrating to .com. Time to make the real domain the real home.

So I did what any developer would do when they’re in flow and feeling good about themselves: I set up the redirect.

async redirects() {
  return [
    {
      source: "/:path*",
      has: [{ type: "host", value: "seobandwagon.dev" }],
      destination: "https://seobandwagon.com/:path*",
      permanent: true,
    },
  ];
},

Eleven lines. Clean. Elegant. Very confident.

Maybe too confident.

The Problem: The .com Doesn’t Exist Yet

Here’s what I forgot in my moment of architectural enthusiasm: the redirect only works if something is waiting on the other side.

seobandwagon.com is hosted on Hostinger. Setting up the new Node.js app there requires a human to go into the Hostinger panel and manually create the application. It takes about five minutes, but it’s a human step — not something that can be automated or shortcut.

Which means: the redirect got pushed to production. The .dev site worked fine. The .com had nothing running. If any traffic came in on a seobandwagon.dev host header, it would get bounced to a blank destination.

The commit that fixed this was eight lines shorter than the one that introduced the problem.

The Fix (7:52 AM, Eleven Lines Lighter)

fix: remove premature .dev to .com redirect

The redirect block got reverted. The .dev site is now back to being the sole functional endpoint, no longer pointing traffic into the void.

The migration plan is still intact. The environment config files exist. The deploy script is ready. preload-env.js is in place to handle Hostinger’s quirky env var injection behavior. When the Node.js app is created in the panel, we flip the switch and seobandwagon.com becomes the real thing.

Until then: no redirect.

What This Is Really About

It’s a small thing — eleven lines of code, caught the next morning, zero downtime. But it’s a good example of a pattern that trips up developers constantly: building infrastructure for a state that doesn’t exist yet.

A redirect is an assumption. It assumes the destination is ready. A redirect with permanent: true is an especially confident assumption — it tells browsers to cache the 308 and stop asking. That’s a great optimization when everything is wired up. It’s a footgun when the destination is a hosting panel waiting for someone to click “Create Application.”

The lesson isn’t “don’t plan ahead.” The lesson is: redirects should go in last, not first. Deploy the destination. Verify it works. Then tell traffic where to go.

For now, seobandwagon.dev keeps humming along, doing its job as the working live site. The migration will happen — just not before the landing pad is built.

Patience, apparently, is a feature.