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

MarginDeck 1.1.1 began with a small-looking edit that had a large consequence.

Suppose I record a hosting plan at $20 per month, charged on the 15th. In August, the provider raises the price to $100. If the Cost has only one editable amount, replacing $20 with $100 makes the current record look right—but it can also make January through July look as though the service had always cost $100.

That is not merely a display problem. Historical cost, trends, estimated contribution profit, and spend-to-date can all move when I edit today's plan. A past product review may then tell a different story from the one I actually saw at the time.

Version 1.1.1 changes that model. A recurring Cost can now have a sequence of billing terms, each beginning on a specific expected charge date. The same schedule also gives optional local reminders a clearer source of truth.

One Cost can have more than one set of terms

A Cost still represents one stable obligation: Hosting, Design Tool, AI API, or another expense I want to follow over time.

What changes is the assumption that this obligation must have one permanent amount and schedule. In 1.1.1, a monthly or yearly Cost can keep a Billing Terms Timeline containing stages for:

The interface presents this as Price & Billing History. The internal timeline language is useful for explaining the design, but the practical result is easier to read as a history:

Period Recorded terms
Jan 15–Aug 14 $20 monthly
From Aug 15 $100 monthly

An expected charge before August 15 uses the first stage. An expected charge on or after August 15 uses the second. There should be one applicable stage for each expected occurrence, without two versions of the same Cost appearing on the boundary date.

This is a record of billing details entered by the user. It does not mean MarginDeck has checked a bank, card, or vendor transaction.

A plan change and a record correction are different actions

When I change an amount or schedule, I need to answer one question: did the plan actually change, or am I correcting something that I entered incorrectly?

A plan change creates a new stage. It is the normal choice for a confirmed price increase, price decrease, cadence change, or billing-date change. In MarginDeck, I can start with the next expected charge or choose when the change begins.

A record correction edits an existing stage. It is for cases such as typing $120 instead of $12 or recording the wrong starting date. Because a correction can alter months covered by that stage, MarginDeck treats Correct an Existing Record as an explicit operation rather than the default meaning of Save.

That distinction protects history without making it impossible to repair history. A ledger that can never be corrected is not trustworthy either.

For a more general workflow that also works in a spreadsheet, see How to Change a Subscription Cost Without Rewriting History.

Increases and decreases follow the same rule

There is no special accounting state for “price increase” or “price decrease.” Both are changes in terms with an effective date.

If a cost moves from $20 to $100 on an expected charge date, earlier occurrences remain $20 and later ones use $100. If it moves from $100 to $20, the same boundary applies in the opposite direction.

The difference between the old and new amount is not treated as an extra charge, credit, prorated amount, or refund. MarginDeck does not calculate those adjustments. A separate positive charge can be recorded as a one-time cost. This is not a refund or credit-entry workflow.

This boundary matters because a schedule can describe what I expect without pretending to reconstruct a provider's invoice.

Schedule changes belong in the history too

An amount is only part of a subscription's terms. A provider may also move the billing date or switch a customer between monthly and yearly billing.

If a monthly charge moves from the 5th to the 15th, the new stage needs a new first expected charge date. If a monthly plan becomes yearly, I need to record the first expected annual charge rather than asking the app to infer one from the old monthly pattern.

An amount-only change keeps the existing schedule. A schedule change records a new schedule from the date I select.

Recurring and one-time costs remain separate concepts. Version 1.1.1 does not turn a recurring Cost into a one-time Cost inside the timeline. If an obligation truly changes between those forms, the clearer record is to stop the old Cost and create the new one.

The same caution applies when a stopped service restarts after a gap. Until a complete active-interval history exists, a new Cost avoids erasing the inactive period.

Past, present, and future use the same boundary

Storing stages would not help if every screen interpreted them differently. The more important implementation work was making historical views, Upcoming, product views, trends, estimated contribution profit, recurring burn, and runway resolve the terms that apply to the same expected occurrence.

Upcoming uses the terms effective on each expected charge date, including future changes recorded in advance. Historical months before that boundary do not need to be rebuilt around today's price.

A backdated plan change is also possible when the change really happened earlier but was not recorded at the time. In that case, calculations from the selected effective date can change, while earlier periods remain under the preceding stage.

Cost allocation remains a separate timeline. Changing a subscription price or billing schedule does not silently change which Product received the cost. Billing terms answer “how much and when?” Allocation answers “where does this cost belong?”

Keeping those two histories independent was one of the less visible but more important design constraints in the release.

Optional reminders use the resolved expected charge

Once a Cost has a dated schedule, a reminder can refer to a specific expected occurrence and the terms applicable to it.

Local reminders are off by default. Creating a Cost, launching MarginDeck, or opening Upcoming does not request notification permission. MarginDeck asks for macOS notification permission only after I choose to turn on a reminder for a Cost.

For a monthly Cost, the normal choices are:

Yearly and future one-time costs can also use 30 days before. A newly selected reminder is scheduled for 9:00 a.m. local time on the calculated reminder date.

Each Cost has one reminder preference rather than a different setting for every occurrence. If its amount, cadence, expected date, stop boundary, or reminder lead changes, MarginDeck reconciles pending local reminders against the updated schedule. Turning the reminder off, stopping the Cost, or deleting it removes that Cost's pending requests.

If notification permission is denied, the preference can remain visible while Upcoming and cost calculations continue to work. The reminder feature does not become a condition for using the underlying schedule.

What “local reminder” does and does not mean

I chose the phrase expected charge deliberately.

A reminder is based on the billing information saved in MarginDeck. It is not evidence that a payment was initiated, completed, declined, or even presented by the provider. MarginDeck does not connect to a bank or vendor to confirm the transaction.

The feature also does not discover subscriptions, cancel a provider plan, or send a request to change it. It does not use push notifications, email, or SMS. The notification is scheduled locally through macOS, and operating-system delivery cannot be guaranteed.

That narrower promise is still useful. An expected-charge reminder can create a review point before an annual renewal or a recurring software bill without turning an operating-cost tool into an account-monitoring service.

A practical workflow

For a confirmed subscription change, my intended workflow is:

  1. Open the Cost and choose Change Amount or Schedule.
  2. Choose Start with Next Expected Charge or Choose When the Change Starts.
  3. Enter the new amount, cadence, or expected billing date.
  4. Review the old terms, new terms, effective date, historical impact, and reminder impact.
  5. Save, then check Price & Billing History and Upcoming.
  6. Enable a local reminder only if that review point is useful.

If the earlier record was simply wrong, I use Correct an Existing Record instead and review which period that stage covers before saving.

This separation adds one decision to the edit flow, but it removes a much more dangerous ambiguity: whether editing today's subscription should rewrite yesterday's numbers.

Disclosure: I am Junhua Jin, the developer of MarginDeck. I write these field notes to explain the operating ideas behind the product, including the limitations that shape its design.