Why Reproducible Setups Make Websites Less Risky
When a developer's computer doesn't match the live server, bugs follow. How a scripted development environment prevents that and makes handover cheaper.
Most of the cost of running a website is invisible. The hosting bill is small. The big costs are the hours it takes to fix things when they go wrong — and a surprising amount of that time gets eaten by a single problem: differences between the developer's computer and the live website.
It sounds petty. It isn't.
The "works on my machine" problem
Every website needs a particular environment to run — a specific version of PHP or Node, a specific database, particular libraries. When the developer's laptop has slightly different versions to the production server, code that works perfectly in development can break the moment it goes live. Or worse, work for a week and then break when something updates.
This is the bug nobody wants to debug. It rarely produces clear error messages. It always burns hours.
The fix: matched environments
The cure is to make the development environment a near-perfect copy of the production environment. Same OS, same versions, same configuration. If the live server runs PHP 8.1, then development runs PHP 8.1 — exactly. No surprises.
The tool I use for this is Vagrant. It lets me run a small virtual machine on my laptop that matches the production server, configured automatically from a script. Every project I take on gets its own Vagrant environment. The script lives in the project's code repository, so any other developer who picks up the project — me in five years' time, or whoever takes over from me — gets the same environment with one command.
Why this matters to you, the owner
A few practical effects:
- Fewer launch-day bugs. Code that worked on the dev laptop usually works on the server too, because they're effectively the same machine.
- Cheaper handover. If you ever change developers, the new one doesn't spend a week guessing at your environment. They run one command and they're up and running.
- Disaster recovery. If your production server is wiped out, recreating the environment from scratch takes minutes rather than days. The script is the environment.
- Less wasted time — and therefore less wasted money, since debugging "works on my machine" issues is something you'd otherwise be paying a developer to do.
What to ask your developer
If you've already got someone maintaining your site, two useful questions:
- "Is the development environment scripted, or is it just installed on your laptop?" The first answer is what you want.
- "If your laptop got stolen tomorrow, how long would it take to set up a replacement and continue working on my site?" A good answer is "a few hours". A worrying answer is "weeks".
The bottom line
Reproducible environments aren't glamorous, and your customers will never see them. But they're the difference between a website that's predictable to maintain and one that surprises you with new bugs every few months.
Get in touch if you want to know how your current site is set up, or how to make your project less dependent on one specific developer's laptop.
Get in touch
Have a project in mind?
Get in touch and let's talk about what your business needs online.
Let's talk about your project.
Ready to get started? I'd love to hear about your business and what you're looking to achieve online.