Building the software is half the job. The other half starts the moment real people are using it and you can no longer say “hang on, let me restart it.” Software in production has to run while you sleep, it has to survive when something breaks, and it must not leak the data people entrusted to it. This lesson is about how to pull that off without owning a server room or having a security department.

Where it all runs: cloud, VPS, or your own hardware

The first decision is where the software physically lives. You have three roads, essentially, and they differ in how much you pay in money, how much in your own labor, and how much control you keep.

Managed cloud (AWS, Google Cloud, Azure, or simpler platforms like Vercel, Railway, Fly). You rent a service, not a machine. The provider handles the hardware, system updates, and scaling. You pay more to run it, but almost nothing in hassle. For most projects, this is the sensible place to start.
VPS (a virtual server at Hetzner, DigitalOcean, and the like). You get a bare machine and do whatever you want with it. Cheap, full control, but updates, backups, and security are all on you. It makes sense when you have someone who knows how to keep an eye on it.
Your own server in-house. Full control and no monthly bill for compute. In exchange you’re dealing with power outages, air conditioning, internet, and the person who drives in at 2 a.m. on a Saturday to swap a dead drive. For a small company it’s almost always needless weight to carry.

The more control you take on, the more work lands on your plate. Your own server looks cheap on paper, right up until you count the hours you spend on it instead of on the business.

Start as simple as you can. You can always move from managed cloud to your own setup later, once cost or volume forces your hand. The reverse, where a small company builds its own infrastructure from day one, usually ends with the software running worse and costing more than it would on a rented service.

Deploying without drama: what CI/CD means in plain terms

Here’s the bad way to push a new version live: someone manually copies files over FTP one evening, forgets something, the site goes down, and nobody quite remembers what they changed. That’s what you want to avoid.

CI/CD is simply the automation of this boring, error-prone work. In two steps:

CI (continuous integration). Every time a developer changes something, the computer runs the tests on its own. If something breaks, you hear about it right away, not later from an annoyed customer.
CD (continuous deployment). When the tests pass, the new version ships by itself, the same way every time. No manual copying, no “well, it worked on my machine.”

The value isn’t that it’s trendy. It’s that deployment stops being an event you dread and turns into a routine you can handle on a Tuesday afternoon. And when something does fail anyway, you roll back to the previous version in one step, instead of hunting at midnight for whatever you overwrote.

A backup you’ve never restored isn’t a backup

Take this one literally, it’s the most expensive lesson in the whole industry. Plenty of companies live in the belief that they have backups, because someone set them up once upon a time. Then comes the day they need them, and they discover that a year’s worth of backups went into the void, or that a restore takes three days they don’t have.

Automate it. A backup that someone has to run by hand will, sooner or later, not get run. Set it up so it runs on its own, on a schedule.
Keep it elsewhere. A backup on the same server as the data is useless the moment the whole server goes down. It belongs somewhere else, ideally with a different provider.
And above all, test the restore. Every so often, take a backup and actually restore the data from it into a test environment. Only when that goes through do you know the backup really works.

The goal isn’t just to have a copy of the data. The goal is to know how long it takes to be back up and running after a disaster. Measure that number, don’t guess it.

Monitoring and logs: you want to know about a problem before your customer does

The worst way to find out about an outage is a phone call from a client who hasn’t been able to pay for the past hour. Monitoring is a cheap insurance policy against that situation.

Uptime checks. A service that periodically pokes your software to see if it responds, and if it doesn’t, sends you a text or an email. There are even free options, and you can set them up in a few minutes.
Error reporting. When something crashes in the app, you want to know about it, not wait for someone to report it. Tools like Sentry collect the errors and send them to you with detail on where they happened.
Logs. A record of what the software did. When something goes wrong, logs are often the only way to find out why. Having them is the difference between “we’ll fix it in an hour” and “we’ll guess all day.”

You don’t need to watch a hundred dashboards. It’s enough to know the software is running, and to be alerted when it stops or starts throwing errors.

Security basics without the panic

Security sounds like a topic for the paranoid and big corporations. The truth is that the overwhelming majority of disasters come from neglecting the absolute basics, not from some genius hacker. Cover these things and you’re safe from most trouble.

Keep things updated. An unpatched system and outdated libraries are like an unlocked door. A large share of attacks target known holes that have had a fix for ages, only nobody applied it.
Strong logins and two-factor. A password alone isn’t enough, especially for the admin. Two-factor authentication (2FA) stops even the case where someone’s password leaks.
Encryption in transit and at rest. HTTPS is a given today, don’t even start without it. Sensitive data in the database (passwords, absolutely) belongs encrypted, not readable.
The principle of least privilege. Every person and every part of the system should have access only to what it genuinely needs. Then when something does fail, the damage doesn’t spread across the whole system.
GDPR and personal data. Collect only the data you actually need, know where it lives, and be able to delete it on request. Less data means less risk and less worry.

You don’t need to be paranoid. You need the basics done and to know who’s watching them. That gets you further than expensive security audits over a system running software that hasn’t been updated since two years ago.

In the final lesson we’ll look at what all of this costs over the long run, how to plan for maintenance, and when it’s worth keeping the software growing rather than just letting it coast to a halt.