The False Economy of Cheap Engineering

Cheap engineering usually looks sensible in a spreadsheet.

The salary bands are lighter. The delivery partner promises a lower blended rate. A thin internal team looks efficient next to a larger one. Leadership feels disciplined because costs are visible, immediate, and easy to compare.

Then the system starts charging interest.

Roadmaps slip because too few people understand the platform deeply enough to make hard calls early. Rework increases because requirements are being translated by people who can implement tasks but cannot challenge bad assumptions. Production instability grows because quality work is treated as optional overhead until an outage makes it urgent again. The business ends up paying agencies, consultancies, contractors, emergency specialists, or expensive vendor expansions to recover time it thought it had saved.

That is the false economy.

This is not only a salary argument, although salary is part of it. It is an operating model argument. Companies get into trouble when they treat engineering capability as a cost centre to be minimised rather than a strategic capability that protects product quality, delivery speed, resilience, and commercial freedom.

For low‑risk, low‑change, non‑differentiating work, "good enough" engineering can be perfectly rational. Not every internal tool needs principal‑level architecture. Not every brochure site needs a platform team. But many businesses now depend on digital platforms for revenue, customer experience, fulfilment, marketing operations, pricing, analytics, content operations, and regulatory change. On those systems, cheap engineering is rarely cheap at system level.

The Spreadsheet is Not the System

Most underinvestment decisions start from a narrow question: how do we reduce engineering cost this quarter?

That question sounds commercial. In practice, it is often incomplete.

McKinsey's work on developer velocity is useful here because it makes the point that software performance is not mainly a story about how many developers you employ or how quickly they type. The strongest outcomes correlate with tools, product management, culture, and talent management, not simply with cost compression.

Google's research on developer productivity lands in a similar place. It found that code quality, technical debt, tools, and infrastructure, team communication, goals, and priorities, and organisational change all affect productivity. In other words, weak engineering environments create drag that payroll‑only models do not capture.

The SPACE framework makes the same warning from a measurement perspective. Developer productivity is not one thing, and it cannot be reduced to one output number without losing the parts that matter most: satisfaction, performance, collaboration, efficiency, and flow.

That matters because companies often "save" money by looking only at visible headcount cost whilst ignoring system cost:

• rework created by weak decisions
• slower delivery caused by unclear ownership
• higher incident and recovery cost
• more management overhead to compensate for thin technical judgement
• supplier dependency created by capability gaps
• future migration cost caused by poor architecture
• weaker hiring and mentoring pipelines

The spreadsheet sees a cheaper team. The system experiences a slower, riskier, more dependent business.

Cheap Delivery Often Creates Expensive Ownership

Delivery cost and ownership cost are not the same thing.

A build can be cheap to produce and expensive to own. Anyone who has inherited a rushed platform knows the pattern. The first milestone is presented as a win because something shipped. Six months later the organisation discovers that the content model is awkward, the analytics are unreliable, release confidence is low, the integration points are brittle, and every "small" change requires three meetings and a specialist.

Martin Fowler's Technical Debt Quadrant remains useful because it distinguishes between prudent short‑term compromises and reckless ones. Cheap engineering frequently lives in the reckless quadrants, not because individual engineers are careless, but because the organisation knowingly removes review, design, testing, and platform discipline whilst pretending the consequences will stay small.

This becomes painfully obvious in platform work. If a company underinvests during a replatform or CMS migration, the cost does not disappear. It reappears later as post‑launch drag, awkward content operations, duplicated logic, weak observability, or high change failure rates. That is why the operational preparation described in How to De‑Risk a CMS Migration Before the Real Migration Starts matters so much. Cheap migrations often fail because they are priced as implementation exercises rather than ownership transfers.

The same thing applies to broader architecture work. Building for Change: Architecture Lessons from Multi‑Phase Replatforms is really about preserving future changeability, not decorating a system diagram. A platform that is cheap to launch but expensive to evolve has not actually reduced cost. It has deferred it.

Payroll Savings Often Come Back as Supplier Spend

This is one of the most common and least honest patterns in digital organisations.

Leadership freezes permanent engineering hires, trims salary bands, or resists senior internal appointments in the name of discipline. A year later, the same organisation is paying day rates to contractors, discovery fees to agencies, rescue fees to consultancies, and premium licence costs to vendors because the internal team cannot move fast enough or confidently enough on its own.

