Operation, maintenance and support for your digital product

Custom-developed software should not only be continuously evolved, but it also requires maintenance and, in most cases, support and service. In a constantly changing world, technical environmental variables, usage requirements, and user expectations shift. Operating systems need backups, certificates must be renewed, and unexpected problems can pop up at any time. All of this makes the ongoing care of an app or website mandatory. The scope of this support is defined in a service level agreement.

Do you have an urgent problem?

Click here for our contact details for support and general enquiries.

The components of an SLA

  • System definition and system boundaries: Which product is involved, and which of its components are covered by the agreement? For example: Server X, Content Management System Y, and Android App Z.

  • Responsibilities: Which tasks will you, your team or your company take on, and which tasks will Apps with love handle? Where might third parties be responsible? Clarity on these questions is absolutely central to efficient operations. That is why we regulate this comprehensively and in detail using a RACI matrix. This matrix defines the following for a wide variety of aspects:

    • Who carries out a task (Responsible)

    • Who makes decisions (Accountable)

    • Who is consulted (Consulted)

    • Who needs to be informed (Informed)

In addition, this matrix specifies whether the associated efforts are included in a flat fee or billed based on time and materials (T&M).

  • Response times in the event of a support request or a so-called incident: We define how quickly you can expect an answer from our support team and how long it takes until we begin working on a solution.

  • How does the support process work? Naturally, this also includes naming the responsible persons or teams and providing their contact details.

  • What are the costs and which additional options are included in the contract?

How we define response times together

The SLA sets out the basic expectations that apply in different situations: response times are determined according to the severity of the incident.

The severity level is determined by the urgency and the impact of the issue on our customer. Response times define the maximum amount of time available for each incident.

For example, if an app can no longer be launched on any device, this is both a high-priority issue and has a significant impact. This is classified as a blocker incident. In this example SLA, the response and resolution times for a blocker have now been set at a maximum of 4 and 8 hours respectively.

Matrix for prioritising incidents, based on the axes of urgency (low to high) and impact (low to high)
Matrix for determining the priority (severity level) of an incident
Sample table showing response and resolution times for incidents with different priorities. The times range from "best effort" to "max. 4 hours" for incidents with priorities ranging from "Low" to "Blocking".
Sample agreement on response times based on incident priority

Costs incurred in the operation, maintenance and support of a digital solution

What does an SLA cost? As is so often the case, the answer is: it depends.

In principle, you most likely have the entirely justified expectation that we will still be there for you and your product once the initial development is completed. At the same time, it is neither in our interest nor our clients' for an entire project team to just sit around waiting to solve a problem in a product that, hopefully, won't even occur in the first place. That’s why we need a middle ground between "once the final development sprint is done, everyone disappears" and "we fund a product team that has nothing to do all day." This middle ground is called "availability."

Availability is a major (cost) component in the SLA and ensures that we can maintain a support team dedicated to handling all incoming issues. In this area, timing is everything: if all support tickets need to be tackled within a very short timeframe, and in emergencies, even on weekends, it will be more expensive than if things can occasionally take a bit longer.

The second cost factor relates to the system itself. The following factors are significant:

  • What components are involved? (Backend, APIs & interfaces, CMS, frontends, etc.)

  • How extensive is the solution? Key factors include: complexity, data volume, number of users.

  • Which systems are used and what costs do they incur? A cloud server is almost always required, which in turn needs a monitoring service. Other external services that are frequently used and incur costs include: email delivery systems, authentication services, spam and fraud prevention tools, payment providers, etc.

The third factor, which is linked to the second, concerns the expectations regarding our service. For example: practically all our SLAs for native apps include a provision where we test the app on beta versions of Google’s Android and Apple’s iOS during the summer. This allows us to identify what needs to be adapted before the new operating system generations are officially released in the fall. If you can and want to do this yourself: go for it! Your SLA will be cheaper, though the responsibility for the app's functionality after the OS update will naturally rest with you.

Support and options are the final factor: based on our experience, we suggest the expected support effort and include a corresponding hourly quota in the contract. How much that is depends heavily on the respective product or project.

Taking these four factors into account, as a rule of thumb you can expect annual costs of around 5% to 15% of the original development costs. A concrete example: if developing your app costs 100,000 francs, you can assume that maintenance, operation, and support costs will range between 5,000 and 15,000 francs annually.

Something many of our clients also find convenient is to set aside a certain budget in the contract for optional add-ons. This provides the flexibility to pragmatically implement minor changes in a practical way, without having to trigger a whole new proposal, contract, or purchasing process. We’ll tailor this entirely to your requirements and are happy to discuss them with you!

Can Apps with love operate my product, even if it was developed somewhere else?

Yes and no. In order to truly take responsibility, we need to understand a product inside and out. We would love to get to know you and your product. A code review is usually the first step in that process.

Get in touch if you'd like to learn more about the support and operations provided by Apps with love, or if there's anything we can do to help!