Vercel round 2: the cuts that are left

First: Vercel charges for how long the whole build machine is alive, rounded up to the next whole minute — not the time until the site is ready, which is what every earlier figure used. The consequence is not academic: a saving of less than a whole minute can buy nothing at all. Tested by removing a 21-second step from 35 real deploys — 13 saved a full minute, 22 saved zero.

Second, and it retracts a saving we announced: a cancelled build is never charged for. A project with no cancelled builds matches its invoice exactly on 7 days out of 7. On our own worst day, the non-cancelled builds alone match the invoice to the unit, while counting the cancelled ones overshoots it by 180–200%. It is not a "too short to bill" rule either — one of those cancelled builds ran 17 minutes.

So the fix that stopped thousands of start-then-kill builds saved roughly nothing, and "cancelled builds are 40% of our spend" was a calculation, never a bill.

It also changes what we are trying to cut: at the time, the real production deploy was about 41% of what we paid to build — twice the share we thought. After the three fixes it is 100%, because the other 59% was the preview copy that one of the fixes removed.

The target is therefore not a dollar figure. It is a threshold: get a build's machine time under 300 seconds, against 330 today. We need about 30 seconds of cuts, combined, and nothing smaller is worth shipping alone.

Every number in that table is now read off Vercel's own bill, two ways that agree to the unit: the billed-CPU field summed per project, and Vercel's billing export for the whole account. Earlier versions of this table were priced from how long each deploy took and then calibrated against the bill, and those calibrations were absorbing the cancelled-build error. They are superseded. Four different daily figures had got into circulation — $26.29, $18.21, $14 and $19.67. The measured one is $9.04; the others should not be quoted again.

A cycle is a calendar month, billed on the 14th — read off ten real invoices. This one was 30 days, which makes the daily budget $6.67; the one now running is 31 days, which makes it $6.45 and the gap $80 instead of $71. The $271 is the measured daily figure carried across a cycle, not a cycle that has been billed yet.

One avenue is still open, and it is not on this page. Everything here is closed, but how often we build production is not — it belongs to the build-volume work, and it is the only thing left that can move the number. Closing the last $2.37 a day means production building about 30% less often: everything that is not building now costs $1.25 a day and nothing on the list touches it, so the build itself would have to come down from $7.79 a day to $5.42 — a cut worked out in dollars, because Vercel prices build minutes on a tier scale and the rate we are actually billed ($0.003307 a minute over these two days) is not the list $0.0035. Deploying less often is the thing we were told not to do, so this is a founder's trade, not an engineering one.

Full working, with the controls and the day-by-day numbers: the bill, re-derived.

When this was first written, six deploys since the fixes was not enough to tell a 1–2% change from noise, and we did not claim otherwise. The median deploy read 290 seconds after, against 276 and 287 on the two full days before. Two full days are now in, and the per-deploy cost has not moved: $0.183 a production deploy on the Monday and $0.196 on the Tuesday, against $0.172 on the Saturday before. Production still ships whenever a change is merged; what changed is that nothing else is being built alongside it.

So the claim rests on what was shipped rather than on those medians: nothing merged in this round touches the production build at all. Three levers shipped write-ups only; the other four shipped nothing. And both of the two changes that could have made a deploy slower — the smaller machine, and keeping the compiler cache — were measured and deliberately not made.

That day-to-day comparison has now been taken, on 2026-10-14, and it is the figure above.

The type check was already switched off on Vercel 184 days ago; a real build log says so in as many words. GitHub's check is still required, so nothing slipped through.

The compiler cache is the one that mattered. The hope was that there was room to keep it, since the saved files now measure 1.01 GB against a 1.5 GB limit. The compiler's share alone is 2.15 GB. It does not fit, and if the total ever goes over the limit Vercel throws away all of it — including the part that currently turns a 98-second package download into 3 seconds. This is the one change on the list that could have left us worse off than before we started.

Duplicate deploys do not exist: 109 production deploys shipped 109 different changes, never going backwards. One change had two attempts, but the first failed in three seconds before any building began.

The debug-file upload could never have worked: the credential it needs has never existed on the project, and the error tracker's own list of uploaded files is empty.

The build machine closes on one measured fact: the price per unit of work is identical on every size of machine, to six decimal places, on our own bill. So halving the cores only saves money if the build does not take twice as long — and it would have added up to 2.8 minutes to every deploy.

Our production crash reports are unreadable today. The debug-file upload has never run, so the ability to read a production error properly is something we assumed we had and do not. Switching it on would add 30–90 seconds to every production deploy — the one thing we were told not to do. That is a trade between debuggability and deploy speed, and it is a founder's call.

The deploy depends on one Vercel setting that is invisible from our code. If someone deletes it, the type check silently comes back, every deploy gets slower and dearer, and no change in our code would show why. Raised as a decision, with the ordering that matters: our code must set it first, and only then can the Vercel copy be removed. The reverse order causes exactly the problem.

Everything on the account that is not building the main site now comes to $1.25 a day, read off the bill for both post-fix days ($1.2489 and $1.2430 — steady to half a cent). That covers every page a person loads, all 45 scheduled background jobs, and the other 19 projects, of which two built anything at all (52¢ and 66¢ a day between them). For the month just billed it was $51.09 against $579.64 of building.

It is half the remaining gap, and there is nothing in it to cut: deleting every scheduled job would recover about a sixth of the target and would risk missing real work.

That sweep was checked for blindness: it did find the one other project that builds, so the zero for the other 18 is a real zero rather than a broken search.

• A full day of billing since the fixes. Now read — two of them, 2026-10-12 and 2026-10-13, off Vercel's own bill. That is where every figure on this page now comes from.
• How many production deploys we really do a day. Now measured: 44 on the Monday and 37 on the Tuesday, against 63 on 2026-10-10 and 84 on 2026-10-09. The earlier "96 if scaled up" was an extrapolation and is superseded.
• The spend limit itself. No Vercel interface we can reach reports the configured $200 — it is derived from Vercel's own email arithmetic (300% of $600.08) and is waiting on somebody to read it off the billing settings page. It does not change any figure above.
• The cost of each individual scheduled job. Vercel's usage pages refused our access token on five different attempts. The whole-category ceiling above answers the question that was actually asked.
• Peak memory during a build. Not published by Vercel, so the memory risk of a smaller machine is named rather than measured.
• Whether the build genuinely goes faster with more cores. Settling it would mean running the same change on two machine sizes, which means changing the setting. Deliberately not done.
• The contents of the second 11-second silent gap — being measured now.