Maintenance & Support
Ongoing engineering support for products already in production — the unglamorous work that keeps everything else from breaking.
The software that keeps running without drama is easy to take for granted — right up until a dependency with a known vulnerability sits unpatched for eight months, or a bug that's been silently annoying users finally costs a real customer, or the one person who understood the codebase leaves and takes the context with them.
Maintenance is unglamorous by nature — nobody celebrates a product that didn't break — which is exactly why it's the first budget line teams cut, and the first thing that quietly compounds into a real problem.
Products supported by "whoever has time this week" instead of a real process accumulate risk invisibly: security patches slip, small bugs pile up because nobody owns triaging them, and a genuine SLA becomes "we'll get to it eventually."
Algotrax runs maintenance as a real discipline with a response window and a monthly record of what changed — not a best-effort inbox that happens to check itself sometimes.
What's included
Bug triage and fixes on an agreed response window
Dependency and security updates on a schedule, not only after an incident
Uptime and error monitoring with alerting to a real person
Small feature requests handled without opening a new project every time
A monthly summary of what changed and what's next
How it actually runs
Onboarding audit
A read of the existing codebase, dependencies, and known issues before support formally starts — even for products Algotrax didn't originally build.
SLA & response window agreed
A concrete response time for bugs by severity, set explicitly, not implied.
Scheduled dependency & security updates
Patches applied on a real schedule, not only after something's already gone wrong.
Monitoring & alerting
Uptime and error tracking wired to notify a real person, so issues surface before a client reports them.
Monthly reporting
A real summary of what changed, what was fixed, and what's coming — visibility instead of a black box.
What most agencies get wrong here
Treating maintenance as "whoever has spare time."
No accountability means no real response window, whatever the informal promise was.
Skipping the onboarding audit on an inherited codebase.
Committing to a response SLA on code nobody's actually read yet is a promise made blind.
Only updating dependencies after an incident.
Reactive patching means the vulnerability was live for however long it took to notice — the whole point of a schedule is closing that window.
No monthly visibility into what's actually happening.
A support arrangement with no reporting is indistinguishable from nothing happening at all, from the client's side.
How the engagement works
Support engagements run as an ongoing retainer, typically monthly, sized to the product's actual complexity and the response window that matters for it — a consumer app with real-time usage needs a tighter SLA than an internal tool used a few times a week.
The onboarding audit for a codebase Algotrax didn't build is priced as its own short phase, since understanding someone else's code properly takes real time before support can be honest about response times.
Feature requests that grow beyond "small" get scoped and priced separately and honestly, rather than quietly absorbed into the retainer at the expense of the SLA.
Once support is running on a real SLA, the backlog of "we'll get to it eventually" stops growing, and security patches happen on schedule instead of after something's already gone wrong.
Getting started is the onboarding audit — a proper read of the codebase before any response-time commitment gets made, even for products Algotrax didn't originally build.
Tell us where maintenance & support fits in, and we'll reply within a day.
- A real person reads this, not a queue
- No discovery call required to get a straight answer
- Tell us to go away and we will — no drip sequence
Questions worth asking first
No — an onboarding audit for any codebase, then support proceeds the same way. Most maintenance engagements start with us reading someone else's code first.