Ask most founders how much of their product's price actually goes toward the software running it, and you'll get a shrug or a guess. The number matters more than it looks like from the outside: it's the difference between a business where growth makes margins better, and one where every new customer quietly makes them worse. "How much margin should software eat?" isn't really one question — it's a different answer depending on whether you're running a subscription SaaS product, a physical product with a companion app, or a service business running on custom internal software. Each one has a different healthy range, and mixing them up is how founders end up either overcharging customers or quietly bleeding margin without noticing.
Software Costs Are a COGS Line, Not an Afterthought
The first mistake is lumping every software-related cost into one vague bucket. In proper financial terms, only some of your software spend counts as cost of goods sold (COGS) — the direct cost of delivering the product to the customers you already have. That includes cloud hosting, third-party API and software fees, payment processing charges, and the DevOps or site-reliability labor that keeps production running. Building new features, on the other hand, is R&D — an operating expense, not a cost of delivery. Mixing the two together makes your margin look worse than it is, and makes it impossible to answer the actual question: how much does it cost you, per customer, to keep the lights on?
- Counts as software COGS: cloud hosting and infrastructure, third-party API costs, payment processing fees, DevOps and production-engineering labor, customer support tied directly to using the product.
- Counts as R&D / OpEx instead: building new features, exploratory engineering work, redesigns, and anything that grows the product rather than keeps the current version running.
- Easy to miscount: engineers who split time between maintaining production and building new features — only the maintenance portion belongs in COGS.
What Healthy Software Margins Actually Look Like
For pure subscription SaaS businesses, the benchmarks are well established. Industry surveys of private B2B SaaS companies consistently put healthy software COGS somewhere between 15% and 30% of revenue, which works out to a gross margin in the 70–85% range. Within that, hosting typically runs around 5% of revenue, DevOps another 3–4%, and professional services or support-related delivery costs another few percentage points on top. If your software COGS is pushing past 30% of revenue, that's usually a sign to look at hosting optimization, renegotiate third-party contracts, or examine whether the support model scales the way the pricing assumes it does.
R&D spending sits in a different bucket entirely and follows a different curve. Early-stage companies still chasing product-market fit often put 50% or more of revenue into R&D, because there's more product to build than there is revenue to fund it. Mature SaaS companies typically settle into the 20–30% range once the core product is stable. Neither number is "eating into price" the way COGS does — R&D is an investment decision, while COGS is the direct cost every customer generates the moment they use the product.
Gross margin is the core indicator of SaaS scalability — it determines how much of every revenue rupee is available to fund sales, support, and future product work.
Common framing among SaaS finance teams
Beyond Pure SaaS: Software as a Cost Center in Other Business Models
These benchmarks assume a subscription SaaS business where software delivery is the product. Plenty of Fall Rise's clients don't fit that model neatly, and the right question changes shape for each one.
Physical Product Plus Companion App
If software is a supporting layer on top of a physical product — a companion app for a hardware device, for instance — the app's hosting and maintenance cost is usually small relative to manufacturing and logistics, but it's still worth pricing in explicitly rather than treating as a rounding error. A neglected companion app becomes a support and churn liability fast, even if it was never the primary cost driver at launch.
Service Businesses Running on Custom Internal Software
For a business whose product is really a service — logistics, field operations, retail distribution — supported by custom software rather than sold as software, the calculation flips. The software isn't generating revenue directly; it's an enabling cost that needs to earn its keep through efficiency gains: fewer support calls, faster dispatch, cleaner records. FieldOps, our field service management platform, is a good example — the admin dispatch dashboard, technician app, and customer portal all cost money to run, but the return shows up as reduced coordination overhead for trades businesses, not as a subscription line customers see directly.
Enterprise Custom Software With a One-Time Build
Some products are priced as a one-time or milestone-based build rather than a recurring subscription. The Umiya Jari Inventory System, an enterprise inventory and billing platform with 28 transaction types across four account roles, is a case where the client pays for the build and then a smaller ongoing hosting and maintenance cost — closer to how traditional software licensing worked than to SaaS-style recurring COGS. The margin question there is less "what percent of MRR" and more "what's a fair annual maintenance fee relative to what it would cost to run this in-house."
The Line Items People Forget to Count
Whichever model you're in, a handful of costs consistently get left out of the mental math until someone actually adds them up:
- Payment processing fees — typically 2–3% of every transaction, which adds up fast at scale and is easy to forget because it never shows up as a single line item.
- Backup and disaster recovery — storage, redundancy, and the engineering time to actually test a restore, not just configure one. This connects directly to the questions raised in do you actually need backups, or is your hosting provider handling it?
- Uptime and monitoring infrastructure — the tooling and redundancy that reduces how often you're exposed to the costs covered in what happens to your business if your app goes down for an hour.
- Third-party API costs — SMS, email, maps, AI inference, or payment gateways that scale with usage and can quietly grow faster than revenue if they aren't priced into the product from day one.
- Security and compliance overhead — audits, certifications, and the engineering time spent on them, which shows up more the moment a product starts selling to larger or regulated customers.
A Practical Way to Think About It
- Separate COGS from R&D first. Anything that keeps the current version of the product running for existing customers is COGS; anything building the next version is R&D.
- Total your true COGS as a percentage of revenue — hosting, DevOps, support, payment processing, and third-party APIs, all of it, even the small recurring charges that don't feel worth tracking individually.
- Compare against the benchmark for your model — 15–30% of revenue for recurring SaaS, a smaller fixed percentage for a physical product's companion app, and a maintenance-fee-relative-to-value calculation for one-time enterprise builds.
- Price with margin as an input, not an afterthought. Once your price is set, this is the moment to compare it against the frameworks in how to decide pricing for your SaaS product and make sure the number you land on actually clears your target margin once real COGS is subtracted.
- Check effective price, not list price, against that margin. Discounts and fees quietly erode the number you thought you'd calculated, which is exactly the gap covered in how to calculate the effective price for your product.
- Revisit quarterly. Hosting costs shift with usage, third-party pricing changes, and a feature that seemed cheap to run at 100 customers can look very different at 10,000.
How We Help Founders Think About This at Fall Rise
When we scope a new build, we walk through the ongoing cost structure alongside the initial one — because a product that's cheap to build but expensive to run can quietly undo a pricing model that looked fine on paper. For a consumer app like Penso Notes, our diary and journaling app, that meant designing storage and media handling to keep hosting cost per user low enough to support a sustainable free tier before a single paid plan existed. For enterprise builds like Umiya Jari Inventory System, it meant being upfront with the client about what ongoing hosting and maintenance would cost relative to the build, so the total cost of ownership was clear from day one rather than discovered a year in. You can see more of this kind of scoping across our project portfolio.
This cost-structure conversation happens whether we're building a SaaS platform, a mobile app, or custom software supporting a service business, and it's a core part of how we scope hosting and deployment from the start — the architecture decisions made at that stage are what determine whether your software COGS sits at 15% of revenue or 35% two years later. It's also worth reading alongside how much it actually costs to build a SaaS MVP if you're still at the stage of budgeting the build itself, not just the ongoing margin.
There's no single right answer to how much margin software should eat into your price — there's only the right answer for your specific model, and it starts with actually separating COGS from R&D instead of treating all software spend as one number. Get that split right, benchmark it against your model, and revisit it as you scale — the businesses that get surprised by margin erosion are almost always the ones that never did this math in the first place. If you want a second opinion on your own cost structure before you finalize pricing, let's talk.
