What does "an update" actually mean?

Since I started Frontend Supply, I've been trying to find the right words to explain how the work is structured.

Pricing fixed-scope work is easy. You know what you're building, you scope it, you name a price. Traditional freelance has always worked this way. But ongoing work doesn't have a fixed scope. You can assign anything: new features, fixes, pages from scratch, code review, or even tasks from different codebases. That's the whole point of the model.

When the scope is open, the only honest thing you can sell is capacity. And capacity needs a unit.

When I first launched, that unit was hours. Basic was 2 hours a day, Pro was 3. I thought that was concrete enough. But the questions that came back were completely fair: "Do you stop working once the hours are up?" and "What does the hour count even matter if the pace varies?" They were right. Hours felt arbitrary.

So I switched to "updates." Basic gets 2 updates a week. Pro gets 3. That felt more honest to how I actually work. I think in chunks of deliverable work, not clock time.

But I just had a call with a potential client who said the same thing: "It's still unclear what an update actually means."

Also fair.

Why the word is awkward

Here's the honest problem: "update" isn't a precise unit. Some weeks a client has a queue of small, well-scoped tickets and I ship 5 updates in a single day. Other weeks there's one big, complex piece and that's the whole week. Both are correct uses of the plan.

When I write "2 updates per week" in the pricing section, what I mean by an update is a meaningful chunk of shipped frontend work. Not a small tweak. Not a one-line fix. Something that moves the product forward in a visible way.

I added a tooltip to the pricing section to hint at this. But a tooltip isn't enough to actually show it.

Two real examples

I went back through the git history of a recent project, a greenfield build I did for a client, and mapped exactly how the work broke into updates. This project is a good example because it was built from scratch, which makes the batches clean and easy to trace.

In practice, the work is rarely this tidy. An update can be a mix of multiple parts from different screens or even different apps. That's exactly why it's hard to show a "typical" update. There isn't one. These two examples were the cleanest I could find to actually demonstrate the scope.

Here are two separate outputs from that project, each representing exactly 3 updates (one full week on the Pro plan).

Example 1: AI chat page

A full AI chat interface with multiple screens, a chat section, and Google Maps integration. Fully responsive across all breakpoints.

This is what 3 updates looks like in practice. One week of Pro plan.

Example 2: Groceries domain

A groceries UI with 5 pages, also fully responsive, including all modals and interactive screens.

One more thing

The hours never actually went away.

Internally, I still think of Basic as roughly 2 hours of focused work per day, and Pro as 3 to 4. That's how I separate the plans and manage my time across clients. I work with up to 3 at once, so I need a way to make sure each one gets proper attention.

But that's a capacity management tool, not a hard limit on the work. If a task takes longer, I don't stop. The hours are there to make sure I'm being fair across clients, not to cap what I deliver to any one of them.

So when I say "updates," I mean meaningful output. And when I say Basic or Pro, I mean how much of my day is genuinely dedicated to your product.