Why you shouldn't let customers pay for features
madewithlove
We help SaaS companies & VCs. How? With software development, technical leadership, due diligence, or coaching.
What's good for the business isn't always good for the product. And vice versa.
Rushing out features might be good for sales but will harm quality in the long run. And spending weeks improving quality has an opportunity cost that will hurt sales. Building a software product is walking a tightrope.
One of the clearest examples of this is building bespoke features for customers. From a sales perspective, it's a great opportunity to increase cash flow and bind customers. From a product viewpoint, it's a source of complexity and distraction.
Building bespoke features for customers is a double-edged sword for an early startup.
The typical example is an integration with a customer's intranet application.
We like your handy calendar SaaS, but could you make sure it syncs with our MyAcmeCalendar SharePoint app? We'll pay for it!
When wooing new customers, especially large ones, there is a temptation to make some quick cash. Startups are often eager to build a feature that doesn't really match their vision but would help smooth over sales. In a lot of cases, potential customers would love to pay you to develop that feature. That's a win-win, right?
The problem isn't building a feature that gets used by only a subset of users. That's common and we have the tools to handle that. The problem is the changing relationship with your customers.
As a SaaS vendor, you sell access to your product. For a fixed monthly fee, your customers get access to an ever-improving set of features that solve expensive problems for them. While SaaS pricing can be steep, it's a steal compared to building it yourself. That's the business model: you sell access to the best-in-class solution for your customer's problem.
But by allowing your customers to pay for a bespoke solution, you become an IT vendor to them. Not only do you have to build the integration, but you also have to maintain it– even if MyAcmeCalendar has breaking API changes. But on top of that, you've set a precedent. You've shown them that they are the experts, not you. The customer now feels like they can request features and that you will build it to spec.
That change in relationship is a lot more expensive than the few thousand euros they're paying you to develop!
The way to circumvent this problem is to build the feature at your own expense. You can try to generalize it so it appeals to more customers. You could even charge your customer a monthly surcharge for this "add-on" module. But you shouldn't let them pay a lump sum to develop it.
Accepting a transactional payment for a feature changes the relationship with your customer. While it might feel like a win-win in the short run, it puts you in a weaker position going forward.