English
Romana
A client wrote to us a few months ago with a simple question: his internal management application had been running without visible issues for three years, so why keep paying for maintenance? The answer came quickly, after a technical audit: the framework in use already had two major unpatched security releases behind it, and one of the PHP libraries used for payment processing had been officially unsupported for a year. The application "worked", but it was running on an increasingly fragile foundation.
Custom web application maintenance includes security updates, error monitoring, verified backups, periodic performance reviews, and minor functional adjustments — a set of recurring activities, not a single on-demand intervention. The cost typically ranges from a few hours to a few days of work per month, depending on the application's complexity and the level of risk the business can accept.
This guide explains, from the HappyWeb team's perspective, exactly what activities are part of a maintenance contract, how the monthly cost is estimated, and what security risks appear when a custom application is left without upkeep over the long term.
What custom web application maintenance actually includes
The term "maintenance" is often used loosely, as a vague form of "support". In practice, for a custom Laravel project, maintenance covers distinct activities, each with its own role:
- Security updates — applying patches for the framework, PHP libraries (Composer), and front-end dependencies (npm) as soon as known vulnerabilities are published.
- Production error monitoring — tracking error logs and automated alerts so an issue is identified before a customer or internal user has to report it.
- Periodically verified backups — not just automatically generated backup files, but a real restore test, at a regular interval, confirming the backup actually works.
- Periodic performance reviews — checking response times and database queries, especially after growth in traffic or data volume.
- Minor functional adjustments — small changes driven by business evolution (a new field in a form, an adjusted business rule) that don't justify a separate project but accumulate over time.
The difference from a one-off "fix it when needed" intervention is the recurring nature: each of the activities above only creates value if it's repeated at a predictable interval, not only once a visible problem has already appeared.
How much does custom application maintenance cost: factors that shape the budget
There's no universal fixed price for maintenance, because the effort depends directly on the application's complexity and the level of risk the business accepts. The main factors that influence the estimated monthly cost:
| Factor | Impact on cost | Why it matters |
|---|---|---|
| Application complexity | Directly proportional | A B2B application with multiple integrations needs more review hours than a presentation website |
| Number of external integrations | Increases cost | Each external API (payments, shipping, parts catalog) can change its data contract without prior notice |
| Data volume and traffic | Increases cost over the medium term | Applications with growing traffic need more frequent performance monitoring |
| Risk level accepted by the business | Lowers or raises cost | An online store handling online payments justifies more frequent maintenance than a presentation site with no sensitive data |
| Age of the existing codebase | Increases initial cost | An application with accumulated technical debt needs extra effort in the first maintenance cycle to reach a stable baseline |
As a rough benchmark, a minimal maintenance package (security updates, verified backups, basic monitoring) typically starts at a few hours of work per month, while a business application with multiple integrations and high traffic may require several days of work per month. Exact figures remain indicative and depend on the technical audit specific to each application.
Why an "old" application effectively becomes a security risk
Source code doesn't "decay" on its own over time, but the environment around it changes constantly: new vulnerabilities are discovered in frameworks and libraries, external service providers modify their APIs, and older PHP versions fall out of official support. An application that hasn't been updated in two or three years quietly accumulates exactly this kind of exposure.
The risk isn't theoretical. A PHP library that's no longer officially supported stops receiving security patches, which means any vulnerability discovered in it afterward stays open indefinitely, until a manual migration happens. For an application handling customer data, payments, or sensitive internal information, this technical gap turns directly into business risk — from data leaks to complete service unavailability.
Common security risks and how structured maintenance prevents them
- Risk: outdated PHP/JavaScript dependencies. Mitigation: periodic checks for known vulnerabilities (e.g. Composer/npm audit) and applying patches as soon as they're available, not at the next major project.
- Risk: backups that have never been tested through a restore. Mitigation: a real restore test at a regular interval, not just confirmation that the backup file was generated.
- Risk: application access retained for former collaborators or employees. Mitigation: periodic review of active accounts and permissions, with immediate revocation at the end of a collaboration.
- Risk: expired SSL certificates or API keys with no warning. Mitigation: automated monitoring of expiration dates, with alerts well ahead of the deadline.
- Risk: production errors discovered only when a customer reports a problem. Mitigation: structured logging and automated alerts for critical errors, checked proactively rather than reactively.
In-house maintenance vs. a contract with the application's developer: how to choose
For companies considering an in-house maintenance team, the decision usually depends on three practical criteria:
- Knowledge of the codebase — the developer who built the application already understands the architectural decisions and the reasoning behind them; a new in-house team needs ramp-up time, especially for applications with complex business logic.
- Actual monthly workload — if maintenance only requires a few hours per month, hiring a dedicated in-house person is rarely justified economically; a contract with the existing developer remains more efficient.
- Long-term continuity — a clear maintenance contract removes the risk of depending on a single in-house person, who may leave without complete documentation.
In most projects from the HappyWeb portfolio — from online stores like autopiesa.ro and eutruckparts.ro, to services like easy-parking.ro and climanet.ro — maintenance is treated as a natural continuation of the development project, not a separate service, precisely to preserve full knowledge of the application's architecture.
Practical plan: what to check periodically on your own web application
For a company that already owns a custom application and wants to evaluate whether its current maintenance is sufficient, we recommend a structured three-stage review:
- Stage 1 — initial technical audit: check the framework version, the PHP/JS library versions, and the date of the last applied security update.
- Stage 2 — real backup testing: request a test restore from an existing backup, not just confirmation that the file exists.
- Stage 3 — recurring maintenance plan: set a fixed interval (monthly or quarterly) for security updates, monitoring, and access permission reviews.
A quick mini-checklist for a fast evaluation:
- Do you know exactly which framework and PHP version your application runs on?
- Have backups been restore-tested in the last 3 months?
- Is there a clear process for revoking access for former collaborators?
- Are SSL certificates and API keys monitored for expiration?
- Are there automated alerts for critical production errors?
What a well-structured maintenance contract looks like in practice
At HappyWeb, maintenance for custom Laravel applications is explicitly documented: the included activities, the reporting interval, and the response time for a critical error are set from the start, not negotiated ad-hoc with every request. This contractual clarity is what turns maintenance from an unpredictable cost into a planned investment, similar to technical insurance for a business-critical digital asset.
Frequently asked questions about custom web application maintenance
How often should a custom web application be updated?
Critical security updates should be applied as soon as they're published, typically within a few days. Routine updates (minor libraries, dependencies) can be scheduled monthly or quarterly, depending on the risk level the business accepts.
What happens if I stop maintenance entirely?
The application keeps running in the short term, but unpatched security vulnerabilities accumulate, and the risk of incompatibility with external services (payment processors, third-party APIs) grows progressively, until migration becomes far more costly than recurring maintenance would have been.
Does maintenance include building new features?
Not usually. Maintenance covers updates, security, monitoring, and minor adjustments. Significant new features are treated separately, as distinct projects, even when delivered by the same team.
Does a small application with low traffic still need maintenance?
Yes, even if at a minimal level. Security updates remain necessary regardless of traffic volume, because vulnerabilities target the code and its dependencies, not the number of visitors.
How do I know if my current application already has a known vulnerability?
An initial technical audit, checking framework and dependency versions against public vulnerability databases, is the fastest way to find out the real security state of the application.
Conclusion: maintenance is the planned cost of a stable application over the long term
Custom web application maintenance isn't an optional cost — it's the planned price of keeping an application stable and secure over the long term: security updates, tested backups, continuous monitoring, and minor functional adjustments, applied recurrently, not only once a visible problem has already appeared.
Want a website or application built around your business's real needs? Contact us to discuss your project.
Not sure what technical state your current application is in?
HappyWeb provides technical audits and maintenance for custom Laravel applications, with security updates and continuous monitoring. Request an evaluation of your current risk level.
Related articles
Image generated with AI, used for illustrative purposes.
Write a comment