Custom website development services
in Philadelphia

Launch is treated as a moment. It is a sequence, and most of the things that go wrong on it are decided in the week before rather than on the day.

The sequence starts with a content freeze. From a stated hour, nothing changes on the old site. Without that line, somebody publishes an update on the afternoon of the migration and it exists in one place only, and nobody notices for a month. The freeze is unpopular and it is short. It is also the only way the two systems can be compared.

Then the rehearsal. The migration runs end to end against a copy, on the real data volume, timed. A rehearsal answers the question that matters on the day, which is not whether the process works but how long it takes. An import that runs in four minutes on sample data and two hours on the real set turns a quiet evening into an incident.

Rehearsal also produces the rollback. You should know, before starting, what the exact steps back are and at which point they stop being available. A plan that cannot say when the last safe exit passes is a hope.

Domain records are their own hazard. Name servers cache, so a change does not take effect everywhere at once, and for a window both the old and new site are being served to different people. Lowering the cache time a day or two in advance shortens that window considerably. It costs nothing and it is forgotten constantly.

During that window, anything written to the old site is written to a system that is about to disappear. Forms are the usual casualty. Enquiries arrive into an inbox nobody is watching any more.

A launch checklist has to include the unglamorous items too. Certificates on the new host. Mail authentication records, which break quietly and are only discovered when a customer says they never got the confirmation. Analytics and tag configuration. Search engine access, since a staging site normally blocks it and that block has been known to travel to production.

We run the first hour as a checklist read aloud by two people. One executes, one confirms. It is slow on purpose. The alternative is discovering on Monday that step four was skipped because it seemed obvious at eleven at night.

This is the least interesting part of a web project and the one that causes the worst arguments. Ownership of the assets. It is settled cheaply at the start and expensively at the end.

The domain is first. It should be registered to the organisation, in an account the organisation controls, with billing that does not depend on one person’s card. Domains registered by an agency, or by a staff member who has since left, are the single most common way a working site becomes unreachable overnight. A registrar will not hand an account to somebody who cannot prove they own it, and proving it after the fact is slow.

Hosting follows the same rule. Access under the client’s own account, with the supplier added as a user, means a supplier can be changed without a migration. Access that exists only inside a reseller arrangement means leaving requires permission from the party you are leaving.

Then the code. Who holds the repository, and does the client have a copy today rather than on request? A promise to hand it over is not a copy. Repositories should carry the client as an owner from the first commit.

Licences deserve a line of their own, because they expire. Commercial plugins, fonts, stock photography and mapping keys are usually bought during a build and renewed by nobody. A font licence tied to the agency is a font licence that stops when the relationship does.

Third-party accounts multiply quietly. Analytics, search console, mail delivery, payment gateway, the review platform, the chat widget. Each one was created by whoever needed it that day. A year later nobody can list them, and two of them are on a personal address.

So we keep a register from the beginning. Asset, where it lives, which account owns it, who pays, when it renews, who to contact. Five columns. It gets updated when something is added, because a register nobody maintains is worse than none: it creates confidence without accuracy.

Handover is then a short event instead of a project. Transfer the ownership, remove the leaving party as a user, rotate the shared credentials, confirm each item against the register.

The test for whether this is in order is one question, and it is worth asking today rather than during a dispute. If your current supplier stopped answering the phone tomorrow, what would you not be able to get back?

A modern site is assembled from other people’s services. Fonts from one provider. Maps from another. A chat widget, a booking calendar, a payment gateway, a review feed, an analytics script. Each is a dependency with its own availability, and none of them are yours to fix.

The question is not whether one of them will fail. It is what your page does on the day one of them does.

The worst arrangement is a blocking one. A script loaded early, in a way that holds up the page until it answers, turns somebody else’s slow afternoon into your outage. The page is fine. It simply never finishes.

Fonts are the everyday version of this. A page waiting on a font file shows nothing where the text should be, and the visitor sees a blank column. Loading text in a fallback first, then swapping, is a one-line decision that removes the whole failure mode.

Embedded widgets need a designed absence. If the booking calendar does not load, the page should say so and show a phone number. An empty rectangle tells a visitor nothing and looks like a broken site rather than a busy supplier.

Payment is the case that deserves a real plan rather than a fallback. If the gateway is unavailable, the order should be held, the customer told plainly, and somebody alerted. Silently losing the attempt is the expensive outcome, because the customer assumes it worked.

Then the quieter risk. A third-party script can read the page it sits on. Every one you add is a party with access to whatever a visitor types, so the list needs an owner and a review date, and anything nobody can justify should come off.

We keep that list as part of the build. What it does, who needs it, what the page does without it, and when it was last checked. Then we test the failures on purpose by blocking each one in turn and looking at the result.

It takes an afternoon. It is also the only way to know what your visitors see on somebody else’s bad day.