Most decisions about how fast to build a machine-learning system are made before a line of it is written, in the shape of the contract. Ours was, and it left a clean record of the choice, because the engagement offered two tracks for the same vision pipeline and we picked the fast one. The standard track was 32 weeks at 4 FTE for 100000 EUR. The accelerated track was 16 weeks at 6 FTE for 180000 EUR. Same system on either path: the raster-log digitisation stack that became VeerNet, EarthScan's encoder-decoder for lifting well-log curves off scanned paper. What differed was time, team size, and price, and the interesting thing about running the fast track is that it forces you to be honest about what the extra money was for. This note is that honesty, written as delivery economics rather than model architecture, because the modelling has its own home and we are not going to re-litigate it here.
The seductive reading of an accelerated track is that it is the same plan, run faster, by throwing a bigger team at it. Two extra people, half the calendar, a premium for the hurry. That reading is wrong in a way that is worth being precise about, because getting it wrong is how a delivery lead promises the sponsor the full 32-week scope in 16 weeks and then spends the back half of the project explaining why that was never what was bought.
The arithmetic that breaks the intuition
Take the two tracks apart into the numbers that actually govern delivery. The first is cost per week, which is just the price over the weeks. The standard track runs at 3125 EUR per week; the accelerated track at 11250 EUR per week. The accelerated week costs 3.6 times the standard week. That multiple is larger than the headline price ratio, which is only 1.8x, and the gap between those two ratios is the first sign that something other than plain acceleration is being priced. You are not paying 1.8 times as much for the same work compressed. You are paying 3.6 times as much per unit of calendar, which is what happens when you rent a bigger team for a shorter, more intense window.
The second number is the one that breaks the intuition entirely: total staffed labor, measured in FTE-weeks. The standard track is 4 FTE across 32 weeks, so 128 FTE-weeks. The accelerated track is 6 FTE across 16 weeks, so 96 FTE-weeks. The fast track, the expensive one, commits less total labor than the slow one. Thirty-two fewer FTE-weeks of human effort, at 80000 EUR more in price. If the accelerated track were the same plan run faster, it would need at least as many FTE-weeks as the standard plan, probably more, because compression is not free. Brooks made the durable version of this point four decades ago: people are not fungible units of schedule, and adding heads to a late or tight project buys less than linear speedup because coordination overhead rises with team size [1]. So a track that delivers in half the time with fewer FTE-weeks is not defying that law. It is obeying it, by quietly doing less work.
What the premium actually pays for
Once you accept that the accelerated track is fewer FTE-weeks, the 80000 EUR premium stops being mysterious and starts being specific. It is not buying more engineering. It is buying three things that have nothing to do with the amount of work and everything to do with the shape of it.
It buys calendar. Sixteen weeks off the delivery date has value to a sponsor independent of the work inside it, because the system starts earning, or de-risking, or unblocking a decision, sixteen weeks sooner. DeMarco's framing is the useful one here: schedule and effort are separable quantities, and a project can trade one for the other because they are not the same measurement [2]. The premium is partly a price on the calendar itself, paid regardless of how many FTE-weeks sit behind it.
It buys team compression, which is a real cost. Running six people flat out for sixteen weeks is not the same management problem as running four people for thirty-two. The coordination surface is denser, the tolerance for a bad hire or a sick fortnight is lower, and the ramp-up of the two extra people is amortised over half as long, so a larger fraction of the accelerated budget is spent on people who are still getting oriented. That is precisely the overhead Brooks warned about, and it is a genuine cost even when it does not show up as more delivered work [1].
And it buys the decision to cut scope, made in advance and paid for honestly. This is the part that the FTE-weeks number forces into the open. If the fast track has fewer FTE-weeks, then some of the plan is not being done, or not being done to the same depth. The engagement was organised into four project blocks. The coherent way to read the accelerated track is that not all four survive at full depth on the short calendar; some are trimmed, deferred, or delivered thinner. The premium is what it costs to make that cut deliberately, up front, as a priced decision, rather than discovering it in week twelve as a slip.
The lesson: scope is the lever, not speed
The habit this left us with is to stop treating "go faster" as a coherent request and to translate it immediately into its two real components. You can move the delivery date by adding people, within the sublinear limit Brooks sets, and you can move it by cutting scope. The accelerated track did both, and the FTE-weeks number tells you which one did the heavy lifting: with fewer total FTE-weeks than the standard track, the dominant lever was scope, not staffing. The two extra bodies compressed the calendar; the trimmed plan is what made 16 weeks arithmetically possible at all.
For a vision pipeline specifically, this lever has a natural place to land, and it is not the model. The trained network is a small fraction of the delivered system. Sculley and colleagues put the hard number on the intuition: in a real ML system the modelling code is dwarfed by the surrounding plumbing, data handling, serving, monitoring, and glue [3]. So when scope is the thing being cut, the honest place to cut it is rarely the architecture and almost always the plumbing depth: how many field edge cases the data pipeline handles cleanly, how automated the retraining loop is, how much of the serving and monitoring is production-grade versus demo-grade. A 16-week vision pipeline and a 32-week one can ship the same core model and be very different systems, because the difference lives in the blocks around the model, which is exactly where an accelerated scope cut should be spent if you want the core capability intact and the hardening deferred.
That reframing also disciplines the GPU budget, which is where the accelerated track's intensity is most visible. Compute is rentable by the month at fixed tiers, 750 EUR for a high-end card and 1800 EUR for an advanced one, and the accelerated track's short, dense window means more of that rent is running in parallel rather than spread thin. The cost per week is 3.6x for the same reason the GPU footprint is denser: you are compressing the same core build into half the calendar, so the burn rate per week is higher even as the total FTE-weeks are lower. Reading the GPU line without the FTE-weeks context makes the accelerated track look profligate. Reading them together makes it look like what it is: a deliberately intense, deliberately trimmed run.
What we would tell the next sponsor
If a sponsor asks for the fast track, the useful conversation is not about whether we can go faster. It is about which of the four blocks they want at full depth and which they will accept thinner, because that is the decision the price is actually pricing. The accelerated track is not a discount on time bought with a premium on money for identical output. It is a different, smaller plan, run by a bigger team, in a shorter window, at a higher weekly rate. Say that plainly at the contract stage and the back half of the project is a delivery problem. Leave it implicit and it becomes a trust problem, when the trimmed scope surfaces as a surprise instead of a choice. The arithmetic was always there to be read. The only question is whether you read it before you sign or after.
Limitations
This is one engagement's contract structure read as delivery economics, not a general model of accelerated delivery, and it should be read that way. The weeks, FTE counts, prices, and four-block count are the sourced figures from the accepted proposal; the cost-per-week and FTE-weeks quantities are plain arithmetic on those figures and carry no assumptions. The interpretation that fewer FTE-weeks implies a scope cut is the load-bearing inference, and it is an inference, not a logged fact: it is possible in principle to shave FTE-weeks through pure efficiency rather than scope, though the sublinear-speedup literature makes that an unlikely full explanation for a 25 percent labor reduction alongside a 50 percent calendar cut [1]. The instrument's scope lever is an illustrative dial over the sourced four-block count; it shows the mechanism, not a logged per-block staffing plan, and no number in it is unsourced beyond the sourced totals it redistributes. The GPU tier prices are sourced but the claim that the accelerated window runs compute more densely is a modelling assumption about how a compressed schedule uses rented cards, not a measured utilisation series. Finally, this says nothing about whether either track produced a good model; delivery economics governs how the work is bought and staffed, not whether the resulting pipeline digitises a log a petrophysicist would trust, which is a separate question with its own evidence.
References
[1] Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley (1995). The argument that adding staff to compress a schedule buys less than linear speedup, because people are not interchangeable and coordination overhead grows with team size. https://www.pearson.com/en-us/subject-catalog/p/mythical-man-month-the-essays-on-software-engineering-anniversary-edition/P200000000276
[2] DeMarco, T. Controlling Software Projects: Management, Measurement, and Estimation. Yourdon Press (1982). The case that schedule and effort are separable measurements that behave differently under pressure, so a project can trade calendar for effort. https://archive.org/details/controllingsoftw0000dema
[3] Sculley, D. et al. Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NIPS 2015). The account of how the trained model is a small fraction of a real ML system, with most of the cost in the surrounding data, serving, and monitoring plumbing. https://papers.nips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html
