Software Maintenance and Support Services: Fixes, Updates and Improvements for Your Web and Mobile Apps

Software maintenance and support services keep an application working, secure and current after launch. That means fixing bugs, updating the app when operating systems, browsers, app stores and third-party APIs change, keeping dependencies patched, improving speed, and helping users when something breaks. Our in-house engineers in San Francisco maintain web apps, mobile apps, AI apps and the integrations around them, both software our team built (200+ projects delivered) and software built by others after a code review. Support is billed per hour, with scope and response times set in a written agreement for each client, because a dispatch system for ambulance crews and an internal reporting tool need very different levels of cover.

Sources: ISO/IEC/IEEE 14764:2022, clause 3; Apple upcoming requirements; Google Play target API level requirements. All checked Oct 31, 2026.

What are the types of software maintenance?

The international standard for software maintenance, ISO/IEC/IEEE 14764:2022 (third edition, published January 2022), defines five maintenance types. Every change request can be classified as a correction or an enhancement and then as one of these types.

Type (ISO/IEC/IEEE 14764:2022)	Standard’s definition, short form	Reactive or proactive	Real example
Corrective	Modification after delivery to correct discovered problems	Reactive	A payment reminder sends twice; a form rejects valid phone numbers
Adaptive	Modification after delivery to keep the software usable in a changed or changing environment	Reactive	Rebuilding an iOS app with Xcode 26 for the App Store; moving to a new API version
Preventive	Modification after delivery to correct latent faults before they occur in the live system	Proactive	Fixing a query that will time out as data grows; renewing a certificate before it expires
Perfective	Modification to provide enhancements for users, improve information for users, or improve performance, maintainability or other attributes	Proactive	Speeding up a slow dashboard; refactoring a module nobody can safely change
Additive	Modification after delivery to add functionality or features to enhance usage of the product	Proactive	Adding a CSV export or a new report
Emergency (a corrective type)	Unscheduled modification to temporarily keep a system operational, pending corrective maintenance	Reactive	Switching off a failing feature or routing to a fallback while the root cause is fixed

Source: ISO/IEC/IEEE 14764:2022, definitions 3.1.1 to 3.1.10 and the notes to 3.1.8 (the reactive and proactive grouping, which the standard attributes to SWEBOK). Read from the standard’s official preview, checked Oct 31, 2026.

Two notes from the standard are useful when writing a contract. First, additive maintenance can sit inside maintenance for small additions, while “larger changes can involve a new development effort”, so a maintenance agreement should say where that line is. Second, the standard notes that some organizations split each type into scheduled, unscheduled and emergency work, which is a practical way to set priorities. Older articles list only four types (corrective, adaptive, perfective, preventive); additive was added as a distinct type in the 2022 edition’s definitions.

What is included in our software maintenance and support services?

Area	What we do	Maintenance type
Monitoring and alerting	Uptime, error rates, failed jobs, slow pages and queues, with alerts to our engineers	Preventive
Incident response	Triage, reproduce, temporary workaround where needed, root cause fix, written incident note	Emergency, corrective
Bug fixes	Prioritized backlog of reported and found defects, fixed through version control, tests and a release note	Corrective
Security and dependencies	Patching libraries and frameworks with known vulnerabilities, upgrading runtimes before end of support, secrets rotation	Preventive, adaptive
Platform and store changes	iOS and Android SDK and target level updates, browser changes, app store policy changes	Adaptive
Integrations	Keeping CRM, payment, mapping and other APIs working through version changes and rate limits	Adaptive, corrective
Backups and recovery	Checking backups run and that a restore actually works	Preventive
Performance	Query, caching and bundle size work when the app slows down as usage grows	Perfective
Small improvements	An agreed number of hours for small features and UX fixes	Additive, perfective
AI app upkeep	Re-running evaluation sets when model versions change, watching cost per task, reviewing flagged answers	Adaptive, perfective
Reporting	A monthly note: incidents, changes shipped, open risks, upcoming platform deadlines	All

Exclusions are written down too: large new features (scoped as projects), redesigns, and outages of third-party services we do not control, though we still help you route around them.

