There is no honest fixed monthly price for maintaining an application until it is clear who is responsible for what. The cost depends on the condition of the system, its technology and infrastructure, the number of important processes and integrations, the required monitoring, backup and deployment procedures, the volume of support requests and the agreed response hours.
A useful estimate separates four types of expense: infrastructure and external services, ongoing team availability, work actually carried out and larger development projects. Only then can two offers be compared on equal terms.
Hosting is only one part of the cost
A server, domain and certificate allow an application to operate, but they do not maintain it. Hosting alone will not tell you that an invoice job has stopped, an integration has failed to download orders or a database backup cannot be restored. It will not update the code or repair a failure caused by a changed external API unless those responsibilities were explicitly included.
The same applies to backups. Creating a file does not prove that it contains all required data or that it can restore a working system. The offer should define what is backed up, how often, how long copies are retained, where they are stored and how restoration is tested.
What makes up the maintenance cost?
| Cost group | What it may include | What the company is paying for |
|---|---|---|
| Infrastructure and external services | server or cloud resources, domain, email, SMS, payments, file storage, monitoring and external APIs | resources and access to services required by the application |
| Ongoing support and availability | receiving alerts and requests, checking backups, planning updates and taking responsibility during agreed hours | access to a person who knows the agreed scope and can begin handling an issue |
| Work performed in the system | diagnosis, repairs, updates, deployments, configuration and small changes | specific work covered by a retainer, a limit or a separate order |
| Larger development | new modules, migrations, modernisation, infrastructure rebuilds or recovery after a serious incident | a separate project that should not be hidden under the general term "maintenance" |
One offer may include only server administration and a response to submitted issues. Another may also include monitoring of important processes, backup checks, regular updates and an agreed allowance for work. Comparing only the monthly totals can therefore be misleading.
What has the greatest impact on the estimate?
How important the system is to the business
An information website has different maintenance needs from a system that accepts orders, bookings or data required by staff throughout the day. The greater the consequences of a stopped process, the more important monitoring, a clear reporting channel and a previously agreed response procedure become.
The condition of the code and technology
Maintenance becomes more expensive when a project uses unsupported versions of PHP, its framework or libraries, has no tests, or depends on manual deployment without a safe rollback path. PHP publishes support dates for each branch, while Laravel maintains its own correction and security support policy. Technology versions therefore need attention throughout the life of the application, not only on launch day.
The number of processes and integrations
Checking the homepage will not reveal every failure. Queues, scheduled jobs, payments, messages, imports, exports and connections to other systems may each need separate monitoring. Every additional process introduces its own failure modes and a dependency on an external provider.
Documentation and access
A repository, infrastructure description, service inventory, deployment procedure and backup information make diagnosis faster. If a previous provider did not hand these over, the first step may be to organise access and assess the system. The application handover checklist helps collect the basics, but it does not replace an inspection of the code and server.
Required support hours and response time
Availability has a cost even in a month without an outage. A shorter initial response time requires reserved capacity and knowledge of the specific system. It is also important to distinguish starting work from completing the repair. A resolution date can often be estimated only after diagnosis.
When is one-off work enough?
Not every application needs a monthly retainer. A one-off order may be sufficient when the system does not support a critical process, the company accepts a planned work date and needs a specific update, configuration change or repair. Other responsibilities, including monitoring, backups and communication with the hosting provider, must then have another owner.
Ongoing support makes more sense when the application is used every day, changes regularly, has integrations or runs background jobs. It is also useful when the company wants one party to own alerts, backup checks, the update plan and controlled deployments.
At Domin Software we can agree one-off work, regular support or a separately priced response-time option. The right model depends on the system and the consequences of its unavailability.
Why does an SLA affect the cost?
An SLA should not be a vague promise of fast help. It needs to identify the applications and environments covered, service days and hours, reporting channels, severity levels, initial response times and the responsibilities of both parties.
Domin Software does not publish one SLA for every customer and does not promise 24/7 support. Our standard support window is Sunday to Friday, 08:00 to 17:00 Europe/Warsaw time. We do not provide support on Saturdays. On Polish public holidays we can respond only to critical events agreed in advance. Exact terms apply only after they have been written into an offer or agreement.
Monitoring can run around the clock without providing a round-the-clock human response. It may detect and record an alert, while the handling time still depends on the agreed support window.
How should two maintenance offers be compared?
| Question | What should be stated clearly |
|---|---|
| What is covered? | applications, environments, server, integrations and important processes |
| What is monitored? | specific endpoints, jobs, queues, integrations and alert recipients |
| How are backups checked? | scope, frequency, retention, storage location and restoration tests |
| When are requests handled? | days, hours, time zone, channels and escalation rules |
| What does response time mean? | acknowledgement, initial assessment and start of handling, not automatic completion of the repair |
| How are changes made? | testing, approval, deployment and rollback |
| What is included in the fixed fee? | availability, named responsibilities and any work allowance |
| What is priced separately? | larger development, migrations, audits, recovery after an attack and work outside the agreed scope |
| Who owns the accounts? | the customer should retain control of hosting, domain, data and billing |
If an offer does not answer these questions, complete the scope before comparing prices. The lowest amount may simply mean the narrowest responsibility. A higher price does not automatically prove better protection either. The written scope and the way the service is verified are what matter.
What should be prepared for an estimate?
Start with the purpose of the application and its most important processes. It is also useful to provide:
- the technology and versions, if known;
- a list of environments, integrations, background jobs and external services;
- information about the repository, documentation, tests and deployment method;
- the current monitoring and backup scope;
- the impact of an outage and acceptable support hours;
- typical requests and the expected scope of small changes;
- information about account ownership and who approves deployments.
Do not send passwords, keys, databases or customer data through the contact form. At the first stage we need a description of the situation, not production access.
The application maintenance planner helps collect this information and creates a working summary. Its result is not an automatic estimate or an SLA agreement.
What do our previous projects show?
Development of the 44Islands system did not end with its first launch. Later stages expanded booking management, user roles and direct sales. It shows how care for a working application can include support for the existing scope as well as separately agreed development.
Historical support for three PrestaShop 1.6 stores included VPS and environment configuration, domains, Apache and PHP, module installation, performance work and template improvements. It lasted approximately one year. Those stores are no longer in production, so this evidence confirms the type of work performed, not their current condition or the price of a new service.
In both cases the scope followed the actual system. Previous projects are not a ready-made price list for the next customer.
Frequently asked questions
Does hosting include application maintenance?
No, unless the offer explicitly combines the services and defines the responsibility. Hosting provides resources, while maintenance may cover process monitoring, backups, updates, diagnosis, deployment and support requests.
Does regular support always include a fixed number of developer hours?
Not necessarily. A fee may cover availability and named responsibilities, with or without an additional work allowance. The agreement should state what happens when the allowance is used and which tasks are separate projects.
Is creating a backup enough to protect the system?
No. You also need to know what it contains, where it is stored, how long it is retained and whether it can restore a working system. Restoration tests need an agreed scope and frequency.
Can the cost be determined without access to the code?
An initial cooperation model and the information needed for an estimate can be identified without access. Taking precise responsibility for an existing system may, however, require paid discovery of the code, infrastructure, versions and deployment process.
Does monitoring mean a 24/7 response?
No. Monitoring can operate continuously, but alerts are handled during the hours stated in the agreement. On-call service outside standard hours requires a separate arrangement.
Is the development of new features included in maintenance?
Small changes may fit within an agreed allowance. Larger modules, migrations and modernisation should have their own scope, acceptance criteria and estimate.
Choose the next step
If you first need to organise the requirements, use the application maintenance planner. It collects information about the system, backups, monitoring, requests and the expected cooperation model without automatically sending data or producing an estimate.
If the scope is already clear, review our application and online store maintenance service. Describe the purpose of the system, its key processes, the impact of an outage and the expected support hours. We will then establish whether one-off work, regular support or a separately agreed SLA option is appropriate.
Sources
- PHP Supported Versions, accessed 28 October 2026.
- Laravel Release Notes and Support Policy, accessed 28 October 2026.
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, accessed 28 October 2026.
- OWASP A06:2021, Vulnerable and Outdated Components, accessed 28 October 2026.