So you are building a software product. Maybe it’s provided as software-as-a-service, maybe it’s run by your customers. Doesn’t matter. There always comes a time, when one of your customers comes to you with a request for a special feature. Let’s explore what are your options for how to deal with this and what to watch out for.
Triage
First, you need to look whether the functionality is not already present in your product or the end result could be achieved by using your product in a different way. If that is the case, you might need to revise your documentation or onboarding procedures.
But let’s assume it’s something that needs to be developed. You or your product team needs to think hard and maybe talk to some of your other customers. Is this thing unique to only one customer? Even if it’s unique, could it be something that other customers might potentially want in the future? If you come to the conclusion you want this in your product, it’s all good. Add it to the backlog and proceed as usual. The end.
More often than not, however, it’s really something special to this customer and cannot be used by anyone else. This is the difficult part.
Counsel
Your next course of action should be trying to talk the customer out of it. I cannot stress this enough, and hopefully after finishing this article, you will understand why. Try to understand what they really need and suggest different approaches. Do not be afraid to recommend a competitor product to them, if you know it exists. They should appreciate your honesty. Make them understand you really do not want the feature in your product and why that is.
Develop
If the above fails, which it often does, next phase begins. And it usually begins with the customer telling you, that they are willing to pay for the development and they will ask you for an estimate. You basically have three options how to approach this, all of them bad. Let’s explore.
Option 1: Build it in
The “easiest” option is you simply cave in and build the feature into your product. Assuming you do not want it there, you will probably hide it for other customers, in order to not clutter the user interface. But it will still be there, possibly forever. That means you will have to maintain it. It will slow you down in the future, as with every new release you will have to test it. It will increase the complexity of your product, make it more difficult to onboard new developers and generally accrue technical debt. Because only one customer is using it, it will take a long time to find all the bugs.
When estimating the cost of this solution, you should calculate all this in. As a general rule of thumb, let your developers estimate the development time and then multiply it by ten. Crazy, eh? But that is not all. This is just direct cost. What about opportunity cost? Your team will be building this feature, instead of working on what you wanted to work on. How much money was that supposed to bring you over time? Hopefully at least five or ten times what you pay your developers. All of this cost should be added to the quote. Is your special customer still willing to pay the price?
Option 2: Fork it
Let’s say you understand that adding the feature would encumber you in the future, as we’ve shown in the first option. The second possibility is to fork the project and built the feature there. Easy enough. You still sacrifice your development capacity and have to pay the opportunity cost. At least, it will not create technical debt. In case it’s a SaaS, it will need it’s own infrastructure and operations. If you have everything automated this should also be relatively easy to accomplish.
I’m sure you are looking for the but. It’s there, don’t worry. By forking, you effectively created a new custom product. That means it will not receive any new features and bug fixes from the main line, unless someone ports the changes over. This costs time and money. If you are not upfront about this with the customer, they will expect you to pay for it. Forever. Therefore, you need to tell them they are getting the product as is now, plus the new feature, but that’s it. If they want features from main or bug fixes, they have to pay for porting them. Again, are they ready for that?
Option 3: Modularize it
Seemingly the most elegant solution is to make your product modular and encapsulate the custom functionality in a custom module. You might even halfway be there already, if you designed your product right. This can either be internal module as part of the software instance (think Wordpress-like) or you can expose your APIs to the customer and let them build it in their environment.
However, unless you were prescient, or damn lucky, during the design, the module boundaries will rarely fit perfectly for the custom use case. The API will probably not provide exactly the methods the customer will need. So there will still be some work to be done and paid for.
Every time you release a new version of your core product, the modules will need to be tested for compatibility. If compatibility breaks, and it will, you’ll engage in endless discussions with the customer, who is to blame and more importantly, who will pay for the required changes to their module or API client. They did not ask for this, so they will be resisting to pay.
The more modules there will be, the worse this will get.
Conclusion
As you might have guessed, I am not a fan of custom development within a standardized product. I understand why clients want it and I somewhat understand why producers allow it. It is very difficult to say no to customers, especially when they are important. When you are a startup with few months of runway, it is tempting to extend it by collecting the paycheck. As I tried to explain here, the check is seldom fat enough to cover the real cost, though.
The saddest part is, the unique feature is often abandoned few months or years down the line, or worse, never used. The fact that no other customer wanted it should have also told you something.
But wait, there is more. If you treat one of your clients this special way, they will expect to be treated like that in the future. Pray that they do not talk about this to your other clients, because that will open a door you do not want open. Politics.
So don’t do it. Unless you really have to. In which case, at least make sure you get paid for it fairly.
Comments