Maintenance · Inherited software
Nobody maintains the software you already paid for
It is one of the most common calls we get at Eolas Labs: the system works, the business depends on it, and the person who built it has stopped answering. Software does not wear out from use — it wears out because the world around it keeps changing while the code stands still. Here is what breaks first, in what order, and what we check before taking on something we did not write.
The call almost always opens the same way: “it works, but nobody has touched it in two years”. Sometimes the supplier shut down, sometimes it was one person who changed jobs, and sometimes they are still there but no longer answer this particular client. What does not change is the caller’s position: they depend on a piece of software, they do not know what is inside it, and they have nobody to ask.
One thing is worth saying first, because it saves money: nobody maintaining it does not mean it is broken. A well-built system can go years without a new line. The problem is not the code. It is that everything around the code keeps moving.
What breaks first, and in what order
When a system goes unmaintained it does not fail all at once. It fails in layers, and nearly always in this order. None of these have anything to do with what your software does — they are all things that happen to it from outside.
| What fails | When it usually shows up | What it looks like from outside |
|---|---|---|
| TLS certificate | Months | The browser warns the site is not secure and people leave |
| A third-party API | Months to a year | The data stops arriving: stock, payment, shipping or the map |
| Payment provider or carrier | A year | The gateway changes version and checkout stops completing |
| Language or framework version | One or two years | Nothing, until something needs changing and it will not build |
| The hosting | Two years or more | The provider retires the plan and gives you a window to migrate |
| Nobody remembers how to deploy it | At the first change | An hour of work turns into a week |
Notice that only the last one is a code problem. The first five are maintenance in the literal sense: somebody has to be watching. That is why an unmaintained system does not visibly degrade — it looks fine right up until the day it does not, and that day tends to be the worst possible one.
What we check before saying yes
Adopting software somebody else wrote is a different job from building it. We do not take it on blind: before signing a maintenance agreement we run a review, and the review can end with us saying no. These are the five questions, in order of importance.
- Do you have the access? Not the code — the access. Domain, DNS, hosting, repository, app store accounts, payment gateway. It is the part most often missing and the only one no amount of technical work can solve: if the domain is registered to somebody who does not answer, that is the first thing to fix.
- Does the source code exist, and is it complete? A server running the application is not the same as having the code. It can be worked around, but that is a different price and a different conversation.
- Can it be stood up somewhere else? If nobody can start a copy in a fresh environment, there is no safe way to change anything. This is the test that fails the most projects.
- Is there personal data inside? If there is, there is a data processor who may right now be nobody at all, and that is a legal problem before it is a technical one.
- What breaks if it goes down one afternoon? The code does not decide this — you do, and it determines which maintenance tier makes sense.
Why we operate what we build
Worth showing our hand here. We do not sell maintenance as something bolted onto the end of a project: it is what we have been doing with our own systems since before we sold the first one to a client. These four are in production right now and we run them ourselves, with these months accumulated as of 30 August 2026.
| System | In production since | Months |
|---|---|---|
| Eolas Prints | February 2022 | 54 months |
| Simientes Infinitas | August 2025 | 12 months |
| SomosTorre | May 2026 | 3 months |
| Bar Cabrero | June 2026 | 2 months |
Four of our own systems in production as of 30 August 2026: Eolas Prints has 54 months, Simientes Infinitas 12, SomosTorre 3 and Bar Cabrero 2.
Months in production · as of 30 August 2026 · Systems operated by Eolas Labs
The Eolas Prints store has been selling for 54 months, and in that time we have changed payment provider, carrier and the version of nearly everything. None of that was in the original plan. That is exactly the part of the work that never appears in a build quote, and the part that decides whether a system reaches year three alive.
An unmaintained system does not degrade gradually: it looks fine right up until the day it does not.
What it costs
Our maintenance prices are published, and they are the same for a system of ours as for an inherited one: from €150 a month for sites and stores, from €450 once there is live data or published apps, and from €900 when a written SLA and out-of-hours cover are needed. No lock-in.
On top of that, once only, comes the review described above. If the review concludes that rewriting is the sensible answer rather than maintaining, we tell you then — not six months into paying a monthly fee to hold up something that will not hold.
When we say no
We say no when we cannot stand behind something safely, and we would rather say it before charging a monthly fee. The three usual cases: when there is no way to stand up a copy of the system in another environment, when access is missing that only an unresponsive third party can recover, and when the system handles personal data in a way that would have to be rebuilt before anyone could operate it with a clear conscience.
In all three the honest path is not a maintenance agreement: it is a discovery, a plan, and a decision about whether rebuilding is worth it. It costs more up front and a good deal less than finding out in month seven.
Frequently asked questions
Can you take over a website or system that somebody else built?
Yes, it is a routine part of what we do. Before accepting it we run a review: we check that the access exists (domain, DNS, hosting, repository, app stores and payment gateway), that the source code is complete, that we can stand up a copy in another environment, and what personal data it handles. If any of that does not hold, we tell you before charging you a monthly fee.
What breaks first in software nobody maintains?
Nearly always in this order: the TLS certificate within months, some third-party API that stops answering, the payment gateway or carrier when it changes version, the language or framework version after one or two years, and the hosting when the provider retires the plan. Only the last problem — nobody remembering how to deploy it — is a problem with the code. The rest happen to the software from outside.
What does it cost to maintain software that is already built?
From €150 a month for sites and stores, from €450 a month when there is live data or published native apps, and from €900 a month when a written SLA and out-of-hours cover are needed. No lock-in. The initial review of an inherited system is charged once and can end with us recommending you do not maintain it.
What if I do not have the source code?
It can be worked around in some cases, but it is a different price and a different conversation, and it is worth knowing before starting. What technical work cannot substitute for is access: if the domain, the DNS or the app store account is registered to somebody who does not answer, recovering it is the first job and sometimes the slowest.
Is it better to maintain what exists or rewrite it?
It depends on whether the system can be stood up in a fresh environment. If it can, maintaining nearly always wins: it is cheaper, it does not interrupt the operation, and it preserves years of decisions nobody ever wrote down. If it cannot, maintaining it means paying a fee against a risk that does not go down, and then the honest answer is a discovery and a decision about rebuilding.