The map that broke six months after launch

A site I built for a regional church association has a directory of one hundred and forty-two congregations on an interactive map. Finding the nearest one is the site’s single most important job. Somebody moves to a village, opens the site, and needs an answer.

I checked that page this week. The map loads with a grey watermark repeated across every tile — For development purposes only — and a dialog in the middle saying Google Maps could not be loaded correctly.

The code is fine. It has not changed. What changed is on the Google Cloud project: a billing or API key restriction that switched the map into development mode. It is roughly fifteen minutes of work in a console to fix.

The interesting question is not how to fix it. It is: how long has it been like that, and who was supposed to notice?

Failures that arrive late

There is a category of problem that cannot be caught by testing before launch, because at launch everything works. It arrives later, on its own schedule, and it looks like this:

• A card expires and a service quietly drops to a free tier with a watermark, or stops responding entirely.
• An API provider deprecates the version you integrated against. You had eighteen months of notice, in an email to an address nobody reads.
• A free tier gains a rate limit. Your site was under it in year one and is over it in year two, so the feature works in the morning and not in the afternoon.
• A third-party script’s CDN has an outage, and for forty minutes your page does not render.
• A certificate on somebody else’s domain expires and the browser refuses to load their widget.

What all of these share is that your site reports no error. Nothing is in the log. The PHP ran fine. The page returned 200. From every angle the site is healthy — except in the browser of a person trying to find a church.

Why nobody notices

The developer has moved on. That is not negligence, it is what “the project is finished” means.

The client visits their own site less than you would think, and when they do, they go to the pages they are editing, not the map page they never touch. Nobody in the organisation is monitoring anything, because monitoring was not in the scope, was never quoted, and would have looked like padding if it had been.

And the visitors who hit the broken feature do not report it. They leave. That is the whole failure mode in one sentence: the people who discover the problem have no relationship with you and no reason to tell you.

Building so that failure is visible

You cannot prevent a third party from failing. You can control what your page does about it.

Every third-party feature needs a fallback that does the job. On a map, that means the underlying data — names, addresses, links — rendered as an ordinary list, present in the HTML whether or not the map script ever loads. Not a spinner. Not an apologetic message. The actual information, in a form that works. If the map dies, the page becomes a directory, and the visitor still finds the village they were looking for.

This has a pleasant side effect: that list is also what a search engine indexes and what a screen reader reads. Building the fallback first tends to improve the primary experience too.

Failures should be detectable from outside. A monitor that fetches the page and checks for an expected string — a congregation name, a price, a product code — catches this class of problem within the hour. Free tiers of uptime services do it. The check is trivial; the discipline of setting it up is what is missing.

Isolate the dependency. If the map provider must be replaced, that should touch one module, not fifteen templates. Talk to a small internal interface and let one adapter know how strange the outside world is. When the outside world changes, one file changes.

Set the limits deliberately. API keys should be restricted by referrer and by quota, and the billing account should have an alert on it. A key with no restrictions is a key that can be lifted from your page source and spent by somebody else — and the first you hear of it is the invoice.

The conversation nobody has at handover

Here is the part that is not technical.

When a project ends, both sides quietly assume somebody else owns what happens next. The client assumes the developer is watching. The developer assumes the client will call if something breaks. Neither is watching, and the thing that breaks is the thing neither of them looks at.

The fix is one document and one uncomfortable conversation. Write down every external service the site depends on: what it is, whose account it lives in, who pays for it, what happens if it stops, and who gets the alert. For the map that is Google Cloud, billing on the organisation’s card, alert to the organisation’s address, fallback list already in the page.

Then say the sentence out loud: after handover, nobody is monitoring this unless you arrange for somebody to. It is not a sales pitch for a retainer. Some clients will say fine, we accept the risk, and that is a legitimate answer — but it should be an answer, not an assumption.

Why I left it in the case study

I published this failure on my own portfolio, on the case study for that site, where potential clients read it.

That was deliberate. A portfolio where every project is in perfect condition is a portfolio assembled from screenshots taken on launch day. It tells you nothing about what the developer is like in month fourteen, which is the thing you are actually buying.

The fix here needs the billing account, and that belongs to the organisation rather than to me. So the honest version is: I know about it, I have written down what it needs, and it is visible rather than quietly hidden. That is a more useful thing for a prospective client to see than another green screenshot.

The general rule I take from it: a site is not a deliverable, it is a dependency graph with your name on it. Half of it is code you control. The other half is other people’s services, and those will change without asking you. Build the page so it survives them, and write down who is watching.