Keep production systems healthy long after launch.
The systems that run your business need ongoing ownership, whether AnAr built them, you inherited them from a team that has since moved on, or they are AI and agentic systems that drift silently until something breaks. We keep them understood, monitored, supported, and safe to change.
Systems do not fail loudly. They decay quietly, then break at once.
Most maintenance problems are not sudden. They build up over months while the system still looks fine from the outside. Three patterns cause the majority of them.
The people who built it have moved on, and no one owns the knowledge.
Business rules, edge cases, and the reasons behind old decisions live in the heads of engineers who have left. What stays behind is a codebase no one fully understands and is afraid to change. Every fix becomes a gamble.
Maintenance gets treated as a ticket queue while the system decays.
Tickets get closed, but dependencies age, security patches slip, and small workarounds pile into structural debt. The team is busy the whole time. The system still gets more fragile every quarter.
AI systems degrade invisibly, and the dashboards look green.
A model version gets retired. A prompt change quietly regresses answer quality. Retrieval data goes stale, latency creeps up, token spend climbs. None of it throws an error. The system keeps responding, just worse, and you find out from users.
Three ways we keep systems running
Most engagements start in one of these three modes. Many grow to cover all of them as the relationship deepens.
For: systems AnAr built
Continuity
When we build a product, the same engineers can keep owning it: feature work, security patching, dependency upgrades, and operational support on a defined retainer. The knowledge never leaves, so changes stay safe and fast.
For: inherited systems
Takeover
When a previous team or vendor built the system and has since moved on, we take it over. We map it before we touch it, so the code is understood and documented before any change ships. More on this below.
For: agentic and LLM systems
AI Operations
Agentic and LLM-integrated systems need a kind of maintenance ordinary apps do not: eval monitoring, prompt versioning, model-deprecation migrations, and retrieval freshness. The AI-native part of the job, covered in detail below.
We understand it before we change it
The outcome you want: a system no one on your team fully understands becomes safe to change again. That depends on one thing, understanding the system before touching it. Taking over a codebase you did not build is where most maintenance handovers go wrong. A team starts fixing tickets in code it has not mapped, and every change risks breaking behavior no one knew was load-bearing.
We do the opposite. Before we ship a single change to an inherited system, we build a documented understanding of what it does and why. This runs on our four-phase engineering method, Understand, Plan, Implement, Verify, the same discipline behind AI-assisted development. Comprehension is the first phase, not an afterthought.
Much of this runs on pre-built components of our own for code assessment, business-rule extraction, and test generation, not manual reading alone.
The difference from a modernization engagement: there, comprehension precedes a rebuild. In maintenance, it precedes ongoing ownership. The system stays in production the whole time.
- Codebase comprehension. AI-assisted analysis reads the full system, then engineers validate what it surfaces. We build the mental model the original team never wrote down.
- Dependency and integration mapping. Every external service, database, and internal coupling documented, so no change has a surprise blast radius.
- Risk and debt mapping. Where the real fragility lives, which modules are safe to touch and which need care before anyone does.
- Business-rule recovery. The logic and edge cases buried in the code, extracted and written down instead of lost.
- A documented handover. You get a mental model of your own system that survives staff changes, ours or yours.
Keeping AI systems healthy
Keep your AI system performing as well as the day it shipped, instead of letting it drift until users notice. An LLM or agentic system that shipped six months ago is not the same system today, even if the code has not changed: the models behind it move, the data behind it ages, and quality drifts without a single error in the logs. Maintaining these systems means watching the things ordinary monitoring never sees.
Eval and regression monitoring
Automated evaluation suites run against every prompt or model change, so a quality regression shows up in a test result before it shows up in a user complaint.
Prompt and version control
Prompts, system messages, and tool definitions are versioned like code, with a clear history and the ability to roll back a change that made things worse.
Model-deprecation migrations
When a provider retires a model version you depend on, a Claude or GPT release reaching end of life, we re-test behavior and migrate you to its replacement without breaking what worked.
Retrieval and RAG freshness
Retrieval indexes and embeddings are kept current as your source data changes, so answers stay grounded in what is true now, not what was true at launch.
Guardrails and safety
Output validation, refusal handling, and prompt-injection defenses are tested as the system evolves, not set once and forgotten.
Latency and token-spend monitoring
We track response latency and token spend per request, so silent slowdowns and quiet budget creep get caught while they are still small.
A defined model, not an open-ended ticket queue
You know exactly what the maintenance relationship covers, what it runs to, and that releases will not surprise your users. Every mode runs on the same four-phase discipline applied to each change: understand it, plan it, implement it, verify it. Coverage and change safety are agreed up front, not left open-ended.
Coverage and support
An agreed support model: named engineers who know your system, severity levels each with a response commitment, agreed coverage hours, and a clear escalation path. Not a shared queue where your system is one of many.
Observability
Monitoring on the things that predict failure: dependency health, error rates, latency, and for AI systems, eval scores and token spend. Problems surface before users feel them.
Change safety
Regression suites run before any change reaches production traffic. Nothing ships on hope. If a release regresses behavior, it is caught in verification, not by your customers.
AI-assisted delivery
We use AI-assisted triage and automated code comprehension in our own maintenance work, so a small team can own a large system and move fast without cutting corners.
Engagements are scoped to defined milestones, not open-ended time and materials. When maintenance follows one of our modernization builds, it picks up cleanly from the hyper-care window, typically thirty to ninety days after cutover, into an ongoing maintenance retainer covering continuing feature work, security patching, and operational support.
Taking over a compliance-regulated codebase no one wanted to touch
An NMLS-regulated mortgage-education portal on a complex, undocumented codebase
The situation: A US education company ran a mortgage-training portal that had to stay compliant with NMLS regulation. The codebase was complex and poorly documented, talent was hard to find for it, and every change risked a regulatory breach. It was exactly the kind of system a new team is afraid to touch.
What AnAr did: We mapped the system before changing it, recovered the business and compliance rules buried in the code, and took over ongoing ownership. Regression coverage was put around the compliance-critical paths first, so changes could ship without risking NMLS conformance.
Why teams hand their systems to AnAr
We take over systems we did not build.
Comprehension-first is not a slogan. We map an inherited, undocumented codebase and recover the knowledge the original team left behind before we change anything. Most vendors start fixing tickets on day one and hope.
We maintain AI systems, not just apps.
Eval monitoring, prompt versioning, model-deprecation migrations, and retrieval freshness. Our reusable AI component library and our own AI engineering practice mean we know how these systems fail, because we run them ourselves.
150+ projects. 95% client retention. 12 years of delivery.
Retention is the maintenance metric that matters most. Clients stay with us for years because the systems we own keep working. The track record is real and verifiable.
We use AI in our own maintenance, every day.
AI-assisted triage, automated code comprehension, and AI-generated regression scenarios are standard practice on every engagement. A small, senior team can own a large system safely because the tooling does the heavy reading.
What leaders ask before handing over maintenance
If your question is not covered below, a system review is the fastest way to a specific answer. Most general questions are answered on this page.
Can you take over a system you did not build?
Yes. It is one of the two most common ways engagements start. We do not begin by fixing tickets. We begin by mapping the system: dependencies, integration points, where the risk lives, and the business rules buried in the code.
Only once we have a documented understanding do we start making changes. That order is what makes a takeover safe rather than a series of gambles.
How do you handle a codebase with little or no documentation?
We build the documentation that was never written. AI-assisted analysis reads the full codebase, and our engineers validate what it surfaces, so we can map an undocumented system far faster than reading it line by line.
You end up with a mental model of your own system, dependency maps, recovered business rules, and risk notes, that survives staff changes on both sides.
Do you maintain LLM and agentic applications, or only traditional software?
Both, and AI systems are where we differ most from a general maintenance vendor. Agentic and LLM-integrated systems need eval and regression monitoring, prompt and version control, retrieval freshness, guardrail testing, and latency and token-spend monitoring.
These systems degrade without throwing errors, so ordinary uptime monitoring misses it entirely. See our GenAI and agentic AI work for how we build them in the first place.
What happens when a model we depend on is deprecated?
Providers retire model versions on their own schedule. When a version you rely on reaches end of life, a Claude or GPT release being sunset, we re-run your evaluation suites against the replacement, adjust prompts where behavior shifts, and migrate you across without breaking what worked.
Because the eval suites already exist, we can prove the migrated system behaves at least as well as the old one before it goes live.
What is the coverage and response model?
Support is agreed up front, not left vague. You get named engineers who know your system, severity levels each with a response commitment, agreed coverage hours, and incident handling with a clear escalation path, rather than a shared queue where your system competes with everyone else's.
Engagements are scoped to defined milestones, not open-ended time and materials, so you always know what the maintenance and support relationship covers and what it runs to.
How does maintenance relate to a modernization engagement?
They connect directly. After a modernization build, there is a hyper-care window, typically thirty to ninety days after cutover, while the system stabilizes. Maintenance picks up cleanly from there as an ongoing retainer covering continuing feature work, security patching, and operational support.
If the underlying stack itself is no longer supportable, that is a modernization conversation first. See Legacy Application Modernization or AI-Driven Application Modernization.
When is maintenance not the right answer?
Sometimes it is not. If the stack is out of vendor support, cannot be hired for, or has decayed past the point where patching is safe, maintaining it is money spent keeping a dead end alive. We will tell you that directly rather than sign a retainer against a system that should be replaced.
In that situation the honest move is to modernize first, then maintain. Start with Legacy Application Modernization or AI-Driven Application Modernization, and maintenance picks up cleanly once the system is on a supportable footing.
Is our source code and IP protected?
Yes. Your source code is your IP. Confidentiality terms are agreed in writing before any code is shared, and visibility is limited to the engineers assigned to your engagement.
Tell us what needs looking after
A short note is enough to start. We begin every maintenance relationship with a review of the system, so you get a real read on its health before any commitment.
Come to us with:
- A system we built that you want us to keep owning
- An inherited codebase no one on your team fully understands
- An AI or agentic system that needs proper monitoring
- A production system you are worried is quietly decaying
You will speak with engineering, not sales. The first reply comes from someone who can answer technical questions about your system, within one business day.
Send a Message
A few details so the right engineer follows up.
Routed to the right engineer
We read what you sent and route it to someone who works in that area, not to a sales queue.
A reply within one business day
You get a substantive response from an engineer, with first thoughts on your system where they are clear.
A system review to go deeper
We set up time to look at the system, agree the coverage that fits, and how best to work together.
If the stack itself is no longer supportable, start with Legacy Application Modernization →
If you want to add AI while modernizing, see AI-Driven Application Modernization →
