A new software product often looks inexpensive at the idea stage. The code can start on an existing laptop, a free service tier can host the prototype, and most of the tools are already on the card statement.
The cost becomes clearer only when the idea is placed on a timeline. Free tiers may end, a developer account renews once a year, launch assets land in one month, and an existing design or AI subscription has to support another product.
A 12-month product cost plan does not need to be a full financial model. It needs a consistent boundary, a schedule, and a visible distinction between resources you already pay for and spending the project may add.
Decide what the plan is meant to answer
Use a cost plan for a bounded question:
If I pursue this product for the next 12 months under these assumptions, what costs belong to the plan, and when are they expected?
That question is narrower than “Is this a good business?” It does not include demand, revenue, price, tax, financing, or the value of the founder's time unless you add those in separate views.
Keeping the question narrow prevents a familiar spreadsheet problem: one page gradually becomes a budget, cash-flow statement, sales forecast, profitability model, and launch checklist, while none of those views has a clear definition.
Write the plan's start month and length at the top. Twelve months is useful because it captures at least one occurrence of most yearly services, but it is not mandatory. A three-month validation may deserve a three-month plan. A long regulated launch may need eighteen or twenty-four.
Separate costs into three groups
Start with three groups rather than one undifferentiated expense list.
1. Existing resources the product may use
These are services already paid for by the portfolio: a design suite, source-control plan, AI assistant, monitoring account, bookkeeping service, or shared hosting platform.
Choose the share that belongs in the plan. If a $20 monthly design tool may support the new product half the time, the planned share is $10 per month.
This is an attribution, not necessarily new cash spending. The portfolio may still pay $20 whether or not the new product begins. Keeping this group visible helps you understand the product's resource footprint without describing every attributed dollar as incremental spend.
If assigning shared resources is the difficult part, the shared SaaS cost guide explains equal, revenue-weighted, usage-based, and custom approaches. A pre-launch plan usually needs a simple custom share because it has no product revenue or usage history yet.
2. New recurring costs
These are services expected to begin if the project proceeds: a new hosting plan, database, email service, licensed API, support tool, or product-specific subscription.
Record the amount, currency, cadence, first expected charge, and known stop point. Avoid writing only a monthly equivalent. A $120 yearly account and a $10 monthly service have the same arithmetic average but different timing and cancellation decisions.
3. New one-time costs
These may include a domain purchase, launch artwork, a security review, a contractor milestone, a device, or a one-off dataset.
Place each cost in the month where it is expected. Do not spread it merely to make the chart look smooth. If the timing is uncertain, note the assumption or compare two schedules.
For a wider operating-cost inventory, see The Real Cost of Running Multiple Software Products.
Build the schedule before calculating the average
Consider a fictional product called Focus Notes. The plan starts in August 2026 and runs for 12 months.
The assumptions are:
- 50% of an existing $20 monthly design tool;
- $24 per month for new cloud hosting;
- $96 for launch assets in the first month.
The period totals are straightforward:
| Assumption | Calculation | 12-month cost |
|---|---|---|
| Existing design tool share | $20 × 50% × 12 | $120 |
| New cloud hosting | $24 × 12 | $288 |
| Launch assets | $96 × 1 | $96 |
| Total | $504 |
Now place those amounts on the schedule.
| Period | Design share | Hosting | Launch assets | Scheduled total |
|---|---|---|---|---|
| August 2026 | $10 | $24 | $96 | $130 |
| September 2026–July 2027, each month | $10 | $24 | $0 | $34 |
The first month is $130. Each later month is $34. Together they equal $504.
Only after calculating that total should you derive the average:
$504 ÷ 12 = $42 average monthly cost
The average is useful for comparing this plan with a six-month or twelve-month alternative. It is not a forecast that the card will be charged $42 each month.
Treat yearly costs the same way
Suppose Focus Notes also requires a $99 developer membership that renews in November. Add $99 to November, not $8.25 to every month of the schedule.
The revised 12-month total becomes $603, and the comparison average becomes $50.25. But the expected monthly pattern is still uneven:
- August: $130;
- November: $133;
- the other ten months: $34 each.
This treatment preserves the expected cash timing. It also makes a practical question visible: will the product still be active when the yearly service renews, and when must the renewal decision be made?
You may also keep an amortized operating view for other forms of analysis. Just label it clearly and do not substitute it for the expected-charge schedule. One number explains cost over a service period; the other explains when cash may leave.
Use ranges for uncertain usage costs
Some product costs are not fixed. Storage, model inference, email, maps, media processing, and payment fees can grow with customer behavior.
Do not hide that uncertainty inside one confident amount. Build a small range:
| Scenario | Usage assumption | Monthly cost |
|---|---|---|
| Low | Prototype and private beta | $15 |
| Working | Early public usage | $45 |
| Stress | Usage grows before pricing catches up | $120 |
Keep every non-usage assumption the same, then compare the three totals. The purpose is not to predict the exact number of requests. It is to learn whether the decision changes across a reasonable range.
If the plan remains acceptable only under the low case, the uncertain cost deserves a measurement or a technical limit before launch. If all three cases are manageable, more detailed forecasting may not improve the decision.
Disclosure: I make MarginDeck. This article describes my own work on the product.
MarginDeck 1.2 stores one chosen amount per planned cost rather than a full scenario system. You can save separate plans when two materially different cost structures deserve to remain available, but the feature is not presented as probabilistic forecasting.
Keep currencies independent
If the product uses a USD hosting service and a EUR contractor, keep separate totals unless the plan defines an exchange-rate policy.
A useful conversion policy needs at least:
- the rate source;
- the date or averaging period;
- the reporting currency;
- a decision about when to refresh the rate.
Without that policy, adding 500 USD to 300 EUR is not a total. It is two amounts with their units removed.
For a small plan, showing both currencies separately is often enough. The decision-maker can see the obligations without mistaking a temporary exchange-rate assumption for a stable product cost.
Take snapshots of assumptions
A plan should be reviewable later. Record the price and schedule used when the plan was made instead of linking every cell to a live vendor page or automatically replacing it with the newest portfolio value.
Then add a lightweight review routine:
- Mark which assumption changed.
- Keep the earlier value visible in a note or version.
- Decide whether the active plan should adopt the new value.
- Recalculate the total and explain material differences.
This prevents a shared tool's price change from silently altering a plan that someone already approved for further investigation.
MarginDeck's New Product Planning follows this pattern for existing costs. It copies the recorded schedule into the plan. If the source changes, the plan can identify that state, but it keeps the saved assumption until the user explicitly refreshes it. The planned share remains a plan-only value.
For the full product behavior, see MarginDeck 1.2: Plan a New Product Before You Create It.
Add owner time beside the cash plan
Cash cost is not the whole investment for an independent developer. Estimate owner time beside the plan, but do not mix it into service invoices without a label.
For example:
| Work | Hours | Internal value | Planning value |
|---|---|---|---|
| Initial build | 160 | $50/hour | $8,000 |
| Launch and documentation | 30 | $50/hour | $1,500 |
| Monthly maintenance | 8 × 12 | $50/hour | $4,800 |
The hourly value is a decision assumption, not a salary payment or objective market price. Use a value that represents the alternative use of your time and test more than one rate if the result drives the decision.
Keeping cash and owner time adjacent produces two useful statements:
- “This plan schedules $603 in product costs, including the developer membership.”
- “It may also require 286 hours under the current work estimate.”
Those statements are clearer than combining everything into one unexplained “budget.”
Do not add revenue merely to complete the spreadsheet
A cost plan can be useful before revenue evidence exists. Adding a sales forecast because the sheet feels unfinished creates false balance.
If you have evidence for pricing, conversion, retention, or signed customers, build a separate revenue scenario and state its source. Then use a clearly defined measure such as contribution profit to connect revenue and cost.
If you do not have that evidence, keep the cost plan and write down what must be learned. The plan can still set an experiment boundary: for example, “Spend no more than $600 and 120 hours before five customer interviews and one paid pilot.”
A reusable planning checklist
Before accepting the result, confirm:
- The start month and planning length match the decision window.
- Existing resources and genuinely new spending are separated.
- Every existing resource has an explicit planned share.
- Monthly, yearly, and one-time costs follow their expected schedules.
- Stop dates are included for services that will not run through the full plan.
- One-time launch and review costs are not hidden.
- Usage-sensitive services have a range or a documented working assumption.
- Different currencies are not added without a conversion policy.
- Total cost equals the sum of the scheduled months.
- Average monthly cost is labelled as an average, not a monthly charge.
- Owner time is visible in a separate view.
- Revenue and success claims appear only when supported by separate evidence.
The plan is ready when another person—or you three months later—can reconstruct the result from the assumptions.
Use the plan to define the next decision
The output should lead to an action. You might reduce the initial toolset, delay a yearly purchase until validation, set a usage cap, reuse an existing service, or decide that a three-month experiment is more appropriate than a twelve-month commitment.
Disclosure: I am Junhua Jin, the developer of MarginDeck. I built New Product Planning because I wanted to test cost assumptions without adding hypothetical products and costs to the operating portfolio. MarginDeck can save these plans locally on a Mac, but the same method works in a spreadsheet: preserve the schedule, show the assumptions, and keep an estimate from pretending to be an actual charge.