Bugs wait at the bottom of the backlog
Customer reports sit behind the next feature for weeks. The customer who filed one is still waiting, and usually tells someone.
Explore
Custom software · Product maintenance & support
Maintenance matters as much as the next feature
A bug that waits a quarter at the bottom of Jira costs you the customer who reported it. So does a surprise cloud bill, an unpatched library or a framework two major versions behind. We run maintenance as a stream of its own: an AI pipeline that triages bugs and drafts fixes, with an engineer approving every plan and every merge. Upgrades run on a schedule, security patches go out as advisories land, and someone watches the cloud bill and the alerts. Your team keeps the roadmap. You see what was fixed, how it was tested and what still needs your call.
- 50 ticketsThrough our AI software factory in one week, 48 completed
- $2.90Inference per ticket, with a person approving every plan and every merge
- 52%Of commits after go-live were fixes, on our own product
This is for you if maintenance keeps losing to the roadmap
Upgrades keep getting postponed
The framework is two major versions behind, the runtime is close to end of life and every dependency bump feels like a gamble. So nobody touches it.
Cloud bills, alerts and advisories nobody owns
The bill grows every month, monitoring wakes someone at 2am and security advisories pile up in an inbox nobody reads.
Only one person knows how it works
The developer who built it moved on, or is the last one left who understands it. Every change waits for them.
What you get. Maintenance that does not wait in line
An AI fix pipeline with two human gates
Agents triage the report, reproduce it, plan the fix, build it and run the tests. An engineer approves every plan and merges every pull request. Nothing merges on its own. In our own factory week the line ran 50 tickets at about $2.90 each in inference. A bug gets worked on this week, not when a sprint frees up.
Fixes that stay fixed
Each fix is checked on the changed behavior and the paths nearby, and the regression suite grows with it. Repeated reports often point to a deeper problem, so we record the pattern and agree with you which root fixes go into the stream.
Upgrades on a schedule
Renovate or Dependabot opens the update, CI runs your tests, an agent fixes what the upgrade broke and an engineer reviews the merge. Dependencies, frameworks and runtimes move in small steps, so no upgrade turns into a migration project.
Security patching
Attackers have the same new models we do, and they use them to find weak spots faster. We patch known vulnerabilities as advisories land, scan dependencies and code, and check permissions, secrets and exposed endpoints. Fixes go through the same gates as every other change.
Cloud costs and monitoring
We watch the bill and the alerts on AWS, Azure, GCP or wherever the product runs: idle resources, oversized instances, noisy alerts and the errors users hit first. Each month you get a short list of what to cut and what to fix.
Knowledge in the repo, not in one head
Documentation, runbooks and tests live in your repo, and tickets stay in your tracker. With that context, AI coding agents and any motivated engineer can pick up the code. Changes still get reviewed, but the product no longer depends on the one veteran who remembers why it works.
The ownership line
Who approves changes and what you keep
How changes reach production
Work follows the release schedule agreed with your team
A person approves the plan before implementation
A person reviews the pull request and test results before merging
On-call coverage and response times require a separate written agreement
You keep
The repository, the tracker and the documentation
Your cloud accounts and the bill
The priorities of the maintenance stream
Decisions on root fixes and bigger changes
Tech stack. Clouds, pipelines, monitoring, upgrades
We work in the clouds, trackers and pipelines you already have. AI agents take the repetitive part of triage, fixes and upgrades, and an engineer reviews every change.
Tech stack
- AWS
- Azure
- GCP
- Vercel
- Cloudflare
- Kubernetes
- Docker
- Terraform
- GitHub Actions
- GitLab CI
- Sentry
- Grafana
- Datadog
- OpenTelemetry
- Renovate
- Dependabot
- Snyk
- Playwright
- Claude Code
- Codex
- Jira
- Linear
- ClickUp
- Node.js
- Java
- .NET
- Python
- PostgreSQL
How we work
Give maintenance its own line
Our own product, PirxeyOS, took about twenty working days to build. Then 150 people moved onto it, and 52% of the commits after go-live were fixes. Across its log the fixes fall into four groups: 51 for data consistency, 35 for real devices and screens, 31 for permissions and security, 26 for APIs and integrations. Shipping starts the work. We plan for those groups instead of discovering them one ticket at a time.
Integrations change, regulations change, products change, architecture evolves. Build it. Document it. Maintain it. Collect data. Optimize. There’s just no other way.
How it works. From a stuck backlog to a running line
Review the product and the inflow
Ticket history, release schedule, cloud accounts, how far behind the dependencies are and the areas that break most often. You get the first risks and what we need before we take responsibility.
Set up the line and the gates
We connect the fix pipeline to your tracker and CI, and write down who approves plans and merges, which reports are urgent, the upgrade schedule and who watches alerts. On-call coverage and new features are separate decisions.
Triage, fix, test, release
Agents draft, engineers decide. Every fix, upgrade and patch goes through your review and your pipeline, with regression tests for the changed behavior and the paths nearby.
Review the stream each month
What came in, what was fixed and how fast, which upgrades and patches shipped, what the cloud bill did and which patterns to fix at the root. Task-level time records show where the hours went.
Client work from the same engineering teams
AI · FinTech
Taking over and rebuilding a crypto intelligence platform
PropTech · Platform
Rescuing a construction management platform after a failed first build
Questions about handing over maintenance
- No. We work in your repository, your cloud and the tools your team already uses. If one of them gets in the way of the work, we tell you what and why, and you decide.
- With a 30-minute scoping call. We look at what you have and what you need, then propose a first step with its scope and price before any work starts.
- Customer reports and regressions, compatibility fixes for new operating-system and browser versions, dependency, framework and runtime upgrades, security patches, cloud cost and monitoring, and small changes. For Ranorex we run a stream like this today, including customer reports and compatibility fixes, with regression coverage kept useful as the product changes.
- Yes. That is most maintenance work. We start with a limited review of the code, the accounts and the release process. AI coding agents help us map an unfamiliar codebase quickly, and we write down what is missing before we take responsibility for it.
- Rescue and takeover gets a stalled or hard-to-change product back under control. Maintenance is the ongoing stream once access and the release process are clear. A product in trouble may need the recovery work first.
- No. A person approves the plan before anything is built, and a person merges the pull request with the test results open. In our factory week that meant two decisions per ticket, minutes each. Agents speed up the work between the gates. Review by someone who understands the system is still the real limit, and we plan capacity around it. Your team keeps the product priorities.
- Only if a separate written agreement covers it. The stream works through your tracker and release schedule; on-call coverage, availability and response times are agreed separately, in writing, before they apply.
- Most of the routine part, yes. Renovate or Dependabot proposes the update, CI runs the tests and an agent fixes what broke. Major framework and runtime upgrades still get a plan and a human review, but they arrive in small steps instead of one risky migration every few years. Small product improvements can go into the stream too, tracked apart from defects.
- We track incoming tickets, time from report to fix, recurring defects, release regressions, how far behind the upgrades are, open vulnerabilities and cloud spend, then compare the same measures over time. We do not promise that every queue shrinks by the same percentage.
- The budget follows the size of the stream: your ticket inflow, the release schedule and the skills the product needs. We agree it before the stream starts. AI inference is a small line next to engineering time. In our factory week it came to about $2.90 a ticket, not counting setup and human review.
- The code, tests, documentation, runbooks and ticket history stay in your tools throughout. Because the knowledge is written down, your own engineers, working with the same AI agents, can pick it up. The handover covers open tickets, the release state and the patterns we found.
How we think about this, in our own words
Interactive briefs and articles by our team, picked for this service
Shipping new things while drowning in tickets
Balance support tickets, regressions and testing in your team's week and compare six months with a maintenance stream of its own.
Read the briefPirxeyOS: 20 days to build, 30 weeks to keep alive
Our own product took about 20 working days to build. Across its whole commit log, 46% of 587 commits were fixes.
Read the briefAI software factory: where the humans go
Assemble an agent production line yourself and see where the people have to stand: 50 tickets in a week, two human gates, $2.90 a ticket.
Read the briefTell us what keeps landing on your team
Tell us about the product and who uses it, how many tickets arrive, how often you release, where it runs and how far behind the upgrades are.
Direct contact
Mike KacprowiczBook a callChief Growth Officer