A Customer Will Pay for a Feature. Should You Build It?

No, you should not automatically build a feature just because a customer offers to pay for it. For an early-stage founder, saying "yes" to custom development can provide a short-term cash infusion, but it risks turning your scalable product company into a bespoke development agency. The decision must be based on whether the requested feature solves a validated problem for your broader market, or if it solely serves the idiosyncratic needs of one dominant customer.

While early revenue is crucial for survival, building one-off features introduces long-term obligations, concentration risk, and significant opportunity cost. To make the right call, you need to separate genuine product discovery from custom software development.

The Trap of Bespoke Development

When a large prospect waves a check in exchange for a specific feature, founders face immense pressure to comply. However, acceding to these requests without rigorous evaluation introduces several hidden costs:

Ongoing Obligations: Every line of code you write must be maintained, updated, and tested against future features. A feature built for one customer becomes a permanent tax on your engineering velocity.
Concentration Risk: If you build heavily for one anchor client, your roadmap becomes captive to their demands. If they churn, you are left with a bloated product that doesn't fit the broader market.
Opportunity Cost: The time your team spends building a custom integration or niche workflow is time they are not spending on your core value proposition.

Before committing, you must evaluate how this request fits into your broader strategy, much like you would when managing MVP scope for a two-person team.

The Feature Evaluation Worksheet

Use the following decision table to evaluate a customer's feature request. Score each criterion as High, Medium, or Low.

Evaluation Criterion	"Yes" Indicator (Build)	"No" Indicator (Decline/Pivot)
Reusable Demand	Multiple prospects have cited this exact need.	Only this specific customer has asked for it.
Strategic Fit	Aligns directly with your core product vision.	Pulls the product into an adjacent, unplanned market.
Maintenance Burden	Low complexity; uses existing architecture.	High complexity; requires new infrastructure or ongoing support.
Opportunity Cost	Replaces a lower-priority roadmap item.	Delays a critical, high-impact feature for the broader market.
Willingness to Pay	Customer will pay a premium that covers long-term maintenance, not just initial dev.	Customer expects standard SaaS pricing after a one-time build fee.

How to Interpret the Results

Mostly "Yes" Indicators: The customer is essentially funding your roadmap. This is excellent product discovery. Proceed with scoping.
Mixed Indicators: The underlying problem is valid, but the customer's proposed solution is too narrow. You need to extract the root problem and design a more generalized solution.
Mostly "No" Indicators: The request is bespoke agency work. Politely decline, or offer to integrate via an API so they can build it themselves.

Hypothetical Scenario: The Custom Integration

Consider a hypothetical scenario: You run a B2B SaaS platform for inventory management. A large enterprise prospect offers a $20,000 upfront contract if you build a direct integration into their proprietary, legacy ERP system.

Applying the worksheet:

Reusable Demand: Low. No other customer uses this specific legacy ERP.
Strategic Fit: Low. Your vision is to integrate with modern, cloud-based accounting tools.
Maintenance Burden: High. Legacy systems often have brittle APIs requiring constant attention.
Opportunity Cost: High. Building this takes your lead engineer offline for four weeks.

In this scenario, despite the $20,000 check, the correct strategic decision is to decline the custom build. The ongoing maintenance and opportunity cost will rapidly eclipse the initial revenue.

Extracting the Root Problem

Customers are experts in their own pain, but they are rarely experts in software design. When a customer asks for a specific feature, treat it as a symptom rather than a prescription.

Instead of asking, "How do you want this to work?" ask:

"What is the business impact of not having this feature today?"
"How are you currently solving this problem manually?"
"If we solved the underlying problem differently than you proposed, would that still be valuable?"

By digging into the root cause, you can often find a generalized solution that satisfies the paying customer while also adding value to your broader user base.

Next Steps

If you decide the feature request aligns with your strategic roadmap and has broad market appeal, your next step is to rigorously define its scope. Do not let the paying customer dictate the technical architecture. Draft a clear Product Requirements Document (PRD) that outlines the problem, the generalized solution, and the specific boundaries of the initial release to protect your engineering bandwidth.