Custom work is a tax on customers you have not met

Published September 27, 2026 · 6 min read

The request comes from your best customer, and it is reasonable. They want one extra field on the export, a report in a slightly different shape, a setting that only makes sense for how their team works. They will pay for it. It will take an afternoon. Saying yes feels like service and like revenue at the same time. It is neither, most of the time. It is a small permanent tax you have just agreed to charge every customer who has not found you yet.

Why yes feels free

The cost of custom work is almost entirely hidden at the moment you agree to it. You see the afternoon it takes to build and the goodwill from the customer who asked. You do not see the settings page that now has an option nobody else understands, the edge case your next change has to route around, or the support message six months from now from a different customer who found the option and broke something with it.

The asymmetry is the whole problem. The benefit lands on one account, today, and is visible. The cost is spread across every future customer and every future change, and is invisible. Any decision with that shape will be made badly by default, because the human brain weighs the thing in front of it far more heavily than the thing it cannot see.

What a one-off request actually costs

Build time is the smallest line item. The larger ones arrive later and never send an invoice.

• Every future change has to be tested against the special case, forever, or you break the one customer you were trying to please.
• The product gets harder to explain. Each option added for one account makes onboarding a little heavier for everyone else.
• Support gets harder, because the behaviour of the product now depends on which customer is asking.
• Your roadmap starts being written by whoever asks loudest, which is rarely the same as whoever represents the most customers.
• You cannot remove it later without breaking a promise, so it stays long after the customer who asked for it has left.

None of these is dramatic on its own. Together, repeated a few dozen times, they are how a clean small product turns into something only its founder can operate.

The request is data. The specification is not.

The mistake is not listening to customers. The mistake is confusing what they need with what they described. A customer asking for a custom export usually needs to get data into another tool. A customer asking for a special report usually needs to answer one question their manager keeps asking. The specification is their guess at a solution. The need underneath it is the useful part.

So keep a plain log of requests, written as needs rather than features. When the same need appears from customers who do not know each other, you have found something worth building, and you can build the version that works for all of them instead of the version one of them happened to sketch.

How to say no without losing the account

Most operators avoid saying no because they imagine the customer leaving. In practice customers leave over slow answers and broken promises far more often than over a clear refusal. A no that arrives quickly, explains itself and points somewhere useful is a form of respect.

The shape that works is simple. Name what the product will not do. Offer the closest thing it already does. Tell them honestly where the request stands: on a list you are watching, or genuinely out of scope. And if the need is real but specific to them, offer to solve it outside the product, as separate work, at a separate price, with no change to what everyone else uses.

When custom work is the right call

There are good reasons to say yes, and pretending otherwise is its own kind of dogma. Early on, building one thing by hand for one customer can be the fastest way to understand a problem well enough to productise it. A services engagement can fund a product that is not yet paying for itself. And occasionally a single request turns out to be the feature every customer wanted and nobody else thought to ask for.

The test is whether the custom work stays fenced. If it lives outside the shared product, is priced as its own thing and can be ended cleanly, it is a business decision you can reason about. If it quietly changes the product that everyone uses, it is a tax, and you are collecting it from people who never agreed to pay it.

The portfolio version of this problem

Running several small businesses makes this sharper, not softer. Every special case in one product is attention that cannot go to the others, and attention is the scarcest thing an operator of more than one business has. A product that needs its founder to remember which customer has which exception cannot be handed to a template, a contractor or an automated process. It can only be run by hand.

The discipline that keeps several products runnable is the same one that keeps one product healthy: the product does one thing the same way for everyone, and anything that has to be different for one customer is visibly, deliberately, separately paid for. It feels less generous in the moment. Over any longer stretch it is the more generous choice, because it protects every customer who has not arrived yet.

Common questions