Software Maintenance

Software maintenance for the system you already run.

Production software does not stay healthy on its own. Dependencies age, security patches land, bugs surface and small requests pile up. We agree what we maintain, how requests reach us and how fast we respond, then do the work with a record you can check.

Scope your maintenance agreement →

DIRECT ANSWER

Software maintenance is the ongoing care of production software: updates, dependency and security patches, bug fixes, small enhancements and monitoring hygiene. Scope, working hours and response times are agreed per contract; it does not include 24/7 coverage or an uptime SLA.

Best for

Owners of a production system that can be built and released, and needs a reliable maintainer
Teams whose developers have moved on to new work and want routine care handled

Consider another approach

A change of provider that needs access recovery and knowledge transfer first
24/7 on-call operations or a contractual uptime guarantee

Start from a system someone can maintain

Maintenance assumes we can build, test and release the system. If access, documentation or the previous provider are the problem, that is a Software Takeover first; its handover, recovery and dependency upgrade offers keep their own scope and terms. If the onboarding check finds the system cannot be released safely, we say so before agreeing a maintenance scope. Structural change, such as replacing a framework or splitting a monolith, is Legacy Modernization.

What routine care includes

The agreement lists the systems and environments covered. Work outside that list is quoted before it starts.

Updates and security patches

Keep runtimes, frameworks and libraries on supported versions. Security advisories are triaged and patched in an agreed order of priority.

Bug fixing

Reproduce, fix, test and release defects reported by your team or found in logs and error tracking.

Small enhancements

Minor changes within an agreed monthly budget. Anything larger is quoted separately before work starts.

Monitoring hygiene

Keep error tracking, logs, certificates and alerts useful. Alerts route to a named person during agreed hours.

Response times are agreed, not implied

The contract names the systems covered, the request channel, working hours, how severity is classified and the response targets for each class. Those targets apply during the agreed working hours. We do not offer a 24/7 on-call service or an uptime SLA, and a maintenance agreement does not create one. Hardening the running environment is Cloud Security; controls on the build and release path are DevSecOps. The Trust Center sets out our general support boundaries.

Illustrative record: one month of maintenance

An illustrative monthly report lists dependency updates applied and deferred (with reasons), security advisories checked, bugs fixed with the release that contains each fix, small changes delivered against the agreed budget, open items and the decisions you need to take. This is an example format, not a customer result or a service-level commitment.

Onboard, maintain, review

The onboarding check is scoped and quoted on its own. The maintenance agreement follows from what it finds.

Onboarding check
We build, test and release the system once in an agreed environment. You receive a version inventory, known risks and a proposed maintenance scope.
Ongoing maintenance
A monthly agreement covering the agreed systems, working hours, request channel and response targets per contract.
Periodic review
Review what was done, what aged and what keeps breaking. A recurring structural problem becomes a separate modernization or security decision.

Bring access, the version list and the people who report problems

We need repository, CI and hosting access, the current version list, known issues, error tracking, the people who report problems and a person who can approve releases. Larger features belong to Software Development. For budgeting, the software maintenance cost guide explains typical cost drivers; its model is not a quote or a support commitment.

// proof

Ongoing care in existing engineering work

IKB: Wavect worked inside IKB’s Smart City build on infrastructure and devices, handed the platform over to IKB’s in-house team completely, and stayed on as external support for new device integrations, the Grafana stack, field connectivity and manufacturer calls. MyMerch documents a multi-year engagement improving a working Shopify business in targeted steps without a rewrite. Polity documents long-running QA ownership with flakiness reduction and bug triage across services. None of these cases documents 24/7 coverage or an uptime commitment.

Complete Platform Handover

Smart City IoT for Innsbruck: extended and scaled the LoRaWAN infrastructure, evaluated and integrated multi-vendor devices, wrote …

Kubernetes LoRaWAN Docker

~50% Efficiency improvement for the MyMerch team

MyMerch’s team puts the efficiency gain at ~50%. Fewer delivery errors, improved Shopify conversion, no rewrite.

Shopify Shopify Liquid JavaScript

7 services Unified Testing

1.5 years owning QA across seven services and multiple vendors. Quality stayed shippable through every refactor.

React Java/Kotlin Go

These are selected projects, not our full portfolio. We have shipped 100+ products since 2018.

Questions before you start

Do you offer 24/7 support or an uptime SLA?

No. We do not offer 24/7 on-call coverage or an uptime SLA. Working hours, severity classes and response targets are agreed in the contract and apply within those hours.

What response times do you commit to?

The ones written into the contract. They depend on the severity class and the agreed working hours, and we agree them after the onboarding check, once we know the system.

Can you maintain software someone else built?

Yes, if it can be built and released. The onboarding check shows that. If the previous provider is leaving and access or knowledge must be recovered first, that is a Software Takeover.

Where does maintenance end and new development start?

Small enhancements fit inside the agreed monthly budget. Larger features are quoted separately or handled as a Software Development engagement, so routine care does not quietly turn into an open-ended build.

How is maintenance billed?

As a monthly agreement for the agreed scope. Work outside that scope is quoted before it starts. We do not publish a price before the onboarding check, because the cost depends on the system.

Scope your maintenance agreement

Describe the system, its stack, who maintains it today and what keeps slipping. Keep credentials and confidential data out of the first enquiry.