Software Maintenance and Support: SLA and When to Hire

Software support and maintenance, which we call "sustentação" in Brazil, is the ongoing work of keeping a digital product running, secure and up to date after it goes live. When the project ends and the team leaves, the software still needs care: dependencies get old, servers need fixes, users find problems and the business asks for small changes. Without someone responsible, the product ages fast.

In this guide you will see what software support is, what it includes, how an SLA works, when to hire it and how to keep your system from becoming a legacy that is hard to touch.

What is software support?

It is the recurring service that takes care of the product in production. The support team monitors, fixes, updates and makes small improvements, with a team that knows the code. The idea is that the product does not depend on the memory of a single person nor sit idle until the next big overhaul.

Support is not the same as a new development project. A project builds something new, with a start and an end. Support maintains what already exists and responds to what happens day to day.

What is the difference between support, maintenance and helpdesk?

The terms get mixed up, but they help organize the conversation:

• Helpdesk: assists the user and helps solve questions and usage problems. It is the front door.
• Corrective maintenance: fixes defects found in the system.
• Preventive maintenance: updates dependencies, applies security patches and adjusts infrastructure before something breaks.
• Evolutionary maintenance: makes small improvements and adds new features.
• Software support (sustentação): brings all of this under one team and one agreement, with monitoring and clear responsibility.

What does software support include?

The scope varies, but a well-built service covers four fronts:

• Security updates. Fixing known flaws in libraries, operating systems and servers.
• Monitoring and alerts. Watching what is live, with a warning when something departs from normal, before users notice.
• Fixes and small improvements. Handling defects and improvements that fit the contracted volume.
• Periodic report. What was done, what was found and what needs a decision.

In many cases it also includes tracking backups, reviewing infrastructure costs, updating documentation and helping with incidents.

What is an SLA and how does it work in support?

An SLA (service level agreement) is the written commitment about how the team responds when something happens. A good SLA defines:

• Severity. What is critical (system down), what is important (a main function failing) and what is minor (a visual adjustment).
• First response time. How quickly someone acknowledges the ticket.
• Resolution or workaround time. How quickly the problem is solved or worked around, by severity.
• Service window. On which days and hours the team is available.
• Channels. Where the ticket is opened and how progress is communicated.
• Measurement. How compliance with the agreement is tracked and reported.

Be wary of a generic SLA that promises speed without defining what is critical. And remember that the SLA depends on the system being minimally documented and monitored. Without that, the team takes longer to understand the problem than to fix it.

When should you hire software support?

A few signs indicate the time has come:

1. The product is live and nobody takes care of it. Whoever built it has moved on to another project.
2. Dependencies and servers are out of date. Each month without updates raises security risk and the difficulty of updating later.
3. Small improvements sit in the queue. The internal team can only handle what is urgent.
4. Problems depend on a single person. If that person leaves, nobody knows how the system works.
5. The system was built by third parties or with the help of AI. Knowledge about the code needs to be rebuilt. See what to review in auditing an AI-built app.
6. The business depends on the system to sell or operate. An outage has a direct cost.

How does support keep a system from becoming legacy?

A legacy system is old software that still runs the operation but that nobody can change without fear. It almost never starts out bad: it ends up that way for lack of continuous care. The guide to legacy systems details the signs and the modernization paths.

Support avoids this fate because it:

• Keeps dependencies current, reducing the cost of each update.
• Preserves knowledge, with documentation and a team that follows the code.
• Fixes small debts before they pile up into a big overhaul.
• Measures and alerts, showing what is degrading before it becomes a crisis.
• Supports evolution, with software architecture decisions reviewed as the product grows.

How do you choose a support vendor?

Ask:

• Will the team get to know my code, or will each ticket be handled by a different person?
• How are tickets classified and what is the SLA by severity?
• Is there active monitoring, or does the team only act when I warn them?
• How does the hours package work and what happens when it runs out?
• Who is the technical lead and how is communication handled?
• Do the code, the access and the documentation stay with me?
• How is security handled, including updates and access review?

Vendors who built the system tend to have an advantage, but well-run support can also take over a product built by third parties, after a phase of understanding the code.

Examples of support in practice

A few UEEK projects show the kind of care that continues after launch:

• Wellu: after migrating a platform built with AI to its own infrastructure, the product keeps evolving with code review and separate environments. See the case.
• Bom Controle: the app was delivered with documentation and versioning designed so the internal team could take over maintenance. See the case.
• DairyTech: the app that reads the milk test through the phone camera has been evolving continuously since launch. See the case.

Frequently asked questions

Is software support mandatory?

It is not mandatory, but it is good practice for any product that runs an operation. Without it, security and downtime risks grow over time.

What is the difference between support and a development squad?

Support maintains the existing product, in a recurring package of hours. A development squad is a dedicated team to build and evolve continuously, with greater delivery capacity.

Does support include new features?

It includes small improvements within the contracted volume. Larger new features are usually handled as a project or through a squad.

Does support work for a system built by another company?

Yes, as long as there is access to the code and an initial phase to understand the architecture, map risks and document what is missing.

How does the SLA work in an hours package?

The SLA defines response time by severity, and the package defines the volume of work available per month. Both must be described in the agreement, together with what happens when the volume is exceeded.

When does a system need modernization and not only support?

When maintenance costs more and more, changes become a risk and the technology is no longer supported. In that case, support buys time while the modernization is planned.

How UEEK can help

UEEK has worked for 14 years with digital products, for more than 200 clients, in 6 countries, on more than 500 projects. In support, we take care of the product after launch, with security updates, monitoring, fixes, small improvements and a monthly report, in monthly packages of hours with a team that knows your code. If you do not yet have a technical lead to decide priorities, UEEK as your CTO can support those decisions.

Talk to UEEK about supporting your product