More engineers won’t fix it. Good design can cut your software bill in half
When software gets slow and expensive, the usual answer is to hire more engineers. Often that makes it worse. The data says a large share of engineering money goes to two things: building what nobody uses, and paying for yesterday’s shortcuts. Good design attacks both.
Waste #1: building what nobody uses
Pendo looked at real usage across hundreds of software products and found that 80% of features are rarely or never used. Each of those features was designed, built, tested, and is still maintained today.
Good product design decides what not to build. A one-week prototype tested with five customers is much cheaper than a feature that takes three months to build.
Waste #2: paying interest on shortcuts
In Stripe’s survey of developers, 17.3 hours of a 41.1-hour week, about 42%, went to technical debt and bad code. That is time spent working around old decisions instead of building new value.
McKinsey heard the same from CIOs: 10 to 20% of the budget for new products is diverted to fixing tech debt.
Waste #3: architecture that is more complex than the problem
Amazon’s Prime Video team ran one monitoring service as many small distributed pieces. When they redesigned it as a single, simpler service, its infrastructure cost dropped by more than 90%, and it scaled better.
That is one service, not all of Prime Video. But the lesson travels: complexity has a monthly bill.
Does this add up to half?
Not for every company, and anyone promising an exact figure is guessing. These studies measure different things, so their numbers can’t simply be added up. But they point the same way: around four in ten engineering hours go to old shortcuts, most features see little use, and infrastructure is often built for problems the business doesn’t have. In many companies, close to half of engineering spend does not move the business. That is the money good design wins back.
What good design looks like in practice
- Decide before you build. A short written design and a review with a senior engineer, before the first line of code.
- Prototype first. Test the idea with real users for days, not months.
- Choose boring, simple technology. One well-structured application usually beats ten services for a growing company.
- Pay down debt on purpose. Set aside time every cycle, instead of waiting for a crisis.
- Measure use. Remove features nobody uses. Less code means less to maintain.
How TechNova can help
We start with the design, not with more people.
- Tech audit: in one to two weeks we show where your engineering time and cloud budget really go, with a prioritised list of fixes.
- Simplify the architecture so changes get faster and the monthly bill gets smaller.
- A plan to pay down technical debt without stopping new features.
Hiring more engineers multiplies whatever your design already is. Fix the design first: build less, keep it simple, and stop paying interest on old shortcuts.
Sources
- Pendo, The 2019 Feature Adoption Report: 80% of features rarely or never used.
- Stripe and Harris Poll, The Developer Coefficient (2018): 13.5 hours a week on technical debt and 3.8 hours on bad code, out of 41.1.
- McKinsey & Company, Tech debt: Reclaiming tech equity (2020): 10–20% of new-product technology budgets diverted to tech debt.
- Prime Video Tech blog, “Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%” (March 2023), as covered by DevClass.
FAQ
Isn’t hiring more engineers the fastest way to go faster?
Only if the design is sound. Adding people to a tangled system adds coordination work and more code to maintain.
What is technical debt, in business terms?
Shortcuts taken earlier that make every later change slower and riskier. Like financial debt, you keep paying interest until you pay it down.
How do I know if my product has a design problem?
Warning signs: simple changes take weeks, releases often break other things, and the cloud bill grows faster than your users. A tech audit tells you where.
Read next: About a quarter of your cloud bill is probably waste. Here’s where to look