The model
Build duration
How many weeks the build takes with the budgeted team: build effort across every application divided by weekly FTE capacity.
- Unit
- weeks
- Where you enter it
- Computed; shown on the All Apps view and flagged when it exceeds the release cadence.
What it means
The sum of build effort across all applications divided by the FTE capacity per week. It is workspace-level because the same people build every application; a per-application duration is shown on each tab but labelled as indicative, since it assumes the team works on nothing else.
It is checked against the release cadence implied by runs per year: a build that takes longer than the gap between releases is flagged.
Why it matters to the cost
Duration is the feasibility check the cost figures do not give you. Two tools with similar five-year totals can differ by months in when the suite is actually useful, and a suite that is not ready for the next release delays every saving in the model by that long.
Typical values
Weeks for an AI-native tool on a single application; a quarter or more for a homegrown framework across an estate.
Typical values describe a category of tool — AI-native, codeless, script-based, homegrown, manual — never a named product. Why we do not price named products.
Where it appears in the model
Build duration is a workspace-level question
- FTE capacity
- FTEs in budget × productive hours per FTE per year ÷ 52
- Build duration
- Σ Build effort across all applications ÷ FTE capacity
Every name is a link to its definition. See the whole model.
Try it with your numbers
The calculator works build duration out from the rows it is built on. Change those and every total on the page moves with them — free, in your browser, nothing to install.
See how build duration impacts the calculation of test automation costsLast reviewed 2026-09-15. All terms.