Web application maintenance
Your applications run your day-to-day operations. They have aged, changed hands, accumulated patches. We take them over, stabilise them, and evolve them — without throwing everything away.
Who is this for?
You are probably in the right place if one of these situations sounds familiar:
- An internal application has been running for ten years, but the original developer can no longer be reached.
- You inherited a codebase that nobody on the current team wants to open.
- Users report slowdowns, recurring bugs, or a dated interface.
- An agency is offering to "rewrite everything" — and you wonder whether that is really the only option.
- You need to add one feature, but every change breaks two others.
What we do, concretely
- Audit of the code, the database and the hosting infrastructure.
- Security updates, dependency upgrades, language upgrades (for example PHP 5 to PHP 8).
- Bug fixes, regression resolution, edge cases straightened out.
- Progressive refactoring, module by module, with no service interruption.
- New feature development, integrations with your other tools.
- Documentation written as we go, so a future handover remains possible.
- Monitoring, backups, incident recovery.
Stack we know: PHP, MySQL, SQLite, Apache, modern JavaScript, Linux.
Where we work
Three engagement modes depending on the project and your preferences:
- Remote. For day-to-day maintenance, feature work and most audits. We regularly serve clients across France and Europe without travel.
- On site, across France and Europe. For initial audits, scoping workshops, sensitive deployments or whenever the client team’s culture calls for it.
- Locally, in the Auvergne-Rhône-Alpes region. Progely is based in the Auvergne-Rhône-Alpes region of France. Recurring work in Lyon, Grenoble, Saint-Étienne, Clermont-Ferrand, Annecy and the surrounding area — same-day on-site presence available.
Why maintain rather than rewrite?
The pull of starting from scratch is strong: "the code is old, we might as well do it properly this time". In the vast majority of cases, it is a costly mistake — here is why.
What a rewrite actually costs you
- Years of forgotten business rules. Every exception and edge case was coded for a reason — one that is often lost over time. A rewrite makes them resurface in production, one by one, at the most visible moment.
- A budget multiplied by two or three. Large software rewrites overrun their envelope in an overwhelming majority of cases. Long-standing industry studies (Standish CHAOS) put the share of projects delivered on time and on budget at less than a third.
- Double maintenance. While the new application is being built — often for one or two years — the old one has to keep running. You pay maintenance for both, with the same team.
- Your users' trust. The current application works. The new one promises better, but your users have to relearn everything — and will tolerate rollout bugs far less on a tool they use every day.
- The risk of never shipping. A meaningful share of rewrites are abandoned mid-way or never reach end users. The old application remains — more fragile than before, and this time with no fallback plan.
Our position: in the vast majority of situations, progressive modernisation is faster, cheaper and safer than a rewrite. We stabilise, we document, we replace critical modules one at a time. The application stays in production throughout, and you see results after each cycle.
How we work
Short cycles, regular releases, no service interruption. We start with a short initial audit that identifies the priority risks and gives you a clear view of what deserves to be done — and in what order. You then decide the pace and the scope.
Frequently asked questions
Is it better to rewrite an old application or maintain it?
In the vast majority of cases, progressive maintenance is faster, cheaper and less risky than a rewrite. A full rewrite means rediscovering years of business rules that only exist in the current code, paying maintenance for both versions in parallel, and carrying a significant risk of the project being abandoned mid-way. We only recommend rewriting when the underlying stack has genuinely reached end of life.
How can we take over a web application if the original developer is gone?
This is the most common situation in the applications we take over. We start with an audit of the code, the database and the infrastructure. We then rebuild the missing documentation as we go and bring the application back to a state where any team can maintain it going forward.
How long does an audit of an existing web application take?
Typically a few hours to a few days depending on the size of the application. The purpose of the audit is to give you a prioritised list of risks (security, performance, technical debt) and a clear estimate of the work ahead. You then decide the pace and the scope.
What technologies do you work with?
Primarily PHP (from PHP 5 up to current versions), MySQL, SQLite, Apache, modern JavaScript and Linux. We take on bespoke applications, older CMS installations and internal back-offices alike.
Can new features be added without breaking what already works?
Yes — that is precisely the point of an ongoing maintenance engagement rather than one-off interventions. Each change is scoped to a short cycle, tested in isolation, and delivered to production with no service interruption.