Maintaining a custom business application: what to agree before launch
After launch, someone still needs to maintain the environment, check backups, handle faults and plan changes. Replace a vague promise of “support” with agreed tasks, named responsibilities and clear charging arrangements.
Hosting covers only part of the work
Paying for a server or cloud service provides the resources included in that service. It does not automatically answer who fixes an application fault, investigates a failed import or helps an employee regain access.
When comparing maintenance offers, separate infrastructure charges from work on the application itself. Ask who receives invoices, who controls administrative accounts and who acts on a supplier warning. A single invoice may cover several services, but responsibility should still be understandable.
Define maintenance through specific tasks
The table below is a list of matters to agree, rather than a package offered at a particular price. Different applications need different levels of support.
Scroll the table sideways to read what needs to be agreed for each maintenance area.
| Area | What should be agreed |
|---|---|
| Infrastructure | Who manages services, charges, capacity and access. |
| Backups and recovery | What is copied, how often and who tests restoration. |
| Updates | Who evaluates changes, tests them and agrees installation timing. |
| Faults | Where reports go, how priority is decided and when work starts. |
| Integrations | Who notices pending records and maintains compatibility. |
| User support | Which questions are included and who manages permissions. |
| Development | How additional features and their budgets are approved. |
For every area, identify an owner and the limits of the service. Where a task costs extra, agree how expenditure is authorised. A business should not discover during an outage that nobody has responsibility for restoring a backup or investigating a particular connection.
Backups need to support recovery
Begin with two business questions: how long an interruption can be tolerated, and how much recent activity could be reconstructed another way. These answers help determine backup frequency and recovery arrangements. “Daily backups” alone does not establish how quickly work can resume or what happens to changes made since the most recent copy.
Check whether attachments are included as well as the database. Agree the storage location, access, retention period and how a failed backup is reported. Recovery also requires instructions for starting the application and access to the configuration it needs.
Ask for a restoration test and a record of its result. PostgreSQL documentation distinguishes checking a backup’s integrity from performing a test restore and checking that the database works. This is a specific technical example of why a successful backup check does not finish the verification. PostgreSQL backup verification documentation.
Run the test in an agreed environment and check both required records and basic user tasks. Its result can be used to improve the plan before recovery is needed during an actual interruption.
Response time is different from repair time
A report being acknowledged, diagnosis beginning and service being restored are separate events. An offer should make clear which event a stated time refers to and which working hours count towards it.
Classify issues by their effect on the business. Being unable to open any jobs needs a different response from a broken export that has a temporary workaround. A minor appearance change should not compete for attention on the same basis as a complete interruption to work.
A useful report describes the action, expected outcome, actual result and time of occurrence. Share only the information needed to investigate it. One nominated person in the business can collect details from users and keep them informed of progress.
Separate a fault from an additional feature
An agreed export missing a column from the accepted scope is a different request from creating a new report. Documented functionality and acceptance conditions provide a reference for that discussion.
In a fictional example, a company commissioned an open-job list containing a due date and an owner. Incorrect date sorting needs to be assessed as a fault in that view. Adding employee capacity planning extends the scope and needs its own description and estimate. Making the distinction explicit helps both sides plan cost and priorities.
A recurring fee might include a defined amount of support time or a defined set of tasks. Check how work is reported and how anything beyond the allowance is approved. Paying per request also needs availability arrangements: having no subscription does not by itself reserve a developer’s time.
Plan updates and external dependencies
Before changing the application, agree checks of essential tasks and a route back if deployment causes problems. The business should know whether a pause is required and who confirms correct operation afterwards.
If the application connects to another product, include that supplier’s notices, changes to access and expiry of relevant permissions in the plan. The system integration scope should also explain how missing transfers are detected. A connection can need attention even when the application’s web page still opens normally.
Keep a short record of changes and known issues. This helps distinguish a new problem from an existing limitation and gives the next person investigating an incident some context. The level of documentation should match the application and its importance to everyday work.
Preserve the option of a handover
Before work starts, agree access to the code as provided for in the contract, startup instructions, integration details, data export and an inventory of the services required to run the application. Accounts and credentials need identified owners and a method of transfer to an authorised person. A folder of source code alone is insufficient for a smooth support handover.
Agree the tasks involved when the relationship ends and any charge for helping another supplier take over. The buying decision should cover the application’s life after its first release, including how the business can move responsibility later.
For a new application, discuss these points alongside rollout and data migration. When describing a project to brigdev, include the company’s working hours, the tasks that depend on the application and the systems already in use. That information helps define an appropriate level of support.
Describe one task you want to improve.
Tell me how it works today and what gets in the way. We can then work out whether I can help and where to start.
Describe your task