01
Severity 1: production down
Example: Users cannot log in, payments fail or data is being lost or exposed.
Approach: On-call engineer engaged within the agreed response target, workaround first, root cause and fix after, written incident report.
Maintenance and Support
Software maintenance and support services
Your product is live, and every week brings a bug report, a dependency warning or an alert nobody owns. Agnotic Technologies takes over maintenance and support for web, mobile and backend software: fixes by severity, updates on a schedule and monitoring you can see.
Web, mobile and backendSeverity-based SLAsSecurity updatesVendor handover
Trusted by global innovators
Maintenance support
What are software maintenance and support services?
Software maintenance and support services keep a live product working after launch. At Agnotic Technologies, maintenance support covers bug fixing, dependency and security updates, monitoring, small enhancements and on-call response, run against severity levels agreed in writing. It applies to web apps, mobile apps and backend systems, whoever built them.
Support is the reactive half: someone answers when production breaks. Maintenance is the planned half: updates, clean-up and small changes that stop the next incident.
Both run in your repositories and cloud accounts, so you keep full visibility of what changed and why.
What does a maintenance engagement cover?
Six streams of work. Most products need all of them; the mix changes with the product's age and traffic.
Corrective fixes
Bugs reported by users, monitoring or your team, reproduced, fixed with a test and released through your pipeline.
Dependency and runtime updates
Framework, library, SDK and runtime upgrades planned before versions reach end of life, not after.
Security patching
Vulnerability alerts reviewed, prioritized by severity and patched, with a record of what was fixed.
Monitoring and alerting
Uptime, error rates and job failures watched, with alerts routed to a named engineer instead of a shared inbox.
Small enhancements
Changes too small for a project, such as a new field, report or integration tweak, planned in a monthly batch.
Mobile store upkeep
OS version support, store policy changes and SDK updates for iOS and Android apps, so releases are not rejected.
Severity levels
How are support requests prioritized?
By impact, not by who shouts loudest. Response and resolution targets for each level are agreed in the support agreement before the engagement starts; these are the definitions we start from.
02
Severity 2: major feature broken
Example: A core workflow fails for some users, or an integration stops syncing.
Approach: Picked up ahead of all planned work; a fix or rollback goes out as a hotfix release.
03
Severity 3: minor defect
Example: A screen shows wrong formatting, or a non-critical report is slow.
Approach: Fixed in the next planned release, with a regression test added.
04
Severity 4: request or question
Example: A small change, a configuration question or a cosmetic issue.
Approach: Added to the enhancement backlog and planned with you in the monthly review.
Vendor handover
How do we take over software from another vendor?
Most maintenance engagements start with code someone else wrote. These steps come before we accept any severity targets.
Access and inventory
We list repositories, cloud accounts, domains, app store accounts, third-party services and credentials, and confirm they belong to you.
Build and deploy from scratch
We rebuild the product from source and deploy to a staging environment, to prove nothing depends on one person's laptop.
Read-only audit
Dependencies, known vulnerabilities, test coverage, logging and backups are reviewed before we change anything.
Risk list and first fixes
You get a ranked list of risks. The most urgent ones, often expired dependencies or missing backups, are fixed first.
Steady-state support
Monitoring, on-call and the monthly maintenance plan start once the product can be built, deployed and restored by our team.
Updates
How are dependency and security updates handled?
Updates are planned work, not an afterthought. These are the practices on every maintenance engagement.
- Automated dependency alerts in your repository, reviewed by an engineer each week
- Security fixes ranked with the CVSS severity scale and patched in order of risk
- Runtime and framework versions tracked against their published support schedules
- Every update goes through automated tests and a reviewed pull request before release
- Breaking upgrades, such as a major framework version, planned as their own piece of work with a rollback plan
- Backups and restores tested on a schedule, not assumed
- A changelog of every update, so your team and auditors can see what changed
What drives software maintenance cost?
We do not publish prices. Maintenance support cost depends on the size and age of the codebase, the number of platforms and integrations, and the severity targets you need.
Out-of-hours on-call for Severity 1 costs more than business-hours support. A product with outdated dependencies needs a catch-up phase before steady-state maintenance.
Startups often begin with business-hours support and a small enhancement budget, then add on-call when traffic grows. The scoping call turns these drivers into a written support agreement.
Checklist
Handover checklist before you switch vendors
Ask your current vendor for these before the contract ends. If any are missing, that is the first thing we fix.
Source code in your repositories
Every repository, including scripts and infrastructure code, under your organization's account.
Cloud and store accounts in your name
Cloud, domain, email, app store and payment accounts owned by you, with admin access you control.
A working build and deploy
Written steps or a pipeline that builds and deploys the product from a clean machine.
Secrets and credentials list
Where every API key and password lives, so they can be rotated on the day the vendor leaves.
Known issues and open tickets
The current bug list, recent incidents and anything promised to users but not shipped.
Backups and a tested restore
Where backups are stored, how often they run and when a restore was last tested.
What we maintain
Which products do we maintain?
Any software in production, whether Agnotic built it or not.
Web applications
Customer portals, admin tools and marketing platforms, including framework and hosting upgrades.
Mobile apps
iOS and Android apps kept current with OS releases, store policies and SDK changes.
Backend systems and APIs
Services, databases, background jobs and integrations, with monitoring on the parts users never see.
Healthcare software
Products that hold PHI, where our healthcare managed services add HIPAA-ready controls and EHR interface monitoring.
Standards
Standards behind our maintenance work
Named references we apply when triaging, patching and documenting changes.
NIST SP 800-218CVSS v3.1Semantic VersioningOWASP Top 10HIPAA Security Rule
Facts and sources
Facts and sources behind maintenance support
Standards and vendor documentation that shape how we patch, update and prioritize, each linked to its primary source.
NIST SP 800-218 (SSDF) practice RV.1 asks software producers to identify and confirm vulnerabilities on an ongoing basis, including by monitoring vulnerability databases and security mailing lists, so they can be remediated in accordance with risk.
Source: NIST SP 800-218, Secure Software Development Framework, practice RV.1The CVSS v3.1 specification maps scores to a qualitative severity scale: None 0.0, Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0.
Source: FIRST, CVSS v3.1 Specification Document, Table 14GitHub Dependabot security updates can fix vulnerable dependencies by raising pull requests with security updates when a Dependabot alert is found in the repository's dependency graph.
Source: GitHub Docs, About Dependabot security updatesThe Node.js project states that production applications should only use Active LTS or Maintenance LTS releases, and that LTS status typically means critical bugs are fixed for a total of 30 months.
Source: Node.js, Previous releases
Frequently Asked Questions
Bug fixing by severity, dependency and security updates, monitoring and alerting, small enhancements and a monthly report. On-call cover for production outages is added when the product needs it. The exact scope is written into the support agreement.
Yes, most of our maintenance work starts that way. We take over through a handover: access and inventory, a rebuild from source, a read-only audit and a ranked risk list, before we accept any severity targets.
Response and resolution targets are set per severity level in the support agreement, and depend on whether you need business-hours or out-of-hours cover. We agree them on the scoping call rather than quoting one number for every product.
We do not publish prices. The cost depends on the codebase size and age, the platforms and integrations, and the severity targets and on-call hours you need. The scoping call gives you a written support agreement to compare.
Yes. Startups usually begin with business-hours support, a monthly enhancement budget and monitoring, then add on-call cover as usage grows. The same severity definitions apply from the first month.
Yes. We work in your issue tracker, repositories, chat and monitoring tools, so tickets, fixes and alerts stay where your team already looks. We add tools only when something is missing, such as error tracking.
Engineers use AI tools to read unfamiliar code, draft fixes and write tests, and every change still goes through human review, automated tests and the release checklist. AI never merges, deploys or closes an incident on its own.