When Your Biggest Customer Wants a Custom Feature

The email is flattering and the request is reasonable. Your largest account, the one paying meaningfully more than anyone else, needs one thing your product does not do. They are not threatening to leave. They are asking nicely. It would take you a week.

The trap is that this decision looks like a product question and is actually a concentration question. Answer it in the wrong order and you will spend the next two years maintaining someone else's roadmap.

Do the arithmetic before you do the feature

Two numbers decide most of this, and neither is the feature's build time.

Number one: what share of revenue is this account? If they are 8 percent of revenue, this is a normal prioritisation call. If they are 40 percent, you are not running a product company with a large customer, you are running a services business with a brand. That is a viable business, but it should be a decision rather than a drift.

Number two: what does the feature cost over three years, not one week? Build time is the smallest component. The real figure includes:

A one-week build is rarely a one-week commitment. Two weeks of engineering is a fair planning estimate for a "small" custom feature, and the recurring drag is the part that actually hurts, because it taxes everything you build afterwards.

Run those two numbers first. They usually make the answer obvious.

The only question that matters about the feature itself

Not "can we build it" and not "will they pay for it." The question is:

Would a customer who has never heard of this account also want it?

That single test sorts almost every request into one of three buckets, and each has a different correct response.

Bucket one: generally useful, they just asked first

Most requests land here more often than founders expect. A large customer hits a limitation earlier because they use the product harder, not because they are unusual. Their request is your roadmap arriving early with a funded reason to build it.

Build it as a normal feature. Ship it to everyone. Tell the customer they got it first, which is true and is worth something to them. Do not take custom money for it, because taking custom money creates an expectation of custom treatment on a feature that was always going in.

If you want to control the rollout, feature flags let you give them early access without forking anything. That is the cheapest version of "yes" available and it should be your default.

Bucket two: genuinely specific to them

Their compliance regime, their legacy system, their internal process. Nobody else will ever want it. This is real work with no product leverage.

Three honest options:

1. Build it and charge properly. Not at your hourly rate. At a price that reflects perpetual maintenance: a build fee plus an ongoing increment to their subscription, explicitly framed as maintenance. If they will not pay the ongoing part, that tells you what the feature is worth to them.

2. Build it as an extension point rather than a feature. A webhook, an API endpoint, a scriptable hook. You ship general capability, they build their specific thing on it, and you maintain a stable surface instead of their business logic. This is the answer that most often makes everyone happy, and it is underused. Adding a public API and webhooks turn a custom request into a general one.

3. Say no, with an alternative. Recommend an integration, a workaround, or an implementation partner.

Option two is the one to reach for first. It converts a liability into a product.

Bucket three: it would make the product worse for everyone else

Rarer, and the most important to catch. Some requests are not additions but reversals: a default your other customers rely on, a simplification you deliberately chose, a constraint that is the actual product.

Say no clearly and early. A soft no here is worse than a hard one, because it produces six weeks of hopeful follow-ups and then the same answer with more damage. Explaining the reasoning honestly, and what you will do instead, retains far more accounts than people fear. Telling a client their idea will not work is the same conversation in a services context.

How to price the yes

If you land in bucket two and decide to build, price it in two parts. Founders routinely charge for the first and forget the second.

• A build fee covering the work, at a rate that reflects it being custom rather than roadmap work.

• A maintenance increment, a permanent addition to their subscription, in exchange for you continuing to carry the feature.

The second part does the real work. It makes the ongoing cost visible to both sides, gives you revenue that scales with the burden, and creates a natural conversation later if the feature stops being worth it to them. Without it, you have sold a one-time product with a permanent cost, which is the structural error underneath most of these situations. Related reasoning in pricing an AI feature you add to an existing product and handling scope creep.

Put a review date in the contract. Twelve months, at which point you both look at whether it is still needed. Features are much easier to remove when removal was always scheduled.

The concentration problem underneath

If this request feels impossible to refuse, that feeling is the real finding. It means one account has enough leverage that your product decisions are not fully yours.

That is worth addressing directly, and not by saying no to this feature. It is addressed by making the next twelve months about reducing the concentration: more accounts in that segment, ideally with similar needs, so the next request from them arrives as a segment signal rather than a demand.

Reframed that way, a large customer with unusual requirements becomes useful market research. If you can find nine more companies with their problem, bucket two turns into bucket one and the custom feature becomes a product line. If you cannot find nine, you have learned something important about the segment, and you should price accordingly.

The general version of this trap, and how to structure work so it does not recur, is in scoping a productized service so it does not become custom work. The wider revenue picture is in AI monetization strategies.

FAQ

Should I build a custom feature for my biggest customer? Build it as a general feature if any other customer would plausibly want it. If it is genuinely specific to them, prefer an extension point such as an API or webhook, and charge both a build fee and a permanent maintenance increment if you build it directly.

What if they threaten to leave? Then you have a concentration problem, not a feature problem. Handle the immediate request on its merits, and treat the leverage as the thing to fix over the following year by diversifying the account base.

How much should I charge for custom work? A build fee reflecting custom rather than roadmap work, plus an ongoing subscription increment for maintenance. The ongoing part is what most founders omit and what most determines whether the deal is good in year three.

Is it ever right to just say no? Yes, particularly when the request would degrade the product for other customers. Say it early and clearly, with a specific alternative. A slow no costs more goodwill than a fast one.

What if I cannot tell which bucket it falls into? Ask five other customers whether they would use it. Their answers cost you a week and settle the question better than any internal debate.