One Big Customer. One Big Request. Should You Build It?

The demo went well. The buyer likes the product, and your sales team is already talking about a launch date. Then the buyer says, “We’re ready to move forward. We just need one thing.” That one thing is an approval workflow you never planned to build, and they need it before the end of the quarter.

It’s tempting to say yes while everyone is still on the call. A large customer can bring revenue, useful feedback, and a chance to learn how your product holds up in a bigger business. But a feature that sounds small in a demo can occupy your team for months once you include testing, support, and the changes it forces elsewhere. The decision gets easier when you understand the customer’s problem, the value to your product, and what your team would have to postpone.

Ask to See the Work That Happens Today

Customers often describe a feature by explaining how their current system works. If they ask for three approval screens, it may be because three people review a request today. Their real need could be more specific: managers should approve exceptions, and finance should be able to see who signed off. Once you know that, you can explore options that fit how your product already works.

Ask the buyer to walk you through a recent example. Who started the request? Where did it get stuck? What information did the approver need? Then find out what would actually prevent them from using your product on day one. A record of who approved a request might be essential. A report with the same layout as their old system might be something they’re willing to revisit later. You’ll get a better estimate once you know which details matter and why.

Look for a Pattern Across Customers

A request can point to a valuable product improvement even when only one customer asks for it directly. Your support team may already have heard related complaints. Another customer may be solving the same issue with spreadsheets, email threads, or a colleague who checks every request manually. Look for evidence of the underlying problem instead of counting votes for a particular button or screen.

It also matters which customers would benefit. If your SaaS product is moving toward larger teams, an approval feature may fit even if your smaller accounts never use it. On the other hand, a workflow that copies one buyer’s internal structure can be difficult to explain, sell, and support elsewhere. Ask your team how they’d describe the finished feature to a second customer. If that explanation only makes sense after describing the first buyer’s business, you may be looking at custom work.

What you discover	A reasonable next step
Several customers need the same outcome	Consider a shared feature with a focused first release
Existing settings can meet the need	Demonstrate the workflow before promising development
The request depends on a tool the buyer already uses	Check whether an integration can cover the gap
The outcome is valuable but the full request is large	Agree on what must work at launch and what can wait
The rules are unique to one customer	Evaluate it as separately scoped custom work
The request would delay a more important commitment	Explain the tradeoff and offer a realistic alternative

An Illustrative Example: The Three-Level Approval Request

Imagine a SaaS company that helps property managers coordinate maintenance. A prospective enterprise customer asks for three levels of approval on every work order, with separate screens for site staff, regional managers, and finance. The product team could start designing those screens immediately. Instead, they ask to see a few recent jobs, including one that took too long to approve.

It turns out that the delays mostly happen when repairs exceed an authorised spending limit. Routine requests rarely need a regional manager or finance reviewer. The team proposes a smaller release: send requests above an agreed limit to an authorised reviewer, record the decision, and let staff check the status. They ask the buyer to test this against both a routine repair and a costly exception. The buyer can then judge whether the proposed release covers the real need, and the SaaS team can assess whether other property managers would use it.

Engineering note: If you make an approval rule configurable, decide what happens to requests already in progress when someone changes it. A request submitted under one rule should have a clear, predictable path even if an administrator updates the settings before approval.

Count What the Feature Will Cost After Launch

A development estimate tells you how much effort it may take to ship the first version. It doesn’t tell you how much work the feature will create later. A customer-specific rule may need separate testing whenever permissions change. Support staff may need to learn which behaviour applies to which account. If the original customer leaves, your team may still be maintaining their workflow. Those costs should be part of the discussion before you agree to build.

Make the tradeoff concrete by naming the work that would move. If accepting the request pushes back an onboarding improvement, who will feel that delay? Conversely, if the request could help you sell to more teams in your target market, what evidence supports that opportunity? Put both possibilities on the table. A deal can justify changing the roadmap, but it’s easier to make that decision when everyone can see what’s being exchanged.

Give Sales a Useful Answer Before the Next Call

When the customer’s problem is clear but the solution still needs review, give sales a response they can use: “We understand that larger repairs need approval before work begins. We’re checking whether our current workflow can support that, and we’ll show you what’s possible before committing to a date.” That keeps the conversation moving without making a promise engineering hasn’t evaluated.

If you decide to build, write down what the first release will do and how the buyer will tell whether it works. If you decide against it, explain the specific gap and offer a workable option if you have one. A clear answer early gives both sides room to make a decision they can stand behind.

Frequently Asked Questions

Should we charge for a feature requested by one customer?

Separate pricing can make sense when the work requires customer-specific implementation or ongoing support. Decide who will maintain it, what future changes cost, and whether the capability will become part of the shared product.

When is a simple workaround enough?

A workaround can fit when the task is infrequent, the process is reliable, and the customer understands who owns it. Agree on when you’ll revisit it, especially if the team expects usage to grow.

What should we agree on before committing to a delivery date?

Agree on the outcome, what’s included in the first release, the dependencies, and the examples the customer will use to accept it. Then estimate the work against your existing commitments.

If you’re weighing a customer request against your SaaS roadmap, talk it through with SpartanBots Technologies. Bring the workflow the customer wants to change. It’s the most useful place to start.