Saying Yes (or No) to Custom Deals: Smarter Choices in Large-Account Sales and Product
Custom deals in large-account sales can make or break a product's trajectory, yet most teams lack a clear framework for deciding which requests to accept. This article draws on insights from experienced sales and product leaders to outline eight practical principles for evaluating custom opportunities. These guidelines help teams protect product integrity while capturing strategic accounts that genuinely align with long-term growth.
Favor Durability After Approvers Depart
We decide based on whether a request makes our operating model stronger or pushes it away from how we work. Large customers can sometimes lead to special requests that are difficult to manage over time. We ask one simple question before making a decision: Will this still make sense after the people who approved the agreement are no longer involved?
One client asked for different usage terms and broader access than our standard approach allowed. We could have agreed because the opportunity was important. Instead, we linked the extra access to regular reviews and clear goals that both sides understood. That shifted the discussion from getting special treatment to sharing responsibility, and it helped us keep the relationship clear and sustainable.
Embrace Problems, Reject Solutions
I run product and engineering for seven products solo, so every custom request has a visible cost in something else not shipping.
The rule: say yes when the request is a sharper version of something already on the roadmap, and no when it's a new axis. Customers are excellent at identifying problems and unreliable at specifying solutions, so I try to accept the problem and decline the implementation.
The question I ask before committing: if three more customers asked for this, would I be pleased or trapped? A request that would be welcome three more times is a product direction. One that would be a burden three more times is a services contract wearing a product costume.
What preserves the relationship is being specific about the trade rather than vague about the timeline. "We can do this in the next cycle if we drop X" is a real conversation. "It's on the roadmap" is the answer that damages trust, because everyone knows what it means.
Pilot Before Long-Term Commitments
The boundary we use is asking whether the custom request would require changing something core to how we deliver for every other client, or whether it can be handled as a one time exception within our existing process. A large client once asked for a dedicated weekly call in addition to their standard reporting cadence, which felt reasonable to agree to quickly, but we tested it as a pilot for one month first rather than committing indefinitely. That test revealed the weekly call mostly repeated information already in the async report, so we restructured it into a shorter biweekly strategic call instead, which satisfied the client's real need for more contact without permanently absorbing the account manager's time. The test before commit approach turned a request that could have quietly become unsustainable into a sustainable version of the same relationship, negotiated from data instead of a guess about what the client actually needed.
Decline Outcome Guarantees
A founder told us he wanted a guaranteed number of term sheets written into the agreement or he would take his budget elsewhere. Founders hire us to reach investors, so requests to reshape an engagement are routine and we bend on most. Pricing, timelines, sector exclusivity for a stretch, extra rounds of deck work. What we will not put on paper is a promised outcome. Which investor replies or writes a check is not ours to control. That clause would just be us charging him for luck. You can price your own hours however you want. The other half of that table is not ours to sell.
He pushed for 2 weeks before we settled on a volume of qualified introductions instead of a result. That engagement has been our steadiest one since. Everything about how we work is negotiable except the promise of a result.
Protect a Simple, Auditable Model
The most reliable boundary is whether the request preserves a clean security and engineering model. When a customer asks for a special feature or contract term, the visible scope is rarely the full scope. The hidden impact lands in testing, change management, documentation, and future assurance conversations. If the request cannot be explained simply to engineering, customer success, and an auditor, it is usually too expensive to carry, even when revenue pressure is high.
I have seen negotiations improve by replacing yes or no with a design standard. One customer wanted a highly specific exception tied to internal governance. The conversation shifted toward principles, verifiable controls, and shared operational expectations, which produced a durable agreement without introducing brittle complexity into the product.
Enforce a Cost-Per-Lead Test
When a large prospect asks for custom features or special terms at Distribute, my first filter is our core unit economics. Because our platform handles autonomous AI cold outreach on a strict pay-as-you-go model, our entire operation is built to keep customer acquisition costs low and predictable. If a request introduces heavy manual oversight—like bespoke campaign strategy or custom reporting structures that don't feed back into the AI—it breaks our model and creates unsustainable operational drag.
The primary boundary I use in these conversations is a strict cost-per-lead test. I look at the request and evaluate whether the custom feature will directly optimize the AI's messaging hooks to drive down that specific client's cost-per-acquisition. If it just serves a subjective preference or tracks a vanity software metric, it doesn't get built.
This boundary recently turned around a tense negotiation with a major client. They wanted to write special terms into the contract that required massive amounts of custom human hours for multi-channel strategy before we even launched their email sequence. I refused the terms, but I mapped out exactly why. I showed them a side-by-side teardown of their pipeline, illustrating how adding those manual strategic layers would immediately inflate the baseline cost-per-lead the AI was supposed to reduce. The conversation instantly shifted from defending our standard terms to strategizing on how to use our existing daily-budget model to maximize their pipeline. Framing a "no" as a rigid protection of their own acquisition costs turned a difficult standoff into a long-term deal without compromising our operations.
Scope, Price, and Support Explicitly
My boundary is whether the request can be priced, documented and supported without becoming a permanent operational exception. A custom request may look profitable at the point of sale but become expensive when it creates repeated manual work, unclear responsibility or future expectations that were never included in the original price.
In construction-related work, I saw how disagreements began when clients assumed an additional item was included while the business treated it as outside the agreed scope. The solution was to put the request into a separate written scope, calculate its real labor and follow-up cost, and state clearly what remained outside the standard service.
If the customer accepts the real cost and the request does not weaken delivery for other customers, it can become a good deal. If it depends on informal promises or permanent workarounds, saying no is usually cheaper than winning the contract.
Route to Specialists, Own the Interface
Route It, Don't Build It
We use a single test when a customer asks for something custom: can this be served by a partner integration instead of building it ourselves?
At Nika Finance, we route perpetuals through Hyperliquid via builder codes and prediction markets through Polymarket. When a customer asked if we could add options trading, the immediate question was not whether options are valuable. They are. The question was whether we should build an options matching engine and settlement layer ourselves, or whether we could route that traffic to a partner who already does it better.
We route it. Every time.
This rule keeps our three-person team focused on what only we can build: the interface, the wallet, the cross-chain plumbing, and the AI layer that lets users express what they want in plain language. Everything else routes to partners who specialize in that specific infrastructure. The result is that we ship five product lines (spot, perps, staking, yield, prediction markets) with a surface area that looks much larger than what three people could build if we tried to own every piece of the stack.
The boundary that makes this negotiation work is clarity about what we own versus what we orchestrate. If the feature request touches the user-facing interface or the connective tissue between products, we build it. If it touches matching engines, settlement layers, oracle infrastructure, or liquidity depth, we route it.
This turned a recent conversation with a customer who wanted derivatives on non-crypto assets into a Polymarket routing decision rather than a six-month build. We shipped it in days by connecting to existing infrastructure instead of months by building from scratch.
The test is simple. If someone else already built the best version of this, route to them and own the interface. If no one built it yet and it is core to how users interact with the product, build it yourself.
