The CTO's Cost of Goods Sold

Understanding COGS transformed how I approach sprint planning and roadmap discussions. Instead of treating all work equally, we now evaluate the financial impact of our choices.

I'm standing in front of our C-Suite, watching their faces shift from curiosity to concern as I explain why our latest feature took three sprints instead of one. "We hit some technical debt," I say, the words tasting like cardboard in my mouth. "Had to fix a few critical bugs along the way."

The CFO leans forward. "So what was the actual cost of delivering that feature?"

I freeze. I know exactly how many story points we burned. I can recite our velocity metrics backwards. But the actual cost? The real dollars and cents of what it took to ship that feature versus what we spent just keeping the lights on?

I have no idea.

"I'll get back to you on that," I manage, feeling like I've just failed a pop quiz in my own subject matter.

That night, I dive deep into our Jira tickets, our time tracking, our commit history. What I discover makes my stomach drop. We're spending 47% of our engineering time on bug fixes. Nearly half our "development" isn't developing anything new. It's paying interest on technical debt we accumulated months or even years ago.

The P&L Line I Never Understood

Every month, I sit in our leadership meeting and watch our CFO walk through the P&L. Revenue at the top, then Cost of Goods Sold (COGS), leaving us with Gross Profit. Below that, Operating Expenses including our R&D spend—which is basically my entire engineering budget.

I always thought COGS was for "real" product companies. Companies that manufacture things. For our SaaS business, I assumed it was just our AWS bills and maybe customer support costs.

I was dead wrong.

COGS represents the direct costs of delivering your product to customers. And in a SaaS business, a huge portion of that cost is hidden in what I've been calling "development work."

According to KeyBanc's 2023 SaaS Survey of over 600 private SaaS companies, the median COGS for SaaS businesses is 27% of revenue.¹ But when I looked at our financials, ours was only showing 18%. Were we that much more efficient than everyone else?

No. We were miscategorizing millions of dollars in costs.

The Bug Fix That Opened My Eyes

At one company I worked at, we had a production incident that I remember to this day. A memory leak in our payment processing service was causing intermittent failures. Five engineers spent two weeks tracking it down and fixing it. The root cause? A poorly implemented feature from 18 months earlier.

During our post-mortem, I calculated the cost. Five engineers for two weeks at an average fully loaded cost of $200,000 per year. That's roughly $8,000 in salary costs. Add in the opportunity cost of delayed features, and we're looking at $20,000 to fix one bug.

But where did that $20,000 show up in our financials? In R&D expenses, right alongside the cost of building our revolutionary new analytics dashboard.

That's when it all came together for me. We were mixing the cost of keeping our product running with the cost of building new capabilities. We were hiding our true COGS in our innovation budget.

What Actually Belongs in COGS

I scheduled time with our CFO to understand COGS better. Together, we went through our engineering activities and started categorizing them properly.

True COGS activities in engineering include:

• Bug fixes in production systems

• Performance optimization to maintain SLAs

• Security patches and updates

• Scaling existing infrastructure to handle growth

• On-call engineering time

• Maintenance of existing features

True R&D activities include:

• New feature development

• Prototyping and experimentation

• Platform improvements that enable new capabilities

• Technical debt reduction that enables future velocity

The distinction seems obvious now, but we'd been treating all engineering work as R&D.

The Numbers That Made Me Sweat

When we recategorized our last quarter's engineering work, the results were sobering.

Out of our $2.5 million quarterly engineering spend:

• $1.175 million was actually COGS (47%)

• Only $1.325 million was true R&D (53%)

This shifted our company COGS from 18% of revenue to 29% of revenue. We went from industry-leading efficiency to slightly below average. Our gross margin dropped from 82% to 71%.

The board wasn't happy about the revised numbers, but they appreciated finally understanding where our engineering resources were actually going.

The Compound Effect of Technical Debt

Research from the Consortium for Information & Software Quality shows that poor software quality cost the US economy $2.08 trillion in 2020.² Trillion with a T.

In my own organization, I started tracking the lifecycle of bugs. What I found terrified me. Capers Jones's research in "The Economics of Software Quality" shows that bug fix costs increase exponentially over time.³ A bug that would cost $25 to prevent during design costs $100 during development, $500 during testing, and $1,500+ after release.

