Why I Built BundleCheck: A Bundle Size API for Real Developer Workflows

Venkatesh Bommadevara — Sat, 14 Feb 2026 21:23:57 +0000

Why I Built BundleCheck

I needed bundle sizes for a side project.

Not a chart. Not a dashboard. Just an API call in a script:

input: package name (+ optional version)
output: raw, minified, gzip, brotli

That should have been straightforward. It wasn’t.

The friction with existing options

I tried several tools and APIs first, expecting this to be solved already.

What I found:

Slow: 5-10 second responses are tolerable for occasional browser checks, but painful for CI and automation.
Broken: docs that returned 404, API routes that timed out, and UI results that didn’t match API behavior.
Paywalled too early: services that advertised API access but blocked useful testing almost immediately.

None of that works if you want bundle size checks as part of your normal developer workflow.

What I wanted instead

I wanted a bundle size API that feels like infrastructure, not a demo:

Predictable request/response shape
Explicit error messages (not ambiguous failures)
Fast responses for repeated checks
Clear signal for cached vs fresh data
Easy to integrate in scripts, pipelines, and internal tools

So I built BundleCheck around those constraints.

What BundleCheck returns

One request gives you the package size profile used in real integration decisions:

raw
minified
gzip
brotli

Example request:

curl -H "X-API-Key: $BUNDLECHECK_API_KEY" \
  "https://bundlecheck.dev/v1/api/size?package=react&version=latest"

Example response shape:

{
  "package": "react",
  "version": "19.1.0",
  "fetchedAt": "2026-02-14T18:20:00.000Z",
  "cached": true,
  "sizes": {
    "raw": 12345,
    "minified": 6789,
    "gzip": 2450,
    "brotli": 2100
  }
}

The cached flag is especially useful when you’re debugging performance or tracking cold-start behavior in your integration.

Design choices that matter in practice

I cared less about flashy UI and more about operational behavior:

Cache-first path for repeated requests
Fresh compute path when data is missing or stale
Consistent API semantics so errors are actionable
Simple endpoint contract so setup time stays low

This was the difference between "nice tool" and "something I can trust in CI".

Who this is for

BundleCheck is designed as an API building block if you are building:

CI budget checks in your own pipeline
dependency health dashboards
release guardrails tied to your thresholds
package comparison tools
internal engineering tooling

These are integrations you can build on top of the API. If that sounds like your use case, I want to onboard you early and shape limits/features around real usage.

Request beta API access

The API is in beta and I’m onboarding teams gradually.

When you request access, include:

what you’re building
expected request volume
where BundleCheck fits in your workflow

That helps me prioritize reliability and limits for actual production use, not just synthetic benchmarks.

Bundle Check: https://bundlecheck.dev/

Request beta API access: https://bundlecheck.dev/beta

API docs: https://bundlecheck.dev/api

If you test it and hit edge cases, I’d genuinely like that feedback. Those reports drive the roadmap.

Forem: Venkatesh Bommadevara

Why I Built BundleCheck: A Bundle Size API for Real Developer Workflows