The short version
- The staging URL everyone quoted in meetings was a completely different application from the production site.
- Nobody was wrong on purpose. The link had been pasted into a doc a year earlier and nobody re-checked it.
- Before touching anything: confirm what serves the domain, how it deploys, and who can publish. Three checks, twenty minutes.
- The riskiest moment in any inherited codebase is your first deploy, because you are testing an assumption you did not know you had made.
On an inherited enterprise project, the staging URL everybody quoted in meetings turned out to be a completely different application from the one serving the live domain.
Nobody was wrong on purpose. The link had been pasted into a project document a year earlier, it had been correct then, and it had been repeated in every status update since. The site it pointed at was real, it looked broadly similar, and it was not the site.
Why does this happen so reliably?
Because URLs get quoted from documents rather than verified against reality, and documents do not update themselves.
A staging environment gets rebuilt. A project moves hosts. Somebody spins up a preview for a proof of concept and the link outlives the experiment. Each of those is unremarkable on its own. The compounding effect is that on any project older than about a year, at least one widely-quoted URL is stale.
| Assumption | How it gets made | How it breaks |
|---|---|---|
| This URL is the site | Pasted into a doc once | Host or environment changed |
| This repo is the source | It was handed to you | A second repo also deploys |
| This branch is production | Convention | Production tracks a different branch |
| This command deploys | It works locally | It publishes to the wrong target |
| I can publish | Nobody said otherwise | The real path is a git push |
The three checks
What serves the domain. Look at the response headers and whatever deploy metadata the host exposes, then compare the rendered markup to the repository you were given. Two minutes.
How a change reaches production. Not how you would deploy it. How this team deploys it. On the project above, publishing was a push to a branch, and running the obvious deploy command directly would have pushed a half-finished build over the live site.
Who can publish. Named people on both sides. Shared credentials with no owner produce exactly the situation where everyone assumes somebody else verified the target.
The riskiest moment on an inherited codebase is your first deploy, because it tests an assumption you did not know you had made.
The safe first change
Make something trivial, visible and reversible, then follow it end to end through the real publish path.
A single word in a footer. Push it, watch it go through whatever the actual process is, and load the live domain to confirm it appeared. That proves the entire chain before anything important depends on it, and it takes fifteen minutes.
We now do this before touching anything on an inherited project, and it has caught a wrong deploy target more than once.
Write it down where it will survive
Put the deploy path in the repository, not in a shared document. Command, branch, host, and the verification step.
Documents drift because nothing forces them to update. A file sitting next to the code is at least in front of the person who changes the process. It is the same reasoning as a publish gate is cheaper than a retraction: the safeguard has to live in the path of the work, not in a place people are expected to remember to visit.
Frequently asked questions
What should you check before working on a client's existing website?
Three things: what actually serves the live domain, how a change reaches production, and who has permission to publish. All three are assumptions people carry from memory, and all three are frequently wrong on inherited projects.
How do you confirm which deployment serves a live domain?
Check response headers and any deploy metadata the host exposes, then compare rendered markup against the repository you were given. Do not rely on a URL pasted in a project document, because those age badly and nobody re-verifies them.
Why is the first deploy on an inherited project the riskiest?
Because it tests assumptions nobody knew they were making: that the repo is the source of truth, that the branch maps to production, and that the deploy command is the one the team uses. Any of those being wrong is discovered by breaking something.
What is the safest way to make a first change to an inherited site?
Make a trivial, visible, reversible change and follow it end to end through the actual publish path. A single word in a footer proves the whole chain works before anything important depends on it.
Who should own publishing access on a client project?
Somebody named on both sides, documented at kickoff. Shared credentials with no owner produce the situation where everyone assumes someone else verified the deploy target.
How do you document a deploy path so it does not decay?
Put it in the repository rather than a shared document, next to the code it describes, and include the command, the branch, the host and the verification step. Documents drift because nothing forces them to update. A file in the repo is at least in front of whoever changes the process.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
