Build vs Buy Analysis: [Capability name]
Sourcing analysis for one business capability: whether to build it,
buy a commercial product, subscribe to SaaS, adopt open source, extend
a platform the organisation already owns, or have a partner deliver it.
It records the capability need, a differentiation test, knock-out
screening, fit against functional and quality needs, five-year cost,
time to market, lock-in and exit, skills and operating model, risks, a
weighted evaluation with sensitivity, and the decision with its
conditions. Structure aligned with the acquisition planning concerns of
ISO/IEC/IEEE 41062:2024 (software acquisition) and the quality model of
ISO/IEC 25010:2023. Replace every [bracketed] value and every row
marked Example.
Document control
| Field | Value |
|---|
| Document ID | [BVB-001] |
| Capability | [Capability name and ID from the capability map] |
| Business owner | [@business-owner] |
| Decision needed by | YYYY-MM-DD |
| Horizon for comparison | [Example: 5 years] |
| Version | [0.1] |
| Status | [Draft / In review / Decided / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@cto], [@business-owner], [@procurement], [@security-architect], [@finance-partner] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related documents | [ADR-NNN], [TCO-NNN], [TS-NNN], [VES-NNN] |
Approvals
| Role | Name | Decision | Date |
|---|
| Business owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief technology officer or architecture board | [@name] | [Decision] | YYYY-MM-DD |
| Finance | [@name] | [Decision] | YYYY-MM-DD |
| Procurement | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft: need, differentiation test, long list |
| 0.2 | YYYY-MM-DD | [@name] | Example: Knock-out screening and TCO summary added |
| 1.0 | YYYY-MM-DD | [@name] | Example: Decided: hybrid (open-source engine plus custom rules) |
Contents
1. Decision context
| Item | Value |
|---|
| Trigger | Example: The pricing logic inside the legacy e-commerce platform cannot run personalised promotions, and the platform is being replaced by a composable stack over the next 18 months |
| Current state | Example: Prices and promotions are maintained in spreadsheets and loaded nightly; 3 to 5 pricing errors reach customers each month |
| Cost of doing nothing | Example: Marketing estimates USD 1.2 million a year in promotions it cannot run, plus the manual effort of 2 full-time pricing analysts |
| Non-negotiable constraints | Example: Live before the peak season of YYYY, 9 months after the decision date; data stays in the EU; must expose APIs to the new storefront and the point-of-sale system |
| Strategy references | Example: Architecture principle AP-04 "Buy for parity, build for advantage"; cloud strategy CS-2 (managed services first) |
| Out of scope | Example: Supplier cost pricing and the ERP price master |
2. Capability need
2.1 Outcomes
- Example: Merchandisers create and schedule promotions without IT
involvement, with approval workflow.
- Example: Every price shown on web, app and in store comes from one
service, so channels cannot disagree.
- Example: Personalised offers can be targeted at customer segments in
real time.
2.2 Key requirements
| ID | Requirement | Type | Must or should |
|---|
| CAP-REQ-001 (Example) | Evaluate price and applicable promotions for a basket of up to 100 lines | Functional | Must |
| CAP-REQ-002 (Example) | p95 latency below 80 ms at 2,000 requests per second at peak | Performance efficiency | Must |
| CAP-REQ-003 (Example) | 99.95% monthly availability for price evaluation | Reliability | Must |
| CAP-REQ-004 (Example) | Customer and order data processed and stored in the EU | Security and compliance | Must |
| CAP-REQ-005 (Example) | Promotion rules editable by business users with versioning and approval | Functional, interaction capability | Must |
| CAP-REQ-006 (Example) | Simulation of a promotion's margin impact before publishing | Functional | Should |
| CAP-REQ-007 (Example) | Rules and history exportable in an open format | Flexibility, maintainability | Should |
3. Differentiation test
| Question | Answer | Evidence |
|---|
| Do customers choose us because of how this capability works? | Example: Partly: promotions drive 30% of revenue, but competitors offer similar mechanics | Marketing analysis MA-17 |
| Does our way of doing it differ from industry practice in ways we want to keep? | Example: Yes for personalised bundles; no for standard discounts | Workshop notes WS-3 |
| Would a standard product force us to change a process we consider an advantage? | Example: Only for bundle logic | Fit-gap FG-2 |
| How often does the capability change? | Example: Weekly rule changes; quarterly new mechanics | Change log |
| Is there a mature market of products for it? | Example: Yes, several SaaS and packaged products | RFI responses RFI-04 |
| Do we hold, or can we hire, the skills to build and run it? | Example: Partly; rule engine skills are scarce | Skills review |
| Class | Meaning | Default sourcing stance |
|---|
| Differentiating | Sets the organisation apart and changes often | Build or assemble, keep control of the core logic |
| Parity | Must be done well, but the way it is done is not an advantage | Buy or subscribe, configure rather than customise |
| Commodity | Standard, stable, widely available | Subscribe or use the platform already owned |
Result: [Example: Mixed. Standard price and discount evaluation is
parity; personalised bundle logic is differentiating. Options that
combine a standard engine with custom rules are therefore in scope.]
4. Sourcing options and knock-out screening
4.1 Options
| ID | Option | Description |
|---|
| O1 (Example) | Build | Custom pricing service developed and run by the in-house platform team |
| O2 (Example) | Subscribe (SaaS) | Commercial pricing and promotions SaaS, configured and integrated |
| O3 (Example) | Buy (packaged, self-hosted) | Commercial product licensed and run in our cloud account |
| O4 (Example) | Open source plus custom (hybrid) | Open-source rule engine, custom bundle logic and business UI built in house |
| O5 (Example) | Extend existing platform | Pricing module of the ERP already licensed |
| O6 (Example) | Partner delivers and runs | Systems integrator builds and operates a custom service under a managed service contract |
4.2 Knock-out criteria
| Knock-out | O1 | O2 | O3 | O4 | O5 | O6 |
|---|
| KO-1 Meets CAP-REQ-002 latency at peak (evidence: benchmark or reference) | Pass | Pass | Pass | Pass | Fail | Pass |
| KO-2 Data stays in the EU (CAP-REQ-004) | Pass | Pass | Pass | Pass | Pass | Pass |
| KO-3 Live before peak season | Pass | Pass | Fail | Pass | Pass | Fail |
| KO-4 Within budget ceiling over the horizon | Pass | Pass | Pass | Pass | Pass | Pass |
| Result | Continue | Continue | Excluded | Continue | Excluded | Excluded |
Example notes: O5 failed KO-1 because the ERP module evaluates prices
in batch and its synchronous API was measured at p95 410 ms. O3 and O6
failed KO-3: the vendor's earliest installation slot and the partner's
mobilisation plan both end after the peak season start. O1 passes KO-3
on plan only (9 months against a 9-month window, zero float); that
residual exposure is carried as BVB-RSK-001 and scored in C4 and C6,
not hidden by the pass.
5. Fit assessment
5.1 Functional fit
| Requirement | O1 Build | O2 SaaS | O4 Hybrid | Evidence |
|---|
| CAP-REQ-001 Basket evaluation | Full (to be built) | Full | Full | SaaS demo D-2; engine PoC P-1 |
| CAP-REQ-005 Business rule editing | Full (to be built) | Full | Partial: UI to be built | Demo D-2 |
| CAP-REQ-006 Margin simulation | Full (to be built) | Partial: no bundle simulation | Full (to be built) | Demo D-2 |
| Personalised bundles (differentiating) | Full | Partial: fixed bundle types | Full | Fit-gap FG-2 |
| Fit summary | All needs met, all to be built | 2 partial | 1 partial, closed by planned build | |
5.2 Quality fit
| Characteristic | Key concern | O1 Build | O2 SaaS | O4 Hybrid |
|---|
| Performance efficiency | p95 below 80 ms at 2,000 rps | Unproven until built | 45 ms at 3,000 rps in vendor test, verified at reference | 38 ms at 2,500 rps in PoC P-1 |
| Reliability | 99.95% availability | Depends on our operations | Contractual 99.9% only | Depends on our operations |
| Security | EU data, access control, audit | Under our control | Certified; EU hosting and EU-based support confirmed in the draft contract | Under our control |
| Flexibility | Add new mechanics quickly | High | Limited to vendor roadmap | High |
| Maintainability | Long-term change cost | Whole codebase ours | Vendor maintains | Engine maintained by community; custom code ours |
Example finding: O2's contractual availability (99.9%) is below
CAP-REQ-003 (99.95%). It is not a knock-out because the vendor offers a
premium tier at extra cost, which is included in section 6.
5.3 Integration and data fit
[Describe how each option connects to the storefront, point of sale,
customer data platform and ERP, and who owns the price data.] Example:
all three options expose REST APIs. O2 needs a nightly product catalogue
export to the vendor and holds a copy of promotion history; O1 and O4
read the catalogue from the existing event stream.
6. Cost over the horizon
All figures in USD thousand, undiscounted, Example values from TCO-007.
| Cost line | O1 Build | O2 SaaS | O4 Hybrid |
|---|
| Year 1 implementation (build or configure, integrate, migrate) | 1,400 | 250 | 800 |
| Year 1 run (licences or subscription, cloud, people) | 100 | 500 | 80 |
| Years 2 to 5 run, per year | 380 | 500 | 300 |
| Years 2 to 5 run, total | 1,520 | 2,000 | 1,200 |
| 5-year total | 3,020 | 2,750 | 2,080 |
| Exit cost at year 5 (estimate, not in total) | 50 | 300 | 80 |
Example arithmetic: O1 = 1,400 + 100 + 4 x 380 = 3,020. O2 = 250 + 5 x
500 = 2,750, where 500 per year is a subscription of 380 (premium
availability tier) plus an internal team of 120. O4 = 800 + 80 + 4 x
300 = 2,080. For the net present value of each stream, use the TCO
analysis; ranking by undiscounted total is enough here only when the
spend profiles are similar.
7. Time to market and delivery capacity
| Item | O1 Build | O2 SaaS | O4 Hybrid |
|---|
| First release (standard pricing and promotions) | Example: 9 months | Example: 4 months | Example: 6 months |
| Differentiating bundle logic | Example: 12 months | Example: Not available; depends on vendor roadmap | Example: 9 months |
| Team needed | Example: 8 engineers, 1 product owner | Example: 2 integration engineers, 1 configuration specialist | Example: 5 engineers, 1 product owner |
| Capacity available | Example: Platform team fully booked until Q2; hiring needed | Example: Available | Example: 3 engineers available, 2 to hire |
| Fits the peak season date? | Example: Only with no slippage | Example: Yes, with margin | Example: Yes, with 3 months float |
8. Lock-in, exit and portability
| Concern | O1 Build | O2 SaaS | O4 Hybrid |
|---|
| What is locked in | Example: Nothing external; knowledge locked in the team | Example: Rule definitions in a proprietary format, promotion history | Example: Engine-specific rule syntax for standard rules |
| Data export | Full | Example: CSV export of promotions; history via API only, rate limited | Full |
| Exit route | Rewrite or replace | Migrate rules to a new product; 6 months parallel run | Swap engine behind the service interface |
| Contract protections needed | Not applicable | Example: Data return in an agreed format, 12-month exit assistance, price cap on renewal | Not applicable |
| Open-source licence | Not applicable | Not applicable | Example: Apache-2.0 engine; no copyleft obligations; licence review LR-12 |
| Project health (open source) | Not applicable | Not applicable | Example: OpenSSF Scorecard checks reviewed; 3 active maintainers from 2 organisations |
9. Skills and operating model
| Activity | O1 Build | O2 SaaS | O4 Hybrid |
|---|
| Product ownership | Internal | Internal | Internal |
| Engineering of core logic | Internal team | Vendor | Internal team on top of community engine |
| Configuration of rules | Business users through custom UI | Business users through vendor UI | Business users through custom UI |
| 24x7 operations | Internal SRE rota | Vendor, with internal on-call for integration | Internal SRE rota |
| Vendor management | Not applicable | Required: 0.2 full-time equivalent | Not required |
| Skills gap | Rule engine design, high-throughput services | Vendor configuration certification | Engine internals, 2 engineers to hire |
10. Risk comparison
| ID | Risk | Option | Likelihood | Impact | Response |
|---|
| BVB-RSK-001 (Example) | Build overruns and misses the peak season | O1 | High | High | Phase the scope; fall back to manual pricing for one season |
| BVB-RSK-002 (Example) | Vendor roadmap never delivers bundle types | O2 | Medium | High | Contractual roadmap commitment, or accept the gap |
| BVB-RSK-003 (Example) | Vendor price rises sharply at renewal | O2 | Medium | Medium | Renewal cap in the contract |
| BVB-RSK-004 (Example) | Open-source engine loses maintainers | O4 | Low | Medium | Engine isolated behind an internal interface; budget for a fork if needed |
| BVB-RSK-005 (Example) | Hiring the 2 engine engineers takes longer than planned | O4 | Medium | Medium | Short-term contractors from a specialist partner |
| [BVB-RSK-NNN] | [Risk] | [Option] | [L / M / H] | [L / M / H] | [Response] |
11. Weighted evaluation and sensitivity
The weighted score of option j is Sj=∑iwisij, with the
weights wi summing to 1 and scores sij from 1 (poor) to 5
(excellent).
| Criterion | Weight | O1 Build | O2 SaaS | O4 Hybrid | Evidence |
|---|
| C1 Functional fit | 0.25 | 5 | 4 | 4 | Section 5.1; O4 partial closed by its own planned build, O2 partials depend on the vendor roadmap (BVB-RSK-002), and its bundle gap is scored again under C2, so C1 is not lowered twice |
| C2 Control of differentiating logic | 0.15 | 5 | 2 | 4 | Sections 3, 5.2 |
| C3 5-year cost | 0.20 | 2 | 3 | 4 | Section 6 |
| C4 Time to market | 0.15 | 2 | 5 | 3 | Section 7 |
| C5 Lock-in and exit | 0.10 | 5 | 2 | 4 | Section 8 |
| C6 Delivery and skills risk | 0.15 | 2 | 4 | 3 | Sections 9, 10 |
| Weighted score | 1.00 | 3.50 | 3.45 | 3.70 | |
Example arithmetic, criterion by criterion from C1 to C6:
SO4SO1SO2=0.25(4)+0.15(4)+0.20(4)+0.15(3)+0.10(4)+0.15(3)=3.70=1.25+0.75+0.40+0.30+0.50+0.30=3.50=1.00+0.30+0.60+0.75+0.20+0.60=3.45 | Scenario | Weight change | O1 | O2 | O4 | Leader |
|---|
| Baseline | As above | 3.50 | 3.45 | 3.70 | O4 |
| Example: Urgency dominates | C4 0.25, C2 0.05 | 3.20 | 3.75 | 3.60 | O2 |
| Example: Cost pressure | C3 0.30, C1 0.15 | 3.20 | 3.35 | 3.70 | O4 |
| [Scenario] | [Change] | [ ] | [ ] | [ ] | [ ] |
Example reading: moving 0.10 of weight from C2 to C4 changes O2 by
−0.10(2)+0.10(5)=+0.30 and O4 by −0.10(4)+0.10(3)=−0.10, so
the leader changes. The baseline lead of O4 over O1 (0.20) is also inside
the rule-of-thumb noise band, so the score alone does not decide. Two
facts do: O4 has the lowest 5-year cost by USD 0.67 million (section 6)
and meets the peak season date with float (section 7). The business owner
confirmed that the date is firm but that a one-season fallback to manual
pricing is acceptable, which keeps the baseline weights.
12. Recommendation and decision
| Item | Value |
|---|
| Recommendation | Example: O4 Hybrid: open-source rule engine behind an internal pricing service, with custom bundle logic and business UI |
| Main reasons | Example: Lowest 5-year cost (USD 2.08 million), keeps control of the differentiating bundle logic, meets the peak date with 3 months float |
| Runner-up and why it lost | Example: O1 Build: highest cost and the peak date only without slippage. O2 SaaS leads only if time to market is weighted above control |
| Conditions | Example: Two engine engineers hired or contracted by YYYY-MM-DD; PoC P-1 load test repeated at 3,000 rps; licence review LR-12 closed |
| Next steps | Example: Technology selection of the engine version and hosting (TS-021); ADR-045; update the capability map sourcing column |
| Review trigger | Example: Revisit if hiring fails by YYYY-MM-DD, if a SaaS vendor adds bundle simulation, or at the 2-year architecture review |
| Decision | [Approved / Approved with conditions / Rejected], [@decision-maker], YYYY-MM-DD |
| ADR | [ADR-NNN] |
12.1 Decision roles
| Activity | Solution architect | Business owner | CTO or board | Finance | Procurement |
|---|
| Capability need and differentiation test | R | A | C | I | I |
| Options and knock-outs | R | C | A | I | C |
| Cost summary | R | I | I | A | C |
| Weighted evaluation | R | C | A | C | C |
| Decision | C | R | A | C | I |
R = responsible, A = accountable, C = consulted, I = informed.
13. Glossary and references
13.1 Glossary
| Term | Meaning in this template |
|---|
| Build | The organisation designs, develops and runs the capability itself |
| Buy | The organisation licenses a commercial product and runs it |
| Subscribe (SaaS) | The organisation uses a product the vendor runs as a service |
| Hybrid | A standard component, commercial or open source, extended with custom parts |
| Differentiating capability | One that sets the organisation apart from competitors and changes often |
| Parity capability | One that must be done well but is not a source of advantage |
| Knock-out criterion | Must-have condition; an option that fails it is excluded before scoring |
| Lock-in | Cost and effort of moving away from an option once adopted |
| Exit plan | Agreed route, time and cost to leave an option, including data return |
13.2 References
| Reference | Version or date checked | Use |
|---|
| ISO/IEC/IEEE 41062:2024, Software engineering, Life cycle processes, Software acquisition, iso.org and standards.ieee.org | Edition 2, published October 2024 | Acquisition planning concerns (structure only) |
| ISO/IEC 25010:2023, Product quality model, iso.org | Edition 2, November 2023 | Quality characteristics in section 5.2 |
| ISO/IEC/IEEE 12207:2026, Software life cycle processes, iso.org | Edition 2, 2026 | Acquisition and supply processes as context |
| OpenSSF Scorecard, scorecard.dev | Checked at date of analysis | Open-source project health signals |
| [TCO analysis TCO-NNN] | [Version] | Section 6 |
| [PoC report, demo notes, RFI responses] | [IDs] | Evidence for scores |
Standard and licence note
Structure aligned with the acquisition planning concerns of
ISO/IEC/IEEE 41062:2024 and the product quality model of ISO/IEC
25010:2023. These are copyrighted standards: only their numbers, titles
and the names of quality characteristics are used, and no clause text,
tables or definitions are reproduced. The differentiation test, scoring
method and all other text are original and follow common industry
practice; figures in the worked example are illustrative. Check the
current editions at iso.org and obtain the standards for their
normative content. Template licence: MIT.