Opinion

Stop maintaining sandbox apps: the hidden tax on every DevRel team

Most API-first companies run a Heroku app or Lambda just to host integration demos. We tallied what it actually costs in engineering time per quarter.

·6 min read

Every API-first company we have talked to in the last three months runs at least one sandbox app whose only purpose is to demo their product. A small Express server proxying calls to their API. A Next.js page with hard-coded test keys. A Lambda that occasionally panics because the runtime moved on without it.

Nobody owns it. It got built by the first DevRel hire, deployed to a Heroku dyno that someone has the credentials to, and then it became infrastructure. Below is what we have repeatedly seen this cost — not in dollars, in attention.

What the demo sandbox really costs

  • ·Two PRs per quarter to bump a vulnerable dependency that has nothing to do with the demo itself.
  • ·One full afternoon per release training the new SE on how to point the demo at their own account.
  • ·One outage per quarter where a viewer plumbed in their production key and the sandbox stopped responding because it now belongs to two people at once.
  • ·Six hours per year explaining to security why the demo app reads from S3 with broad IAM permissions.

The math: roughly 40 engineering hours per year per sandbox, plus a handful of incidents nobody schedules. On a DevRel team of three, that is one full work-week vanished — and nobody felt it because it never lands in one sprint.

The structural problem

Sandboxes are integration-shaped, not product-shaped. They contain logic that belongs in your API docs, deployment infrastructure that belongs to your platform team, and customer-key handling that belongs to your security team. None of those teams own the demo, so it falls to whoever ran the last workshop.

The sandbox app is the single piece of code in our org with zero owners and zero on-call. We just hope it does not break before a conference.

What replaces it

A purpose-built demo host gives you the same outcome — interactive integration, real upstream calls, viewers using their own keys — without the deployment surface. Push a ZIP, get a URL, your keys never leave the proxy. That is exactly what apiqube does, and the reason it exists is the math above.

If you do not want to move yet, at least audit yours: who owns it, who last shipped to it, what would happen if the cloud account it lives in lost access tomorrow. Most teams do not know.