Skip to content
Platform & Infrastructure

Maintenance & Support For Systems People Depend On

Maintenance and support keeps a shipped system healthy: dependency and security updates, uptime monitoring, incident response with agreed response times, small enhancements, and — for AI systems — continuous evaluation as models are deprecated and replaced by their providers.

  • A named engineer who knows the system
  • Agreed response windows
  • We support systems we did not build

How it runs · 5 steps

  1. Take ownership properly
  2. Establish the baseline
  3. Patch on a schedule
  4. Respond to incidents
  5. Manage the AI lifecycle

Built with

  • Sentry
  • Uptime monitoring
  • Log aggregation
  • Dependabot
  • Dependency audits
  • Secret rotation
  • Eval suites
  • Prompt versioning

More in Platform & Infrastructure

Questions first?Talk to an engineer

AI systems decay differently from ordinary software

Providers retire model versions on their own schedule, pricing changes without notice, and a silent update can shift output quality without a line of your code changing. A maintained AI system is re-evaluated against its original eval set on a schedule, so drift is caught by a test rather than by a customer.

Conventional maintenance still matters just as much: dependencies age into vulnerabilities, certificates expire, and the thing that takes a system down is usually mundane. We handle both, and we will take on systems we did not build.

The Problem

What this usually fixes

  • Nobody owns it any more

    The team that built it has moved on, and every change now starts with someone reverse-engineering the deployment.

  • Dependencies aging into vulnerabilities

    Updates are deferred because nothing is tested, until an advisory forces an emergency upgrade across several major versions at once.

  • Quality drift with no cause

    The AI feature is worse than it was and nothing in your code changed, because the provider updated the model underneath it.

  • Support that is a ticket queue

    Every incident starts by explaining the system to someone new, which is most of the time to resolution.

How We Work

The process

Each step produces something you can review — a document, an environment, or working software — rather than a percentage in a status report.

  1. Take ownership properly

    We read the codebase, map the deployment and data flows, and write down what we found — including the risks you did not know about.

  2. Establish the baseline

    Monitoring, error tracking, and — for AI systems — an eval set capturing current quality, so future changes have something to compare against.

  3. Patch on a schedule

    Dependency audits, security updates, and secret rotation applied routinely rather than after an advisory forces it.

  4. Respond to incidents

    Agreed response windows and a named engineer who already knows the system, rather than a queue that starts with introductions.

  5. Manage the AI lifecycle

    Re-run the eval set against new model versions before migrating, track cost per request as pricing changes, retire prompts that no longer earn their place.

What You Get

Why teams choose this

  • Someone who already knows it

    Incidents start at diagnosis rather than at orientation, which is most of the difference in time to resolution.

  • Security as routine

    Scheduled patching and dependency audits mean upgrades are small and frequent instead of large and forced.

  • Model changes caught by a test

    Scheduled re-evaluation means provider drift shows up in a report rather than in a customer complaint.

  • Costs that stay predictable

    Cost per request tracked as provider pricing moves, so an AI feature does not quietly become the largest line in your infrastructure bill.

Stack

Technologies we build with

Tools we have delivered production work on, not a capability matrix. We pick per project and will explain the trade-off behind each choice.

Monitoring
  • Sentry
  • Uptime monitoring
  • Log aggregation
Security
  • Dependabot
  • Dependency audits
  • Secret rotation
AI lifecycle
  • Eval suites
  • Prompt versioning
  • Cost tracking
Delivery
  • GitHub Actions
  • Docker
  • Terraform
Industries

Who this is for

Anywhere a system has moved from a project into an operational dependency.

  • B2B software
  • Fintech
  • Healthcare
  • Insurance
  • Logistics
  • E-commerce & retail
  • Education
  • Manufacturing

Will you maintain software your team did not build?

Yes, and it is a substantial part of this work. We start with a paid assessment: reading the codebase, mapping the deployment and data model, and producing a written risk register ranked by cost and urgency. That document is yours regardless of whether we continue. Taking over an unfamiliar system without that step is how support engagements go wrong, so we do not skip it — including when the handover is urgent because the previous team has already left.

What response times do you offer?

Response windows are agreed per engagement and tied to severity rather than offered as a single number. A typical arrangement is one business hour for a production outage, same business day for a significant degradation, and next business day for everything else. What matters more than the number is who responds: an engineer who already knows your system, rather than a first-line queue that starts by asking you to explain the architecture.

How do you handle AI model deprecations?

Your evaluation set is re-run against the replacement model before anything migrates, and results are compared against the thresholds agreed when the system was built. If quality holds, we migrate on a planned date rather than on the provider's deadline. If it drops, we adjust prompts and retrieval, or stay on the current version while we do. This only works if an eval set exists — where one does not, building it is the first thing we do.

What does a maintenance agreement typically cost?

Ongoing maintenance generally runs $1,500–$12,000 per month depending on system size, uptime expectations, and whether AI evaluation is in scope. The variables are how much of the stack we monitor, the agreed response windows, and how much small-enhancement work is included alongside keeping things running. We price it after an assessment rather than from a description, because the gap between how a system is described and how it is built is usually the thing that determines the effort.

Inherited a system nobody wants to touch?

We will read it, map it, and give you a ranked list of what actually needs attention. The assessment is yours either way.