Most Engineers Don't Understand Cost

The engineer who chose the message bus, the serialization format, the deployment topology, and the replication strategy is responsible for more of the company's infrastructure budget than anyone in finance. That engineer has never seen the invoice. This is not a personal failure — the engineering discipline does not treat cost as a design constraint, and organizations pay for that omission every month.

Engineering culture draws a clear boundary between building and operating. Architecture reviews evaluate correctness, performance, failure modes, and extensibility. Code reviews evaluate logic and test coverage. Hiring interviews evaluate algorithmic thinking and system design. None of these processes include cost modeling as a first-class concern.

The omission reflects how the discipline was formed. Computer science curricula teach time complexity and space complexity — abstractions that describe resource consumption in relative terms, independent of what those resources cost. An engineer trained to minimize latency and maximize throughput has internalized design constraints. An engineer trained to evaluate the dollar cost of a design choice at the architecture level is rare, because almost no professional context teaches that skill.

The result is a division that feels natural. Engineers make technical decisions. Finance tracks the bill. Leadership mediates when the bill gets uncomfortable. The problem is that the technical decisions are the bill. Every choice about how data moves, where state lives, and how services communicate has a cost signature — and the person making that choice cannot read it.

The specific failure is not that engineers make expensive decisions. It is that cost enters the conversation only after the architecture is committed — when the monthly invoice surfaces, when a budget review flags a line item, when a CFO asks why infrastructure spend is growing faster than revenue. By that point, the cost is structural. It is embedded in message patterns, invocation chains, storage strategies, and replication topologies. Reducing it requires re-architecture, not optimization.

This is the contradiction worth naming: cost is treated as an operational outcome of technical decisions, when it is actually a design property of the architecture itself. An architecture does not incur cost because it is running. It incurs cost because of how it was designed to run. Operational cost can be managed with knobs — scaling policies, instance sizing, reserved capacity. Design cost can only be managed by changing the design, which means the window for cost-effective intervention closes the moment the architecture ships.

Organizations that wait for the invoice to evaluate cost are evaluating at the only point where changing it is expensive.

A mid-stage SaaS company — roughly 30 engineers — built its backend on an event-driven architecture using managed cloud services. Domain events published to a managed message bus, downstream services subscribing to relevant topics, Lambda functions handling processing, DynamoDB for persistence. The system was clean. Services were decoupled. Deployment was independent. The team had followed every principle the cloud provider's reference architectures recommended.

Eighteen months after launch, infrastructure cost was growing 40 percent faster than revenue. Finance flagged it. Engineering trimmed the obvious waste — oversized instances, unattached volumes, idle resources. The growth rate did not change.

The actual cost driver was the event topology itself. A single user action — updating a subscription plan — triggered a domain event that six services consumed. Each consumption invoked a Lambda function. Three of those functions published downstream events, triggering further invocations. One user action produced, on average, fourteen message deliveries and eleven function invocations. The company had 12,000 active accounts generating roughly forty meaningful actions per day. The math was arithmetic once someone did it. Nobody had done it, because the architecture had been designed for decoupling, not for economic efficiency.

The internal event chattiness — the volume of messages the architecture produced talking to itself — was the dominant cost driver. Not storage, not compute, not data transfer. The communication pattern between services scaled with system complexity, not customer count. Every new service subscribing to existing events increased the cost of every action across the platform, regardless of whether the company had gained a single customer.

No one on the engineering team had modeled this. The pricing page of every managed service was public. The event topology was documented. But connecting architecture diagrams to pricing models was a skill nobody possessed, because it had never been framed as an engineering skill.

Cost illiteracy in engineering is not an individual knowledge gap. It is a disciplinary one. The tools engineers use — architecture decision records, design documents, performance benchmarks — have no standard field for cost modeling. The reviews engineers participate in have no checkpoint for cost impact. The promotions engineers pursue reward technical sophistication, not economic reasoning.

Cost awareness, where it exists, is accidental. An engineer who managed their own cloud bill for a side project may have the reflex. But these are incidental experiences, not professional formation. The median engineer at a funded startup has never connected a design choice to a dollar figure — not because the information is unavailable, but because no process in their career has ever asked them to.

The organizational failure is the mirror image. Finance tracks infrastructure spend in aggregate. Engineering makes infrastructure decisions in detail. The two groups operate at different altitudes with different vocabularies, and no mechanism routinely translates between them. Cost reviews happen quarterly. Architecture decisions happen weekly. By the time the quarterly review identifies a trend, thirteen weeks of architectural choices have already shipped.

The terminal cost is not the infrastructure bill. Bills can be paid. The terminal cost is that the organization permanently operates with a gap between the people who understand the architecture and the people who understand its financial consequences — and no role, process, or incentive bridges it.

Engineers propose technically sound solutions without cost models. Finance proposes budget constraints without architectural context. Leadership arbitrates based on whichever argument is more legible in the moment. Over time, infrastructure decisions oscillate between over-engineering — technically optimal designs nobody priced — and reactive austerity — cost cuts that degrade system properties nobody modeled. Neither mode produces good outcomes. Both feel rational from inside their own frame.

The organization does not notice this oscillation as a pattern. Each over-investment looks like good engineering. Each cost cut looks like good management. The alternation is visible only from a vantage point that holds both the architecture and the pricing model simultaneously — a vantage point that, in most organizations, nobody occupies.

The most expensive technical decision is not the one that costs the most. It is the one nobody knew had a price.

Key Takeaways

• The people making the most consequential financial decisions in a software organization — which database, which messaging pattern, which deployment topology — are typically the people with the least financial context, because engineering culture does not treat cost as a design constraint.
• Cost enters most engineering organizations only after the architecture has shipped, at which point reducing it requires re-architecture rather than optimization — the most expensive possible intervention window.
• Event-driven and microservice architectures on managed cloud services can produce cost curves that scale with internal system complexity rather than with customer count, and this property is invisible without connecting architecture diagrams to pricing models — a skill most engineering teams do not possess.
• Cost illiteracy in engineering is a disciplinary gap, not an individual one: architecture decision records, design reviews, and promotion criteria have no standard mechanism for cost modeling.
• Organizations that separate technical decisions from financial consequences create a permanent oscillation between over-engineering and reactive austerity, because no role or process bridges the gap between the people who understand the architecture and the people who understand its cost.