Why build BBRmap

Teams without dedicated finance or FinOps support can be at a disadvantage when architecture choices come with very different cost structures. The technical tradeoffs may be relatively easy to understand, but estimating the full economic impact can require work that is difficult to do quickly or consistently. A reusable model can provide the structure—and some of the heavy lifting around capacity and engineering-effort estimates—without requiring each team to build the analysis from scratch.

Software teams regularly have to choose among different ways of implementing the same capability: competing managed services, different vendors or service configurations, or alternatives that shift more or less responsibility to the engineering team. That can include the familiar choice between building and operating something internally, using a managed cloud service, or adopting a more fully managed product. The technical differences are usually visible. The economic differences are harder to compare. Each option can shift costs among infrastructure, vendor charges, implementation work, and ongoing engineering effort. Those costs are measured differently and show up in different forms (provider bills, commercial terms, implementation work, and engineering capacity) and often require assumptions about how a workload will translate into resources and operating effort.

That gap became more apparent to me during my years at Amazon and AWS. I spent more than 17 years at Amazon, including eight years at AWS, where as a Finance Director I worked with infrastructure and engineering teams on product economics, capacity, usage-based business models, and operating plans. One question kept coming back: how does a development team that does not have finance support with the time and experience to work through these economics make a good comparison? I also saw how easily comparisons could become incomplete. Customers evaluating cloud and on-premises alternatives would sometimes compare costs that looked similar but did not represent equivalent capabilities or responsibilities. A cloud bill might be compared with server and storage costs while some of the work required to operate the infrastructure internally was treated differently or left out. A useful comparison puts the alternatives on an equivalent economic basis and makes the assumptions visible.

That is the problem BBRmap is intended to help with. (The “BBR” in the name comes from Build, Buy, Rent.) You describe the workload and the operating requirements. The model translates those requirements into infrastructure needs, vendor usage, setup effort, and ongoing engineering work associated with each implementation option. It then applies published rates or rates you provide and compares the alternatives. The result is a first analysis that is faster to assemble and useful as a basis for technical and financial judgment.

This matters more now than it did a few years ago. Infrastructure spending has become more consequential as AI and other compute-intensive workloads grow. At the same time, more technology businesses are considering consumption- and usage-based pricing, which makes understanding the relationship between workload, architecture, cost, and unit economics increasingly important. The same analysis also matters when negotiating with vendors: it is easier to evaluate a commercial proposal when you understand what the other options would cost and which assumptions drive the comparison. BBRmap is an attempt to make that kind of analysis reusable rather than something each team has to assemble for itself. It will not know everything about a particular company's systems, engineering practices, contracts, or constraints. Those details matter, so the model makes its assumptions visible and allows its estimates to be replaced with better company-specific information where available.