Revenue is satisfying to watch, but it does not tell you whether a product is helping your business.

An app with $1,000 in monthly revenue can be a strong small product, a costly distraction, or something in between. The answer depends on what must be spent to generate and support that revenue.

Contribution profit gives indie developers a practical product-level view. It asks a focused question: after the costs assigned to this product, how much remains to support the rest of the business and reward the owner?

Define the number before calculating it

In this guide, the internal operating measure is:

Product contribution profit = revenue − direct costs − allocated shared costs

And, when revenue is greater than zero:

Contribution margin = product contribution profit ÷ revenue × 100%

The Shared Cost Allocator applies this model to a small product portfolio so you can compare allocation methods without uploading any data.

Traditional contribution-margin definitions may subtract only variable costs. The version above also includes an explicit share of common operating costs because a multi-product indie business needs to see whether each product helps carry the shared toolset. Call it “operating contribution profit” in your own records if that prevents confusion.

This is a management metric, not net income and not a replacement for formal accounts. Taxes, financing, depreciation, and legal accounting treatment may sit outside it.

Decide what counts as revenue

Choose one consistent basis for internal comparisons.

For a subscription app, you might use revenue recognized for the month. For a very small operation, you might initially use net cash received because it is easier to maintain. Either can be useful, but mixing invoice values for one product with payout values for another produces a misleading comparison.

Document how you handle:

For example, if you record the amount received after an app store's commission as revenue, do not subtract the same commission again as a cost. If you record gross customer sales, then include the commission as a direct cost. Both views can work; double counting cannot.

Separate direct and shared costs

Direct costs have a clear relationship with one product. Common examples include:

Shared costs support multiple products or the whole operation. Examples include bookkeeping, design software, source control, a common analytics account, and general development tools.

Assign direct costs first. Then give the product a reasonable share of common costs. If your allocation method is not yet clear, start with a simple shared-cost policy rather than excluding the shared pool entirely.

A hypothetical calculation

Suppose a fictional app called NovaNotes has the following monthly figures. This example starts with revenue before the fees and refunds listed below. If your revenue figure already excludes them, do not subtract them again.

Item Amount
Revenue $1,500
Product infrastructure $120
Payment fees $45
Refunds $15
Product-specific support $100
Allocated shared costs $220

Direct costs total $280. The calculation is:

$1,500 − $280 − $220 = $1,000 contribution profit

The contribution margin is:

$1,000 ÷ $1,500 = 66.7%

This hypothetical result means NovaNotes leaves $1,000 after the costs included in this model. That amount is available to pay for owner time, taxes, investment, costs outside the model, or profit.

It does not mean the owner takes home $1,000. If the app requires substantial unpaid labor, its economic result may be much lower.

Add an owner-time view without corrupting the core metric

Solo developers often treat their time as free because no salary leaves the bank account. That is acceptable for a cash view, but dangerous for product decisions.

Keep two adjacent measures:

  1. Cash contribution profit uses actual operating expenses.
  2. Economic contribution after owner time subtracts hours multiplied by a chosen internal hourly value.

If NovaNotes requires 12 hours per month and the owner values that time at $50 per hour, the internal time cost is $600. Economic contribution after owner time becomes $400.

The $50 rate is not an objective market fact. It is a decision tool. Choose a rate that represents the alternative use of your time, document it, and apply it consistently. You can also run two scenarios—a conservative low rate and a higher opportunity-cost rate.

Read changes, not just snapshots

One month's contribution profit is useful, but the trend is more informative.

Track the same definition over time and annotate events:

Suppose profit increases while revenue stays flat. You may have removed waste or shifted customers to a more efficient plan. If revenue grows but contribution margin falls, usage costs, support effort, or acquisition spending may be rising faster than sales.

Always inspect the underlying amounts. A percentage can swing dramatically when a product has very little revenue.

Use scenarios before making a decision

Contribution profit becomes especially helpful when you change one assumption at a time.

For a price decision, model the new price with several plausible customer-retention outcomes. For a hosting change, compare the monthly saving with migration time and risk. For a product shutdown, separate costs that truly disappear from shared costs that will simply move to the remaining products.

A product with negative contribution today is not automatically a failure. A deliberate investment-stage product may be expected to lose money. The metric makes that subsidy visible so you can set a budget and a review date.

Likewise, a positive contribution product is not automatically worth keeping. A small profit that demands urgent support every weekend may compare poorly with a lower-maintenance alternative.

How I apply the boundary in MarginDeck

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

When I designed MarginDeck's product contribution view, I deliberately labelled the result estimated contribution profit rather than profit. The number depends on the revenue, costs, and allocations the user records; it is a decision-support view, not a substitute for accounting records.

MarginDeck imports aggregate net revenue according to each source's metric. Do not deduct fees or refunds already excluded from that amount a second time. The owner-time calculation in this guide is a separate estimate; MarginDeck does not track hours.

I also chose to show contribution margin as undefined when revenue is zero. Displaying 0% would look tidy, but it would be mathematically misleading because the calculation divides by revenue. That edge case is a useful test for any profitability spreadsheet or tool: a missing denominator should stay visible instead of being converted into a reassuring number.

Those labels may seem conservative. I think they make the metric more useful because the boundary remains clear when someone returns to the result months later.

Common mistakes

Treating every expense as variable

A shared design subscription does not vanish when one customer cancels. Distinguish costs driven by sales or usage from costs paid regardless of activity.

Mixing monthly and annual figures

Keep annual services in their recorded billing month so the scheduled cost remains visible. If you also calculate a normalized monthly comparison, label it as a separate analytical view rather than substituting it for the scheduled cost.

Ignoring failed payments and refunds

Dashboard sales and collectible revenue are different. Use a source that reflects your chosen revenue definition.

Changing the method to improve the result

If allocation rules change every time a product looks weak, comparisons lose meaning. Set review conditions in advance.

Comparing unlike product stages

A pre-launch app and a mature subscription product serve different purposes. Compare each with its plan and stage, then evaluate the portfolio as a whole.

A useful monthly review

For each product, record revenue, direct costs, shared-cost allocation, contribution profit, contribution margin, owner hours, and one short note explaining material changes.

Then ask:

A spreadsheet can handle this well. If you operate several products and want a dedicated view, disclosure: I am Junhua Jin, and I build MarginDeck. It is designed to help makers understand costs and profitability across products. The definitions and cautions in this guide apply regardless of the tool you choose.