You Fired the Developer but Not Their Code

We had a chatbot product we were building. AI assistant for websites - the kind of thing you demo to clients to close deals fast.

Except every time we loaded the page, something was broken.

The colors were wrong. The responsiveness was off. At one point we had two chatbots loading on the same page simultaneously - one orange (default, not ours), one in our brand colors - stacked on top of each other like some kind of UI nightmare. My devs were confused. I was confused. We even got Webflow support on it. They looked. They shrugged. They couldn't find the problem either.

This went on for weeks.

Then one of my developers - newer to the project - asked a simple question during a call: "Wait, what's this script tag in the footer?"

There it was.

Some developer who'd worked on the project before - long gone by this point - had installed an old, default chatbot widget and left a script tag sitting in the Webflow footer embeds. He didn't document it. Nobody knew it was there. When we built the new chatbot, we layered our code right on top of it. Two chatbots. Competing CSS. One belonging to a person who'd been off the project for months.

We'd been debugging a ghost.

This Should Have Taken 16 Hours

That's not an exaggeration. The actual work - fixing the responsiveness, cleaning up the UI, getting the core functionality stable - was maybe 16 hours of focused dev work if you knew what you were dealing with.

We spent weeks on it.

And I'm not blaming my dev team. They're good. They worked hard. The problem is that nobody handed them a map. The previous developer took his knowledge with him and left the code behind. No documentation. No list of what was installed. No notes on custom scripts, footer embeds, third-party widgets, anything.

So every bug was a mystery. Every visual glitch could have been anything. CSS issue? Framework conflict? Server misconfiguration? No - it was a dead man's script tag that nobody knew to look for.

That's what ghost code does. It doesn't announce itself. It just breaks your product while your team burns hours chasing the wrong problems.

The Ghost in the Machine

Every startup has this problem, even if they don't know it yet.

You hire a developer. They build stuff. They make decisions - sometimes smart ones, sometimes weird ones - and they implement them without telling anyone. Custom script here, webhook there, a third-party widget dropped into a footer embed because it was faster than doing it the right way. They leave. Maybe they get fired. Maybe they find another gig. Doesn't matter. They're gone.

But their code isn't.

And here's the specific trap with Webflow - or any visual CMS - the visual editor only shows you what you built through the interface. The footer embeds? The custom code blocks? Those are a text field. They don't appear in the visual editor. They don't get flagged in component audits. They just sit there, running, doing whatever the person who wrote them decided they should do.

In our case, that meant loading a completely separate chatbot widget that got into a CSS war with our new one, overwriting our styles, breaking our layout, and stumping everyone who looked at it - including Webflow support - because nobody thought to check the footer embed.

Weeks of debugging time. On a 16-hour problem.

What the Developer Left Behind

When we finally found the script, the cascade made sense immediately. The old widget was loading first in the page sequence. Its CSS was running before our CSS. So every time our code tried to render correctly, the ghost widget's styles were already in place and partially overriding ours.

The visual result: broken responsiveness, wrong colors, a zoom glitch on mobile that nobody could explain, and layout weirdness that only appeared sometimes - because some pages loaded the widget and some didn't, depending on caching. It looked like five different bugs. It was one bug expressing itself five different ways.

The developer who found it - the newer guy who asked about the script in the footer - didn't do anything technically brilliant. He just looked somewhere nobody else had thought to look. Fresh eyes. No assumptions about what should be there. That's all it took. And once he found it in the footer, it took Vishal about thirty seconds to remove it.

That's the ghost in the machine. It operates outside your normal visibility - in footer embeds, environment variables nobody documented, webhook connections to old third-party accounts, API keys tied to an email address that no longer exists. The developer left, but every single one of those invisible threads stayed behind.

The Real Cost Isn't the Bugs

The bugs themselves are fixable. Once you know the root cause, cleaning it up is usually fast. A few minutes to remove the script tag. A few hours to tidy the CSS. Done.

The real cost is the time you spend not knowing what you're looking for.

My team spent weeks debugging symptoms instead of causes because nobody had a record of what was installed. Not a formal audit. Not even a rough Slack thread saying "hey, I added this widget to the footer." Nothing. The knowledge lived in one person's head, that person was gone, and we were left guessing.

Think about what that costs in practice:

• Dev hours burned chasing false leads
• A product demo nearly derailed because the UI was still broken
• Webflow support conversations that ate calendar time and went nowhere
• Morale hits every time a "fixed" bug came back because the root cause was still there
• Delayed client meetings while we waited for stability that never quite arrived

None of that shows up attributed to "previous developer left an undocumented script." It just looks like your dev team is slow, or your product is unstable, or your tech stack is bad. The actual cause is invisible.

That's why I call it the ticking clock. Not because the bug will eventually explode - some ghost code runs for years without doing obvious damage. But the moment you need to move fast, add a new developer, or demo to a client, you'll find out exactly how much you don't know about your own codebase.

The Developer Off-Boarding Protocol Nobody Does

Most startups have an onboarding checklist. Give the dev access to GitHub. Add them to Slack. Share the Notion docs. Set up their AWS credentials.

Almost nobody has an off-boarding checklist.

And that's where the ghosts come from.

