SaaS COGS: The Complete Allocation + Benchmarks Optimization Guide

If you’re build­ing a SaaS com­pa­ny at $5M–$15M ARR, one of the high­est-lever­age met­rics you can mas­ter is SaaS COGS (Cost of Goods Sold). Get it right, and you unlock 5–7 per­cent­age points of addi­tion­al gross mar­gin. Get it wrong, and you’ll pitch investors on a busi­ness you think is worth 10x ARR when it’s actu­al­ly worth 5x.

Here’s the prob­lem: there is no con­sen­sus on what counts as COGS in SaaS. Most founders default to “any­thing relat­ed to deliv­er­ing the prod­uct,” then end up clas­si­fy­ing cus­tomer suc­cess salaries, onboard­ing labor, and even part of R&D as COGS. That’s a finan­cial mis­state­ment that com­pounds every val­u­a­tion con­ver­sa­tion.

This guide gives you the allo­ca­tion rules, bench­marks, worked exam­ples, and a play­book to get COGS right.


What Is SaaS COGS, and Why the Definition Matters

COGS (Cost of Goods Sold) is the cost to deliv­er the prod­uct to one addi­tion­al cus­tomer, exclud­ing sales, mar­ket­ing, and over­head.

For a tra­di­tion­al man­u­fac­tur­er, COGS is straight­for­ward: mate­ri­als, labor, ship­ping. For SaaS, it’s slip­pery. You have no phys­i­cal inven­to­ry. You have no incre­men­tal labor per cus­tomer (usu­al­ly). So what counts?

The oper­a­tive prin­ci­ple: COGS includes only costs that vary with cus­tomer count or cus­tomer usage, and are direct to deliv­ery.

Costs that scale with rev­enue but serve the entire com­pa­ny (like R&D or exec­u­tive salaries) are oper­at­ing expens­es, not COGS. Costs that sup­port cus­tomer suc­cess after the tech­ni­cal prod­uct works (upselling, reten­tion calls) are S&M or CS, not COGS. The dis­tinc­tion is crit­i­cal because it sep­a­rates “cost to deliv­er what the cus­tomer bought” from “cost to keep or expand the cus­tomer.”

SaaS COGS typ­i­cal­ly includes:

  • Host­ing and infra­struc­ture (AWS, Google Cloud, Azure, Data­dog)
  • Third-par­ty tools and APIs embed­ded in the prod­uct (Stripe, Twilio, Ope­nAI, Anthrop­ic, etc.)
  • Cus­tomer sup­port and tech­ni­cal sup­port (not success/account man­age­ment)
  • Onboard­ing and imple­men­ta­tion labor (if required to acti­vate the cus­tomer)
  • DevOps, SRE, and inci­dent response (main­tain­ing pro­duc­tion sys­tems)
  • Hosting/monitoring/observability tools (Data­dog, New Rel­ic, Sen­try)
  • Pay­ment pro­cess­ing fees (Stripe, Pay­Pal com­mis­sions)

SaaS COGS does NOT include:

  • R&D / Prod­uct Devel­op­ment — build­ing new fea­tures, inter­nal tool­ing
  • Sales & Mar­ket­ing — acqui­si­tion, events, adver­tis­ing, con­tent cre­ation
  • Cus­tomer Suc­cess & Account Man­age­ment — upselling, reten­tion, strate­gic reviews (these are S&M expense cat­e­gories)
  • G&A / Exec­u­tive — CEO, CFO, HR, finance, legal
  • Office / Over­head — rent, util­i­ties, insur­ance

SaaS Cost Classification — A decision tree diagram showing cost classification paths: s

The Allocation Decision Tree: Gray Areas

The list above is clean, but imple­men­ta­tion is messy. Here are the most com­mon gray areas and how to resolve them.

Gray Area #1: Sup­port vs. Cus­tomer Suc­cess

The prod­uct is live. A cus­tomer has a tech­ni­cal ques­tion. Who should you staff — sup­port or cus­tomer suc­cess?

  • Sup­port (COGS): “Our API authen­ti­ca­tion isn’t work­ing in this edge case. Help.”
  • Cus­tomer Suc­cess (OpEx): “How do we archi­tect this to scale to 100K users? Let me show you the roadmap.”

