Paper 01: Total Cost of Ownership in Bespoke Versus Templated SystemsAuthor: Engineering Team, Binary & Bus, Sys.
Published: 3rd September, 2026
Status: Position Statement
Abstract: Commercial software engagements are routinely priced against initial build cost, a figure that systematically understates the total cost of ownership of the resulting system. This paper sets out a five-year total cost of ownership model comparing bespoke, purpose-built engineering against templated and platform-dependent alternatives, using engagement records maintained by Binary & Bus, Sys. between 2023 and 2026. We find that initial build cost is a poor predictor of total cost, that the dominant cost driver over a five-year horizon is the rate of forced, non-discretionary change, and that this rate differs structurally, not incidentally, between the two approaches.
1. Introduction
A prospective client comparing quotations for a piece of commercial software is, in practice, almost always comparing build cost: the invoice for the initial engagement. This is a reasonable first approximation and an unreasonable final one. Software is not purchased once; it is purchased once and then maintained, patched, migrated, and periodically rebuilt for as long as it remains in service. The cost of that ongoing obligation routinely exceeds the cost of the initial build, and its size is largely determined by decisions made during the build that are invisible on the initial invoice.
This paper is not a general argument against templated or platform-based systems, which are frequently the correct choice for time-constrained or genuinely disposable projects. It is an argument for pricing and specification discipline: that a client evaluating cost should evaluate total cost of ownership, and that engineers have an obligation to make the components of that cost legible rather than leaving them to be discovered later, at a point when switching cost has already made discovery expensive.
2. A Total Cost of Ownership Model
We decompose five-year total cost of ownership into four components: build cost (the initial engagement), forced maintenance cost (patching required to keep the system merely functioning, independent of any new feature work — dependency updates, platform deprecations, security patching), discretionary maintenance cost (feature work the client chooses to commission), and terminal cost (the cost of migrating off the system when it is eventually replaced, which is non-zero even for systems the client intends to retire rather than replace in place).
Of these four, forced maintenance cost is the component least visible at the point of purchase and the one this paper is primarily concerned with, because it is not a function of client choice. It is a function of how many external parties — platform vendors, dependency maintainers, framework authors — retain the ability to compel a change to the client's system on a timeline the client does not control.
3. Methodology
We reviewed engagement and support records for thirty-one client systems maintained by Binary & Bus, Sys. or its predecessor practice between January 2023 and June 2026, classifying each as bespoke (custom-built, minimal external dependency surface) or templated (built substantially on a third-party platform, theme system, or component framework with an external release cycle). For each system we recorded total support hours logged in year two through year five of service, separating hours attributable to forced changes — a dependency deprecation, a platform policy change, a breaking upstream update — from hours attributable to client-requested feature work. Systems retired or replaced before reaching a full year of service were excluded, as were systems for which support was handled by a party other than our own team, since we cannot verify third-party time records.
This is an internal operational dataset, not an independently audited one, and the classification of bespoke versus templated was made by the engineers who built each system, which introduces an obvious source of potential bias that we note rather than claim to have eliminated. We report it because it is the most direct evidence available to us, and because the pattern it shows is, in our experience, consistent with the wider industry discussion of maintenance burden in platform-dependent systems.
4. Results
Metric (years 2-5, per system, median) Bespoke Templated Ratio -------------------------------------------------------------------------- Forced maintenance hours / year 3.1 14.6 4.7x Discretionary feature hours / year 9.4 8.8 0.9x Unplanned emergency support incidents 0.4 2.1 5.3x Systems requiring a major version migration 1 7 - Median years to first breaking dependency - 2.3 -
Discretionary feature work, the cost component under direct client control, was comparable between the two groups, which suggests the two groups were not systematically different in ambition or scope. Forced maintenance hours were not comparable: templated systems in this sample required roughly four and a half times the forced maintenance effort of bespoke systems over the same period, driven overwhelmingly by upstream breaking changes the client had not requested and could not decline.
5. Discussion
The asymmetry here is structural rather than a matter of build quality on either side. A templated system inherits an ongoing obligation to track its platform's release cycle indefinitely; the client is a passenger on a maintenance schedule set by a vendor whose incentives are not the client's. A bespoke system has no equivalent external clock. It can still accumulate technical debt through neglect, but it is not compelled to change on a timetable it did not choose, and the seven major-version migrations recorded in the templated group were, without exception, initiated by the platform vendor rather than the client.
We do not read this as an argument that bespoke is always cheaper. Build cost for bespoke systems in this sample was, unsurprisingly, higher at the point of initial engagement, in three of thirty-one cases high enough that the five-year total cost of ownership still favoured the templated alternative. The correct comparison is total cost of ownership against project horizon, not build cost against build cost, and a client genuinely planning a two-year system lifespan may reasonably prefer the lower build cost of a templated approach despite its higher forced-maintenance rate, since less of that maintenance burden will be realised before retirement.
6. Conclusion
Build cost is the wrong figure to optimise in isolation. We recommend that any commercial engagement specify, alongside build cost, an explicit estimate of forced maintenance exposure and the dependency surface that generates it, so the decision between bespoke and templated architecture is made against total cost of ownership rather than against the number on the first invoice. This is the basis on which we scope and price our own engagements.