Here's what a real developer off-boarding audit looks like - not just for protection, but for your own sanity as you grow the team:

1. Code walkthrough before they leave

Before the last day, sit down with the departing developer and do a walkthrough. Not a formal code review - more of a "show me everything you built that isn't obvious." Custom scripts, webhook connections, third-party integrations, anything installed outside the main codebase. Get it documented before they walk out the door. This is five times easier to do with them in the room than six months later when you're staring at a mystery script in a Webflow footer.

2. Audit the invisible layer

The visual codebase is the easy part. The hard part is what you can't see in the editor - footer embeds, custom code blocks in your CMS, environment variables, Zapier automations, third-party accounts tied to the developer's personal email, webhook URLs pointing at external services you may or may not still use. Make a list. Every single one. If it runs outside your main repo, it goes on the list.

3. Rotate credentials immediately

Most teams do this incompletely. They revoke GitHub access and forget about the AWS keys. Or they change the master password and miss the API keys tied to the old developer's personal account. Go through every service the developer touched and rotate or revoke access. Not eventually. Before their last commit merges.

4. Document the "why," not just the "what"

The hardest thing to reconstruct after someone leaves isn't what they built - it's why they built it that way. That weird conditional in the Python code that generates the configuration? There was a reason for it. The old chatbot widget still running in the footer? Probably some reason nobody remembers. Before a developer leaves, spend one hour with them asking "why" questions about anything non-obvious. Record it. Drop it in Notion. Future you will thank you.

5. Test everything after they're gone

Don't assume a clean handoff means clean code. After the off-boarding is done and credentials are rotated, do a full smoke test of every feature. This is when the ghosts surface - not during the handoff, but after, when you think you're in the clear and start finding edge cases that never got written down.

This Isn't Just a Tech Problem

I'm using a software development story here because that's what happened to us. But the pattern shows up everywhere.

In agencies, the version is: a salesperson leaves without documenting their pipeline. Deals in flight, relationships mid-conversation, follow-up sequences half-built in a tool only they know the login for. The knowledge walks out the door. The consequences show up three months later when a warm prospect goes cold and nobody can figure out where the conversation ended.

In a sales operation, it's the same thing with cold email sequences. Someone sets up a campaign in Smartlead or Instantly, runs it for three months, gets results, and then leaves. Nobody inherits the list, the sequence, or the account logins. The campaign dies. The knowledge dies with it. You're starting from zero - except you don't know you're starting from zero, because the campaign still technically exists, it's just broken in ways you can't see.

The common thread: we assume the risk leaves when the person leaves. It doesn't. It just becomes anonymous.

When a developer is still on your team and does something unusual, you can ask them about it directly. "Hey, why is there an orange chatbot loading on the page?" "Oh, that was from when we tested the other widget three months ago - forgot to remove it." Five seconds. Problem solved.

Once they're gone, that five-second conversation becomes three weeks of debugging.

The Fix That Would Have Saved Everything

Looking back, one document would have prevented all of this.

Not a full technical spec. Not a codebase walkthrough. Just a running one-pager: "here's what I installed and where." Footer embed added? Write it down. Third-party widget? Write it down. Zapier automation connecting the app to Slack? Write it down. Environment variable controlling a feature flag? Write it down.

One page. Running list. Required update any time something gets added to the invisible layer. Make it a habit the same way you make committing code a habit.

That's the whole protocol for a small team.

If you're running a bigger operation with multiple developers, you formalize it: a systems inventory doc that gets updated as part of every pull request, and an off-boarding checklist that includes a mandatory review of that doc with the departing developer before the final payment clears.

It sounds obvious. Nobody does it. And then they spend three weeks debugging a script tag.

What Happened When We Cleaned It Up

Once we removed the ghost chatbot, something happened that I didn't fully expect: everything else started working.

The responsiveness issue? Gone. The color glitch? Gone. The double-loading? Gone. It wasn't five problems - it was one problem expressing itself in five different ways. The CSS conflict from the old widget was the root cause of basically every visual bug we'd been chasing.

We went from "broken product, can't demo this to a client" to "clean product, ready for a client call" faster than it takes to run a standup.

That's always how it works when you find the real root cause. The fix is almost never as complicated as the debugging was. The work isn't fixing the bug - the work is finding it. And when the thing that caused the bug is invisible by default, that search takes weeks instead of hours.

The dev who found it didn't do anything technically impressive. He just looked somewhere nobody else thought to check. That's also the argument for documentation: when you write down what's installed, you give future developers a reference point for what should be there. Without it, every team member is flying on their own incomplete mental model of the codebase - and mental models leave when people do.

The Takeaway

If you're building a product with contractors or a small dev team - and most of us are - the ghost code problem is coming for you. Maybe it's already there and you don't know it yet.

The fix isn't complicated. It's a documentation habit. It's an off-boarding checklist. It's the discipline to write down what you installed and where, every single time, so the next person who touches the code has a fighting chance of knowing what they're looking at.

The developer is gone. Their code isn't. Act accordingly.

If you want more frameworks for running operations, managing teams, and building systems that don't fall apart when people leave, check out my free resources - scripts, templates, and blueprints from the stuff that's worked across my companies. And if you want to work through this kind of problem live, that's exactly what we do inside Galadon Gold.