A customer has used the same subscription app for two years.
At first, the experience is dependable enough that they barely think about the software itself. They open it, complete what they came to do and leave.
Then small problems begin appearing.
One month, the dashboard takes noticeably longer to load. A few weeks later, an update introduces a form error that forces the customer to repeat part of a task. Another release breaks notifications on their phone. The problems are eventually fixed, but a report they use every Monday continues timing out occasionally, so they learn to export the data another way.
None of these incidents is dramatic enough to trigger an immediate cancellation.
What changes is the customer's relationship with the product.
They stop assuming that an action will work the first time. Important tasks are double-checked. Workarounds become normal. When a competing product is suggested six months later, switching no longer feels disruptive; staying with the existing application already contains friction.
This is one of the most important ways application maintenance affects retention.
Users rarely experience “maintenance” as a technical activity. They experience its outcome as speed, reliability, correctness, compatibility, clarity and confidence that problems will be resolved when they occur.
When those qualities deteriorate repeatedly, customer experience deteriorates with them. Retention can eventually follow.
Nielsen Norman Group makes a useful distinction between upstream experience metrics—such as task success and error rates—and downstream business outcomes such as support demand, conversion and churn. The value lies in connecting those layers rather than treating usability and retention as unrelated measurements. Nielsen Norman Group: Connecting UX metrics to business outcomes
For Levelworks, that connection is reflected most clearly in User Friendly & Delightful App Health, supported by Performant, Error Free, Resilient and Supported. Maintenance protects those qualities after launch, when real usage and years of change begin testing them.
Engineering teams may classify maintenance work as:
Users do not experience those categories.
They experience:
“Checkout failed again.”
“This report takes forever.”
“The app freezes on my phone.”
“I have to contact support every time I do this.”
“This feature used to work.”
This difference in perspective matters when maintenance is prioritized.
A database optimization may look like infrastructure work internally, but if it reduces the time users spend waiting for their account dashboard, it is also customer-experience work.
Fixing a recurring authentication defect is technically corrective maintenance, but to a customer it means no longer wondering whether they will be able to access the service.
The business value of maintenance therefore becomes clearer when technical issues are traced to customer journeys rather than discussed only in engineering terms.
Slow performance creates friction every time the affected workflow is used.
One slow screen may seem minor. If a customer opens that screen 30 times a day, it becomes part of their overall judgment of the product.
Google's web-performance guidance explicitly connects performance with user experience and retention, noting that fast, responsive sites engage and retain users better than experiences that are slow or sluggish. It also emphasizes that performance should be assessed from the user's perspective rather than through one technical load-time number. web.dev: Why speed matters
This is particularly important because performance degradation often develops gradually.
As an application grows:
Users notice the accumulated delay before a product team necessarily declares a “performance incident.”
Maintenance protects the experience by identifying and correcting those regressions before slowness becomes accepted as normal.
[Internal Link: “Why Is My App Slow? 10 Common Causes of Poor Application Performance”]
Customers rarely evaluate reliability through an uptime percentage.
They evaluate it through repeated experiences.
Can they submit the payment?
Does the document upload finish?
Will their changes still be there tomorrow?
Does the report run when their manager needs it?
An application can have high overall availability and still create a poor experience if important workflows fail intermittently.
The effect becomes particularly damaging when failures appear unpredictable. Users begin compensating for the application: refreshing pages, saving work elsewhere, repeating actions or avoiding features they no longer trust.
Mobile-platform quality systems provide a useful example of how closely stability is tied to user-facing quality. Google's Android vitals tracks user-perceived crashes, ANRs, performance and other technical quality signals specifically to help developers improve user experience. Google Play can also reduce an application's visibility when certain user-perceived crash or ANR thresholds are exceeded. Android Developers: Android vitals
Apple makes a similar connection in App Store Connect. Its usage analytics lets developers examine retention, deletions, crashes and usage by app version, device and platform version, allowing teams to investigate whether engagement or stability changed after a release. Apple Developer: App usage analytics
The lesson is not that one crash automatically creates churn.
It is that stability and engagement should be examined together because repeated technical failures shape the experience users are deciding whether to return to.
Users generally understand that software can have defects.
Their confidence changes when the same type of failure keeps returning.
Imagine a customer encounters a duplicate-record bug.
Support resolves it.
Two months later, another release reintroduces the problem.
The third occurrence communicates something beyond the individual defect: the application does not appear to be learning from its failures.
Good maintenance closes that loop.
A production bug should ideally produce not only a code fix but enough investigation and regression protection to reduce the chance of recurrence.
When repeated problems are allowed to return, users gradually become responsible for protecting themselves from the application.
They may:
Those behaviors represent experience cost even when the application is technically usable.
[Internal Link: “Why the Same Bugs Keep Coming Back and How to Stop Them”]
An application's experience is not identical for every customer.
Different users may have:
A product team can therefore see healthy aggregate metrics while a meaningful customer segment is having a poor experience.
Suppose a release works well for 98% of users but creates repeated crashes on one widely used Android device family.
The overall crash rate may initially look manageable.
For users with that device, however, the experience is not “98% healthy.” Their version of the application is unreliable.
Android vitals explicitly provides per-device quality reporting for this reason, allowing developers to identify cases where a particular device model experiences much worse crash or ANR behavior than the application overall. Android Developers: Monitoring app crashes
Maintenance therefore needs enough segmentation to detect concentrated problems.
A compatibility issue affecting a minority can still represent a severe customer-experience failure for that minority.
Customer experience can deteriorate even when performance and reliability remain technically healthy.
New features are added.
Forms become longer. Navigation expands, terminology drifts and formerly simple workflows acquire additional decisions.
The application becomes more capable while individual users may find it increasingly difficult to accomplish familiar tasks.
This is where UX maintenance becomes relevant.
The goal is not perpetual cosmetic redesign. It is identifying places where accumulated product change has increased effort, confusion or inconsistency.
Useful evidence might come from:
This work directly supports retention because a user does not evaluate a product only by what it can theoretically do.
They evaluate how much effort it takes them to receive the value they came for.
[Internal Link: “UX Maintenance: Why User Experience Needs Maintenance Too”]
Not every problem can be prevented.
What happens after a customer encounters one matters too.
Consider two customers who encounter the same defect.
The first reports it, receives a useful response, gets a workaround and sees the underlying issue corrected shortly afterward.
The second repeatedly explains the same problem to different people and receives temporary instructions while the defect remains in the product.
They technically experienced the same bug.
They did not experience the same company.
Support therefore should not operate entirely separately from application maintenance.
The GOV.UK Service Manual recommends tracking support contacts and using them to improve the underlying service. It goes so far as to recommend treating enquiries as potential faults because repeated requests for help can indicate problems in the service rather than merely problems with users. GOV.UK: Set up and manage user support
This creates a valuable maintenance loop:
Customer problem
↓
Support interaction
↓
Recurring pattern identified
↓
Product / technical investigation
↓
Underlying problem fixed
↓
Future support demand reduced
Support should not permanently compensate for a fixable product problem.
Churn is usually a late signal.
By the time a customer cancels, the application may have been disappointing them for months.
Earlier signs can include:
Apple explicitly treats ratings and reviews as feedback about customers' experience with an app and notes that developers can respond to reviews to build rapport with people using the product. Apple Developer: Ratings, reviews, and responses
Those signals are useful because retention should not be treated as something that appears only on a subscription dashboard.
Experience deteriorates upstream first.
Suppose the maintenance team reports:
Those metrics can indicate useful work.
They do not automatically tell you whether customers experienced the improvement.
Connect technical maintenance metrics to customer outcomes.
For example:
Maintenance signal
Experience signal
Retention-related signal
Crash rate
Successful sessions
Return rate
API latency
Task completion time
Workflow reuse
Defect rate
User errors / failures
Support contacts
Availability
Successful transactions
Active usage
Compatibility issue rate
Device-specific success
Retention by device/version
UX improvement
Task success
Feature adoption
Do not expect perfect one-to-one causality.
A retention change may also reflect pricing, competition, seasonality, marketing or product value.
The goal is to investigate whether experience changes and business outcomes move together, rather than declaring every technical improvement responsible for retention.
Nielsen Norman Group's recent guidance uses the same upstream/downstream framing: task success and error metrics help explain experience quality, while measures such as retention and churn show the downstream business outcome. Nielsen Norman Group: Stop reporting UX activity and report business outcomes
Aggregate retention can hide maintenance problems.
Suppose 30-day retention remains stable overall.
Now segment users by application version.
Users on Version 8.2, which introduced a performance regression, may be returning less frequently than users on Version 8.1 or 8.3.
Other useful comparisons include:
Apple's App Store analytics is designed to support some of this investigation by allowing usage and stability metrics to be filtered by app version, device and platform version.
This is far more useful than asking broadly:
“Did retention decline this month?”
The stronger maintenance question is:
“Did the people who received a worse technical experience behave differently afterward?”
Maintenance backlogs can easily contain hundreds of items.
Not every issue deserves equal urgency.
A defect affecting three administrators once a year may reasonably sit below a performance regression affecting every customer's primary workflow.
A practical prioritization model can consider:
How many customers encounter the problem?
How often do they encounter it?
Is it mild friction, task failure or data loss?
Does it affect a secondary feature or the reason customers use the application?
Can users continue immediately, or must they contact support or recreate work?
Is this a one-off problem or something customers have experienced repeatedly?
This turns maintenance prioritization from:
“Which bug is technically most interesting?”
into:
“Which unresolved problem is doing the most damage to the customer's experience?”
That is a much stronger basis for protecting retention.
When customers consistently discover application problems before the maintenance team does, customer experience has already paid the price.
Monitoring should detect important failures through signals such as:
For user-facing applications, those technical signals should be connected to the journeys they affect.
A spike in HTTP errors matters more when you know it represents customers failing to submit orders.
A latency regression becomes easier to prioritize when you know it affects the account dashboard used in every session.
[Internal Link: “How to Detect App Problems Before Your Users Report Them”]
Maintenance becomes much more customer-centered when teams can detect degradation before large numbers of users have to explain it through tickets and complaints.
A major outage is visible.
Ten smaller problems spread across six months can be more difficult to see as one experience.
Yet the customer experiences the accumulation.
This month the application is slower.
Next month an integration fails twice.
Later, a redesign moves a familiar function.
Then support takes several days to resolve a recurring problem.
Each event may have a different internal owner and a different ticket.
The customer does not organize their experience that way.
They simply develop an impression:
“This product has become difficult.”
That is why maintenance reviews should occasionally step above individual incidents and ask whether certain customer groups are repeatedly absorbing technical friction.
The risk to retention often lies in accumulation rather than one catastrophic event.
Healthy applications still encounter incidents.
A resilient customer experience therefore is not one in which failure is impossible. It is one in which failures are limited, detected quickly, recovered cleanly and handled transparently enough that users can continue trusting the service.
For example, compare:
An application fails, retries the customer's payment unpredictably and leaves them unsure whether they were charged.
with:
The payment service is temporarily unavailable, the transaction is not submitted twice, and the user receives a clear message explaining that they can retry safely.
Both involve a dependency failure.
Only one turns the technical problem into significant customer uncertainty.
Maintenance of failure handling, monitoring and recovery therefore affects experience even when the underlying outage originates outside your application.
A maintenance program should certainly measure technical health.
But technical improvements ultimately matter because they preserve the application's ability to serve people and businesses reliably.
For Levelworks, that is why App Health connects technical condition with user experience.
Performant means important interactions do not gradually become frustratingly slow.
Error Free means known defects are investigated and prevented from repeatedly interfering with customer tasks.
Resilient means failures do not unnecessarily become broader customer disruption.
Supported means users have a dependable path to resolution when problems do occur.
And User Friendly & Delightful means years of product evolution do not quietly turn familiar tasks into confusing ones.
These qualities reinforce each other. A beautiful interface cannot compensate indefinitely for crashes, while a perfectly stable system can still lose users if basic workflows become unnecessarily difficult.
A customer does not remain loyal because the application worked well on the day they bought it.
The product has to continue earning that decision.
Every successful login, quick search, reliable transaction and resolved problem reinforces confidence that the application will do what the customer expects.
Poor maintenance works in the opposite direction. Slowness becomes normal, recurring bugs create workarounds, incompatible devices leave some users behind, and unresolved support patterns communicate that known friction is simply part of using the product.
Eventually, switching can feel easier than continuing to compensate.
That is why app maintenance should not be viewed purely as preserving software.
It preserves the experience customers originally agreed to keep paying for, returning to or relying on.
The most useful question is therefore not simply:
“Is the application technically healthy?”
It is:
“Are our maintenance decisions helping customers complete important work reliably enough that continuing to use this product remains the easier choice?”
When maintenance is evaluated through that lens, retention stops looking like a distant marketing metric and becomes something engineering, product, design and support influence every time they decide which problems are worth fixing.
