App maintenance looks after an existing product through defined fixes, upkeep and agreed small improvements. App development can also introduce new screens, workflows, integrations or substantial capabilities. The boundary depends on the actual work, so a clear scope matters more than the label attached to a request.
In this guide
A “small feature” can require a large change behind the interface. Equally, a useful improvement may fit within an existing screen and use data the app already has. Understanding the difference helps you plan a realistic maintenance queue.
A fix restores expected behaviour
A bug fix addresses something the app should already do. For example, a form may reject a valid input or a button may fail to open the intended screen.
Before accepting the work, the team needs to reproduce or review the problem and agree what a successful fix looks like. One visible symptom does not establish one small task. The cause could sit in shared code, a backend service or an external integration.
Use a precise description: the current behaviour, expected behaviour, affected workflow and safe test example. This makes the scope easier to assess and the result easier to approve.
A small change adjusts existing functionality
Small improvements can include contained changes to wording, layout or behaviour within an existing screen. They still need boundaries: where the change applies, which platforms are included and what should remain consistent.
“Change the confirmation message on this screen” is a clearer starting point than “improve the whole checkout experience”. The latter may include research, design, business rules, integrations and extensive testing.
Avoid splitting one substantial project into many tiny labels to make it appear to fit a maintenance allowance. The total dependency and testing scope still exists.
A micro-feature adds a bounded new capability
In Afiniti Global’s care plans, a micro-feature is a small new capability within an existing screen or workflow, using existing data and services, with one agreed acceptance criterion.
Illustrative candidates include a filter on an existing list, a sort option or a display toggle. Each is subject to review. A proposed filter may cease to be a micro-feature if it needs new data collection, a new service or substantial backend work.
App Care includes one micro-feature per month in addition to its allowance of up to 10 accepted small changes and fixes. Care Plus includes two micro-features in addition to up to 20 accepted small changes and fixes. Micro-features do not consume those ordinary change slots.
Larger development needs its own scope
New screens, new integrations, substantial features, redesigns, major migrations and architecture changes need a separate fixed quote under Afiniti Global’s plans.
| Illustrative request | Likely scope to discuss |
|---|---|
| Correct a reproducible validation error on one existing screen | Contained fix, subject to investigation |
| Adjust wording and layout in one agreed area | Small existing-screen change |
| Add a sort option using existing list data | Possible micro-feature |
| Add a new payment provider | Separate integration project |
| Introduce a new reporting screen and data model | Separate development project |
| Move the app through a major framework migration | Separate upgrade project |
These are scoping examples, not advance acceptance of a specific request. The team must review the app and dependencies before confirming the work.
Write a request the team can evaluate
A useful request contains four parts: where the change belongs, what should change, what existing data or services it uses and how you will recognise completion.
For example: “On the existing jobs list, let staff sort by the date already shown on each record. Keep the current default order until the user selects the new option. Confirm the agreed ordering on the supported platforms.”
That example gives the team enough context to assess a possible micro-feature. It also leaves room to identify a hidden constraint before work begins.
Understand how the monthly queue works
Afiniti Global uses one prioritised queue with one change or micro-feature active at a time. Unused monthly allowances expire. Accepted unfinished work carries forward without consuming another allowance in its category; timing still depends on scope, access and approvals.
A monthly allowance is therefore not a promise of simultaneous work or completion of every item within that month. Review existing commitments before adding new priorities. Extra work requires an approved fixed quote before it starts, rather than an automatic hourly overage.
Do both iOS and Android count as one micro-feature?
For Afiniti Global’s micro-feature allowance, agree the supported platforms and acceptance check before work starts. One agreed micro-feature across those platforms uses one micro-feature allowance. The scope must still meet the plan’s boundaries.
Can I use maintenance to launch a new product?
The standard care plans cover an existing mobile product. A new app, major new journey or substantial product expansion needs a development scope of its own.
Have a change in mind? Discuss it with the App Care team. Describe the existing workflow and the result you want, and establish the right scope before paid work starts.