You commissioned a custom system. It was up and running, your team uses it every day, and the problem that prompted it was solved. Three months later, on a Saturday morning, no one can log in. The server disk filled up, the security certificate expired, or the database stopped responding. That is when the question nobody asked in the kickoff meeting comes up: who keeps the server alive.
Development is not maintenance
Development has a clear end. One day the system is up and running, it is delivered, and it gets billed. Maintenance has no end: it is the routine of keeping that system running. They are two different jobs, with two different prices and often two different people responsible.
When you commission a custom system, you are not buying a file saved in a folder. You are buying a program that lives on a server, which is a computer turned on all day in a data center. That computer has an operating system, a database, a security certificate, a domain, and several programs that talk to each other. Any of those pieces can fail on its own.
When someone says “maintain the server,” they are talking about all of this:
- The server: the machine where the system runs.
- The database: where your customers, orders, inventory, and invoices live.
- Backups: copies that run on their own and that one day need to be tested.
- The domain and DNS: the address your customers use to reach you.
- The SSL certificate: the padlock that keeps the browser from marking your site as insecure.
- Transactional email: the confirmations and notifications the system sends.
- Security updates: patches for the operating system and the libraries your application uses.
- Monitoring: what alerts you when something goes down.
None of those pieces warns you before it breaks. The server does not send a letter.
What breaks when no one is watching
| Piece | What happens if no one looks after it | What your business experiences |
|---|---|---|
| SSL certificate | Expires without warning | The browser marks the site as insecure and the customer hesitates before entering |
| Server disk | Fills up with logs and temporary files | The system stops saving and orders stop coming in |
| Backups | They are created, but no one tested restoring them | When you need to go back, the backup is incomplete |
| Operating system and libraries | They go without patches | A public, known vulnerability remains open |
| Domain | The annual payment expires | The system still exists, but no one can find it |
| Transactional email | A key changes or the provider fails | Customers stop receiving confirmations |
Why it is a business problem and not just a technical one
A system that is down is not a nuisance for programmers. It is a hardware store that cannot bill, a clinic that cannot schedule, a real estate agency that cannot list a new property on a Sunday. Every hour the system is down, someone on your team improvises with paper, WhatsApp, or Excel, and the work gets done twice.
The real problem is almost never the outage. The problem is not knowing who to write to when it happens. If there is no name, email, and phone number in an agreement, the outage turns into an argument about whose responsibility it was.
The four maintenance models
| Model | Who responds | When it makes sense |
|---|---|---|
| You maintain it | You or someone on your team | If you have your own technical staff and want full control |
| The studio that built it | The same provider, under a monthly plan | It is the simplest: they know the system and already have access |
| A third party | Another company or a freelancer | Useful if the original provider is no longer available |
| Managed platform | The cloud provider maintains the infrastructure; someone maintains your application | It reduces the pieces you have to look after, but it does not remove the need for an owner |
In all four cases there is one element you cannot skip: someone with a first and last name, in writing, who responds.
If your system is not custom-built but a monthly license from an external provider, the problem changes shape. We cover that case in what happens to your data if you stop paying the license.
Access credentials and the domain must be in your name
This is the point that costs the most when ignored. The domain, the hosting account, the code repository, and the email should be registered under your company’s name, not the provider’s. You can give the provider access; they should not be the owner.
If tomorrow you decide to switch providers, recovering a domain registered under someone else’s name can take weeks. And in the worst case, it does not get recovered.
What should be in writing
A maintenance agreement does not need twenty pages. It needs to answer these questions:
- Who maintains it and how many hours a month they spend reviewing the system.
- What the monthly maintenance includes. A new feature is not maintenance, it is separate development and is quoted separately.
- What happens when something goes down: where it is reported, during what hours, and how long until a response.
- How to access the server, the domain, and the database.
- What happens if you stop paying for maintenance.
- How the relationship ends and how you take the system to another provider.
How to know if you are exposed today
Answer these six questions honestly:
- Do you know which provider hosts your system?
- Do you have the keys to the domain and hosting?
- Do you know when the last backup was and whether anyone ever restored it to test it?
- Do you know when the security certificate expires?
- Do you have a number to write to if the system goes down on a Saturday?
- Do you know how much you pay per month for all of this?
If you hesitate on two or more, you do not have a technical problem. You have a continuity problem that has not cost you money yet.
What a healthy maintenance plan looks like
You do not need someone watching the server every day. You need the server to alert on its own and for there to be a responsible person who reads those alerts.
A reasonable plan includes:
- Monitoring with alerts: site outages, disk filling up, server errors, failed backups, and certificates nearing expiration.
- Daily automatic backup, with a restore test every quarter.
- Security patches applied in an agreed maintenance window.
- A support channel with defined hours and a clear owner.
- A simple report: what was reviewed, what was found, and what was fixed.
The difference between this and having nothing is that the alert arrives before the unhappy customer.
Where the server lives matters
In Venezuela, this is not a detail. If the system runs on a computer inside your premises, any power outage or internet outage leaves your team unable to work, and no one outside can get in even if they want to. If the system lives in the cloud, your premises can lose power and the system remains available from a phone with data.
The second thing is who pays for that server. If the provider pays for it as part of a package, ask what happens to that account if the relationship ends.
Final thoughts
The question is not whether your system will go down. It will go down at some point, like anything that depends on electricity, connectivity, and software. The useful question is different: when it goes down, do you already know who to write to, and does that person already know they are the one who has to respond?
That is decided before delivery, not during the outage.