Why does software need maintenance if nothing is broken?

Because the environment around it keeps moving, and some of those moves have hard dates. Three that affected apps in 2026:

• Apple. Since Apr 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK (or the matching iPadOS, tvOS, visionOS or watchOS 26 SDK). Apple also lists Sep 9, 2026 as the date from which iOS and iPadOS uploads must target iOS 13 or later (Apple upcoming requirements, checked Oct 31, 2026). An app that was not rebuilt cannot ship even a one-line bug fix.
• Google Play. From Aug 31, 2026, new apps and app updates must target Android 16 (API level 36), with lower targets for Wear OS, Android Automotive OS, Android TV and Android XR. Existing apps must target Android 15 (API level 35) or higher to remain available to new users on newer Android versions, and developers could request an extension to Nov 1, 2026 (Google Play target API level requirements, checked Oct 31, 2026).
• AI model prices and versions. Model providers change prices and retire models on their own schedule. Google’s Gemini API pricing page, for example, lists gemini-4-argon rising from $2 to $4 per million input tokens on Dec 1, 2026 (Gemini API pricing, checked Oct 31, 2026, subject to change). An AI app needs someone watching that.

None of these are bugs in your code, yet each one stops the software from shipping or raises its running cost. That is adaptive maintenance, and it is the part owners most often forget to plan for.

What needs maintaining in the systems our team has built

These are builds our engineers shipped. Each shows a different kind of upkeep a production system needs, which is how we plan maintenance for any client system.

Spirit Airlines group booking (10 weeks). A rules-based pricing engine checks live fare class inventory through a Sabre integration, and deposit and balance payments run through Stripe with reminders at 30, 14 and 3 days. After launch, group bookings went from 140 to 610 a month within two quarters. A system like this depends on two outside APIs and on pricing rules that business staff change, so its maintenance centres on integration monitoring, payment edge cases and safe changes to the rules engine.

Life Line Ambulances event EMS (9 weeks). Dispatch at large events dropped from 9 minutes to 90 seconds on average, across 340 events in the first year with up to 60,000 attendees each. The system runs offline on site and syncs on reconnection, and it keeps patient records and an audit trail. For a system like this, preventive work (sync conflict tests, device and OS updates before event season) and clear emergency procedures matter more than feature work.

DAIN AI realtor video app (7 weeks). DAIN produces a listing video in 8 minutes for under $12 in compute, and generated 41,000 tours in its first year. Keeping an AI product at that cost per output means watching model and rendering costs, re-testing output quality when a model version changes, and updating channel formats. Read the DAIN case study, and see AI app development for how we build these.

How our maintenance and support process works

1. Handover and review (first 1 to 2 weeks for a system we did not build). We get access to the repository, hosting, domains, app store and third-party accounts, then review code, dependencies, tests, deployment and known issues. You get a written list of risks in priority order.
2. Baseline. Monitoring and alerts set up or checked, backups verified with a test restore, a dependency and platform deadline list created.
3. Agreement. Priority levels, response and resolution targets, support hours, channels, monthly hours for improvements, and exclusions, all in writing.
4. Run. Incidents handled by priority; fixes and updates shipped through version control, automated tests where they exist, staging, then production with a release note.
5. Report and plan. A monthly note on incidents, changes, open risks and upcoming deadlines (like the Apple and Google dates above), with a recommendation for the next quarter.

How are your support requests handled and billed?

You send a request, we confirm its priority, fix it through our normal release process, and bill the hours it took. How it works for you:

1. You report it through the channel agreed in your written terms, with what happened and where.
2. We set the priority with you using the levels in your agreement, so a payment failure is not queued behind a colour change.
3. We fix and release it through version control, tests where they exist, staging, then production with a release note.
4. You are billed for the work done. Support after launch is billed per hour, and the monthly note lists the changes shipped.
5. Bigger work is quoted first. A new feature or redesign is scoped and quoted in writing as a project before we start.

Response and resolution targets are not standard numbers we publish; we set them with you in the written agreement, based on how critical your system is.

