McGravity
Book a demo

Features ship.
The rot does
not wait.

Duplication, dead docs, drifted dependencies. McGravity reads the repo, does the cleanup you never schedule, and opens a PR. Nothing new gets built. The code just gets healthier.

Book a demo See a maintenance PR
Illustrative PR Generic repository

Remove duplicated payment helper

McGravity proposes a maintenance change

One shared helper. Same behavior.

Consolidates identical reference cleanup. Existing call sites keep the same result.

Files changed 3+5−6
services/checkout/payment.ts+1−3
−const cleanReference = (ref: string) => {−  return ref.trim();−};+import { cleanReference } from "@shared/payment";
services/billing/payment.ts+1−3
−const cleanReference = (ref: string) => {−  return ref.trim();−};+import { cleanReference } from "@shared/payment";
packages/shared/payment.ts+3
+export const cleanReference = (ref: string) => {+  return ref.trim();+};
Repo tests passReady for your review

An example of the work. Not a live run or customer result.

Behavior stays.

Every change is a pull request.

You own the merge.

Cleanup later
is a lie.

You already know the shape of it. The helper copied into the third service. The README for an endpoint you deleted. The package you were going to bump after the launch. The junior (or the model) who cloned the wrong one again.

None of that is a roadmap item. So it sits. Until onboarding is tribal knowledge, a CVE lands on a Friday, or two repos disagree about the API you swore was stable.

McGravity is the owner for that layer.

The work that
never gets a sprint.

A cleanup ticket. A Friday hero. Dependabot noise. Or nothing.
Give the maintenance layer an owner.

Duplication

The same logic living in two places. Or three.

checkout/helpers.ts ↔ billing/helpers.tsRepeated logic

Dead code

Unused exports. Dead files. Code nobody calls.

legacy-client.tsNo references

Stale docs

The README for an API that no longer exists.

README.md → current /v2 APIOut of date

Dependency drift

The package you meant to bump. And the call sites that break when you do.

package.json + affected call sitesDrift detected

Drift across repos

The client, the API, and the architecture that stopped agreeing.

client/ ↔ api/Contract mismatch

Start a run.
Get a PR.

Not a copilot. Not a feature factory.

A maintenance run against the repos you connect: find the rot, fix what is safe, prove it with your tests, send you a pull request.

Book a demo
  1. 1

    Install the GitHub App.

    Connect McGravity to your GitHub organization.

  2. 2

    Pick the repositories.

    You choose which codebases get a maintenance run.

  3. 3

    Start a maintenance run.

    The cleanup gets its own space. Your engineers keep shipping features.

  4. 4

    Watch the work.

    McGravity detects issues, repairs what is safe, verifies with your repo’s own tests, and opens a GitHub PR.

    DetectRepairVerifyPR
  5. 5

    Review. Then merge.

    You review anything that needs judgment. Merge is yours.

The code gets healthier.
The behavior stays.

It won’t write your product. It won’t silently rewrite main.
Maintenance has a boundary.

  • No changes to business logic
  • No changes to public APIs
  • No changes to schemas
  • No changes to architecture

If the fix needs any of that, it stops and says why.

Give “cleanup later”
an owner.

Background maintenance for your codebase.
It finds the rot and fixes it.

Book a demo