Redesigns Are Not Blank Slates

Every redesign starts with a lie. Not an evil lie, and not even a deliberate one. Just a bad assumption that gets repeated so often people stop hearing it: “We are basically starting fresh.” No, you are not.

You are not starting fresh. You are inheriting a pile of decisions, shortcuts, forgotten accounts, duct-taped systems, invisible dependencies, and buried risk that somebody has to uncover before launch day punches you in the mouth.

That is the part a lot of web projects still get wrong.

People treat redesigns like creative exercises. New moodboard. New copy. New theme. New stack. New launch plan. Everybody wants to talk about layout, animation, conversion paths, performance, and polish. All of that matters. I love that part too.

But if you think a redesign is a blank slate, you are already behind.

Because the real project usually starts below the surface. Who owns the DNS? Where is email actually routed? Is the site behind Cloudflare, or does somebody just think it is? Are there subdomains still live from three agencies ago? What happens when that contact form fires, where does it go, who gets notified, and has anybody tested it recently, or are we all about to find out together after go-live?

Redesigns do not fail because the mockup was weak. They fail because teams miss the hidden infrastructure, ownership, and workflow risk sitting under the surface.

The Fantasy Version of a Redesign

The fantasy version is clean. Client sends credentials. The old site is messy, but not dangerous. The new build gets handled in staging. Launch day is mostly buttoned up. You point the domain, maybe update a few records, clear some caches, test forms, high five everybody, and move on.

That version exists once in a while.

Most of the time, redesigns are closer to archaeology than greenfield development. You are digging through layers: old hosts, old plugins, old redirects, old MX records, old landing pages somebody forgot about, old tools that still do one weird but important job, and old ownership assumptions nobody has verified in years.

And everybody is weirdly calm about it right up until something breaks. Then it gets expensive fast, because the thing that breaks is never the fun thing. It is not the rounded corners. It is email going dark because nobody knew the registrar login belonged to a former employee. It is leads disappearing because the form was rebuilt but the notification workflow was never tested. It is a subdomain full of old content still live, still indexed, still getting traffic, still linked from some random profile or directory nobody remembered to update. It is a redirect chain pointing users to the wrong place. It is the CDN masking the host so the team thinks they understand the stack when they really only understand the top layer of it.

That is why I have such a low tolerance for the phrase “we will figure it out as we go.”

Sometimes that phrase means flexibility.

A lot of the time it means nobody did discovery.

The Pain Is Not The Build. It Is The Unknowns.

Most web developers can handle the build. That is not the scary part. The scary part is launching into infrastructure you do not actually understand. That is where projects go sideways, and not in some dramatic Hollywood sense. I mean sideways in the most annoying, expensive, reputation-damaging ways possible.

The launch technically happens, but forms are broken.

The domain resolves, but mail stops flowing.

The homepage is live, but old URLs fall apart and local SEO equity gets torched.

The client thinks the project is done, and then the real support nightmare begins.

That kind of mess is brutal because it usually comes from stuff that was discoverable before launch. Not always, but usually. The problem is not that the risk was impossible to see. The problem is that most teams do not have a reliable way to surface it early, so they depend on scattered notes, screenshots, forwarded emails, and human memory.

If discovery depends on scattered notes, screenshots, forwarded emails, and memory, you do not have a process. You have hope.

“Send Us Your Credentials” Is Not Discovery

This is one of my favorite little traps in web work. A team asks for access. The client sends what they have. Everybody acts like the box has been checked. But credentials are not clarity.

A login to WordPress does not tell you who controls the DNS. A hosting panel login does not tell you whether Cloudflare is fronting the site. A Google account does not tell you which forms are wired to which workflows. A handoff folder full of passwords does not tell you whether the important systems are even represented in that folder.

That is why proper discovery has to be more than access collection. You need an actual footprint. You need to know what exists, who appears to control it, what is exposed, what is connected, and where the handoff gaps are, not just for the website itself, but for the web property as an operating environment.

That includes:

• registrar and nameserver reality
• DNS records and mail routing
• hosting platform detection
• CMS detection
• subdomains and redirect behavior
• canonical weirdness
• analytics and marketing tags
• lead capture paths that can quietly break revenue if nobody checks them

