Budget model and vendor evaluation
Written by a person. Last read by a person on 2026-09-07, 21 days ago. Its facts were checked by the eval suite on 2026-09-28.
You are checking whether the money is real, or you want to see weights set before submissions rather than after.
Scenario-based sample. Halden Systems is invented, and so is every figure about it.
Bottom line. $2.1M over 3 years against a gap costing Halden Systems $6.1M a year. We recommend buying the platform and building the content, because the content is the capability and the platform is not. The evaluation weights below were fixed before any vendor was approached.
Total cost of ownership, 3 years
Internal time is in the model. A buy that removes a license cost and adds 0.5 of a person has moved the money rather than saved it, and a model that leaves internal effort out is the standard way that gets hidden.
| Year 1 | Year 2 | Year 3 | Total | |
|---|---|---|---|---|
| Platform licences | $180,000 | $195,000 | $210,000 | $585,000 |
| Implementation and migration | $145,000 | $145,000 | ||
| Content authoring, internal | $310,000 | $180,000 | $150,000 | $640,000 |
| Enablement function, 2.5 people | $220,000 | $230,000 | $240,000 | $690,000 |
| Local expert time, 9 sites | $0 | $0 | $0 | $0 |
| Total | $855,000 | $605,000 | $600,000 | $2,060,000 |
The 2.5 people are a program lead, a content lead and a half-time analyst. They design the program, write the core pieces and hold the standard. They are sized against a library of 79 rather than the 140 we have, and the authoring line above falls by half over 3 years because the teams that own each engineering system take on the pages about their own system, the way they already carry release notes.
The zero row is deliberate and is the number a reviewer should push on. Local expert time is real and it is not new money: those people already answer these questions, at 760 engineer hours a week. The program moves that time rather than adding it, and if it does not, the model is wrong and gate 4 will show it.
Consolidating the $410,000 of duplicate regional spend covers most of year 2 and year 3 on its own. We have not netted it off above, because a saving counted inside the cost of the thing producing it is how a budget stops being checkable.
Make or buy, component by component
"Build against buy" is not one decision. The program has 7 pieces and we made the call separately on each, because the answer is different for a platform than it is for the material that runs on it.
| Component | Decision | Why |
|---|---|---|
| Delivery platform, hosting, assessment engine, reporting | Buy | No advantage in that market, and no reason to acquire one |
| Migrating the 44 units that survive the audit | Buy | One-off, and the vendor does it faster |
| The 57 pieces we write or rewrite | Build | The material is the capability |
| What a unit has to prove, and the standard it is edited against | Build | This is the program, not a feature of a platform |
| Customer and partner certification | Build, on the bought platform | It is the revenue leg, and it reuses the internal material |
| The local expert network and delivery | Build | 9 people at 9 sites is not a thing anybody sells |
| Change management and internal communication | Build | Buying adoption produces a rollout with no owner here |
The only line where the choice is close is the first, so that is the one costed below. Everything else is settled by what it is: the material encodes how our systems actually work, and a vendor writing it would teach a generic tool rather than ours.
The platform decision, with the arithmetic
Content and the enablement function cost the same either way, so they are not in this comparison. What differs is 2 lines.
| Build | Buy | |
|---|---|---|
| Engineering, 1.5 FTE at $145 loaded, 1,800 hours a year | $1,174,500 | none |
| Hosting and infrastructure, $40,000 a year | $120,000 | included |
| Licences, 3 years | none | $585,000 |
| Implementation and migration | none | $145,000 |
| Difference over 3 years | $1,294,500 | $730,000 |
| Build | Buy | |
|---|---|---|
| Time to first site live | 11 months | 4 months |
| Ongoing engineering ownership | 1.5 FTE, permanently | none |
| Accessibility conformance | ours to prove | contractual, and testable |
| Exit cost | none | 1 quarter of export and re-platforming |
We recommend buying. It is $564,500 cheaper over 3 years and live 7 months sooner, which is the opposite of what a build-against-buy comparison usually concludes.
It reads that way only because the engineering time is priced. Build looks cheaper the moment somebody treats those 1.5 people as free, and they are not free.
They are the same engineers absorbing 760 hours a week of interruptions, which is the problem this program exists to reduce. Treating them as free is the same error as a $0 row in a budget, and there is one of those above that we have asked you to push on.
Building also puts an internal team between every content change and the people who need it, which is the exact shape of the problem we are trying to fix.
Evaluation matrix
These weights were fixed on 2026-09-07, before any vendor was approached. This file's history shows it. Weights chosen after seeing submissions are a justification rather than an evaluation, and a procurement reader can tell the difference immediately.
| Criterion | Weight | Why it carries that weight |
|---|---|---|
| Level 2 reporting: can it show understanding, not completion | 25 | The whole program turns on this measure |
| Accessibility conformance, evidenced | 20 | Non-negotiable, and cheaper to demand than to retrofit |
| Asynchronous delivery across 17 hours | 15 | No shared working hour exists |
| Identity integration and revocation | 15 | A security boundary rather than a convenience |
| Export and exit cost | 10 | The clause nobody reads until they need it |
| Content migration effort | 10 | Real, and one-off |
| License cost | 5 | The number everybody optimizes and the smallest line |
License cost is weighted last on purpose. It is 28% of the model and the easiest thing to negotiate after selection, and weighting it heavily selects for the vendor best at discounting rather than the one best at level 2.
Scorecard after signature
Reviewed monthly by the Director of Enablement, reported quarterly to the COO. This is where the money is actually lost.
| Measure | Target | Trigger |
|---|---|---|
| Support tickets we raise, resolved within SLA | 90% | 2 consecutive months below triggers escalation |
| Platform availability during any site's working hours | 99.5% | Any month below triggers a service credit |
| Reporting accuracy: figures we did not have to correct | 100% | Any correction is logged and reviewed |
| Roadmap items delivered against commitment | 70% | 2 quarters below opens the exit clause |
| Accessibility regressions | 0 | Any regression pauses the next payment |
The last row has no tolerance because a regression there breaks a commitment we made to our own staff, and a target with a tolerance is a target that will be spent.