After launch, custom software needs four jobs done: fixing bugs, updating the code when its frameworks and outside services change, running hosting and monitoring, and making small changes users ask for. Three main groups can own that work: the firm that built it, your own team, or a new firm that takes it over.
That choice can outlast the build. A build has an end date. Maintenance runs as long as the business uses the system.
We are The Gnar Company, and we fill more than one of these roles: we build, we stay on to maintain, and we take over code from other firms. Read our parts with that in mind. Gnar's application maintenance and support offer, as it reads on our maintenance page: Hosting, monitoring, support, and the same person who built it. From $1,000 a month.
This guide is for the COO whose build team is leaving, or already left, and who needs the system kept running. It covers what the work is, why software needs it, who can own it, and what to have in hand so you can change your mind later.
What does application maintenance and support cover?#
Application maintenance and support covers the work that keeps live software useful after launch. Maintenance changes the code: bug fixes, updates and small improvements. Support keeps the running system healthy: hosting, monitoring and help when something goes wrong. A custom system needs both.
Here are the four jobs, in plain terms:
- Fix bugs. Something does not work the way it should, and someone changes the code so it does.
- Keep the code current. The frameworks, libraries and outside services the software depends on change on their own schedule. Someone updates the code to match.
- Run hosting and monitoring. The software lives on servers. Someone pays for them, watches them and gets an alert when they fail.
- Make small changes. A new field on a form, a new report, a change to a rule. Users will ask for these as long as they use the system.
The international standard for software maintenance, ISO/IEC/IEEE 14764:2022, gives guidance for maintaining software and defines the types of maintenance. It leaves out the operation of software, such as backup, recovery and system administration. Because the standard puts backup and recovery under operations, a contract written only in maintenance terms can leave them out. Check that yours names maintenance and operations, including backup and recovery.
Gnar's maintenance page has a card for each of these four jobs. Two of them read: when your API changes or a dependency breaks, the team that built your app fixes it. New requests from your team become small updates, built by the people who built the app.
Why does working software need maintenance?#
Working software needs maintenance because the pieces it is built on stop getting fixes on a schedule. A system nobody touches still runs on frameworks that reach end of life. When that happens, new security holes in them stay open unless someone updates the code.
Two common examples, from the projects' own pages:
| Framework | How long a version gets fixes | A date to know |
|---|---|---|
| Ruby on Rails | Bug fixes for one year and security fixes for two years after a minor version first ships | Rails lists security support for its 8.1 series until October 10, 2027 |
| Node.js | Long-term support versions typically get critical bug fixes for a total of 30 months | Node.js 20, first released April 17, 2023, is now marked end of life |
Rails states the consequence plainly in its maintenance policy: when a release series is no longer supported, it is your own responsibility to deal with bugs and security issues. The Node.js release page says production applications should only use its long-term support versions.
So a system launched on a supported version has a clock on it from the first day. The work to keep up is usually small if it happens on time. It is large when a team skips a few years and has to jump several versions at once.
Outside services move too. A payment provider, a shipping carrier or an ERP vendor can change how its API works.
Who can maintain custom software after launch?#
Three main groups can maintain custom software after launch: the firm that built it, your own engineers, or a new firm that takes the code over. Each one works. The right one depends on who knows the code, who has time for it, and how much the system will change.
| The firm that built it | Your own team | A new firm | |
|---|---|---|---|
| Knows the code on day one | Yes | Only if they helped build it or learned it in a planned handover | No; it needs time to learn it |
| Best when | The system will keep changing and you have no engineers | You have engineers with time and the system is core to the business | The builder is gone or no longer a fit |
| What it costs you | A monthly fee | Salaries and the time those engineers spend | A monthly fee, plus a ramp-up period |
| Main risk | Depending on one vendor | The work loses out to other projects | Mistakes while the new team learns the code |
| What protects you | Code, hosting and credentials in your accounts | Documentation and a clean handover | A code audit before they take it on |
Freelancers are also an option for small systems, though not one of the three main owners above. For a system that runs orders, billing or shipping, one person is a single point of failure. If that person is sick or leaves, nobody else knows the code.
When should the firm that built it keep it?#
Keep the firm that built it when the system will keep changing and you do not have engineers who can own it. The builder already knows why each decision was made. It can fix problems and make small changes without the ramp-up a new team needs.
It is a sensible choice for the first year or two after launch. Users find the gaps in the first months. Requests pile up. The team that wrote the code handles them with the least ramp-up.
The risk is lock-in. A builder that holds your code in its own account, or runs your hosting under its own name, makes leaving hard. Owning the code and the accounts is what avoids it. More on that in the handover checklist below.
At Gnar, staying on is optional. You can transition to your internal team with our support, or keep us on through Maintain, our optional monthly support retainer.
When should your own team take it over?#
Move maintenance to your own team when you have engineers with time for it and the system is core to how you compete. Owning it in house costs salaries and attention. It pays off when the system will change every month for years and the business depends on those changes.
The handover is the hard part. Your engineers need the code, the reasons behind it, and enough time with the people who wrote it to ask questions.
Two patterns work well:
- A planned handover. The builder documents the system and stays available for questions while your team takes on more of the work. On Gnar's maintenance page, this option reads: your team takes over the codebase, in your repository and documented for hand-off, with our support.
- Mixed teams for a while. The builder's engineers work inside your team for a period, so knowledge moves by working side by side. Separately, Gnar's Embed puts senior US engineers directly in your team, on a time-and-materials basis.
Start the handover months before the builder leaves.
What should the handover include?#
The handover should give you everything a new team needs to run, change and deploy the software without calling the old one. If any item below sits in the builder's account and not yours, fix that first, while the relationship is good.
The law firm Story LLP lists the core items in its August 25, 2026 guide to agency warranty and support terms: require delivery of documentation, build scripts, credentials and architecture diagrams at project close. It notes that agency contracts often do not address this at all.
A practical checklist:
- The code, in a repository your company owns, with full history.
- Written documentation of how the system works and why key choices were made.
- Build and deploy scripts, so someone new can ship a change.
- Credentials, moved into your company's own password vault.
- Architecture diagrams that show the parts and how data moves between them.
- Hosting accounts in your company's name, with billing on your card.
- Outside service accounts (payments, email, maps, the ERP connection) in your company's name.
- A list of open bugs and planned changes, so nothing is lost in the move.
For a system the business cannot run without, Story LLP also describes source code escrow. The firm deposits the source code, documentation, database schemas and build scripts with a neutral agent. The agent releases them to you when a trigger event named in the contract happens. Story LLP gives the firm's bankruptcy, a sustained failure to provide agreed support, or dissolution of the company as examples.
Can a new firm take over code another firm wrote?#
Yes, a new firm can take over code another firm wrote, if it reads the code first and takes ownership in steps. A rushed takeover is where systems break. The new team changes something it does not yet understand, and a part nobody mapped stops working.
We did this for the AARP Foundation's Property Tax-Aide tools, which help older adults with property tax relief. Our case study describes Phase 1 as the phase where we took ownership of the codebase from the previous firm, stabilized the current tools so they could be used securely, and gathered requirements for the rebuild. After the replatform, Gnar maintained and updated the tools for every subsequent tax year and built new tools for additional states.
Before any takeover, have someone read the code. Gnar's free source code audit works like this: after we sign a non-disclosure agreement, senior engineers in the U.S. tell you in plain English whether to keep the code, fix it or rebuild it, with the worst problems first. The audit can come back saying your code is in reasonable shape. You can use the findings with Gnar or without.
The state of the code decides how long a takeover takes. A clean codebase with tests moves faster. A codebase with no tests and no documentation takes longer, because the new team has to learn it by reading every part.
How do warranty fixes and maintenance work fit together?#
Warranty fixes and maintenance cover different problems, and a good contract keeps them apart. A warranty is the builder's promise to fix its own mistakes for a set time after delivery. Maintenance is paid work for everything else: updates, hosting, monitoring and changes.
At Gnar, the split is written on the maintenance page. After launch there are two kinds of work: fixes under the warranty, and everything else under Maintain. The 12-month warranty obligates us to fix non-conforming code, independent of any ongoing contract.
That last part matters when you choose an owner. If you move maintenance to your own team in month four, the warranty on the code we delivered does not end with the support contract.
Gnar's guarantee, word for word: Three commitments on every build engagement: a fixed milestone price with any overage on us, a guaranteed outcome meaning the software works as specified or we fix it, and a twelve-month bug-free warranty. It covers Discovery, Build, Forge and Maintain. It does not cover Embed. On Compass, Immerse and Integrate, ask us.
What does application maintenance cost?#
Gnar's Maintain starts at $1,000 a month for hosting, monitoring, support and a standing relationship with the person who built your app. How often the system changes, how much it does, and whether hosting and monitoring are included all affect what any maintenance plan costs.
One way to buy maintenance is a retainer. Story LLP describes the retainer model this way: a monthly engagement where you pay a fixed fee for ongoing access to the development team, covering maintenance, bug fixes, infrastructure improvements and, in some cases, feature development.
What to compare across proposals:
- What the monthly fee includes. Hosting, monitoring, framework updates and small changes, or only some of them.
- How unused time is handled. Whether hours roll over or expire.
- How bigger work is priced. A new module should get its own quote.
- Who does the work. The people who built the system, or a separate support desk.
What Gnar publishes: on our custom software page, Maintain is described as a pre-negotiated monthly bucket of time for improvements, upgrades, and ongoing support. Optional, never required. A Gnar Forge project, our fixed-price build for internal tools, includes a month of maintenance after deployment.
How Gnar kept Fitbit Plus running while Fitbit built its replacement#
Gnar kept Fitbit Plus running by maintaining and enhancing the legacy application, which let Fitbit's internal team focus on the new platform. Sometimes the right owner for an old system is an outside team, because your own engineers are busy building the new one.
Fitbit's legacy health coaching platform, Fitbit Plus, came from an acquisition, and Fitbit needed to build the next generation of it, tied more closely to the rest of Fitbit. In the case study, our engineers worked on site at Fitbit's Boston office several times a week, ran detailed code audits, and solved problems with Fitbit's team as they came up.
The case study reports the result: Fitbit moved hundreds of thousands of existing Fitbit Plus clients to the new platform while continuing to meet all client commitments and service-level agreements.
The lesson for a COO is about timing. Maintenance on the old system cannot stop while the new one is built. Somebody has to own both, and they compete for the same engineers unless you split the work.
What should you ask a maintenance provider?#
Ask each maintenance provider the same questions, in writing, before you sign. The answers show who will do the work, how fast they respond, and how easy it is to leave. Put the answers side by side. For software Gnar built, Gnar's answer to the first question below is the team that built your app: it fixes what breaks and makes the small updates.
- Who will work on our system, and did they build it or will they learn it?
- What does the monthly fee include: hosting, monitoring, updates, small changes?
- How do you keep frameworks and libraries on supported versions, and how often?
- How fast do you respond to an outage, a serious bug and a minor one?
- Is the code in our repository and are the hosting accounts in our name?
- What happens to unused hours?
- If we leave, what do you hand over, and how long do you stay available for questions?
Keep the written answers with the contract.