This is not hypothetical. The Government Digital Service guidance on choosing technology and managing lock‑in repeatedly emphasises total cost of ownership, the ability to change direction later, and the danger of losing too much control to providers.

Those documents are dry for a reason. The problem is structurally common. Short‑term convenience is easy to buy. Reversing dependency later is not.

Cloud concentration sharpens the risk. Ofcom's cloud services market study identified switching barriers and interoperability concerns in a market where a small number of providers dominate essential infrastructure. The CMA's later market investigation concluded that competition concerns in UK cloud infrastructure services were likely to be leading to higher costs, less choice, less innovation, and lower quality for customers.

If you underinvest in internal engineering capability whilst becoming more dependent on concentrated cloud, platform, analytics, or AI suppliers, the apparent saving becomes even less durable. You are not only buying cheap delivery. You are narrowing your future negotiating position.

Good Enough is Contextual, Not Universal

There is an annoying tendency in engineering debates to talk as if every system deserves the same investment level. That is obviously wrong.

Some work is genuinely low‑risk. If a small, self‑contained internal admin tool changes twice a year, you may not need the same architecture depth or operational rigour you would want for payments, content operations, identity, or high‑traffic customer journeys. Treating every small project like a mission‑critical platform is wasteful.

But treating every platform like a disposable project is worse.

The right question is not "can we get this done more cheaply?" It is "what is the cost of being wrong here?"

If the system affects:

• revenue collection
• customer trust
• operational continuity
• regulatory or legal exposure
• search visibility
• brand consistency across markets
• analytics quality
• the ability to change business rules safely

then engineering quality is performing a risk‑management function, not merely a production function.

The 2024 DORA report reinforces this point by highlighting stable priorities, user‑centricity, and strong leadership as conditions of better organisational performance. Cheap engineering cultures typically produce the opposite conditions. Priorities churn because estimates were weak, user outcomes get displaced by local cost targets, and delivery teams lose the authority or time required to improve the system properly.

When people say "we just need something good enough", what they often mean is "we have not decided explicitly which risks we are willing to own". That is not pragmatism. It is avoidance wearing commercial language.

Strong Engineering Reduces Cost by Preventing Bad Decisions Earlier

This is the part finance models usually miss.

Strong engineering capability does not only help when code is being written. Its value appears earlier.

Experienced engineers reduce total cost by:

• spotting dangerous scope assumptions before delivery starts
• pushing back on requirements that create lasting complexity
• choosing platform boundaries that reduce future duplication
• designing data flows that do not collapse under reporting or integration needs
• preserving migration options instead of painting the business into one supplier corner
• setting testing, observability, and release standards that prevent repeated incident cost

That is why senior capability has such asymmetric value. The best people do not justify themselves only by producing more tickets. They prevent expensive mistakes from hardening into operating reality.

This is also where cheap hiring decisions become visibly incoherent. Businesses will happily save money on a senior engineer, lead, or architect, then spend far more later untangling the consequences of weaker judgement. I wrote about one part of that role confusion before in Differences in Lead and Senior Front‑End Development Roles. When companies collapse several levels of responsibility into a cheaper role, they are not simplifying. They are buying less judgement than the job actually requires.

Cheap Engineering Creates Organisational Drag, Not Just Technical Debt

Technical debt gets discussed more because it sounds concrete. But the broader damage is organisational.

Underpowered engineering teams tend to create:

• slower product decisions because technical feasibility is unclear
• more cross‑team conflict because nobody trusts estimates
• more dependence on a few heroic individuals
• higher onboarding cost because the system is harder to explain
• weaker mentorship because senior time is consumed by firefighting
• a thinner future leadership bench
• weaker internal credibility for engineering as a strategic function

That last one matters. Once engineering is seen mainly as implementers of pre‑made decisions, the business stops expecting high‑value technical judgement. It then over‑relies on agencies, consultancies, vendors, or a single charismatic external architect to provide the thinking it has chosen not to retain internally.

This is one reason transformation programmes stall after launch. The modern platform exists, but the internal decision‑making muscle required to evolve it never really formed.

The Signs You are Underinvesting in Engineering Capability

Most companies do not announce this openly. The pattern shows up in behaviour.

