The article
Software ages even when nobody touches it. The code that worked last year still calls libraries that keep releasing new versions, runs on systems that keep updating and talks to services like Stripe, Twilio or Auth0 that retire old versions of their APIs. Sooner or later something breaks, often after the people who wrote the code have moved on.
Our software maintenance services keep web platforms, mobile apps and internal tools working: we fix what breaks, update what has aged and answer questions about the code, whoever wrote it. I have been building software for 18 years, and this article is as much a checklist for you as a description of what we do.
Software maintenance in short
| Question | Answer |
|---|---|
| What we maintain | Web platforms, mobile apps and internal tools, whoever wrote them |
| What is included | Fixes; updates of frameworks, libraries and systems; integrations reworked when outside services change; answers from the engineers who know the code |
| How it starts | Access, a review of the code and the setup, a plan with a monthly price, a contract |
| Price | A monthly price set after the review, before any contract; the first call and the rough estimate are free |
| New features | From the same team, each estimated before work starts |
Why software needs maintenance when nobody touches it
Software stands on other people's code, and that code keeps moving. Four kinds of change reach a running system:
- Libraries and frameworks release new versions and stop fixing old ones.
- Systems under the software, from a server's operating system to iOS and Android, update on their own schedule.
- Outside services retire old versions of their APIs, and the code that calls them has to follow.
- Your business asks for changes, and every new feature is more code to keep working.
None of this looks like a bug on the first day. It shows up later as a payment that fails, a login that stops working or an update that will not install, and rarely at a good moment.
What our software maintenance services cover
The work is the same whether we built the software or another team did:
- Fixes for the bugs and errors your users run into.
- Updates of frameworks, libraries and systems when they are needed.
- Integrations reworked when Stripe, Twilio or Auth0 change their APIs.
- Answers from the engineers who know the code.
- New features from the same team, when you need them.
Our software maintenance team is made of developers, QA and DevOps engineers from a company of 70+ specialists, and they build software too: React, Next.js, Vue, Django, FastAPI, Laravel, Swift, Kotlin, Flutter and React Native, on PostgreSQL and Redis. Two kinds of software have pages of their own: web app maintenance for portals, dashboards and SaaS products, and mobile app maintenance for iOS and Android apps and their backends.
Taking over software another team wrote
Software application maintenance starts with reading the code, not with a price. When we take over software we did not write, it goes in five steps:
- Access. You give us the code, the servers and what you know about both.
- Review. We read the code and the setup and list what is risky.
- Plan and price. What to fix first, what to update and what it costs a month.
- Contract. The scope and the price in writing, signed before the work starts.
- Maintenance. Updates and fixes whenever the software calls for them.
Sometimes the review ends with a different result: instead of a plan, a list of what has to change before the software can be maintained at all. Either way you see it before you sign anything, and the decision stays yours.
The handover list: what to collect before a new team starts
Collect it while the old team still answers your email. In October 2026 I read five company pages from the top of Google for this search: none of them tells the owner what to take from the previous team or who should hold the access. Five pages are a small sample, so here is the list I would want in my own hands:
- The code in a repository your company owns, with its full history, not a zip file.
- Every server, cloud account and domain, with the owner of each account named.
- Every outside service the software uses - payments, email, text messages, sign-in - and whose card pays for it.
- Where the passwords and keys live, and who can change them.
- How a new version reaches production: a script or written steps, not one person's memory.
- How to run the tests, if there are tests.
- The known bugs and the parts everyone is afraid to touch.
- Everyone who has access today, so you can close what is no longer needed.
We keep the same record on every project we maintain. Every access and every service is written down, so a new developer starts fast and, if you ever leave, offboarding is a clear list of what to revoke.
What a software maintenance contract should answer
Whichever software maintenance company you hire, check that the contract answers these questions before you sign:
| Question | What to look for |
|---|---|
| What exactly is maintained | The applications, servers and integrations, named one by one |
| What counts as maintenance | Fixes and updates in the monthly price, new features priced apart |
| How fast someone reacts to a breakdown | A time in writing, not "as soon as possible" |
| Who you talk to | The engineers who know the code, not a ticket queue |
| What you get back if you leave | The code, the list of access and services, the notes |
Our contract names what we maintain and the monthly price before any work starts. New features are estimated separately, you talk to the developers directly, and the code and the accounts stay yours throughout.
What the monthly price depends on
We set the price of a software maintenance and support plan after we look at the software and at how it is built. Five things move it:
- How much software there is, and on how many platforms.
- What it is built on, and how old those versions are.
- Whether there are tests, and how a new version reaches production.
- How many outside services it depends on.
- How many changes a month you expect.
None of the five pages I measured names a price; one suggests budgeting a share of the original build cost every year. A rule like that ignores everything in the list above, which is why we price after the review. Our one fixed maintenance price, $29 a month, billed annually ($348), is for the websites we build: see website maintenance.
Software we took further after day one
- RxPhoto. Clinics capture, store and share patient photos with it. We worked on the backend, the web front end and the API behind the mobile app, and our work includes ongoing support for the practices that use it every day.
- Raina Music. Music for restaurants and hotels, mixed like a live DJ. We reworked the streaming backend for many venues at once and wrote the internal documentation that makes new features and onboarding faster.
- AAE Plugin. AI tools inside Adobe After Effects, taken from a technical demo to a product. AI models change fast, so the backend swaps them without an update of the plugin.
- Muzychko Vocal School. Live on its first day; today it has 144 automated tests, two languages and an admin where the artist edits every word.
When maintenance is not the answer
- A website we built on our $499 package. Its upkeep is website maintenance at $29 a month, billed annually ($348).
- You want a developer inside your own team. That is staff augmentation, from $35 an hour; outsource or outstaff explains the difference.
- The software needs to grow more than it needs care. New products and large changes are custom software development, estimated before work starts.
- The trouble is the server, not the code. That is server maintenance.
We sell software development and maintenance services from one company, so the people who maintain your software can also extend it. Send us what needs maintaining: on weekdays from 9 am to 6 pm Miami time a new request gets an answer within 30 minutes, and the first call and the rough estimate are free. Everything else we look after is under IT support.