What is a software maintenance SLA, and what should yours include?

An SLA (service level agreement) is the part of the contract that turns “we will support you” into measurable promises. We do not publish standard SLA numbers, because the right targets depend on how critical the system is; they are set with each client in the written agreement. What every SLA we sign defines:

SLA element	What it settles
Priority levels	What counts as critical (system down, data at risk), high (major feature broken), normal and low (cosmetic, questions)
Response time per priority	How soon an engineer acknowledges and starts work
Resolution or workaround target per priority	How soon service is restored, temporarily or permanently
Support hours and channels	Business hours or extended cover, and how issues are reported
Scope and exclusions	Which systems, environments and integrations are covered, and what is project work instead
Change process	How changes are requested, approved, tested and released
Reporting	What you receive each month
Access and ownership	Who holds code, accounts and credentials; what happens at the end of the agreement

How much do software maintenance and support services cost?

We quote maintenance in writing after reviewing the system, not as a percentage of what the build cost. What moves the price:

Cost driver	Less effort	More effort
Platforms	One web app	Web plus iOS and Android, each with store requirements
Integrations	None or one	Several outside APIs (payments, CRM, booking, mapping, AI models)
Dependency age	Current frameworks with tests	Old versions past end of support, no tests
Criticality	Internal tool, business hours	Customer-facing or safety-critical, extended hours
Change volume	Fixes only	Regular small features each month
Data sensitivity	General business data	Health, payment or personal data with audit needs

Our approach. Support after launch is billed per hour, and we quote the monthly scope in writing after a code review. Many vendor sites quote maintenance as a fixed yearly percentage of the build cost; we have not found a primary dataset behind that rule, so we price from the actual system instead.

Who do we provide maintenance and support for?

• Startups after launch that need a team to keep the product shipping while they raise or hire. See MVP development and SaaS development.
• Businesses whose developer or agency has left, with an app that still needs fixes and store updates.
• Companies with older systems that need stabilizing before or instead of a rebuild. See legacy software modernization.
• Teams running AI apps that need model changes, costs and output quality watched. See AI app development.
• CRM-connected systems where the app syncs with GoHighLevel, HubSpot, monday.com or Pipedrive and the integration must keep working. See CRM integration services.

How to choose a software maintenance and support company

1. They review the code before quoting. A fixed price without looking at the system is a guess.
2. The SLA is written and specific. Priority levels, response and resolution targets, hours and exclusions.
3. You own everything. Code in your repository, accounts in your name, credentials documented.
4. Every change is traceable. Version control, tests, staging, release notes.
5. They watch external deadlines. They should tell you about the next Apple, Google or API change before it blocks a release.
6. Monthly reporting. Incidents, changes and risks, in plain language.
7. Named engineers. You know who works on your system, and knowledge is written down, not held by one person.

Why aibrevo for software maintenance and support

• In-house engineers. A 16-person engineering team in San Francisco led by our co-founder and CTO Shivam Pujara, plus 30+ specialists who work with us remotely.
• We build what we maintain. 200+ software projects delivered by our engineering team, including Spirit Airlines, Life Line Ambulances, DAIN and the builds on our work page, across web, iOS, Android and AI.
• CRM integration built in. Apps that sync with GoHighLevel, HubSpot, monday.com or Pipedrive are maintained with the CRM side in view, not handed to a second vendor.
• Written terms. Scope, SLA targets and price are set in a written agreement after a free call and a review.

We support clients across the US remotely from San Francisco; see app development by state and city.

Sources

All pages opened on Oct 31, 2026.

• ISO/IEC/IEEE 14764:2022, Software engineering, software life cycle processes, maintenance (third edition, January 2022): ISO catalogue page and official preview of clauses 1 to 3.
• Apple Developer, upcoming requirements: Xcode 26 and iOS 13 target requirements.
• Android Developers, Google Play target API level requirements.
• Google, Gemini API pricing: scheduled price change (subject to change).
• Our case studies: Spirit Airlines, Life Line event EMS, DAIN.