That work is not glamorous, but it changes everything.

When you can see the footprint, the project gets calmer.

When you cannot, people start making confident decisions on incomplete information.

That is where the damage starts.

Getting Burned Is a Great Teacher

A lot of useful tools are born from irritation. Not abstract market research. Not a clever category idea. Irritation. Repeated friction. The same stupid problem showing up often enough that eventually you stop saying “someone should build that” and start building it yourself.

That is where FITFO came from. Not from trying to invent a sexy product, but from seeing the same launch risks, vague handoffs, hidden dependencies, and mapless decision-making show up over and over.

Once you notice that pattern enough times, you stop treating it like bad luck. You start treating it like a systems problem. FITFO exists because redesigns are not blank slates. They are inherited operating environments.

FITFO exists to surface the inherited environment before launch week turns hidden risk into public problems.

What Good Website Redesign Discovery Actually Looks Like

Good discovery is not a giant enterprise ceremony. It does not need to become some bloated process doc that nobody reads. It just needs to answer the right questions early enough to matter.

A proper pre-launch picture should help you quickly see:

• where the domain lives
• how DNS is routed
• who is handling mail
• whether a CDN or proxy is obscuring the actual host
• what CMS or platform is in play
• what subdomains exist
• where redirects go
• whether the site has obvious canonical or structural issues
• what tracking or marketing tools are present
• what access gaps could turn into launch blockers

That is the difference between “we have a website project” and “we understand the web system we are about to touch.”

The first one sounds fine in a kickoff call.

The team that understands the environment before launch is the team that keeps control when things get real.

Why This Matters More Now

Web work is not getting simpler. Even small businesses have layered stacks now. Forms route into CRMs. CRMs trigger automations. Mail touches DNS, third-party services, and domain settings people have not reviewed in years. Marketing scripts pile up. Subdomains linger. Multiple vendors touch the same property over time.

And because the modern web is so composable, it is easy for critical pieces to exist half outside the website while still affecting the success of the website. That means a redesign team cannot just think like designers or developers anymore. You have to think like operators. You have to care about footprint. You have to care about what is actually true, not just what is written down in some old doc. That operator mindset is the whole point.

Treat every redesign like a takeover of an existing system, not a blank slate waiting for your creativity.

The Better Way to Launch

I think the better way to handle redesigns is simple. Stop pretending they start from zero. Treat every redesign like a takeover of an existing environment. Map the environment first. Find the weak points before they become public problems. Test the things that impact revenue and communication, not just the parts that are easy to demo. Do not let the launch plan outrun the discovery process, and do not confuse access with understanding. That last one gets people all the time.

Access is not understanding. A password gets you in. Discovery tells you what you are actually touching.

Why I Built FITFO

I built FITFO because I got tired of that gap. Tired of the hidden risk. Tired of vague handoffs. Tired of treating launch blockers like surprises when they were usually just undiscovered facts. So the tool does what I wanted the process to do.

Run it against a domain and it helps surface the footprint:

• registrar and nameserver clues
• DNS, MX, SPF, DMARC, DNSSEC
• hosting and CMS signals
• subdomain mapping
• redirect and canonical hints
• analytics and marketing tag clues
• output formatted so it can actually be dropped into notes, docs, onboarding, or first-call prep

Nothing magical.

Just useful.

Operator-grade visibility before somebody flips the switch.

That is the whole game. Not because every launch is doomed, but because every launch inherits history, and history has a way of collecting sharp edges.

Redesigns Are Memory Problems

That is probably the cleanest way I can say it. Redesigns are memory problems disguised as design projects. The danger is usually hiding in what nobody remembers, what nobody documented, or what everybody assumed somebody else owned. And if you wait until launch week to discover that, you are not unlucky.

If you wait until launch week to discover hidden infrastructure risk, you are not unlucky. You are late.

So no, redesigns are not blank slates. They are living systems with baggage. Some of that baggage is harmless. Some of it can tank your launch. The job is knowing the difference before go-live.

That is the mindset. That is the reason for the tool. And that is the kind of work more web teams should be doing before they call a redesign ready.

If you want to poke around with FITFO, it is in public preview on GitHub right now. Run it on your next client domain and see what shows up. My guess is there is more there than you think.