Custom software maintenance: what to include when hiring

Before comparing monthly fees, ask each provider to place the work in these three categories. This is a scope comparison framework proposed by Duotach, not a legal definition of warranty or a substitute for your contract.

Warranty should refer to the agreed behavior and acceptance conditions. Operations covers the recurring tasks explicitly contracted. Further development adds or changes capabilities. One provider can cover all three, but each request needs a category and an approval rule.

A service level agreement, or SLA, needs to describe when the clock starts and which outcome it commits to. Separate first response, diagnosis, temporary mitigation and final resolution. A ticket reply does not demonstrate that business operations have recovered.

As an example of that distinction, AWS publishes human response times by support plan and severity. Those terms are not your application SLA or a promise to resolve it within the same interval. Documentation checked on November 2, 2026.

Ask for service hours and time zone, applicable holidays, an urgent reporting channel and an escalation owner. Define severity by operational impact: a critical function blocked without a workaround needs different treatment from a visual change. Out-of-hours coverage must be contracted; an automated alert alone does not establish that someone is on call.

Include what happens when an external provider causes the problem: who opens the case, who communicates, which workaround is available and who authorizes it. Infrastructure support and application support need named responsibilities.

Request a row for each relevant component, including those your IT team operates. The goal is to identify the boundaries between application, infrastructure and integrations. This proposed evaluation matrix does not mean every task is included in every maintenance agreement.

Assign who reviews updates and what evidence supports approval. Dependabot raises update proposals that are managed like other pull requests. Receiving an alert or a proposal does not demonstrate compatibility with your business process.

Ask the scope to specify a test environment, approval owner, change window and rollback procedure. Choose journeys that represent the agreed use: sign-in, permissions, a core operation and the integration that depends on the updated component. The provider should record the version and result as well as reporting that a library was updated.

If the system uses an AI model or an external API, include its behavior in those tests when it affects the function. Code and data changes need different procedures: returning to an earlier software version should not be assumed to recover information or undo external actions.

The word backup needs a scope. Ask for included sources, frequency, retention, access, owners and a recovery procedure. Agree on the data loss and downtime the business can tolerate; the provider should compare those objectives with the design and tests.

Supabase documents that database backups do not include objects stored through its Storage API. It also warns that restoring can make the project inaccessible. This is a limitation of that product, checked on November 2, 2026; other services need their own review.

In a fictional example, a portal stores requests in a database and attachments in file storage. Recovering rows without being able to open their attachments does not satisfy a recovery test of the complete process. Request an authorized test in an isolated environment, with its result, outstanding dependencies and the person who accepts recovery. This example is not a client case or a measured result.

A monthly report should make the paid scope verifiable: checks performed, incidents and their status, applied changes, tests and remaining risks with an owner. If the month purchased operations, no new features does not mean no work was performed. If it purchased development, the report should show progress against agreed priorities.

Ask the provider to distinguish commitments, progress and completed work. Starting a task does not make it accepted because it appears on a board. If an incident displaces an improvement, record the reprioritization and your team’s decision.

Compare development cost, recurring services and third-party usage separately. Scope changes with criticality, components, coverage hours and development capacity. A percentage of the original build price alone does not describe the service you are buying.

Before signing, also agree when each coverage starts and how the same correction will avoid being billed twice. If ongoing support ends, assign owners for continuing tasks, company access and outstanding work. To verify code, accounts and documentation, use the custom software handover guide.

Duotach builds custom software for businesses and includes maintenance and new functionality in ongoing work with an agreed scope. When discussing a build or extension, describe the process, systems involved, who will operate it and the post-delivery coverage you need.

The proposal should separate development, warranty, operations and further development. This guide does not promise on-call hours, a universal fee or taking over any existing system without evaluation. Technical assessment, code review and specific tests belong in the paid scope that is agreed.

The form opens a project inquiry. You do not need to attach credentials or users’ personal data to explain the problem.