Who takes care of your project after delivery?
Website maintenance goes beyond fixing bugs: security, backups, domain and speed. See 7 essentials and a 5-step plan for your website.
Website maintenance after delivery: what happens when nobody is watching, and how to choose who will watch for you.
The new website goes live, the team celebrates and the contract with the developer comes to an end. Three months later, a form stops sending messages. Six months later, the browser shows a “not secure” warning. A year later, the domain expires and the page simply disappears.
None of these problems is rare, and none of them is the website’s fault. A website or system is not a product you buy ready-made and put away in a drawer. It is more like a car: it runs beautifully when it leaves the dealership, but it needs servicing, replacement parts and someone who notices the strange noise before it becomes a serious problem.
The question almost nobody asks when hiring is precisely the most important one: who takes care of your project after delivery? In this article you will learn what changes once your project goes live, which kinds of care cannot be skipped and how to organize all of it without needing to understand programming.
Who is involved after the website goes live
Even a simple website depends on several moving parts. It is worth knowing each one before deciding who looks after them:
- Your company: owner of the website, the brand and the customer data that passes through it.
- The developer: knows the code inside out, but usually leaves the picture when the project contract ends.
- The hosting provider: the “plot of land” where the website lives. It keeps the server running, but generally does not touch your website.
- The domain: the address (yourwebsite.com), which must be renewed periodically.
- Plugins, libraries and third-party services: forms, payments, maps, analytics tools. Each one is updated by another company, at its own pace.
- Browsers and search engines: Chrome, Safari and Google change their rules often, and the website has to keep up.
The problem shows up in the gaps between these parts. The hosting provider thinks the website is the developer’s responsibility. The developer thinks the contract is over. And the company thinks that if nothing is broken, everything is fine. When everyone assumes someone is taking care of it, in practice nobody is.
1. Security and dependency updates
What it is: every project uses ready-made parts (systems, plugins, libraries). When someone discovers a flaw in one of these parts, the vendor publishes a fix. Updating means installing that fix.
Why it matters: a known flaw is like a lock whose combination has been posted online. Patchstack, a company specializing in WordPress security, recorded 7,966 new vulnerabilities in 2024 in the WordPress ecosystem, about 22 a day, and 96% of them were in plugins. In Sucuri’s 2023 report, 39.1% of the hacked content management systems were out of date at the time of cleanup.
It is not just WordPress. Every website, even a custom-built one, sits on top of dependencies: the language it runs on (such as PHP or Node.js), the framework, and dozens of open-source libraries that handle tasks like forms, images or payments. Each one receives security patches, small fixes published when a flaw is discovered. Think of them as car recalls: the manufacturer found the defect and the fix exists, but it only helps those who take the car to the shop.
On top of that, these parts have an expiration date. PHP, for example, gives each version two years of full support plus two more years of critical security fixes only. After that, new flaws are no longer fixed. A website that never upgrades ends up, little by little, running on parts nobody repairs anymore.
In practice, looking after dependencies involves three routines:
- Apply security patches as soon as they are released, prioritizing severe flaws.
- Use tools that alert you when a library in the project has a known flaw (many code hosting services do this automatically).
- Plan the larger upgrades, such as moving to a new version of the language or framework before support ends, with testing before going live.
Practical example: XPTO Company installed a form plugin in 2023 and never updated it again. In 2025 a flaw in that plugin was disclosed. With nobody keeping an eye on it, the website started redirecting visitors to gambling pages.
Be realistic: the figures above come from the WordPress ecosystem, the most widely used in the world. Websites built with other technologies face the same risks from outdated dependencies, but these specific figures do not apply to them directly. Updating also carries risk: an update can break another part of the website. That is why it should be done with a backup and testing, not on impulse.
2. Backups that actually work
What it is: a copy of the website and its data stored somewhere else, ready to be restored.
Why it matters: a backup is what turns a disaster into a setback. The US Cybersecurity and Infrastructure Security Agency (CISA) recommends the 3-2-1 rule: three copies of important files, on two types of storage, with one of them away from the main location. The same guidance asks for something almost nobody does: test the restore periodically.
Practical example: XPTO’s hosting provider made automatic backups, but kept the copies on the same server. When the server failed, the website and the backups went down together.
Ask whoever looks after your website: “When was the last time you restored a backup to test it?” If the answer is “never”, you have a hope, not a backup.
3. Domain, hosting and certificate up to date
What it is: the domain is the website’s address; the hosting is where it lives; the security certificate (SSL/TLS) is the padlock shown in the browser.
Why it matters: all three expire. An expired domain that is not renewed is suspended and, if it remains unpaid, can be released for someone else to register. In Brazil, for example, a .br domain is first frozen by Registro.br. The certificate, meanwhile, will expire faster and faster: the CA/Browser Forum, the group that sets the rules for these certificates, approved reducing the maximum validity from 398 days to 200 days starting March 15, 2026, 100 days in 2027 and 47 days in 2029. In other words, renewing by hand is no longer viable; it has to be automatic and monitored.
Practical example: XPTO’s domain was registered in the name of a former employee, with that person’s email on file. The expiration notices went to an inbox nobody read anymore.
4. Monitoring: knowing before your customer does
What it is: tools that check the website all the time and alert you when it goes down, slows down or a form stops working.
Why it matters: without monitoring, the person who discovers the problem is your customer, usually at the worst possible moment. A broken contact form shows no error on screen; it simply stops delivering messages, and you only notice when quote requests dry up.
Practical example: a simple monitor checks the home page every few minutes and sends an alert by WhatsApp or email to the person in charge. A monthly test submission of the form closes the gap the monitor cannot see.
5. Performance and experience on Google
What it is: how fast the website loads and responds, especially on mobile.
Why it matters: Google measures user experience with the Core Web Vitals. To be considered good, a page needs to show its main content within 2.5 seconds (LCP), respond to a tap within 200 milliseconds (INP) and not “jump around” on screen (CLS of up to 0.1), across 75% of visits. A website that is fast at launch becomes slow over time: heavy images added day to day, new marketing scripts, piled-up plugins.
Practical example: XPTO’s team published 8 MB photos straight from their phones to the blog. The website, which used to be fast, became slow on mobile data.
Be realistic: speed is one of the signals Google considers, but on its own it does not guarantee a better position in search. Relevant content still carries more weight.
6. Access and ownership: the website must be yours
What it is: knowing who holds the passwords and in whose name the domain, hosting, code and service accounts (Google Analytics, Search Console, email) are registered.
Why it matters: it is common to discover, when switching providers, that everything is in someone else’s name. Without access, any maintenance becomes a negotiation.
Practical example: a simple document, kept in the company’s password manager, listing each service, its holder, the registered email and the expiration date. Whoever looks after the website gets collaborator access, not owner access.
7. Evolution: the website keeps pace with the business
What it is: ongoing adjustments and improvements: new pages, a newly launched service, a campaign, an integration with the CRM.
Why it matters: the business changes and the website needs to reflect that. A website that does not evolve ages and, sooner or later, becomes a full rebuild project, far more expensive than small improvements over time.
Practical example: instead of rebuilding the website every three years, XPTO sets aside a few hours a month for improvements prioritized from traffic data and requests from the sales team.
Action plan: 5 steps to keep your website from being orphaned
- Take inventory of your access. List domain, hosting, code, email and Google accounts, with holder, registered email and expiration date. Anything not in the company’s name goes on the to-do list.
- Name someone responsible. It can be someone on the team, the developer or a company that offers specialized maintenance and ongoing support services. What matters is that there is a name, not a “somebody”.
- Define what maintenance covers, in writing. Updates, backups with restore tests, monitoring, renewals, response time for problems and how many hours of improvements per month.
- Turn on monitoring and alerts. Website availability, domain and certificate expiration, and a periodic test of the forms.
- Schedule a quarterly review. Half an hour to look at the update report, the website’s speed, the contacts received and the improvements for the next round.
Conclusion
Delivering a website is not the finish line; it is the starting line. Companies that treat their website as a living asset, with someone responsible for it, avoid nasty surprises, spend less on rebuilds and turn the website into a channel that gets better over time.
The good news is that you do not need to understand programming for this. You just need to ask the right question before the problem asks it for you: who takes care of your project after delivery?
If the answer is not clear yet, UON can help. Talk to us and together we will work out what your website needs to stay secure, fast and working for your business.
References
- Patchstack. State of WordPress Security in 2025. Updated March 14, 2025.
- Sucuri. 2023 Hacked Website & Malware Threat Report. June 2024.
- DigiCert. TLS Certificate Lifetimes Will Officially Reduce to 47 Days. May 16, 2025.
- CISA. Back Up Business Data. Undated page; accessed November 5, 2026.
- Google, web.dev. How the Core Web Vitals metrics thresholds were defined. Updated May 7, 2025.
- PHP. Supported Versions. Accessed November 11, 2026.
Ready to turn your idea into an efficient digital solution?
Get in touch and request a personalized quote for your project.
Contact us