Launching is only the beginning: why product support matters more than it seems

When a business orders development, all the attention is focused on the launch: the release date, the development budget, the feature set of the first version. Support is discussed in passing or not at all. "We will figure it out after launch."

This is one of the most common mistakes in working with digital products. The launch is not the finale. It is the point at which the product's real life begins. And what happens after it largely determines whether the development was an investment or just an expense.

What happens to a product without support

Platforms update, the product breaks

Apple releases a new version of iOS. Google updates Android. Browsers change standards. Every such update can break something in your product, from visual glitches to the complete failure of certain features. An app that is not updated will sooner or later start working incorrectly, and the app stores restrict or remove apps that have not been updated for a long time and do not meet current requirements.

In Kazakhstan local systems add to this. A bank updates its acquiring API, the terms of working with Kaspi change, a new version of the 1C configuration comes out, the exchange formats of the ESF e-invoicing system change. Each such change can quietly stop payments, order exports or documents if nobody is watching the integration.

Technical debt accumulates

Code written today starts becoming outdated tomorrow. Libraries release new versions that fix vulnerabilities. Dependencies become incompatible. Without scheduled maintenance, technical debt accumulates to the point where any change to the product becomes risky and expensive, because no one understands what affects what any more.

Security degrades

Vulnerabilities in libraries are discovered regularly. Without timely dependency updates, your product becomes a target. For financial services, healthcare or any product handling personal data, this is not an abstract risk. The Law of the Republic of Kazakhstan On Personal Data and Their Protection requires whoever collects and stores data to take measures to protect it, so a neglected server full of customer data is a direct legal liability. Check with a lawyer what exactly is required of your company.

Bugs go unresolved

Every product reveals bugs after launch, and that is normal. The question is how quickly they get fixed. Without dedicated support, every bug turns into a separate project: finding a contractor, giving them time to understand the code, agreeing on a price. While the fix is being negotiated, customers run into the problem and leave.

Support is not just "fixing it when it breaks"

Reactive support, fixing what is already broken, is the bare minimum. A product that is only repaired but never developed gradually loses to competitors who add new features and improve the user experience.

Professional support includes several levels.

Monitoring and proactive response

The system tracks the product's health in real time: server response speed, errors in the logs, anomalies in user behaviour, failures in the exchange with 1C or the bank. A problem is detected and begins to be addressed before users start complaining. This is a fundamentally different level of reliability compared with "a customer wrote on WhatsApp that something is not working".

Scheduled updates

Regular dependency updates, adaptation to new platform versions, performance optimisation as the load grows. These are not emergency tasks; they are scheduled maintenance that prevents emergencies.

Feature development

The business changes, and the product should change with it. New integrations, additional scenarios, new channels such as WhatsApp or Telegram, a second interface language, expansion to other cities. The team that originally built the product does this faster and cheaper: it knows the architecture and does not waste time getting up to speed from scratch.

Why switching teams after launch is expensive

A common scenario: one team builds the product, and support is handed to another because it is cheaper. At first glance it is logical. In practice, the new team spends weeks, sometimes months, figuring out someone else's code. During that time it works slowly and with a high risk of errors, not because it is bad, but because it does not know the product.

The cost of handing a project to a new team is the time to get up to speed plus the risk of errors when changing unfamiliar code. In most cases, the savings on support are eaten up by exactly these hidden costs.

The team that built the product knows every architectural decision and the reason it was made. In that case, support is not a handover but a continuation of the work. The response is faster, the risks are lower and the cost of changes is more predictable.

That said, depending on a single vendor is not wise either. The code, server access and store accounts should be yours, and the architecture should be documented well enough for another team to take over if needed. We cover this in detail in custom software and vendor independence. With us, the code and access are handed over to the client after delivery.

How to plan support properly

Before launch, not after

The conversation about support should happen before signing the development contract, not after the release. It affects architectural decisions: a product designed with long-term support in mind is built differently from one thought of only as a one-off build. For example, logging, monitoring and clear settings for the exchange with 1C and the bank are built in from the start.

Set an SLA

A Service Level Agreement defines the response time for incidents of varying severity and the time to resolve them. Without an SLA, support works on a "when we get to it" basis. With an SLA, it is a contractual obligation. For products that a business process depends on, that is a fundamental difference.

Separate support and development in the budget

These are two different types of work with different costs and priorities. Support is the mandatory work of keeping things running. Development is an investment in new capabilities. When they are mixed in one pool, they are hard to plan and prioritise.

What you should have in your own hands

Whoever supports the product, your own team or a contractor, check that the company has everything it needs for the product to survive a change of people:

• Code and repository. Owner access to the repository, not only the developer's.
• Server and domain. Access to hosting, the database, backups and the domain registrar, registered to the company. Remember that customers' personal data is stored on a server in Kazakhstan.
• App store accounts. Apple Developer and Google Play Console in your company's name, not on a developer's personal account.
• Integration keys. Access to the APIs of the bank, Kaspi, 1C, the CRM and messaging services, and a clear picture of who holds them and when they expire.
• Documentation. A short description of the architecture and integrations: what exchanges data with what, and how often.
• A calendar of routine work. Renewing the domain, certificates and subscriptions, rotating keys, the yearly iOS and Android updates.

What support costs

There is no single price for support: it depends on how many integrations and users the product has, how critical it is to the business and how often it changes. That is why we agree the format and cost of support and maintenance after an audit: we look at the code, the server, the integrations and what you plan to change.

Support without development is cheaper. Support with active feature development costs more, but at that point it is no longer a cost line; it is an investment in the product's competitiveness.

The right question when planning the budget is not "how much does support cost" but "how much does the absence of support cost". An hour of downtime for a revenue-generating product is a direct loss: payments stop going through over the weekend, orders no longer reach 1C, the app will not open after an iOS update. The reputational damage from a public outage is harder to calculate, but just as real.

Do not confuse support with the warranty. After delivery our six-month warranty covers the agreed scope, but it covers the work under the contract, not OS updates, monitoring or new features. We list a product's running costs before the project starts and cover them in more detail in how much it costs to build an app in 2026. If the product is a mobile app, it is convenient to discuss support right away when ordering app development.