Every feature you agree to is a decision to spend money every year, indefinitely, for as long as that feature exists. Almost nobody prices it that way.
The build cost is the visible number. It goes in the quote, it gets negotiated, and it gets paid. Then the feature ships and quietly joins a list of things that have to be kept working, kept tested, kept explained to new users, and kept compatible with platforms that change on their own schedule. That second cost never appears on any document, which is precisely why it never enters the decision.
This article is about how to make it enter the decision.
A feature is not paid for once
Software maintenance is not one activity. The international standard governing it, ISO/IEC/IEEE 14764 [1], exists specifically because maintenance is several distinct kinds of recurring work rather than a single line item. Broadly, and consistently across the standard's lineage: fixing defects found after release, changing the software because the environment around it changed, improving things that already work, and dealing with latent problems before they cause failures.
Every feature you ship contributes to all four, permanently.
There is a second mechanism, and it is the one that catches teams out. ISO/IEC 25010 [2] defines a product quality model in which maintainability is a named characteristic, on the reasoning that how easily a system can be analysed and modified is a real, measurable property rather than a feeling. As a system's surface area grows, that property degrades. Every feature is not an isolated addition sitting quietly in its own corner. It is a new case that every future change has to be checked against, and a new interaction that every test has to account for.
That is why a two-day change on a small product becomes a two-week change on a large one, doing the same thing.
The platform does not wait for you
Here is the part that turns this from a theoretical argument into a dated one.
A feature nobody has asked to change is not maintenance-free, because the platforms underneath it impose their own deadlines.
Apple requires third-party SDKs on a named list to ship a privacy manifest, and binary dependencies to carry a signature, with Xcode validating both at build time. The requirement applies when you submit a new app, or when you submit an update that adds one of the listed SDKs [3]. A feature built three years ago on a library that has since been added to that list does not stay finished. Your next update has to satisfy a rule that did not exist when the feature shipped.
Google Play runs a rolling target API level requirement. For the current cycle, new apps and updates must target Android 16, API level 36, from 31 August 2026, and existing apps must target Android 15 or higher by that date to remain visible to new users on newer Android versions [4]. Fall behind and the app stops reaching new users, regardless of how well it works for existing ones.
Neither of those is a hypothetical slippery slope. They are published dates, and they apply to every feature in your product equally, including the ones nobody uses.
The cost you can put a number on
Our own maintenance guide budgets fifteen to twenty-five per cent of build cost per year for keeping software alive [8]. Applied to a single feature, that is the clearest way to make the ongoing cost visible during the decision rather than after it.
A feature that costs AED 20,000 to build costs roughly AED 3,000 to AED 5,000 a year to keep working. Over three years, the maintenance approaches half the build cost again. Over five, it exceeds it. And none of that depends on whether anybody uses the feature, because the platform deadlines, the security updates and the regression tests do not check usage first.
That is the arithmetic to put in front of the person asking. Not "no", but "this is AED 20,000 now and around AED 4,000 a year forever, and here is what else we could do with that."
Interface attention is finite too
The other budget nobody counts is the user's attention, and both major stores treat spending it badly as a quality failure rather than a matter of taste.
Apple's review guidelines open the design section by saying plainly that simplicity and ease of use are minimum standards for approval rather than aspirations, and that an approved app still carries an ongoing obligation to remain functional and engaging, with degraded apps removable at any time [5]. Separate guidelines penalise undifferentiated addition directly, on the stated basis that opportunistically creating variants of what already exists degrades discovery and reduces overall quality [5].
Google Play's functionality policy sets a similar floor: apps must provide a stable, responsive and engaging experience, and apps that lack adequate utility or behave inconsistently with that are not allowed on the store [6]. Android's core app quality guidance separately checks consistency of experience across use cases and form factors as a quality item [7].
An important honesty note: those rules govern consumer apps distributed through those stores. They do not govern your internal admin tool, your B2B platform, or your operations dashboard. We cite them because they show how seriously the two largest reviewers in the industry treat interface accumulation as a genuine quality failure, with enforcement attached. The same mechanism degrades an internal tool exactly as much. It just does not have anyone grading it, which is usually worse rather than better.
Where the pressure actually comes from
Worth naming, because most advice on this topic treats it as a discipline problem when it is really an incentive problem.
The cost of saying yes arrives later and lands on somebody else. The cost of saying no arrives immediately and lands on the person saying it. A salesperson who agrees to a feature closes a deal this quarter; the engineer who maintains it inherits the consequence two years from now, quite possibly after the salesperson has moved on. Nobody has ever been thanked in a meeting for a feature they did not build, because the counterfactual is invisible.
That asymmetry decides more roadmaps than any framework does, and no amount of process fixes it if the person who says yes never sees the bill. Two things help. First, make the ongoing cost visible at the moment of the decision, in dirhams, using the maintenance percentage above, so the yes is priced rather than free. Second, put the decision and its reasoning in writing so that when the cost does arrive, it arrives attached to a decision somebody made deliberately rather than to a mystery.
Neither of those makes saying no easy. They make it legible, which is enough to change most outcomes.
The hardest case: one client wants it
Every other request can be judged on its merits against a notionally neutral user base. This one adds revenue risk, relationship risk, and the fact that the person asking is often the person who can end the contract.
Four questions separate the commercial pressure from the product decision, which by default get argued together and are what make this case genuinely hard rather than merely uncomfortable.
Would anybody else use this? If you can name a second plausible user and their use case, it is a feature. If the honest answer is that it is specific to how this one client runs their business, it is a customisation wearing a feature's clothing.
What happens when that client leaves? Every business loses its largest client eventually, through churn, acquisition, a change of buyer, or simply outgrowing the relationship. A feature justified entirely by one relationship becomes dead code the day that relationship ends. It will not be removed, because removing things is its own project with its own risk, and there is always a fear that somebody still depends on it.
Can it be configuration rather than code? A setting, a flag, or a field the client fills in themselves is a completely different cost profile. Configuration is maintained once, as part of a system that already exists. A one-off feature is maintained forever, on its own.
Could it be separate, priced work? Saying no to "in the core product, for everyone, forever" is not the same as saying no to the client's actual problem. Our guides on why app quotes vary and reading a software proposal both describe variations the same way: work outside the agreed shared scope gets its own price and its own decision. That is not a trick, it is how a maintained boundary is supposed to work.
Four answers that are neither yes nor no
Most feature arguments are really arguments about a false binary, in which the only options appear to be building it into the product now or refusing the relationship. There are four legitimate answers in between, and naming them removes most of the emotional weight.
Not yet, with a stated trigger. Not a deferral into silence. A specific, written condition that would change the answer: if three more clients ask, if usage of the adjacent feature crosses a number, once the integration it depends on ships. This converts a recurring argument into one decision that is revisited when the trigger fires rather than every time the requester remembers it.
Configuration rather than a feature. The most useful of the four, because it satisfies the request without adding a new permanent item to the maintenance list or a new branch to reason about.
A manual process while demand is tested. Somebody on the team does the thing by hand for the handful of clients who asked. A weekly export, a scripted report, a spreadsheet. Deliberately slower per instance, and that is the point: it caps the cost of being wrong about demand and produces real evidence of how often the thing is actually used before any code enters permanent maintenance.
A separate charge. It becomes scoped, priced work rather than an addition everyone pays for and you maintain forever. It also creates a genuine market test. If the client will not pay for it separately, that is real information about how much they value it, as against how easy it was to ask for free.
The five-question test
Short written answers, kept even informally, before anybody estimates anything.
Who asked? One person, one team, one client, or a pattern across several unconnected requesters. Count requesters, not requests, because three mentions from the same client is one signal and one mention each from three unrelated clients is something else entirely.
How many others would genuinely use it? An honest estimate rather than a hope.
What does it displace? Nothing is added into empty space. Every feature competes for the same engineering time, the same testing time, and the same finite interface attention. Naming the displaced thing forces the trade to be visible instead of assumed free.
What does it cost to maintain? Not the build cost. The recurring load, anchored at fifteen to twenty-five per cent of build cost per year.
What happens if you decline? Concretely. Does the requester leave, route around it manually, or simply never mention it again? This is usually the most clarifying of the five, because the imagined consequence of saying no is almost always worse than the real one.
Writing these down does two things. It makes the decision defensible later, on the basis of what was known at the time. And it removes recency and loudness bias, which between them settle more feature arguments than merit does.
Saying it well
Three parts, in this order.
Acknowledge the underlying need before addressing the request. The person asking has a real problem, and no to a specific implementation is not no to the problem being real. Naming their problem back to them, in their words, is what separates a considered decision from a dismissal.
Explain the trade rather than the refusal. The five questions in short form are the explanation: this is what it would cost to keep, this is what it would displace, this is who we think would use it. A refusal without visible reasoning reads as arbitrary regardless of how carefully reasoned it was.
Offer the alternative. This is the biggest single lever on how a no lands, because it converts a rejection into a different kind of yes: a trigger condition, a setting, a manual stopgap, or a priced engagement.
What never saying no actually does
The product gets slower to change, because more of it has to be understood before any single change is safe. It gets more expensive to test, because interactions multiply faster than the feature count. It gets harder for new users to understand, which is the exact failure both stores' quality standards describe.
And the parts nobody maintains do not sit quietly forever. A platform requirement lands, or a security update forces a dependency upgrade, or the accumulated weight makes an ordinary change impossible, and the reckoning arrives on somebody else's schedule rather than yours. By then it is rarely small.
We are not going to tell you that this always ends in a rewrite, because no standards body publishes that claim and we would be dressing up a pattern as a law. What we will say is that a system nobody can safely change tends to get replaced rather than repaired, and that decision is usually made under pressure rather than chosen calmly.
If you want help deciding
A technical review of a proposal or a specific scope starts from around AED 1,500 with us, which is the right size for a sanity check on one significant request before you commit. Scoping a feature properly, or one of its four alternatives, as a short paid discovery with a written specification you own, starts from around AED 4,000. A broader assessment and roadmap covering your whole feature set, including what to consolidate and what to remove, starts from around AED 10,000. Final pricing depends on scope, and these are our own figures rather than a market survey.
The free version costs two lines per request. Write down who asked, how many others would use it, what it displaces, what it costs to keep, and what happens if you decline. Do it before anybody estimates anything, and the arguments get considerably shorter.
References
- ISO/IEC/IEEE 14764:2022, software life cycle processes, maintenance
- ISO/IEC 25010:2023, systems and software quality models
- Apple, upcoming third-party SDK requirements
- Google Play Console Help, target API level requirements
- Apple, App Store Review Guidelines
- Google Play, functionality, content and user experience policy
- Android Developers, core app quality
- SKIMBOX, mobile app maintenance cost in Dubai
- SKIMBOX, why app quotes vary in the UAE
- SKIMBOX, how to read a software proposal
Platform requirements and dates accurate as of 23 August 2026. Apple and Google publish rolling schedules, so check the linked pages for the current table before planning against a date.
