{"id":28675,"date":"2026-08-15T15:41:00","date_gmt":"2026-08-15T14:41:00","guid":{"rendered":"https:\/\/www.web-systems.pl\/how-much-application-maintenance-costs-after-launch\/"},"modified":"2026-08-15T15:41:00","modified_gmt":"2026-08-15T14:41:00","slug":"how-much-application-maintenance-costs-after-launch","status":"publish","type":"post","link":"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/","title":{"rendered":"How much does it cost to maintain an application after go-live, and why nobody talks about it"},"content":{"rendered":"\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Spis tre\u015bci<\/p>\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/#Going_live_is_not_the_end_of_the_project_only_the_beginning_of_its_costs\" >Going live is not the end of the project, only the beginning of its costs<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/#What_the_cost_of_maintaining_an_application_is_really_made_of\" >What the cost of maintaining an application is really made of<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/#Technical_debt_or_the_bill_paid_with_a_delay\" >Technical debt, or the bill paid with a delay<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/#Security_and_compliance_require_constant_work_not_a_one-off_audit\" >Security and compliance require constant work, not a one-off audit<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/#Integrations_and_APIs_the_most_common_source_of_unplanned_work\" >Integrations and APIs: the most common source of unplanned work<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/#Scaling_and_data_or_the_cost_that_grows_along_with_success\" >Scaling and data, or the cost that grows along with success<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/#How_to_plan_a_maintenance_budget_sensibly\" >How to plan a maintenance budget sensibly<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.web-systems.pl\/en\/how-much-application-maintenance-costs-after-launch\/#Summary_maintenance_decides_whether_the_application_pays_for_itself\" >Summary: maintenance decides whether the application pays for itself<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Going_live_is_not_the_end_of_the_project_only_the_beginning_of_its_costs\"><\/span>Going live is not the end of the project, only the beginning of its costs<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A conversation about an application usually ends at the launch date. The client gets a proposal split into stages, with deadlines and a price for building the thing, and then silence. The document says nothing about what happens the day after go-live. And that is exactly when the longest phase of the system&#8217;s life begins, the one that will last longer than the build itself and will swallow more money in total. Maintenance is not an add-on to the project. It is its continuation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Why does this happen? Software does not wear out physically, but it ages relative to its surroundings. Browsers change, framework versions change, so do the requirements of mobile operating systems, the terms of payment providers and data protection regulations. The application stands still, the world around it moves forward, and the gap between them grows every month. After a year without care, even a stable system starts generating problems nobody planned for.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">From the vendor&#8217;s perspective the matter is clear: the project budget and the maintenance budget are two separate items, settled differently and serving different purposes. The first one is one-off and finite, the second one is recurring and entirely predictable, as long as somebody does the math up front. The trouble is that sales conversations focus mainly on the first, because a lower implementation price looks better in a side-by-side comparison of offers. And it is not always bad faith. More often, nobody simply asks.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The consequences can be painful. A system that gets no regular attention ages faster than the investment can pay for itself. Small defects pile up, users lose trust in the tool, and the client&#8217;s own team starts avoiding the application and going back to spreadsheets (I have seen this more times than I would care to remember). In the extreme scenario, after two years the company pays a second time for the same thing, only now under the heading &#8220;rewrite from scratch&#8221;. That sum never appeared in the original business case.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"What_the_cost_of_maintaining_an_application_is_really_made_of\"><\/span>What the cost of maintaining an application is really made of<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The question &#8220;how much does it cost to maintain an application&#8221; has no single answer, but it does have a clear structure. There are several components and each behaves differently: some grow linearly with traffic, some are fixed, and some appear in jumps, at moments nobody can predict to the day. Breaking this down into categories gives you more than a price range, because it lets you check what a specific proposal is missing.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The first layer is infrastructure. Application servers, the database, file storage, transfer, backups and, something people often forget, a separate test environment where changes are verified before they reach users. Skipping it looks like a saving. Right up to the first outage caused by a fix uploaded straight to production.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The second layer is external services, billed most often on a subscription or usage basis. The payment gateway, maps, SMS delivery, transactional e-mail, monitoring tools, and more recently also language models, where the bill depends on the number of tokens processed. That last item can catch you out, because it scales with how popular a feature is, not with the number of accounts in the system.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The third layer is people&#8217;s work. Monitoring and responding to alerts, updating libraries, fixing bugs reported by users, small functional changes driven by current business needs. The most flexible item in the whole list and, well, the one people most often try to cut.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The fourth layer is invisible on any invoice, although for some clients it genuinely costs the most:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Infrastructure:<\/strong> servers, database, storage, transfer, backups, test and staging environments<\/li>\n<li><strong>Licenses and external APIs:<\/strong> payments, maps, SMS, transactional mail, usage-billed AI models<\/li>\n<li><strong>Technical team&#8217;s work:<\/strong> monitoring, updates, hotfixes, support, small improvements<\/li>\n<li><strong>Hidden costs on the client&#8217;s side:<\/strong> staff time spent handling tickets, verifying data, training new people<\/li>\n<li><strong>Risk:<\/strong> hours of downtime, working around the process by hand, lost orders<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Being aware of these five groups changes the way you read a proposal. Instead of asking about the price, you ask about the scope.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Technical_debt_or_the_bill_paid_with_a_delay\"><\/span>Technical debt, or the bill paid with a delay<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Every project delivered in a reasonable timeframe contains compromises. With an MVP that is actually a sensible strategy: we are testing a business hypothesis, so we skip part of the tests, simplify the code structure, deliberately leave logic where it should not end up long term. As long as the decision is conscious and written down, everything is fine. It gets worse when the shortcuts stop being temporary and nobody remembers they were ever taken.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The symptoms are plain to see at the first code review. All the business logic crammed into controllers. The same fragment copied in five places with slight differences. Zero automated tests, zero deployment documentation. The result is always the same: every subsequent change takes longer than the previous one, because the developer first has to reconstruct how the system works in their head and then manually check that nothing broke. The client sees only rising quotes for simple things, and gets rightly annoyed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Outdated dependencies are a separate thread. The framework ships new versions, libraries get fixes, the runtime environment reaches end of support. A migration done as you go, version by version, is usually a few hours of work and a short test. The same migration put off for three years? A jump across several releases at once, backward-incompatible changes and weeks of team effort, because half the packages in use have vanished or changed owner in the meantime.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The most common mistake looks like this: updates get postponed until something stops working. Suddenly you cannot ship a fix, because the hosting provider switched off the old version of the runtime. Or a publicly documented vulnerability turns up in a library nobody has touched since launch. And then work that could have been spread across calm quarters happens under pressure, in emergency mode. That is why with <a href=\"https:\/\/www.web-systems.pl\/en\/software-development\/\">custom software development<\/a> it is worth agreeing right away who watches dependency versions, and at what cadence.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tip:<\/strong> book a fixed, recurring slot for updates &#8211; a few hours a month or one day a quarter. Regular small steps cost a fraction of one big migration done when there is no other option left.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Security_and_compliance_require_constant_work_not_a_one-off_audit\"><\/span>Security and compliance require constant work, not a one-off audit<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A security audit before launch is good practice, but it sometimes gets treated as a certificate valid indefinitely. And yet most of the vulnerabilities that will affect the application did not exist at go-live, or were not publicly known. Somebody discovered them later in a library the system uses, described them, published a fix, and that is when the race against time began. A report from a year ago describes the state of things a year ago. That is all.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Maintaining security is a set of repeatable activities written into the calendar. API keys and integration tokens have to be rotated, because over time they end up in too many places: documentation, messages, configuration files on the laptops of former contractors. Permissions in the admin panel need periodic review, because companies grow and people change roles, while an administrator account stays with them long after it stopped being needed. Certificates expire at the least convenient moment, usually at the weekend, so their renewal should be automated and watched by an alert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Backups deserve their own paragraph, because this area is full of illusions. The mere fact that a backup runs and takes up disk space says absolutely nothing about how useful it is. The only copy with any value is one from which a working system was actually restored &#8211; in a reasonable time, on a clean environment, with the full set of data. A restore test run once a quarter turns a theoretical safeguard into a real one. Without it, the first attempt at recovering data happens during an outage, meaning under the worst possible conditions.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">On top of that comes the compliance layer. Personal data protection, retention rules, logging access to sensitive information, being able to document who reached for a client&#8217;s data and when. This requires ongoing attention, not ticking one item off a list before launch. Regulations change, so do processes inside the company, and the application has to keep up with them. Neglecting this layer costs incomparably more than watching it systematically.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Integrations_and_APIs_the_most_common_source_of_unplanned_work\"><\/span>Integrations and APIs: the most common source of unplanned work<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">If you had to name one area that generates the most work nobody foresaw when the contract was signed, it would be integrations. An application rarely lives in isolation. It talks to a payment gateway, a warehouse system, accounting software, a courier, a CRM, an e-mail delivery tool. Each of those connections is a dependency on decisions made outside the project, by people who have no idea our system exists.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Providers of external APIs do exactly what you would expect from growing companies: they release new versions, retire old endpoints, change response formats, introduce request limits or raise authentication requirements. They usually announce it in advance, in a post on the developer blog or by e-mail to the technical address given at registration. Which address tends to be a mailbox nobody ever opens. So the information arrives only when the integration stops working.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The client&#8217;s internal systems behave in much the same way. The ERP gets an update from its vendor, the warehouse software changes its export structure, accounting moves to a new version, and suddenly the file we have been parsing for two years has differently named columns. Nobody warned anybody, because within the company those departments have no reason to talk to each other about data formats.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A fresh variant of the same problem is AI models. Providers retire older versions, replace them with newer ones whose responses behave differently, and change how usage is billed. A prompt fine-tuned for one model can, after a swap, return results in a different format, which throws the whole process off when responses are processed automatically. For that reason <a href=\"https:\/\/www.web-systems.pl\/en\/development-of-artificial-intelligence-based-applications\/\">AI-based applications<\/a> require a planned budget for regular prompt testing and model swaps.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The architectural decision that genuinely lowers this cost is trivially simple: do not scatter calls to an external API all over the code. One intermediate layer, one point where we translate the provider&#8217;s format into our internal model. Then a change on the other side means a fix in one file, not archaeology across twenty.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tip:<\/strong> subscribe to change notifications from every provider and route them to a mailbox somebody actually reads. An integration is not a feature finished at handover, it is an element that needs watching throughout the system&#8217;s entire life.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Scaling_and_data_or_the_cost_that_grows_along_with_success\"><\/span>Scaling and data, or the cost that grows along with success<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">There is a certain paradox in maintenance: the better the business does, the more technical work the application requires. A query that ran instantly on a thousand records can freeze the interface at a million. Nothing broke, nobody made a mistake. The characteristics of the data simply changed, and with them the way the database picks its execution plan. A report that used to generate in the background unnoticed suddenly becomes the most frequent subject of support tickets.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">So the database needs ongoing care. Indexes matched to real usage patterns, not to what was imagined at the design stage. Archiving historical data so that operational tables do not swell indefinitely with orders from five years ago. Cleaning up what has accumulated: orphaned records, duplicates from failed imports, logs kept with no retention policy at all. This work does not add a single feature visible to the user, and yet it decides whether the system stays usable.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A separate topic: traffic that varies over time. A store before the holidays, a booking system in high season, a training platform at the start of the year &#8211; the load can change several times over within a single week. Keeping compute capacity sized for the peak all year round means paying for thin air most months. A more sensible option is an architecture that lets you scale up for the peak and back down afterwards, though this requires design decisions made in advance. Not every application can be run that way without rework.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Monitoring ties all of this together. Collecting metrics, alerts on response time, free disk space, job queues, errors in the logs. It seems unnecessary as long as everything works. But the difference is fundamental: either the technical team catches the problem while it is still building up, or they hear about it from an angry client when the process has already been down for an hour. The second option costs many times more, once you count reputation as well.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"How_to_plan_a_maintenance_budget_sensibly\"><\/span>How to plan a maintenance budget sensibly<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A good maintenance contract starts with precision in describing the scope. Most misunderstandings come from the two sides reading the word &#8220;support&#8221; differently: the client as readiness for anything, the vendor as responding to critical outages. So agree in black and white what the response time and the resolution time are, during which hours they apply, what counts as a defect covered by the contract and what counts as new functionality billed separately.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">From experience: the cleanest model is to separate three funding streams. Technical maintenance, meaning infrastructure, updates, backups and monitoring &#8211; a fixed amount, predictable for both sides. Bug fixing, meaning removing defects in what was already accepted. And development, meaning a pool of hours for new features and changes driven by current needs. When everything comes out of one pot, development always beats updates, because it is visible immediately, while the effects of neglected maintenance only show up a year later.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The second thing to secure at the start is independence. Access to the code repository, to the hosting accounts, to the domains and to the deployment documentation should sit on the client&#8217;s side from day one. Not because you are planning to change vendors. Because any supplier can disappear, and the system has to outlast the commercial relationship. A company that has no objection to such an arrangement is signalling that it intends to keep the cooperation through quality rather than lock-in.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Before you sign the contract, ask a few questions:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>What exactly does the monthly fee cover, and what is billed on top?<\/li>\n<li>What is the response time for a critical outage and during which hours does it apply?<\/li>\n<li>Who owns the code, the hosting accounts and the domains?<\/li>\n<li>What does the dependency update process look like and who pays for it?<\/li>\n<li>Are backups tested by restoring them, and how often?<\/li>\n<li>What happens to the system if we end the cooperation?<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tip:<\/strong> calculate the maintenance cost before you start, at the technology selection stage. An exotic stack can be cheaper to build and more expensive across the next five years, because it is harder to find people who understand it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Summary_maintenance_decides_whether_the_application_pays_for_itself\"><\/span>Summary: maintenance decides whether the application pays for itself<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">An application left without care loses value faster than it can repay the cost of building it. That sounds harsh, but it describes a mechanism that repeats across projects regardless of industry and scale. The system works until its surroundings change, and then the slide begins: small defects, slower operation, a broken integration, a feature that can no longer be updated without rewriting half the code. Each of those stages eats into a budget nobody planned for, because the original return calculation listed only the implementation cost.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That is why an honest conversation about maintenance costs should happen at the very beginning, while the technology and the MVP scope are still being chosen. A client who knows what infrastructure, technical care and a pool of development hours will cost per month decides with the full picture in front of them. It protects their budget from surprises, and the relationship with the vendor from the worst-case scenario, in which every piece of necessary technical work turns into a dispute. Predictability pays off for both sides.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">At Web Systems we approach this from the perspective of a team that has been designing and delivering web and mobile applications, B2B systems, API integrations, automations, e-commerce and AI-based solutions since 2006. Over that time we have taken over enough systems from other vendors to know where the problems accumulate: in skipped updates, in external API calls scattered across the code, in untested backups and in missing documentation. That is why we plan the architecture with what happens after launch in mind, not just with the handover date.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Are you planning a new application, an MVP, a systems integration, process automation, an AI rollout or a modernization of a solution that has stopped keeping up with your company? Write to us. We will gladly calculate not only the cost of building it, but also the real cost of maintaining it in the years that follow, so that you can make your decision based on the full sum rather than just its first part.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Going live is not the end of the project, only the beginning of its costs A conversation about an application usually ends at the launch date. The client gets a proposal split into stages, with deadlines and a price for building the thing, and then silence. The document says nothing about what happens the day [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":28578,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[217,116,406],"tags":[742,714,125,581,294,796,707],"class_list":["post-28675","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-biznes","category-it","category-programowanie","tag-budzet","tag-koszty-it","tag-oprogramowanie","tag-poradnik","tag-rozwoj-aplikacji","tag-utrzymanie-aplikacji","tag-wdrozenie"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts\/28675","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/comments?post=28675"}],"version-history":[{"count":0,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts\/28675\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/media\/28578"}],"wp:attachment":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/media?parent=28675"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/categories?post=28675"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/tags?post=28675"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}