We were consistently paying the $1,500 premium.

Even worse, each bug we shipped increased our ongoing COGS. That memory leak I mentioned? It wasn't a one-time $20,000 cost. Before we fixed it, it was generating 10-15 support tickets per week, each taking an hour to resolve. That's $1,000 per week in support costs that should have been counted as COGS, not customer success expenses.

The Shift in How We Plan

Understanding COGS transformed how I approach sprint planning and roadmap discussions. Instead of treating all work equally, we now evaluate the financial impact of our choices.

When product comes to me with a new feature request, I don't just estimate the development cost. I estimate the ongoing COGS impact. Will this feature increase our bug surface area? Will it require ongoing maintenance? Will it add complexity that slows down future development?

Similarly, when advocating for technical debt reduction, I can now speak the language of the business. "This refactoring will cost $50,000 in engineering time, but it will reduce our quarterly COGS by $30,000 by eliminating the bugs in this module." That's a 7-month payback period—an easy sell to any board.

What This Means for Your Organization

If you're a CTO who can't immediately answer what percentage of your engineering work is COGS versus R&D, you're not alone. In conversations with other CTOs, I've found that less than 20% actively track this distinction.

But you need to start. Open your ticket tracking system and look at your last quarter's work. Categorize each ticket as either maintaining existing functionality (COGS) or building new capabilities (R&D).

The Accelerate State of DevOps Report 2023 found that elite performers spend only 20% of their time on unplanned work and rework, while low performers spend over 40%. But most organizations don't even measure this split.⁴

The Success That Followed

Six months after we started properly categorizing engineering work as COGS versus R&D, our entire approach to product development transformed.

We reduced our engineering COGS from 47% to 31% of engineering spend. That's $400,000 per quarter that shifted from maintenance to innovation. Our true feature velocity increased by 40% without hiring a single additional engineer.

More importantly, we can now have intelligent conversations about trade-offs. When someone proposes a quick-and-dirty solution to meet a deadline, we can calculate the long-term COGS impact. When advocating for code quality improvements, we can demonstrate ROI in reduced future COGS.

Our exec meetings transformed too. Instead of defending why features take so long, I can show them exactly where our engineering dollars go. I can demonstrate why investing in code quality isn't "gold plating", it's reducing our operating expenses and improving our gross margin.

Your COGS Reality Check

Pull up your company's latest P&L statement. Look at the COGS line. Now ask yourself—how much of my engineering work should actually be in that number?

If you're like most CTOs, you've been treating all engineering work as R&D. But the truth is, a significant portion of what your team does is keeping the lights on, fixing bugs, and maintaining existing functionality. That's not R&D. That's COGS.

Start tracking this distinction today. Not because it makes your numbers look better, it probably won't. But because you can't manage what you don't measure. And until you understand your true COGS, you can't make informed decisions about where to invest your engineering resources.

Every bug you ship today becomes tomorrow's COGS. Every shortcut you take compounds into future maintenance costs. But when you start tracking and managing these costs properly, you transform from a head of engineering into a true business leader who understands not just the technology, but the economics of delivering it.

Your CFO knows their COGS. Your COO knows their COGS. It's time you knew yours too.

1. https://info.sapphireventures.com/2023-keybanc-capital-markets-and-sapphire-ventures-saas-survey#:~:text=technology%20and%20culture.-,2023%20KeyBanc%20Capital%20Markets%20&%20Sapphire%20Ventures%20SaaS%20Survey,show%20strength%20despite%20macroeconomic%20headwinds

2. https://undo.io/about-us/undo/news/cost-poor-software-quality-us-2020-report/#:~:text=The%20Consortium%20for%20Information%20&%20Software,get%20changes%20into%20the%20pipeline.

3. https://ptgmedia.pearsoncmg.com/images/9780132582209/samplepages/0132582201.pdf

4. https://dora.dev/research/2023/dora-report/#:~:text=The%20report%20emphasizes%20continuous%20improvement,on%20those%20identifying%20as%20underrepresented.