---
title: "What a Two-Sentence Redirect Ticket Never Said About the Visitor"
canonical: https://dxdev.com/blog/migration-became-landing-page/
datePublished: 2026-04-02
---
A ticket opened as a URL redirect. Two sentences in the description. The implied work was: move a scheduling product to a new path, verify nothing breaks, close the ticket.

That framing lasted about twenty minutes.

Then we started thinking about what someone would see when they arrived at the new URL, and the ticket stopped being plumbing. The product is a scheduling tool that organizations use to manage lineups. A redirect alone would move traffic. It would not explain the destination or help a new visitor decide what to do next.

## What the ticket grew into

By the time it was done, the scope included a full landing page: SEO metadata, an FAQ accordion, feature cards describing what the product does, a demo showcase, a sitemap update, and a site index entry.

The redirect itself was a contained change. The page that made the destination useful, understandable and maintainable took the rest of the day.

We used an AI coding assistant for the implementation. It handled the scaffolding, followed the existing template structure and wired the accordion component. It did not change the product framing on its own, because that was our job. The frame was the problem. The execution was not.

## How many times we merged

We had not anticipated the merge count. The landing page touched the admin layer, the public-facing marketing layer and the sitemap generation pipeline. Each of those lives on a different branch cadence in the production app.

Our hotfix discipline is to cut from master, merge into develop, and promote to a preview branch before anything goes live. That sequence exists for good reasons. It also means a ticket crossing three surface areas produces three or four merge passes before the work settles.

Those merges kept the surfaces separated and reviewed. The assistant sped up the mechanics of each individual merge. The coordination built into the release paths stayed exactly as it was.

## The last ten percent is always naming

After the landing page was live, two things remained. The product had been running under one internal name and was being renamed. The rename had to propagate through page copy, sitemap entries, FAQ content and a set of username references at the database layer.

The username piece was the smallest part and took the longest to verify. Usernames are load-bearing. Renaming them means checking every table where the old string appears and deciding, for each one, whether the reference is display-only or identity-keyed. We checked four tables before we were confident nothing would break.

The rename itself is a judgment call about what the product should be called. We made the call, and the agent ran the find-and-replace. That division of labor worked fine.

## What the two-sentence ticket never described

The ticket said how the code would move. It said nothing about the person arriving at the new location. That person needed a place to land, a reason to trust it and a way to understand the product.

The URL change was the smallest piece of it. The destination and the release path were the rest.