Sup­port solves for prod­uct deliv­ery. CS solves for adop­tion, expan­sion, and reten­tion. In prac­tice, many teams blend these. The allo­ca­tion rule: only the por­tion of CS labor spent on onboard­ing, acti­va­tion, and resolv­ing deliv­ery block­ers belongs in COGS. If your CS team spends 60% of time on acti­va­tion and 40% on upselling/expansion, only 60% of their salary is COGS. The 40% goes to S&M expense.

This requires hon­est track­ing. Most founders avoid it and lump all CS salaries into OpEx, which under­states COGS and over­states gross mar­gin. Investors who dig into your met­rics will catch it, so bet­ter to clas­si­fy cor­rect­ly upfront.

Gray Area #2: Infra­struc­ture — Shared vs. Per-Cus­tomer

You run a mul­ti-ten­ant SaaS plat­form. Most infra­struc­ture costs (com­pute, stor­age, net­work­ing) scale with total cus­tomer count, not with any one cus­tomer. Do all of these costs belong in COGS?

Yes, but with allo­ca­tion log­ic. COGS should be total infra­struc­ture spend ÷ num­ber of cus­tomers. That gives you per-cus­tomer COGS. Track it sep­a­rate­ly by seg­ment (SMB gets low­er per-cus­tomer COGS in mul­ti-ten­ant, enter­prise may require ded­i­cat­ed infra­struc­ture and high­er COGS).

Gray Area #3: Onboard­ing and Imple­men­ta­tion

Cus­tomer signs up. They need onboard­ing to go live. Is that COGS?

If onboard­ing is required to acti­vate the prod­uct and unlock val­ue, it’s COGS. If it’s option­al and tac­ti­cal (nice-to-have train­ing), it’s OpEx. Most com­pa­nies err toward COGS here because onboard­ing direct­ly enables rev­enue recog­ni­tion.

Gray Area #4: DevOps, SRE, and Inci­dent Response

You have a 4‑person SRE team main­tain­ing pro­duc­tion uptime, respond­ing to inci­dents, and improv­ing deploy­ment infra­struc­ture. Is their salary COGS?

Yes. These are oper­a­tional costs to keep the live prod­uct live. Their work is not build­ing fea­tures (R&D); it’s pre­serv­ing the deliv­ery plat­form. Allo­cate 100% of SRE salaries to COGS unless they also spend time on new archi­tec­ture that sup­ports future prod­ucts (then pro­rate).


The Gross Margin Formula and Why It’s Your Profit Engine

Gross Mar­gin = (Rev­enue − COGS) / Rev­enue × 100%

Exam­ple: $10M ARR com­pa­ny with $2M COGS. Gross Mar­gin = ($10M − $2M) / $10M = 80%.

This one num­ber deter­mines three things:

  1. Prof­itabil­i­ty Ceil­ing — After gross mar­gin, you pay sales, mar­ket­ing, R&D, and over­head. A com­pa­ny with 60% gross mar­gin can nev­er reach 40% EBITDA mar­gins (the SaaS bench­mark). A com­pa­ny with 85% gross mar­gin has room to build.
  2. Unit Eco­nom­ics & LTV/CAC — LTV depends on gross mar­gin. LTV = ARPA × Gross Mar­gin % × (1 / Month­ly Churn Rate). Low­er COGS = high­er LTV = health­i­er unit eco­nom­ics = scal­able growth.
  3. Val­u­a­tion Mul­ti­ple — Investors use gross mar­gin as a sig­nal of prod­uct-mar­ket fit, scal­a­bil­i­ty, and unit eco­nom­ics. A 70% gross mar­gin busi­ness trades at 8–10x ARR. An 85%+ mar­gin busi­ness trades at 10–15x ARR. A 50% mar­gin busi­ness trades at 4–6x. Improv­ing gross mar­gin by 5 per­cent­age points is worth $3M–$5M in exit val­ue for a $10M ARR com­pa­ny.

Benchmark Data: Where You Stand

