Fast shipping created the load. Vercel is charging us for too many automatic builds.
This report scopes the current Vercel billing period to Capxul only: capxul-web and capxul-storybook. The headline is not that the team is wasting money by shipping. It is that the current setup turns every burst of shipping into two paid Vercel build streams, including a Storybook stream we rarely need at that cadence.
Generated 2026-04-16 10:32 UTC. Billing period: 2026-04-01T07:00:00.000Z to 2026-04-16T10:30:58.684Z.
Capxul effective spend
Capxul share of Xelmar
Capxul deployments
Merged PRs
Where the Money Went
Vercel-reported spend says this is a build-minute problem. Runtime, functions, images, and data transfer are effectively noise for Capxul in this window.
capxul-web
$52.53 from Build Minutes.
407 deployments: 378 previews, 29 production, 122 errors.
capxul-storybook
$34.56 from Build Minutes.
406 deployments: 378 previews, 28 production, 100 errors.
Spend by Capxul project
$87.09 of $87.09 is Build Minutes. That is 100.0% of Capxul spend.
Shipping Velocity Context
The spend spike lines up with a real delivery spike: 93 merged PRs since the billing period started, 115 PRs opened, and 414 local commits on the current branch history since 2026-04-01. The daily chart uses the Vercel daily billing rows currently posted by the CLI; the headline cards use live period totals.
The goal should be to preserve this shipping pace while removing automatic builds that do not create useful review signal.
Preview Fan-Out
Each Capxul push is feeding two Vercel projects. In this billing period Vercel created 756 previews and 57 production deployments across web and Storybook.
Deployments by project
Top branches by deployment count
222 Capxul deployments ended in ERROR. Failed previews still spend build time before they fail, so repeated failure loops should be treated as cost defects.
Configuration Evidence
Both Capxul Vercel projects are connected to Git and have no ignored build command. The existing-project monorepo skip setting is not enabled in the project payload I inspected.
| Project | Root | Framework | Git deployments | Ignored build step | Skip unaffected | Build machine | Elastic concurrency |
|---|---|---|---|---|---|---|---|
| capxul-web | apps/web | nextjs | {'createDeployments': 'enabled'} | None | None | team/default | True |
| capxul-storybook | apps/storybook | vite | {'createDeployments': 'enabled'} | None | None | turbo | True |
Action Plan
The most useful actions reduce build fan-out while keeping the team moving fast. I would do these in order.
| Priority | Action | What to do | Expected impact | Risk / check |
|---|---|---|---|---|
| P1 | Gate Storybook previews first | Set capxul-storybook to build only on main/dev, or make PR Storybook previews manual. Keep a deploy hook for design QA. | Up to $34.56 MTD; about $68.44/mo at this pace. | Medium: fewer automatic UI snapshots, but preserves production/main Storybook. |
| P2 | Enable monorepo skipped deployments | Turn on Vercel's skip-unaffected-monorepo-projects setting for both existing projects. | Avoids builds when a push does not affect the project root or internal deps. | Low: Vercel uses workspace dependency awareness; verify with a doc-only and package-only PR. |
| P3 | Add a repo-owned ignored build script | Use one script from the repo root and point Vercel Ignored Build Step at it from each app root. | Cuts backend/docs/CLI-only pushes before they consume build minutes. | Low if tested with shallow clone behavior; exit 0 skips, exit 1 builds. |
| P4 | Move Storybook off Turbo unless it truly needs it | capxul-storybook is explicitly configured with buildMachineType=turbo. Trial Standard/Enhanced after gating previews. | Potentially material because Turbo is always billed at a much higher per-minute rate. | Medium: may need memory headroom; do one controlled build before changing permanently. |
| P5 | Limit on-demand concurrency to one active build per branch | Both projects have elastic concurrency enabled. Use the project setting that limits active builds per branch. | Reduces paid duplicate builds during merge trains and fast branch churn. | Low/medium: slower preview feedback on very busy branches, production should stay prioritized. |
| P6 | Treat failed preview builds as spend defects | Current window has 222 failed Capxul deployments. Triage Storybook failure loops before re-enabling full preview fan-out. | Stops repeated paid failures and makes spend reviews less noisy. | Low: cheaper than letting Vercel be the first failing signal. |
Concrete Implementation Shape
Use Vercel's ignored build semantics: exit 0 to skip a deployment and exit 1 or greater to build. Because both projects use app roots, a shared repo script would be referenced from Vercel as node ../../scripts/vercel-ignore-build.mjs web or node ../../scripts/vercel-ignore-build.mjs storybook.
Recommended first policy:
web Build production, build dev, build branches explicitly prefixed with preview/, and build PR branches only when paths affect apps/web or shared UI/runtime packages.
storybook Build production and dev; make other Storybook previews manual unless paths affect apps/storybook or packages/ui and the PR requests Storybook review.
Decision Options
Conservative
Enable monorepo skip plus an ignored build script. Keep web PR previews. Gate Storybook to main/dev. This keeps most review ergonomics and should cut the noisiest spend.
Aggressive
Storybook becomes manual-only; web previews only build for main/dev and preview/* branches. This is the biggest spend reduction, but changes how reviewers request preview environments.
Sources and Caveats
Sources: live Vercel CLI/API for team xelmar, live GitHub PR data for Xelmar-tech/Capxul, and local git history. Vercel gives billing by project/service and deployment metadata by deployment; it does not expose per-deployment dollars through the CLI data used here, so branch-level cost is inferred from deployment counts and build timing, not allocated as exact dollars.
Vercel references: Ignored Build Step exit behavior, monorepo skipped deployments for existing projects, and build machine pricing and concurrency settings.