You are probably underinvesting if several of the following are true:

• Senior roles are defined by broad accountability but priced like execution roles.
• Permanent headcount is tightly constrained whilst contractor and consultancy spend keeps rising.
• Critical platform knowledge sits mostly with suppliers rather than internal staff.
• Engineering managers spend most of their time translating avoidable ambiguity rather than improving the system of work.
• Architecture decisions are repeatedly revisited because the original choices were weak or thinly owned.
• Teams cut testing, documentation, accessibility, observability, or performance work first whenever deadlines tighten.
• The organisation can launch redesigned platforms but struggles to operate or extend them confidently.
• Leadership talks about efficiency mainly in terms of lower salary cost, not lower total cost of change.
• Product teams routinely discover late that "small" requests are difficult because the underlying system is too brittle.
• Hiring good engineers is hard because the roles feel under‑scoped, underpaid, underpowered, or all three.

These are not cultural quirks. They are financial signals.

Cheap Engineering Also Weakens the Next Generation of Capability

Another hidden cost appears in the hiring and mentoring pipeline.

Underpowered teams usually protect the most urgent work first, which means they protect shipping and firefighting. The first things to get thinner are apprenticeship, documentation, architectural explanation, and patient review. That creates a compounding effect. The business is not only short on senior judgement now. It is also making it harder to produce more of that judgement internally later.

That matters because strong engineering organisations do not rely only on buying finished expertise from the market. They also turn solid engineers into future leads, staff engineers, managers, and system owners by exposing them to good reviews, visible trade‑offs, and cleaner platform thinking. When the team is too cheap, too thin, or too overloaded to do that properly, the future leadership bench narrows as well.

This is why cheap teams often end up saying they cannot afford to invest in junior growth, documentation, or wider mentoring whilst simultaneously becoming more dependent on buying finished expertise later at a higher cost. The saving is immediate. The replacement cost arrives more slowly, which is exactly why it gets misread. It also means supplier dependence grows at the same moment internal succession gets weaker, which is about as poor a bargain as a digital business can make. Once that pattern is established, the business starts buying back its own neglected capability at premium rates.

A Practical Framework for Spending Properly on Engineering

If the goal is commercial discipline rather than engineering maximalism, a more useful framework is:

1. Separate Commodity Work from Strategic Platform Work

Do not fund everything equally. But do not pretend your core customer, revenue, and operating systems are commodity either.

2. Price for Ownership, Not Only Implementation

Ask what it will cost to run, change, migrate, monitor, and govern the thing for the next three years, not just what it costs to launch.

3. Treat Supplier Convenience as a Trade, Not a Free Gain

If a platform, consultancy, or agency accelerates delivery, ask what internal capability must still exist to challenge, extend, or replace it later.

4. Invest in the People Who Reduce Future Drag

Senior engineers, staff engineers, strong leads, platform specialists, and excellent engineering managers frequently save more money upstream than they cost downstream.

5. Measure Total Cost of Change

Include rework, incident recovery, external spend, failed launches, defect correction, and time‑to‑understand when judging whether engineering is "expensive".

This matters especially in budget cycles where payroll and supplier lines are reviewed separately. A team can look cheaper internally whilst its missing capability reappears as agency retainers, consultancy rescue work, platform overruns, and a slower cost of change elsewhere in the ledger. Finance discipline gets sharper, not weaker, when those effects are considered together rather than treated as unrelated categories.

6. Make Risk Explicit

If quality, resilience, or future changeability is being traded away for speed or cost, say so plainly and decide whether the business genuinely accepts that risk.

Conclusion

Cheap engineering is not a myth because expensive engineers are automatically better, or because every software problem deserves a lavish team.

It is a false economy because many businesses now depend on digital systems whose real cost is dominated by ownership, changeability, resilience, and judgement quality rather than by initial implementation effort alone.

The companies that get this wrong usually do not think they are sabotaging engineering. They think they are being commercially disciplined. Then they pay the difference through rework, platform fragility, supplier dependence, consultancy rescue work, slower product momentum, and transformation programmes that modernise the stack without strengthening the organisation behind it.

That is the real lesson. Engineering quality is not just a production input. It is one of the ways a business manages risk, preserves leverage, and avoids buying future problems at a short‑term discount.