Your Next Customer Wants a Custom Feature. Should You Build It?

A prospective customer likes your product. There is one thing they need before they can commit: it has to work a little differently for their business.

The change sounds reasonable. It could help you win the customer, and other companies might eventually want it too. Saying yes seems straightforward.

Then another customer asks for a different version of the same feature. A third needs a connection to their accounting system. Soon, a routine product update comes with a question: which customer's version might this break?

This is a familiar decision for software as a service (SaaS) businesses. Customization can help a product serve more customers. It can also leave the team maintaining several versions of what was supposed to be one application.

When I assess a request like this, I look at what the customer needs, what the product should support, and what the team will still be responsible for after delivery. The work can be worth doing. The important part is agreeing what kind of work it is.

Start with the problem behind the request

Take a product that helps service companies schedule jobs, assign staff and record completed work.

One customer wants its clients to book an available appointment themselves. Another wants a dispatcher to confirm every booking. A third needs completed jobs sent to its accounting system so invoices can be prepared.

These businesses could all use the same product. They need different ways of arranging and finishing the work.

Before estimating a change, I want to understand the reason behind it. If a customer asks for a new screen, I ask what they need to do there. If they ask for an extra step, I ask who needs that step and what happens without it.

"We need a different dashboard" might mean their dispatcher cannot see unassigned jobs. That could be useful to every customer with a dispatch team. It might also mean they need a report with fields that exist only in their business.

Those are different pieces of work, even if the initial request sounds similar.

The question I start with is: what does this customer need to accomplish, and does that belong in the product we are building?

Choose how the request should fit

I find it useful to separate customer requests before discussing implementation.

This helps avoid two expensive habits: building a separate version for every request, and trying to turn every request into a setting.

A customer changing the wording on a booking confirmation is straightforward. A customer changing how jobs are allocated needs more thought. A customer asking the scheduling product to become a payroll system is proposing something much larger.

The table is a starting point for that conversation. A request can involve more than one approach: a reusable scheduling feature might also need an integration and customer-specific setup.

Work out what happens after delivery

The development estimate is only part of the decision.

Suppose a customer pays for the accounting integration. Someone will still need to keep it working when the accounting provider changes how other applications connect to it, the customer's access expires or your product changes how completed jobs are recorded.

The same is true of a custom workflow. It may need attention during future releases even when the customer has not requested anything new.

Before committing, I want the proposal to answer:

• What exactly will be delivered, and how will we confirm it works?
• Will it receive ordinary product updates?
• Who will maintain the integration or customer-specific behavior?
• What support is included, and what would be additional work?
• What happens if the customer later wants to change the process?

A one-time implementation fee should have a defined scope. Ongoing support and improvements can be agreed separately, with clear responsibilities.

There is also a product decision here. If the feature will serve several customers, the team may choose to invest in it as part of the main product. If it serves one customer, the commercial arrangement needs to account for that commitment.

This makes it possible to say yes with a clearer understanding of what the relationship will involve.

Keep one product underneath the differences

For the scheduling example, I would start with the shared journey: create a job, arrange a time, assign someone, complete the work and record the outcome.

Customers can have supported choices within that journey. One can enable self-service booking. Another can require dispatcher confirmation. Either can connect an accounting system.

Those choices need to work together. A customer might need both dispatcher confirmation and an accounting integration; they should not have to choose one to get the other.

The codebase is the source code the team maintains for the application. Keeping one codebase means these customers can continue receiving improvements through a shared product, with their settings selecting the behavior they need.

A separate copy for each customer creates a different commitment. A bug fix, new feature or security update may have to be adapted and checked in several places. Over time, the copies can drift far enough apart that ordinary upgrades become separate projects.

I also look for smaller versions of that problem inside a shared codebase. If the application is full of rules that effectively say "when this customer uses the product, follow a different process," the customer-specific versions still exist. They are just harder to see.

I prefer to give the difference a clear name, such as "dispatcher confirmation," define how it works, and make it a supported capability. The next customer who needs it can use the same capability.

A related lesson from my work at Comoto

On the Internal Multi Agent Platform at Comoto Holdings, I worked on specialist assistants, enterprise integrations and the shared application behind them. My contribution also included application and data support for assistant configuration, alongside collaborative work on administration.

The application served internal employee support. Different specialists had different responsibilities, while shared application behavior supported the overall conversation and operating tools.

That experience is relevant here: some differences deserve their own specialist or integration, while others belong in configuration. Deciding where a difference belongs helps the system remain understandable as it grows.

For a SaaS product, I would apply that thinking to customer requests. Give a meaningful difference a clear place in the product, then make it manageable through the application's supported tools and settings.

Make the settings usable

A configuration option still needs a usable interface.

If a dispatcher must contact a developer every time they want to change a booking window, the feature may be configurable in the code but inconvenient to operate.

The right administrator should be able to see the current choice, understand what a change will affect, and make the changes they are allowed to make. Sensible defaults matter too. Most customers should not have to understand every available option before they can start using the product.

Adding more settings also creates work for the people maintaining it. Each option needs an explanation, supported combinations and a predictable result. A short list of useful choices is easier to support than a settings page that has accumulated every request anyone has made.

Some requests genuinely need custom development. I would scope that work directly rather than hide it inside an increasingly complicated settings system.

Protect the customers already using it

Every new variation joins a product that may already be part of someone else's working day.

For the scheduling application, I want to check that existing customers can still create and complete jobs, that each supported booking mode works, and that a failed accounting connection leaves the job and its delivery status clear.

There are also changes that need an explicit rule. If an administrator changes a booking policy today, should it affect appointments already confirmed for next week? The product needs an answer that users can understand.

Customer settings should also respect access permissions. A customer can choose a supported process, but those choices must not expose another customer's records or grant access someone does not have. I covered the technical side of that separation in Your Tenant Context Outlives the Request.

These checks belong in the work required to deliver the customization. They should be considered when agreeing the scope and delivery plan.

Dedicated hosting can still be the same product

Some customers may need their own running copy of the application, particular hosting locations or a different update schedule.

That can be a valid requirement. A dedicated deployment can run the same product release with supported settings. It does not automatically require a permanently different application.

The extra environment still brings hosting, update and support responsibilities. Those need to be planned and priced. Microsoft's guidance on updating multitenant applications covers questions worth agreeing with customers, including when updates happen, which versions remain supported and how to recover if an update causes problems.

I would make those commitments clear before including dedicated hosting in the offer.

What I would agree before saying yes

For each substantial request, I want a short explanation of the decision:

1. The customer problem we are solving.
2. Whether the answer is a setting, integration, shared feature or separate development.
3. What will change for the customer and what needs checking for existing users.
4. Who will maintain it, how it receives updates and what support is included.
5. How the customer will confirm the work is complete.

If the request does not fit the product, I want to explain why and whether a separate application would serve the business better. If it does fit, I want a plan that lets us deliver it and keep improving the product afterwards.

Custom work can be a good way to grow a SaaS business. The decision is about the customer opportunity and the product you will be maintaining once that work is done.

If you are weighing a customer request against the way your application is built, I can help assess and improve the existing application, define the work and deliver it. Tell me about the product and the change you need.