"Are we spending the right amount on technology?" is one of the most common questions I get from CEOs. It's also one of the hardest to answer, because "the right amount" depends on whether technology is your product, your enabler, or your overhead.
Here are the benchmarks I use, followed by the more important conversation about how to think about the question.
The Benchmarks
SaaS companies (technology IS the product): 25-40% of revenue goes to engineering and product development. This includes salaries, infrastructure, tools, and contractors. Early-stage SaaS companies at the high end (40%+) because they're investing ahead of revenue. Mature SaaS companies at the low end (20-25%) because revenue has caught up with the investment.
Technology-enabled businesses (technology ENABLES the product): 10-20% of revenue. Think e-commerce, fintech, healthtech — the product is a service or marketplace, and technology is what makes it work. The technology budget is significant but not the dominant cost center.
Traditional businesses (technology is INFRASTRUCTURE): 3-7% of revenue. Manufacturing, retail, professional services — technology supports operations but isn't the product. At this level, technology spending is comparable to facilities or fleet management.
These benchmarks are useful for sanity checks but dangerous for decision-making. A SaaS company spending 35% of revenue on engineering might be investing wisely in growth or might be burning cash on an over-staffed team building features nobody uses. The percentage alone doesn't tell you.
The Three Ratios That Matter More
Engineering cost per feature shipped. Total engineering cost (salaries, infrastructure, tools) divided by the number of meaningful features delivered in a quarter. This ratio reveals engineering efficiency. If it's climbing quarter over quarter — each feature costs more — you have a productivity problem (growing tech debt, poor team structure, wrong priorities). If it's declining, your engineering investment is compounding.
Infrastructure cost per customer. Your cloud and infrastructure spend divided by active customers. This ratio reveals whether your architecture scales efficiently. For a SaaS product, this should decline as you grow (economies of scale). If it's flat or rising, you have an architecture problem — you're scaling linearly when you should be scaling sub-linearly.
Technology spend as revenue multiplier. The total revenue enabled by technology divided by the total technology spend. If you spend $1M on technology and it supports $10M in revenue, your multiplier is 10x. Track this over time. A rising multiplier means your technology investment is becoming more efficient at generating revenue. A falling multiplier means each technology dollar is producing less business value.
Where Money Gets Wasted
In my experience across 20+ engagements, the top sources of technology budget waste are:
Over-staffed teams. More engineers does not equal more output. Beyond a certain team size relative to the product complexity, adding engineers creates coordination overhead that actually reduces per-person productivity. The optimal team size is almost always smaller than what companies have.
Underutilized cloud resources. As I've written about elsewhere, 30-40% of cloud spend is typically waste — oversized instances, forgotten storage, development environments running 24/7. This is the easiest money to recover.
Building what you should buy. Engineers building custom analytics dashboards, custom authentication systems, custom deployment pipelines when mature SaaS products exist for each. Every custom-built commodity capability is engineering time not spent on your core product.
Maintaining abandoned features. Features that were built, launched, and forgotten — but still consume infrastructure resources, create maintenance burden, and add complexity to every change. Regular feature audits (which features have active users?) reveal surprising candidates for retirement.
The Pod Model Economics
For companies using blended onshore/offshore teams, I use a pod model for budgeting: a pod of 2 dedicated developers plus 1 rotating specialist position can be maintained for roughly $20K/month with proper offshore talent management. This is the atomic unit of delivery capacity.
The question then becomes: how many pods do you need? And is each pod producing value that exceeds its cost? If a pod costs $20K/month and its output generates or protects $60K/month in revenue, the math works. If the pod's output can't be connected to revenue impact, either the pod is working on the wrong things or you need better measurement.
Budget Allocation: The 50/30/20 Rule
Within your total technology budget, a healthy allocation looks roughly like: 50% on new features and capabilities (the things that grow revenue), 30% on infrastructure, reliability, and technical foundation (the things that protect revenue), and 20% on maintenance and bug fixes (the things that maintain revenue).
If your maintenance and bug fix allocation is above 30%, your technical debt is consuming your capacity to grow. If your new feature allocation is above 70%, you're under-investing in the foundation that makes future features possible. Neither extreme is sustainable.
Related: Tech Debt Translation: Making Your CFO Care | Making Your Technology Roadmap Visible | Cloud Cost Optimization