The model
FTE capacity
The hours a week the budgeted team can give: FTEs in budget times productive hours, divided by 52.
- Unit
- hours per week
- Where you enter it
- Settings: "FTEs in budget" and "Productive hours per FTE, per year".
What it means
The number of full-time equivalents in the budget multiplied by productive hours per FTE per year, divided by 52 weeks. It is a workspace-level figure — applications compete for the same people — and it is what build effort is divided by to get the build duration.
The model also compares ongoing effort against it: where the yearly run and maintenance hours would need more FTEs than the budget holds, the vendor is flagged.
Why it matters to the cost
A cost model can produce a plan nobody can execute. Four FTEs at 1,800 hours is about 138 hours a week; a 1,200-hour build takes nine weeks of the whole team, and if a release ships every four weeks the suite will not be ready in time. The flag exists so that shows up before the contract is signed.
Typical values
Two to six FTEs for a single application; the default scenario uses four at 1,800 hours.
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 fte capacity 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 FTE capacity impacts the calculation of test automation costsLast reviewed 2026-09-15. All terms.