Don't become one customer's private chef.

Every new restaurant gets a regular in the first month who never leaves. They come three nights a week. They bring friends. They tell the owner what they think, and they're usually right. Everyone in the kitchen knows their name.

Then one night they ask if the fish could come without the sauce. Of course. The next week, could it come with the potatoes from the lunch menu? Sure. A month later there's a dish that isn't on the menu at all, prepped every afternoon in case they come in, and the cooks call it by the regular's name.

Give it a year. The specials are built around what the regular likes. One cook spends half his shift on their table. New diners come in, read a menu that hasn't changed in months, and wait on a kitchen that's busy somewhere else. The place is still open. It has just turned into one person's private kitchen with a dining room attached.

Software companies do this with their first big customer, for the same reasons the restaurant did. The customer is good. They pay on time. Their feedback is useful. And early on, they may be most of your revenue.

How the bend happens

Nobody decides to become a private chef. It happens one reasonable yes at a time.

Custom features come first. The big account needs an export in one specific format, an approval step shaped like their org chart, a field that only makes sense in their corner of the industry. Each one is small, and each goes into the main product, because keeping a separate version feels worse.

Then special pricing. They got a deal for being first, another for renewing, and now their contract has terms nobody else has. Your pricing page describes a product they don't buy.

The one to watch is the roadmap slot with their name on it. When planning opens with "what does the big account need next," you've stopped building a product and started running their project.

Every one of these feels like customer focus. It is. Just on one customer.

Meanwhile the cost lands where nobody's looking. Every custom feature has to be tested with every release, explained to every new hire, and kept working when you change the parts around it. The kitchen gets slower for everyone, and the regular never sees the bill.

Watching it happen

I've watched a company do this with one very large customer. It literally started changing itself to fit them. The customer kept asking for more, and each ask was more specific than the last, shaped to their own roadmap. Before long the company's whole roadmap was bending around that one account, and it was building things that didn't fit a wider audience.

The part that stuck with me came from the other direction. Because the customer was so large, the company couldn't require anything of them. It wasn't equipped to ask for the specifics around data and connections that would have made the product better for the whole customer base, and not only for that one account. Every request ran one way. Nobody decided that. It just happened, and it was bad for the product.

That's the quiet cost of a private chef. The regular orders whatever they like, and nobody in the kitchen feels able to ask them for anything back.

One loud voice, or real demand

The skill here is telling a market signal from a single voice that happens to be loud and well funded. One question does most of the work: would three other customers pay for this?

Liking it doesn't count. Everyone likes free features. Would they pay more, switch to you, or stay longer because of it? If you can name three accounts or live prospects who'd say yes, it's probably product. If the only name you can come up with is the one who asked, it's a dish for one table.

Two follow-ups sharpen it. Is the request about their problem, or their particular way of solving it? "We need approvals" may be universal. "We need approvals that match our seven-step sign-off" is theirs. And if they left next year, would you keep it or rip it out?

Ways to say yes without forking

Saying no to your biggest customer is hard, and sometimes it's the wrong answer anyway. The better move is usually a different kind of yes.

Configuration. Build the general version with settings, and make their setup one configuration among many. Approvals with an adjustable number of steps serve them and the next twenty customers. Their seven steps become a setting instead of a branch of your code.

Services. If the work is truly theirs, do it as paid services outside the core product: a custom integration, a report built on your data, a script your team maintains on the side. The kitchen can cook a private dish. It just has to be priced like one, and it stays off the menu.

A paid pilot. For something new and uncertain, agree on a scoped pilot with a fee, a time limit and a decision at the end. Either it goes into the product for everyone or it stops. Writing the ending into the deal keeps a pilot from quietly becoming permanent.

When the bend is worth it

There's a real case for letting one customer shape you. A design partner is a customer you choose on purpose, in a segment you mean to serve, who gets early influence in exchange for time, honest feedback and maybe a reference.

The difference is who sets the terms. Pick a partner who looks like your next fifty customers, which isn't always the one with the biggest budget. Decide up front what they get a say in, and what they give back: the data, access and connections that make the product better for everyone. Then put an end date on the arrangement, so it gets reviewed instead of renewed by habit.

A dish made for one table is a favor. A menu made for one table is a different business.