SaaS gross mar­gin bench­marks vary by com­pa­ny stage and ver­ti­cal, but the data is clear.

Met­ricSaaS Medi­anTop Quar­tileNotes
Gross Mar­gin73%85%+Varies by ver­ti­cal; enter­prise SaaS high­er
COGS as % of Rev­enue27%15%–20%Low­er is bet­ter (more mar­gin to work with)
Gross Mar­gin by ARR
$1M–$5M ARR65–70%75%+Larg­er pay­roll drag (support/ops)
$5M–$25M ARR70–75%80%+Economies of scale emerg­ing
$25M–$100M+ ARR75–82%85%+Infra­struc­ture amor­tized; SRE scal­able

Key insight: If you’re at $10M ARR with 65% gross mar­gin and your com­peti­tor is at 80%, they’re 2–3x bet­ter posi­tioned to reach $100M ARR prof­itably. They can spend more on acqui­si­tion, prod­uct, and oper­a­tions while still hit­ting 40% EBITDA mar­gins.


Multi-Tenant vs. Single-Tenant SaaS Cost Structure — Two diverging curves starting at a common point—one flat (sh

Multi-Tenancy vs. Single-Tenancy: COGS Implications

The archi­tec­ture of your prod­uct deter­mines your COGS curve.

Mul­ti-Ten­ant Archi­tec­ture (most SaaS com­pa­nies):

  • One shared infra­struc­ture serves many cus­tomers
  • Infra­struc­ture costs per cus­tomer decline as you add cus­tomers (amor­ti­za­tion)
  • COGS as % of rev­enue decreas­es with scale
  • At 10 cus­tomers: 40% COGS. At 100 cus­tomers: 20% COGS. At 1,000 cus­tomers: 8% COGS.

Sce­nario #1: Mul­ti-Ten­ant SaaS, $10M ARR, 200 cus­tomers

  • Annu­al host­ing cost: $1.2M (scales sub­lin­ear­ly)
  • Annu­al sup­port: $600K (scales rough­ly lin­ear with cus­tomers)
  • COGS: $1.8M = 18% of rev­enue = 82% gross mar­gin

Sin­gle-Ten­ant Archi­tec­ture (some enter­prise SaaS, most cus­tom soft­ware):

  • Each cus­tomer gets a ded­i­cat­ed instance (infra­struc­ture, data, some­times cus­tom code)
  • Infra­struc­ture costs scale lin­ear­ly with cus­tomer count
  • COGS stays high or ris­es as you add cus­tomers
  • At 10 cus­tomers: 50% COGS. At 100 cus­tomers: 55% COGS.

Sce­nario #2: Sin­gle-Ten­ant SaaS, $10M ARR, 50 cus­tomers ($200K ACV)

  • Annu­al host­ing cost (ded­i­cat­ed): $2.5M (scales with cus­tomer count + data size)
  • Annu­al imple­men­ta­tion: $800K (one-time per cus­tomer, amor­tized)
  • Annu­al sup­port: $500K
  • COGS: $3.8M = 38% of rev­enue = 62% gross mar­gin

The les­son: If you’re sin­gle-ten­ant, your COGS stays ele­vat­ed. Your busi­ness is prof­itable only if ACV is high enough to absorb the deliv­ery costs. If you’re mul­ti-ten­ant and grow­ing, your gross mar­gin improves as you scale (a pow­er­ful advan­tage). Investors see this and price accord­ing­ly.


Worked Example: $10M ARR Company COGS Build

Let’s walk through a real­is­tic com­pa­ny: 160 cus­tomers, $62.5K aver­age ACV, mul­ti-ten­ant SaaS, $10M ARR.

COGS Com­po­nents:

Cat­e­go­ryAnnu­al CostCost per Cus­tomerNotes
Host­ing (AWS)$900K$5,625Scales with com­pute, stor­age, data trans­fer; 9% of rev­enue
Third-par­ty APIs$320K$2,000Stripe (pay­ment pro­cess­ing), Send­Grid, Twilio, data ware­house costs
Cus­tomer Sup­port (30 peo­ple)$2.1M$13,125Ful­ly loaded salary + ben­e­fits; support@company.com team
Onboarding/Impl. Labor (10 peo­ple, 40% time)$480K$3,000Imple­men­ta­tion engi­neers allo­cat­ing 40% to onboard­ing
DevOps/SRE (5 peo­ple)$600K$3,750Main­tain­ing pro­duc­tion, inci­dent response, CI/CD
Monitoring/Observability$180K$1,125Data­dog, Pager­Du­ty, Sen­try
TOTAL COGS$4.58M$28,625

Gross Mar­gin = ($10M − $4.58M) / $10M = 54.2%

This com­pa­ny is below medi­an (73% bench­mark). Why?

  1. Sup­port head­count is high — 30 peo­ple for 160 cus­tomers = 1 sup­port per­son per 5.3 cus­tomers. Indus­try bench­mark is 1:10. This com­pa­ny either has high-touch ser­vice or inef­fi­cient triage. (Action: imple­ment sup­port tier struc­ture, auto­mate triage.)
  2. Onboard­ing costs are high — 10 peo­ple at 40% time is $1.2M blend­ed, but allo­cat­ed as $480K to COGS (40% of their time). If imple­men­ta­tion is required for every cus­tomer, this is COGS; if option­al, shift to OpEx. Either way, this is a lever. (Action: build auto­mat­ed onboard­ing flows, reduce per-cus­tomer imple­men­ta­tion time.)
  3. Host­ing costs are rea­son­able — 9% of rev­enue is sol­id for a scal­able plat­form. No imme­di­ate action need­ed.

If this com­pa­ny opti­mizes sup­port to 1:10 ratio and reduces imple­men­ta­tion time by 30%:

  • Sup­port: $1.4M (20 peo­ple instead of 30)
  • Imple­men­ta­tion: $336K (30% reduc­tion via automa­tion)
  • New COGS: $3.736M
  • New Gross Mar­gin: 62.6%

That 8.4 per­cent­age point improve­ment is worth $4M–$7M in acqui­si­tion val­ue (at 10–15x ARR mul­ti­ple for a 62.6% mar­gin com­pa­ny vs. 4–6x for a 54% mar­gin com­pa­ny).


Usage-Based Billing and COGS Complexity

If you charge by usage (per-API-call, per-GB, per-seat), your COGS math becomes more inter­est­ing.

Sce­nario #3: Usage-Based SaaS, $5M ARR, 400 cus­tomers

Your prod­uct charges $0.10 per API call. You main­tain servers, APIs, and pay for band­width. As your cus­tomers’ usage increas­es, your COGS increas­es.

Fixed COGS (infra­struc­ture base­line):

  • Host­ing, mon­i­tor­ing, DevOps: $600K/year (does­n’t change with usage)

Vari­able COGS (scales with usage):

  • AWS for API calls: $0.03 per call (your cost)
  • You charge $0.10 per call, mar­gin $0.07 per call

If cus­tomers run 50M API calls/year:

  • Vari­able COGS: 50M × $0.03 = $1.5M
  • Fixed COGS: $600K
  • Total COGS: $2.1M = 42% of $5M ARR = 58% gross mar­gin

If you increase infra­struc­ture effi­cien­cy (AI, caching, CDN opti­miza­tion), your per-call cost drops from $0.03 to $0.018:

  • New vari­able COGS: 50M × $0.018 = $900K
  • Total COGS: $1.5M = 30% of rev­enue = 70% gross mar­gin

This is a 12-point mar­gin improve­ment from infra­struc­ture opti­miza­tion. That’s a major lever for usage-based com­pa­nies.


The 2025 Angle: AI Inference Costs in Your COGS

If your prod­uct includes AI/ML (LLM infer­ence, embed­dings, fine-tun­ing), you now have a new COGS line item: infer­ence spend.

Run­ning GPT‑4, Claude, Lla­ma, or local mod­els costs mon­ey. As of 2026, Ope­nAI’s GPT‑4 API costs ~$0.03–0.06 per 1K tokens. If your cus­tomers run 10B tokens per month, that’s $300K–$600K per month in infer­ence spend alone.

Sce­nario #4: AI-Native SaaS, $8M ARR, 200 cus­tomers

You’ve embed­ded Claude into your prod­uct. Cus­tomers run rough­ly 100B tokens per month across the prod­uct.

  • Infer­ence cost: 100B tokens × $0.00004 per token = $4M/month = $48M/year

Wait, that’s more than your ARR. That means your COGS is 600% of rev­enue. This is not scal­able.

What actu­al­ly hap­pens: You opti­mize. You use cheap­er mod­els (Lla­ma 2, local infer­ence). You cache heav­i­ly. You batch requests. You add usage lim­its. Your actu­al infer­ence COGS becomes $800K/year instead of $48M.

The les­son: If you have AI infer­ence in your prod­uct, mod­el it explic­it­ly. Infer­ence costs can make or break your unit eco­nom­ics. Price high enough to cov­er infer­ence, or your mar­gins evap­o­rate.


How COGS Affects Your Rule of 40 Score and Valuation

Investors use the Rule of 40 to assess com­pa­ny health: Rule of 40 = Growth Rate (%) + EBITDA Mar­gin (%).

Com­pa­nies that hit or exceed 40 are con­sid­ered healthy. Com­pa­nies below 30 are strug­gling.

Here’s how COGS feeds into this:

EBITDA Mar­gin = (Rev­enue − COGS − OpEx) / Rev­enue × 100%

If you’re at $10M ARR with 65% gross mar­gin and $3M OpEx, your EBITDA mar­gin is:

  • ($10M − $3.5M − $3M) / $10M = 35%

If you improve COGS from 35% to 20% (gross mar­gin 65% → 80%), your EBITDA mar­gin jumps to 50%. That’s a 15-point improve­ment.

If you’re grow­ing at 25% and your EBITDA mar­gin is 15%, your Rule of 40 score is 40 (bare­ly pass­ing). If you improve COGS so your EBITDA mar­gin ris­es to 30%, your Rule of 40 becomes 55 (elite tier). That dif­fer­ence means a 3–4x val­u­a­tion pre­mi­um.


Allocation Playbook: How to Audit Your Own COGS

Most founders have nev­er for­mal­ly allo­cat­ed COGS. Here’s a step-by-step play­book.

Step 1: List All Com­pa­ny Costs Pull your most recent year’s P&L. List every expense cat­e­go­ry. Don’t esti­mate; use actu­al num­bers.

Step 2: Clas­si­fy Each Cost For each line, ask: “Does this cost vary with cus­tomer count?” If yes, does it sup­port prod­uct deliv­ery (COGS) or busi­ness expan­sion (OpEx)?

CostVaries with Cus­tomers?COGS or OpEx?Rea­son
AWS host­ingYesCOGSDirect to prod­uct deliv­ery
VP Sales salaryNoOpExDoes­n’t scale with cus­tomer count
Sup­port teamYesCOGSDirect to prod­uct deliv­ery
Cus­tomer suc­cessPar­tialOpEx (60%), COGS (40%)Split by func­tion
R&D / Engi­neer­ingNoOpExBuild­ing fea­tures, not deliv­er­ing cur­rent prod­uct
Mar­ket­ingNoOpExAcqui­si­tion, not deliv­ery
Exec­u­tive / G&ANoOpExOver­head

Step 3: Allo­cate Shared Costs Sup­port team salary is easy (all COGS). R&D is hard (no COGS). Cus­tomer Suc­cess is in the mid­dle. Cre­ate a rule:

  • If a per­son spends >50% of time on delivery/activation, allo­cate their full salary to COGS.
  • If they spend <50%, allo­cate to OpEx.
  • If 30–70% is mixed, track the per­cent­age and allo­cate pro­por­tion­al­ly.

Step 4: Cal­cu­late COGS as % of Rev­enue

  • Total COGS / Total Rev­enue = COGS %
  • Gross Mar­gin % = 100% − COGS %

Step 5: Bench­mark

  • Is your COGS in line with indus­try bench­marks (15–30% for healthy SaaS)?
  • Is it high­er? Iden­ti­fy the caus­es (high sup­port, high imple­men­ta­tion, high infra­struc­ture).
  • Is it low­er? Ensure you’re not mis­clas­si­fy­ing OpEx as COGS.

Step 6: Iden­ti­fy Levers The top 3 COGS levers for most com­pa­nies:

  1. Sup­port effi­cien­cy — Reduce sup­port head­count per cus­tomer via automa­tion, tier­ing, or tick­et deflec­tion.
  2. Infra­struc­ture opti­miza­tion — Nego­ti­ate cloud dis­counts, improve resource uti­liza­tion, use cheap­er regions/instances.
  3. Onboard­ing automa­tion — Build self-serve, reduce per-cus­tomer imple­men­ta­tion labor.

Common Misclassifications and Why They Matter

Mis­take #1: Includ­ing All Cus­tomer Suc­cess in COGS

Many founders allo­cate the entire CS team to COGS because “they serve cus­tomers.” But CS salaries are pri­mar­i­ly S&M/OpEx. Only the por­tion tied to onboard­ing, acti­va­tion, and sup­port block­ers is COGS.

Impact: Over­states COGS by 5–10 per­cent­age points. Under­states gross mar­gin, mak­ing the com­pa­ny look less attrac­tive to investors.

Mis­take #2: Exclud­ing Sup­port as COGS

Some founders argue, “Sup­port does­n’t direct­ly impact the prod­uct.” Yes it does. Sup­port solves for prod­uct usabil­i­ty and deliv­ery. With­out sup­port, prod­ucts fail.

Impact: Under­states COGS by 2–5 per­cent­age points. Over­states gross mar­gin. When investors dig in, cred­i­bil­i­ty drops.

Mis­take #3: Includ­ing R&D/Product Devel­op­ment as COGS

“Our engi­neers main­tain the prod­uct, so that’s COGS.” No. Main­tain­ing exist­ing fea­tures is DevOps/SRE (COGS). Build­ing new fea­tures is R&D (OpEx). These are dif­fer­ent cost cen­ters.

Impact: Mas­sive­ly over­states COGS. Under­states OpEx. Cre­ates a false appear­ance of high-mar­gin low-cost deliv­ery. Investors won’t believe it.

Mis­take #4: Not Allo­cat­ing Mul­ti-Cus­tomer Infra­struc­ture Costs

“Our $2M AWS bill serves all cus­tomers. How do we allo­cate it to COGS?” Divide by cus­tomer count. $2M / 200 cus­tomers = $10K COGS per cus­tomer.

Impact: If you skip this, you can’t cal­cu­late per-cus­tomer unit eco­nom­ics. You’ll make bad pric­ing, expan­sion, and acqui­si­tion deci­sions.


FAQ: The Long-Tail Questions Founders Actually Ask

Q: Should onboard­ing be COGS if it’s required before a cus­tomer goes live?

A: Yes. If the cus­tomer can’t go live and use the prod­uct with­out onboard­ing, it’s a cost to deliv­er the prod­uct. Allo­cate it to COGS. If onboard­ing is optional/supplemental train­ing, it’s OpEx.

Q: How do we han­dle shared infra­struc­ture costs when we have both mul­ti-ten­ant and sin­gle-ten­ant cus­tomers?

A: Cal­cu­late per-cus­tomer host­ing COGS sep­a­rate­ly for each seg­ment. Mul­ti-ten­ant cus­tomers: divide shared infra­struc­ture by mul­ti-ten­ant cus­tomer count. Sin­gle-ten­ant cus­tomers: allo­cate ded­i­cat­ed infra­struc­ture to those cus­tomers only. You’ll like­ly see 2–3x high­er COGS per sin­gle-ten­ant cus­tomer.

Q: Is pay­ment pro­cess­ing (Stripe fees) COGS or OpEx?

A: COGS. Stripe’s 2.9% + $0.30 per trans­ac­tion is a cost to deliv­er rev­enue. It scales direct­ly with rev­enue and is unavoid­able. Include it in COGS.

Q: Can we allo­cate part of the CEO’s salary to COGS if they spend time on prod­uct?

A: No. Exec­u­tive salaries are over­head, not vari­able costs tied to cus­tomer deliv­ery. Even if the CEO codes, that’s R&D (OpEx). Keep it sim­ple: CEO salary → G&A / OpEx.

Q: How do we han­dle con­trac­tors for imple­men­ta­tion vs. full-time employ­ees?

A: Same rule. If they’re doing onboarding/activation work required to deliv­er the prod­uct, their cost is COGS. Track time sheets and allo­cate pro­por­tion­al­ly if they work on both COGS and OpEx tasks.

Q: What if we have a tiered sup­port mod­el — some cus­tomers get pre­mi­um sup­port, oth­ers get basic?

A: Cal­cu­late COGS per tier. Pre­mi­um-tier cus­tomers have high­er per-cus­tomer COGS (more sup­port labor). Basic-tier cus­tomers have low­er per-cus­tomer COGS. This lets you rea­son about whether your pric­ing mod­el is sus­tain­able for each tier.

Q: If we use AI infer­ence (Claude, GPT‑4), is that COGS?

A: Yes. Every API call you make to an exter­nal LLM ser­vice costs mon­ey and scales with cus­tomer usage. Mod­el it explic­it­ly. If your infer­ence costs exceed your gross mar­gin, you’re not sus­tain­able. This is a crit­i­cal lever to opti­mize.


The Optimization Playbook: Reduce COGS, Improve Margins

If you’re below-medi­an gross mar­gin, here’s the play­book to improve.

Tier 1 (Quick Wins — 0–6 months):

  1. Audit your COGS allo­ca­tion (you’ll like­ly find 2–3 per­cent­age points of mis­clas­si­fi­ca­tion)
  2. Nego­ti­ate cloud dis­counts (most com­pa­nies over­pay AWS/GCP by 20–30%)
  3. Imple­ment sup­port tier­ing (first-response triage, self-serve esca­la­tion)
  4. Build FAQ/knowledge base to deflect low-val­ue tick­ets

Tier 2 (Medi­um Effort — 6–12 months):

  1. Auto­mate onboard­ing flows (reduce per-cus­tomer imple­men­ta­tion labor)
  2. Opti­mize infra­struc­ture for per-cus­tomer cost (cache, CDN, region opti­miza­tion)
  3. Shift rou­tine sup­port to chat­bots (AI-pow­ered sup­port deflec­tion)
  4. Imple­ment usage metering/limits if nec­es­sary (cap unbound­ed usage)

Tier 3 (Struc­tur­al — 12+ months):

  1. Move from sin­gle-ten­ant to mul­ti-ten­ant (if applic­a­ble; reduces per-cus­tomer infra­struc­ture cost)
  2. Build prod­uct fea­tures that reduce sup­port bur­den (self-serve ana­lyt­ics, in-app trou­bleshoot­ing)
  3. Shift sup­port from email-dri­ven to in-prod­uct (reduce tick­et vol­ume, faster res­o­lu­tion)

Most com­pa­nies see 3–5 per­cent­age point gross mar­gin improve­ment per year if they focus on COGS opti­miza­tion. That’s worth $2M–$3M in exit val­ue per $10M ARR.


Closing: COGS Is Your Profit Engine

SaaS founders obsess over growth rate, MRR, and churn. Those met­rics mat­ter. But gross mar­gin — dri­ven by COGS — is what sep­a­rates a $30M exit from a $100M exit.

Most founders mis­clas­si­fy COGS and don’t see it. Investors do. If you want to max­i­mize val­u­a­tion, obsess over COGS allo­ca­tion, bench­mark against peers, and build a relent­less opti­miza­tion pro­gram.

The com­pa­nies that mas­ter this score 80%+ gross mar­gins at $20M+ ARR. The com­pa­nies that don’t cap out at 60–65% mar­gins and plateau at $30M ARR. That dif­fer­ence is worth 3–5x.

Fix your COGS. Every­thing else flows from there.


Related Reading

Learn how SaaS COGS con­nects to your over­all unit eco­nom­ics and scal­a­bil­i­ty:

Facebooktwitterlinkedinmail
author avatar
Vic­tor Cheng
Author of Extreme Rev­enue Growth, Exec­u­tive coach, inde­pen­dent board mem­ber, and investor in SaaS com­pa­nies.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top