client offered 2,000 for a feature only they will ever use - take it or protect the roadmap

Going to be blunt: take the money and stop agonising. At 30 customers you are not defending a roadmap, you are defending an idea of yourself as a product company.

2,000 is real, the relationship is real, and a customer who pays for work is a customer who stays. The mistake people make is not doing bespoke work, it is doing it for free as a favour, or doing it without saying it is bespoke and then supporting it like a core feature forever.

Charge, deliver, be clear about what it is.

Price it against the true cost, not the build. Bespoke work runs about double whatever you estimate, so call it three weeks, and three weeks of a two-day-a-week schedule is most of a quarter.

Then add the part everyone forgets: you now maintain that code forever. Every refactor, every dependency upgrade, every change to your import pipeline has to keep one customer's adapter alive, and you cannot test it because you do not have their system. That is a tax on every future week, and it is why bespoke features feel cheap the month you build them and expensive two years later.

Either charge enough to cover it - 2,000 plus a maintenance fee, or 2,000 with a clear support boundary - or put an end date in the agreement. I use a sunset clause: supported for twenty four months, after that we revisit.

The test I use: is the request a specific instance of something general I would want anyway.

An import from one obscure system is not a feature. An import framework with a pluggable adapter, of which theirs is the first, absolutely is - and once it exists the second and third adapters cost you a day each instead of three weeks. Every serious integration you ever add rides on it.

So take the 2,000, and build the general thing plus their adapter. They get exactly what they asked for. You get infrastructure someone else paid for. If the request cannot be reframed that way - if it is a bespoke report layout that only makes sense inside their company - then it is consulting work, and you price it as consulting work rather than as product development.

If you decide to decline, the wording matters more than the decision and there is a version that keeps the relationship warm.

What I send: I am not going to build this one, because supporting a connector I cannot test would slow down everything else you already rely on. Here is what I can do instead - the export is documented here, and if your team writes the import on your side I will make sure the format stays stable and give you notice before it ever changes.

That is a no with a working alternative attached, and it puts the effort where the knowledge actually is. Two of the three times I have sent it, they built it themselves in a week and were pleased about it.

Said yes to three of these in my first year and I want to describe the drag rather than tell you not to.

None of them was a disaster individually. Together they meant that by month fourteen I had three code paths that only one account used, a test suite I could not run against real data, and a genuine reluctance to refactor anything near the import layer. Roadmap work slowed by maybe a fifth and I could not point at any single decision as the cause.

My rule now is one bespoke commitment live at a time, written down with a review date, and the next one does not start until the previous one is either generalised into the product or retired. Having a number - one - made saying no to the fourth easy in a way that principles never did.

Take it if it generalises. Charge double if it does not. Never build it for free to keep someone happy - that customer never becomes happier, they become a habit.