Infinite Uploads squashed more than twenty bugs on SandyWP sandboxes. Eight releases later, their changelog carries 28 items and 19 of them are fixes.
The team did not get there by writing code faster. They got there by deleting the step that used to sit between a support ticket and a developer, which was building the environment where the bug lived.
Customer overview
Infinite Uploads is a WordPress plugins that allows you to move WordPress media off the local disk and onto cloud storage and a CDN. A site with a heavy media library offloads it, serves it from the edge, and stops paying for the disk.
Their customers range from a single blog to an agency running hundreds of client sites. That range is the whole difficulty.
The plugin has to behave on every host, every PHP version, and every media library it meets. A media library is also the one thing on a WordPress site that nobody can hand over a copy of.
The challenge
A ticket that reaches the Infinite Uploads desk is rarely a logic error somebody can read off a stack trace.
It names a PHP version, a host, a theme, three other plugins and a library of a size nobody on the team has locally. None of it reproduces on a developer laptop, because the laptop is not the thing that is broken.
That left the team three options, and all of them were bad.
Rebuild the reported stack by hand and lose an afternoon. Go back to the customer for more detail and lose two days to the round trip. Or ship a fix on judgement and find out from the next ticket.
The third option was the one that quietly cost the most. A fix that never ran on the stack that produced the bug is a guess with a version number on it.
The solution
Infinite Uploads wired three tools into one pass. The design constraint was simple: no step in it should wait on a human to build an environment.
SandyWP builds the stack. A sandbox comes up on the exact WordPress and PHP version named in the ticket, with the plugins that matter, in seconds. When a bug needs the customer's real content rather than a clean install, the team clones a live site into a sandbox instead.
Claude drives the middle. SandyWP exposes an MCP server, so Claude creates the sandbox, installs the plugins, sets the PHP version, deploys a build, reads the debug log and reports back.
Nothing in that list involves opening a hosting panel, waiting on a provisioner, or asking a colleague for staging credentials.
How a ticket becomes a running sandbox
This is the part that used to cost an afternoon.
- Read the stack out of the ticket. WordPress version, PHP version, the other plugins, the theme, and what the customer was doing when it broke.
- Create the sandbox on that stack. Not the nearest available version. The one in the ticket, because for this plugin the version is often the bug.
- Add the real content when the bug needs it. A clean install reproduces a configuration bug. A library of two hundred thousand files reproduces a scale bug, and only a clone of the customer's site does that.
- Reproduce the failure with
WP_DEBUGon, so the error gets read rather than guessed at. - Fix it, deploy the new build to the same sandbox, run the failing case again.
- Throw the sandbox away.
Step six does more work than it looks like. Nothing carries over between bugs, so no Infinite Uploads fix is ever verified against the debris of the last one.
How the team proves a fix
Reproducing the bug is the half that gets the attention. Proving the fix is the half that reaches the customer.
The sandbox that produced the failure takes the new plugin build, runs the failing case again, and the debug log confirms the error is gone rather than merely quiet.
That is the whole reason the log gets read at all. From a browser, a fix that hides an error and a fix that removes one look the same.
The results
There was a second effect the team did not go looking for. Reproducing every reported bug on its own stack makes the repeat offenders obvious. The team notices when it builds the same environment for the third time in a month.
What changed day to day
| Step | Before | Now |
|---|---|---|
| Build the reported stack | Manual, half a day | Seconds, from the ticket |
| Test against the customer's data | Rarely, too risky | Clone the site into a sandbox |
| Verify the fix on that stack | Often skipped | Same sandbox, same build |
| Clean up afterwards | Staging drifts, forever | Sandbox is deleted |
| Cost of a small bug | Higher than the bug | Near zero |
The change was not that any single fix got faster. It was that the team stopped deciding which bugs were worth the setup cost.
Small bugs are the ones that get dropped at every plugin company. They are real, they annoy real customers, and they are never worth an afternoon of environment building against thirty minutes of fixing.
Once the environment stopped costing anything, the maths flipped and the Infinite Uploads backlog started clearing. That is a triage change more than a productivity one.
Where it leaves them
Infinite Uploads still gets the hard tickets. The difference is that the hard part is now the bug itself rather than the hour of setup in front of it.
Eight releases, 28 changelog items, 19 of them fixes. That is what the loop produced in one stretch, and the loop is now just how the team works.