---
title: "Pricing a backup product honestly"
description: "Four meters, no seats, and one line item that is genuinely hard to price. Here is what each one measures and which of them will actually dominate your bill."
url: "https://saved.sh/blog/pricing-a-backup-product-honestly"
date: "2026-07-29"
author: "saved.sh"
tag: "Pricing"
---

Backup pricing is usually a per-seat number attached to a tier, which is a
strange way to charge for something whose cost to run has nothing to do with how
many people log in.

We meter four things instead, and this post is about what each one is and which
of them you should actually care about.

## The four [#the-four]

<Figure caption="Three meters stop when the run stops. One does not.">
  <MeterTimeline />
</Figure>

**Computation** is time a run spends executing. **Storage** is working space held
while it is in flight. **Transit** is bytes moved, in either direction.
**Archive** is what you are keeping, sampled once a day.

The shape of that drawing is the useful part. Three of the four are bounded by
how long a backup takes. The fourth accrues every day the data sits there, whether
or not anything ran.

<Aside title="So the one that matters is archive">
  Retention, not run frequency, is what dominates almost every bill. Backing up
  hourly instead of daily multiplies three small numbers. Keeping ninety days
  instead of thirty triples the big one.
</Aside>

## What this means if you push from CI [#what-this-means-if-you-push-from-ci]

If you produce backups in your own pipeline and push them, you generate almost no
computation at all: the run happened on your hardware, on your time. Your bill is
archive plus the transit to get the bytes to us.

That is a materially cheaper shape, and we would rather tell you than have you
discover it. It is also the shape we think most people should start with, for
reasons that have nothing to do with the invoice.

## The line item that is genuinely hard [#the-line-item-that-is-genuinely-hard]

Egress is the expensive byte in this business, and it is the one every backup
vendor has to make a decision about. There are three options and none of them are
clean:

* **Charge for restores at cost.** Correct, and it means the worst day of your
  year also generates a bill you did not plan for.
* **Make restores free.** Sounds generous, and it means restore cost is priced
  into everyone's storage, so the customers who never restore subsidise the ones
  who do.
* **Make restores free up to a limit.** Now there is a limit, and limits on
  getting your data back are exactly the thing a backup product should not have.

We charge transit in both directions at one rate. It is not the perfect answer;
it is the one we can explain in a sentence, and it keeps the promise that
matters separate from the price.

<Aside title="The promise, stated separately from the price" tone="accent">
  Getting your data out works in every account state, including one that has run
  out of credit. That is unconditional. The bytes are metered like any other bytes,
  and that is not. Those are two different commitments and blurring them is how
  vendors end up holding data hostage by accident.
</Aside>

## No seats [#no-seats]

Members are capped as a blast-radius limit, not a price. A workspace of one and a
workspace of twenty pay the same for the same usage, because the number of people
who can log in has no relationship to what it costs us to keep your data.

<Stats>
  <Stat value="4" label="Meters, and no fifth line" />

  <Stat value="0" label="Per-seat charges" />

  <Stat value="50" unit="USD" label="Credit on a new workspace, no card" />
</Stats>

## What we will not pretend [#what-we-will-not-pretend]

These rates are measured against our own infrastructure cost, and if that cost
moves they will move. What will not happen is a change applied backwards to a
period you have already used.

Anyone who tells you their backup pricing is final has either been running much
longer than us or has not looked closely at their egress bill.