Every workaround has a tax.

The tax is the overhead that the workaround imposes beyond the actual work. It includes: learning the process in the first place, installing and configuring the tools, knowing which steps to do in which order, understanding what correct output looks like, and handling the edge cases that break the standard path. The tax is paid every time the workaround is run, plus a larger fixed cost up front to get it working at all.

For some users — the ones motivated enough and technical enough to build the workaround in the first place — the tax is acceptable. They paid it, they documented it, they can repeat it. But the workaround’s author is rarely representative of the broader population with the same problem. Most people who would benefit from the capability can’t or won’t pay the friction tax. They don’t have the technical background. They don’t have time to learn a ten-step process. They’re not willing to assemble a workflow from components they’ve never used before.

This is the friction tax: the cost that keeps a mechanism from reaching the people who need it.

What the Product Does

A product’s core job is to absorb the friction tax so the user doesn’t have to pay it.

The user doesn’t install anything beyond the product itself. They don’t configure anything beyond their basic preferences. They don’t need to know which underlying tools are being used. They don’t need to understand how the mechanism works — only what inputs it needs and what outputs it produces. When something goes wrong, the product handles it or explains it in terms the user can act on.

All the setup, orchestration, and error handling that the workaround required the user to manage manually — the product manages instead. The user experiences only the output.

This is not a trivial contribution. The friction that workarounds impose is often the dominant cost. In knowledge work, where tools require judgment and configuration, the setup and orchestration overhead can easily dwarf the actual processing time. The analyst who spent fifteen minutes getting an AI to process a data room spent another three hours figuring out how to make that work the first time, and another thirty minutes each subsequent time navigating the setup. The product eliminates the three hours and the thirty minutes. The fifteen stays.

The Friction Tax as Pricing Floor

The friction tax tells you something useful about pricing: it’s the minimum that a product is worth to someone who already knows the workaround exists.

If a user can get the same output by running the workaround themselves in thirty minutes, your product needs to be worth more than thirty minutes of their time. If they’re a professional billing at $200/hour, that’s $100 — but that’s the floor for someone who already knows the workaround. For users who don’t know it, or who can’t execute it, the value is higher: the product gives them access to a capability they effectively don’t have.

This is why professional tooling for narrow domains can charge more than its technical cost might suggest. The alternative isn’t a free tool — it’s a manual process that most users can’t run. The product isn’t competing with a free workaround; it’s competing with “unable to do this at all” for most of its market.

The Expertise Layer

Some workarounds have an additional tax: the expertise required to evaluate whether the output is correct.

A tool that synthesizes documents and produces a structured output requires the user to know whether the output is right. If the user doesn’t have domain expertise, they can’t evaluate the output — they don’t know if the pro forma assumptions are reasonable, whether the red flags are material, whether the checklist is complete. The output is only valuable if the user can apply judgment to it.

This expertise tax is different from friction in a specific way: it can’t be absorbed by the product. The product can’t substitute for the user’s domain judgment. What it can do is make the output evaluable — structured, sourced, and annotated in ways that make the user’s review faster and more reliable.

A product designed for expert users can price for expert users. The price reflects not just the time saved, but the value created when domain expertise is applied to good output. That’s a different and higher number than the time-savings calculation alone.

Finding Your Floor

The friction tax calculation is a useful starting point for pricing:

What does the manual process cost a professional to run, including setup and repetition overhead? That’s the minimum value of absorbing it.

What does the capability cost someone who can’t run the process at all — who either outsources it, skips it, or makes decisions without it? That’s the ceiling for how much value the product can claim, bounded by what the user is willing to pay versus alternatives.

The product is priced somewhere in that range, probably closer to the floor than the ceiling at first, until the product has demonstrated enough reliability that professional trust accrues.

But you start with the friction tax. That’s the number that tells you whether this is worth building at all.