The Real Cost of Running Multiple Software Products

The cost of a software product is rarely just its server bill.

A small app can run on inexpensive infrastructure while depending on payment processing, email, monitoring, design tools, domains, support time, and the developer's attention. When you operate several products, those costs overlap. The card statement shows what the portfolio spends, but not what each product demands.

List direct services, shared tools, owner time, and irregular costs separately.

Think in five cost layers

1. Direct infrastructure and services

These costs exist because a specific product exists: dedicated compute, storage, databases, transactional email, product APIs, domains, and product-specific monitoring. Record which vary with usage and which are fixed so you can estimate what happens when the product grows.

2. Transaction and distribution costs

Payment processors, app stores, marketplaces, refunds, chargebacks, and currency conversion can sit between a customer's payment and your payout.

Use a consistent revenue convention. If you record gross sales, show these deductions as costs. If you record only the net amount received, avoid subtracting them again.

3. Shared operating costs

One source-control account, design suite, AI assistant, bookkeeping service, or analytics subscription may support every product. Put these costs in a shared pool and use a documented allocation policy such as equal allocation, revenue weighting, usage, or deliberate custom weights.

If the allocation policy is the unclear part, start with the shared SaaS cost guide and test the options in the Shared Cost Allocator.

4. Labor and owner attention

For many indie products, time is the largest invisible input. Maintenance, customer support, release work, compliance, incident response, content, and context switching all consume hours.

Keep owner time separate from cash expenses, but do not hide it. Track approximate hours by product and multiply them by an internal value when you want an economic view. The rate is a planning assumption, not an invoice.

5. Irregular obligations and risk

Annual renewals, legal reviews, tax preparation, device replacements, security incidents, and platform-policy changes do not appear every month. Yet a portfolio must absorb them.

Schedule known annual expenses in their expected billing month. If a normalized monthly comparison is useful, keep it as a separate analytical view rather than replacing the scheduled cost. For uncertain events, keep a portfolio reserve or scenario rather than inventing an exact product-level amount.

A hypothetical portfolio

Disclosure: I make MarginDeck. This article describes my own work on the product.

Consider three fictional products: PocketLedger, ClipForge, and TinyStatus. The owner wants both a cash operating view and an economic view that includes time. This example starts with revenue before the fees listed below. If your revenue figure already excludes them, do not subtract them again. Owner time is a separate economic-cost estimate, not a cost automatically recorded by MarginDeck.

The portfolio also pays $300 for shared software. For this example, the owner chooses revenue-weighted allocation. Revenue shares are 60%, approximately 33.3%, and approximately 6.7%, so the shared amounts are $180, $100, and $20.

The owner's monthly time is estimated at 5, 10, and 3 hours. At a hypothetical internal rate of $40 per hour, time values are $200, $400, and $120.

This example does not prove that ClipForge or TinyStatus should close. ClipForge may be in a planned investment phase. TinyStatus may be strategically useful or close to becoming maintenance-free.

It does reveal the tradeoff. Cash dashboards alone show all three products contributing. Adding time shows that two products currently consume more economic value than they create under the chosen assumptions.

Cost the product you actually operate

A common mistake is to model the idealized architecture rather than the current product. An unused premium database tier is still a real cash cost. So is a support tool retained for one legacy customer.

Review the actual recurring ledger and ask of every line:

• Would this cost disappear if the product disappeared?
• Does it grow with customers, usage, or revenue?
• Is it shared, and if so, what drives the benefit?
• Is it a current necessity, a convenience, or forgotten waste?
• Is the monthly figure hiding an annual commitment?

Include maintenance drag

Two products with identical revenue and cash cost can have very different value.

One may require a quiet monthly dependency update. Another may create frequent support interruptions, fragile releases, and repeated platform reviews. Hours capture part of this difference, but interruption cost also matters. Ten scattered fifteen-minute tasks can be more disruptive than one focused block of equal duration.

You do not need a stopwatch. Use broad, consistent estimates such as maintenance, support, growth work, and incidents. Review them monthly. If a product repeatedly consumes more attention than expected, that pattern deserves a decision even if the estimate is imperfect.

Separate sunk cost from future cost

Past development effort may explain your attachment to a product, but it should not determine the next investment. Compare expected future benefits with future cash, time, and risk. A year already spent building an app cannot be recovered by spending another year on it.

Keep historical investment for learning and retrospective analysis. Keep it out of a forward-looking “continue, grow, maintain, or stop” decision unless it changes a future obligation.

Model growth before it arrives

Some software costs stay flat for a long time and then jump at a pricing tier. Others rise smoothly with requests, storage, messages, or transactions.

For each meaningful cost, note its driver and next threshold. Then model a few scenarios:

• current usage and revenue;
• revenue doubling with similar customer behavior;
• usage doubling without revenue doubling;
• a vendor moving to the next billing tier;
• a product entering low-maintenance mode.

These are not forecasts that need false accuracy. They are stress tests. A product with a healthy margin today may be built on an API whose cost grows faster than its pricing.

What building an upcoming-cost view taught me

While building MarginDeck's Upcoming Costs view, I had to separate facts that are easy to collapse into one monthly number: the amount, billing date, recurrence, stop month, and product allocation. A $120 annual renewal and a $10 monthly subscription may average to the same monthly cost, but they create different cash and cancellation decisions.

The projection in MarginDeck comes from the schedule recorded by the user; it does not pretend to know what a bank or vendor will actually charge. That constraint reinforced a useful rule for my own reviews: keep expected schedules, actual cash charges, and product-level operating costs as related but distinct views.

This makes uncertainty easier to see. It also makes actions more specific: update a schedule, prepare for a renewal month, stop a recurring cost from a future date, or investigate a charge that differed from the plan.

Turn the inventory into a monthly practice

Start with a recurring-cost register containing vendor, amount, billing frequency, renewal date, product assignment, cost driver, and cancellation consequence.

Once a month:

1. Reconcile actual product revenue and direct costs.
2. Check new, cancelled, or changed subscriptions.
3. Allocate the shared pool using your documented rules.
4. Add approximate owner hours in a separate economic view.
5. Compare product contribution with the previous month.
6. Choose one concrete action.

That action might be cancelling a redundant tool, changing a plan, raising a price, simplifying support, or accepting a deliberate subsidy until a specific review date.

Every quarter, revisit the larger structure: which products deserve growth work, which should remain in maintenance, and which no longer justify their obligations.

Set a budget for experiments

Real-cost analysis can become overly harsh if every experiment is expected to be immediately profitable. Exploration has value, and some products need a defined investment period.

The point is to make that investment explicit. “This product may use up to $300 and 12 hours per month until November” is a manageable decision. “It is basically free to run” often hides a growing collection of subscriptions and interruptions.

A spreadsheet is enough to build the first clear view. You can combine it with the methods in the contribution-profit guide. If managing the relationships becomes cumbersome, disclosure: I am Junhua Jin, and I build MarginDeck, which focuses on costs and profitability across products.