PayGlue sits between your payment provider and your Ghost site. Somebody pays, PayGlue hears about it, your member gets access. That means every change I make to the software lands on your site, whether you asked for it or not.
In July I built a way to avoid that. In August I discovered I had stopped using it eight weeks earlier.
What I built, and why
By July the product was live and somebody was paying for it. Every change I finished went straight to that person’s site the moment it was ready, with nothing in between.
So I built the step in between: a complete second copy of PayGlue, with its own database and its own everything. A rehearsal stage. Try the change there, watch it work, and only then touch the real thing. That part took an afternoon.
The danger was not where I was looking
Before I started, the thing that worried me was the database. Point the test copy at the real database by accident and you could damage real data.
That turned out to be the one thing that could not happen. The hosting keeps the two copies on separate private networks, so the test copy cannot reach the real database no matter what you type into it.
The actual risk was somewhere I had not thought about: the service that manages logins. That service lives outside the hosting and has no idea that one of the copies is only a rehearsal. If I had let the test copy use the real login service, then the first time I tested the “delete my account” button, it would have deleted a real person’s account.
That generalises past my particular setup. Your hosting protects what sits inside it, and every outside service you connect to is on the other side of that line. A key copied from the real system works on the real system, wherever you paste it.
The wizard that would have changed the live system
There is a hosting tool I use that offers a helpful setup wizard. Click through it and it wires everything up for you.
What it wires up would have pushed every change I made, including the half-finished ones, straight onto the live system, which is the exact opposite of what I was building. I caught it because I read the command before accepting it, which is a thin reason to catch anything. So the warning now sits in the file where that mistake would be made, one line above the relevant section, rather than in a document nobody would think to open at that moment.
Start empty, not copied
The convenient way to create a second copy is to duplicate the first one and then correct the settings that should differ. I started from nothing instead and filled in each setting by hand.
The difference is not how careful you are, because both ways involve missing something. If you duplicate and miss one, that setting still points at the real system and nothing tells you. If you start empty and miss one, the setting is simply absent and nothing starts, which you find out in under a minute. It is worth more to change which way a mistake falls than to promise yourself you will be careful.
Why test emails are more dangerous than they look
The test copy runs the same nightly jobs as the real one, over invented accounts with invented email addresses. If those emails actually went out, every one of them would bounce, and enough bounces make mail providers treat your whole domain as suspect. The damage does not show up that week. It shows up months later, when a real welcome email to a real customer lands in spam.
So the test copy rewrites every recipient to a single internal address before anything is sent, including the copy lines that people forget about. As it happens, today it does not even get that far, because it writes emails to a log file instead of sending them. I keep the redirect anyway, since that arrangement is exactly the kind of thing that quietly changes.
The two settings nobody looked at again
That is all about building it. When I rebuilt the whole thing in August, I found something less comfortable.
Every hard wall had held. Database, cache and logins were still properly separate, two months on. What had gone wrong were two ordinary settings, typed in once by hand and never read again.
One of them held the web address of the app, and on the test copy it pointed at the real app, with a stray space in front of it. The other held the list of addresses a payment checkout is allowed to send a customer back to, and it had been copied from the real system word for word. Those two together decide where a customer lands after paying, so on the test copy the real app was an allowed destination and the test app was not. A test purchase could not find its way home.
Nothing failed loudly about any of this. Everything reported healthy the entire time.
The copy nobody used
I had written down how I would work: build the change, try it on the copy, then release it. What I actually did was release it, for two months.
When I opened the test copy in August, the last change on it was from 26 July, and the real system had moved 88 changes past it. It had been sitting there the whole time, running, healthy, costing money and verifying nothing. Nobody noticed, because there was nothing to notice. Nothing had broken and nothing had complained.
At the end of the rebuild I sent one deliberately marked request through the test copy and read both systems’ logs. It appears in the test log, and in the real system, at that moment, there is nothing at all. That check took two minutes, and without it everything in this section would be an assumption rather than a fact.
What I changed
On the day I built it, the automated checks caught three of my own mistakes before they could reach anybody. For this kind of work there is no equivalent, because no automated check catches a helpful setup wizard or a pasted key. So I built the copy to make carelessness harmless rather than relying on being careful. That part worked. The habit did not.
A safety net catches nobody if you walk around it, and a written rule you do not follow is worse than admitting you go direct, because the rule lets you say “that was tested first” and sound like you mean it.
So the rule got smaller and more honest. Most changes now go straight to the real system after review, and what goes through the copy first is the category that is genuinely hard to undo: anything that changes how data is stored, and anything touching logins, payments or the underlying plumbing. It is a weaker rule, and it is one I will still be following in October, which the previous one was not.
Why I am telling you this
You are handing PayGlue the connection between your members and their money, so you are entitled to know how carefully that gets handled, including on the days it was not handled carefully enough.
Everybody building software gets things wrong. What you can judge me on is whether I notice, whether I say so, and whether anything changes afterwards.
What changed here is small and boring: a calendar entry, eight weeks out, asking whether I am still doing what I said I would do. That is the part I skipped in July.