- Why Change?
Discover the power of cloud cost intelligence.
Give engineering a cloud cost coach.
Learn more about CloudZero's pricing.
Request a demo to see CloudZero in action.
Learn more about CloudZero and who we are.
Got questions? We have answers.
Speak with our Cloud Cost Analysts and get the answers you need.Get in touch
How SeatGeek Decoded Its AWS Bill and Measured Cost Per CustomerRead customer story
Enable engineering to make cost-aware development decisions.
Give finance the context they need to make informed decisions.
Decentralize cloud cost and mature your FinOps program.
Discover the best cloud cost optimization content in the industry.
Gauge the health and maturity level of your cost management and optimization efforts.
Browse helpful webinars, ebooks, and other useful resources.
Learn how we’ve helped happy customers like SeatGeek, Drift, Remitly, and more.
Guide: How To Overcome Tagging And Accelerate Cloud Cost AllocationSee guide
Learn what you should include as SaaS COGS, how to calculate it, and four tips for discussing costs with your leadership team.
When you lead engineering for a company running on AWS, every technical decision you make can have an impact on your profit margin. So it’s no surprise that many of us are increasingly responsible for answering questions and reporting about costs to our executive teams — and in some cases, the board.
However, it can be challenging to translate complex engineering concepts to business leaders. If you frame things well, though, you can have more productive conversations that lead to greater alignment between engineering and the rest of the business.
In my experience, positive discussions about cost tradeoffs can help your team make better decisions about everything from roadmap prioritization to pricing models.
With that in mind, I’d like to share some of my recommendations for discussing cost with your leadership team — and hope it might help you have stronger cost conversations.
Table Of Contents
Cost of goods sold (COGS) in a software-as-a-service (SaaS) company refers to the direct costs you incur in building and running subscription-based software services. COGS are also referred to as cost of sales.
These services are software-enabled and distributed over the internet, which makes them unique. COGS for SaaS differs from traditional software companies that create a physical software copy and distribute it.
Many SaaS companies over-report their COGS because they are unsure what they should include in their cost of goods sold reports. Some equate operating expenses (OPEX) with cost of goods sold (COGS), which is inaccurate and could have negative consequences, such as reducing your share price.
COGS reflect how much you spend on building and supporting the software services that your customers purchase. Meanwhile, operating costs represent the costs incurred to run and support your entire business, not just the software-enabled services you provide.
COGS also differ from cost of revenue in that the latter applies when you sell a physical product. Cost of revenue also includes indirect expenses such as the commissions you'd pay your sales staff and the shipping costs of raw materials.
So, what costs should you consider COGS in a SaaS?
A SaaS company's cost of goods sold includes:
COGS does not include general administration, R&D amortization, product development, internal operations, upselling, rent, commissions, or data center maintenance. These are operational costs.
There are also no rules as to what to include in a SaaS P&L as COGS. As a result, SaaS finance teams struggle to figure out what to account for as COGS, let alone forecast and provision technology costs with accuracy.
Additionally, engineering leaders cannot explain to finance (and to the C-Suite) how engineering activities impact the company’s overall profitability.
We see this and more SaaS cost visibility challenges more often now. They are reasons more SaaS companies are reporting weaker gross margins, and ultimately, insufficient profits to keep them afloat.
If you've migrated to the cloud recently, for example, you're seeing unique infrastructure, metrics, and billing details. Your financial team may be more blindsided now than ever.
As an example, the costs of testing software features in production or scaling your customer's resources can increase COGS. Cloud costs are also highly variable, changing as you onboard more customers, commission additional features, and generate more traffic through viral marketing activities.
When you cannot trace costs back to a specific feature, customer, or project in your app, you may never know how much you spend on each.
As a result, you may struggle to:
The COGS of each SaaS business will differ based on its unique business model, industry, compliance laws, and other factors. What do you do when your costs differ from the "standard" bunch?
As a start, you need to see all your costs in the context of your business. Different companies have differing formulas for calculating COGS manually, such as:
Notice the difference between those SaaS COGS calculation methods and the following formula for calculating a conventional business’s COGS:
COGS = Inventory At The Start Of A Period + Purchases Made Over That Period - Ending Inventory
It is highly unlikely that you will keep inventory as a SaaS company, which is why you will rarely use this last formula.
You are more likely to have COGS similar to the ones in this table:
Customer support for the app
Cost of subscriptions
Total cost of goods sold
Company X’s cost of goods sold equals $51,100 for the specific period these costs accrued.
Sadly, most cloud providers lump all costs into one billing statement. As a result, it is very difficult to determine what cost you what, when, where, and why — reducing your cloud cost visibility.
When you don't have a clear understanding of where your cloud spend is going, you might not know where you can optimize — such as cutting your AWS bill by reducing unused resources, or using more resources for the same fees.
The good news is that you can use a cloud cost intelligence platform like CloudZero to understand your spend and align costs to feature, products, customers, teams, and more.
CloudZero combines COGS with unit economics, enabling you to visualize and map the true cost of supporting each segment of your business. The following are examples of unit costs:
Understanding COGS is important in calculating SaaS gross margins, which typically range between 60-90%. So SaaS COGS should be between 10-40%. Many SaaS businesses end up over-reporting their SaaS cost of goods sold to avoid misrepresenting costs to investors.
COGS can also help you calculate the gross profit of your SaaS business. From there, you can estimate the surplus revenue you have to cover your operating expenses, like rent, sales, and marketing.
You can also use the data to conduct a SaaS COGS benchmark. Comparing key SaaS business metrics and practices to industry peers and standards may allow you to determine how to improve gross margins, and ultimately net profit.
Investors also look out for COGS in SaaS P&L to gauge profitability, hence the attractiveness of a SaaS company.
Higher gross margins lead to a higher valuation, which can boost the amount you can get during a funding round, as you can see here.
Net profits often fall when gross margins are weak. Low-profit margins make it harder to fund R&D and innovation. Furthermore, you may not have enough left over to fund marketing and sales campaigns that can help you attract more and higher-value clients.
Many companies in the SaaS sector assume gross margins will increase as they scale. That's not necessarily true.
It might be tough to optimize your SaaS COGS as a larger company if you have trouble understanding and allocating them now. It could mean being unable to report higher gross margins that would increase your valuation, attract investors, and make it easier to service operating costs.
Now here's the thing. Engineers strive to improve existing technical features, minimize downtime, and integrate additional components. Finance, SaaS executives, investors, and the board want to see how an input X will lead to more recurring sales (renewed subscriptions) and increased profits.
Engineers may not always be aware of the financial aspects of the equation. But they know how operations work at the technical level, including how to scale and maintain service availability to improve customer experiences and, hence, retention.
So, what steps should the engineering team take to align with C-suite (and finance)? In what ways do you encourage SaaS executives to understand SaaS COGS so they can provide the resources you need to innovate?
Engineers are used to communicating technical metrics, whether it's explaining why uptime has improved or advocating for a fresh approach to a roadmap initiative. Instead, break down engineering costs in a way that helps your executive team make sense of your costs.
For example, an executive team or board of directors does not care how much Amazon S3 costs or how architectural choices from years ago resulted in the current cost structure.
They want to know things like:
Then talk about the potential roadblocks that might come up.
In most cases, giving your executive team a list of projects to improve COGS or margins won't be enough since they won't have the context they need to support your decision — and know whether you're recommending the right strategy.
As an engineering leader, it’s your job to remove that uncertainty by providing important context about trade-offs and risks.
We like to group projects with easy-to-understand groupings like “no-brainer” and “moonshot” projects. If a project takes several staff days and saves 10% on your bill, it’s a no-brainer — and your executives will almost certainly agree.
However, some projects are more speculative, so you aren't sure what kind of savings they'll yield. These project might reduce your COGS by half, but they might also be a dead-end. Those are your moonshots.
For example, describe the human resource costs and the roadmap items that might be at risk. You should also express any uncertainty you have about the approach you plan to take. When you're only 50% sure your changes will affect costs and performance, it's better to say so proactively than to embark on your plan only to report lackluster results.
Every engineering initiative will not be a success. Business leaders rely on engineering for information when deciding which risks are worth taking.
If your engineering team spends three months re-architecting the application and there's a 50% chance they'll save $1 million per month, should they do it? Is it worth it to improve performance by 50% while increasing costs by 30%?
Even with the best data, there will always be some uncertainty. It's essential to convey uncertainty accurately by presenting potential risks and benefits as part of any decision-making process. This will allow leadership to make an informed decision.
Margin improvement goes beyond technical system improvements. To ensure the products you build are priced and packaged correctly, get input from your GTM team leaders, such as your CRO or head of product.
One of the most important things you can do is present your cost and utilization data, mapped to the business units they care about.
Taking this approach allows your team to work together to maximize margins — and shows your team potential revenue growth areas they may not have thought of otherwise.
For example, let’s say you work for a SaaS company that offers a messaging platform, and you allow your customers to backup messages for free, but you identify that storage costs are 30% of your COGS. You will want to use this data to discuss whether you should start charging extra for storage — or whether you could reduce the cost of storage with an engineering solution.
Your business can benefit greatly from these sorts of conversations. Not only can you grow your margins and provide direction to your business — but finding a solution that doesn’t involve engineering can help keep new feature delivery on pace so that you can stay competitive.
Engineering leaders who can have successful conversations about COGS don’t wait for a crisis. Cost data is something engineering leaders need to pay attention to continually, and neither engineering leaders nor the exec team should wait for crunch time to have a conversation about it.
If you want to become an expert in cost data, you need to pay attention and use it frequently in your decision-making.
These are ultimately business decisions. Effective executive teams use data to support their choices. You need to show, with data, how the technical decisions your organization has made are associated with your business results and goals.
The team also needs to have enough information about costs, risks, and trade-offs to make their own contributions, even if they do not know how your technical system works and wouldn’t know which way is up on an AWS bill.
Having trouble connecting technical decisions with business results?
CloudZero's Cloud Cost Intelligence platform automatically aligns cloud spend to the metrics businesses care about like COGS, cost per feature, customer, product, team, environment, and more.
Engineering leaders can empower their engineers to see the cost impact of their work and even drill down into cost data from a high level down to the individual components that drive their cloud spend.
Engineering teams can see exactly what AWS services cost them the most and why — and finance teams can finally get the cost insight they need to make informed decisions that ensure profitability for their business.
Request a demo today to see how CloudZero can help your organization understand your SaaS COGS.
CloudZero is the only solution that enables you to allocate 100% of your spend in hours — so you can align everyone around cost dimensions that matter to your business.