Features We Miss in WHMCS: Facebook Pixel, Credit Notes...
Every now and then people ask us if it is possible to purchase only parts of our WHMCS modules instead of the whole software. For each module we can easily say what the X stands for. The table below sums it up.
We think it is now time to publicly explain the reasons why we don't sell parts of our modules.
|Module||Most wanted features|
We could make tens of modules out from Billing Extension, Mercury and Commission Manager. Each of their features could be easily sold as standalone module but we don't do that. For us maintaining many small modules has too many drawbacks:
- Not all modules receive the due attention
- You end up having first and second-class modules that rarely receive updates
- Each module aims at solving one problem only hence new features are a rarity
- Quality varies too much from one module to another
- Delivering updates and fixing bugs takes considerably more time
For a small team like us, keeping up with so many softwares is impractical. We have learned this from experience. That's why today we maintain few big modules. They use the the same framework and receive the due attention. Adding new features and delivering updates is easier. That's how we managed to create such extensive modules for WHMCS.
We completed the transition from many to few modules just few years ago. There's no way we want retrace our steps splitting our 3 modules into tens of smaller pieces. In the next chapters, we are going to be even more honest with you.
We are on a diet. Back in 2014, we had 10 WHMCS modules actively developed. Today we maintain 3 modules. If you ask us where did the other 7 go, in one way or another they merged with Billing Extension, Mercury and Commission Manager.
This was one of toughest and most important decisions we made. Transitioning from many small modules to few big ones, has been a costly and difficult process for three reasons.
First. Every time we merge modules, we lose money. Let's say you had 3 modules that merged into 1. That's good for you. Now your bill is 1/3 of the original cost. Over the years, this happened hundreds of time.
Second. Selling 10 modules is way more profitable than selling just 3. Small and inexpensive softwares are easier to sell. The very fact that they're cheap is a selling point. Moreover they don't require much of documentation and marketing material.
Third. Maintaining big softwares automatically raises the bar. Long story short, we had to create an extensive framework used for all modules. The entire process took 2 years to complete. Half a year for the framework and the rest for modules' refactoring.
As you can imagine, we're not going to throw everything away just because some people want a small slice of a module.
It would be like asking Tesla «I don't need the whole car but just the engine». Meeting this need is not worth the effort. Not only it is impractical but deviates from the main project. We want to keep solving problems by improving our modules. Fragmenting them into multiple parts adds no value.
We understand that our competitors market their products differently. Basically they try to release as many modules as possible aiming to profit maximization. And it works quite successfully. Let us give a quick example.
There's a module that solves one problem and you buy it. Few days later you have another problem and guess what? There's another module to buy. Repeat the process for every problem and need you have et volià! You just spent hundreds of euros to get a lot of small modules.
This is not fiction. Some developers managed to release up to 100 modules. It definitely pays off but it feels a bit weird when you have to purchase multiple modules to solve different facets of the same problem.
Maintaining such an enormous amount of softwares is also impractical. In the long run, we think that top-selling modules gets all of the attention at the expense of less popular picks. Such second-class modules rarely receive updates and don't age well.
We took a different path. Our modules solve hundreds of problems at once. Each of them is specialized in a specific area. As a reference, everything involving billing is integrated in Billing Extension. You don't need to buy anything else. You already own the complete solution.
We're not saying that our strategy is better. It's just that we value productivity more than others. When we have a new idea, we can immediatelly start implementing it in the most appropriate module. We don't need to invest time creating and promoting yet another small software.
If you have read the post were we describe how we increased traffic in WHMCS with SEO, you'd know that we always aim to the long-term scenario over quick wins.
We understand that some people want to take a specific part of a module to get a discount. Let's say you want to get Facebook Pixel that is part of Billing Extension.
The module costs 149 euro and integrates hundreds of features. We didn't count them so let's assume there are 100 features. What should be the price for Facebook Pixel alone? How would you price it?
Some people suggest that the key is determing a price-per-feature. Assuming all features are equal, we could divide 149 euro by 100 features to get a price-per-feature of 1.49 euro. Let's fast forward a year.
There are now 200 features in Billing Extension hence the price-per-feature drops to 0.75 euro. Do you see where I'm going here? What's the point in working harder to see profits lowering as you add more features? This ain't going to work.
The price of a software can't be proportional to the number of features it offers. It would be like asking a discount of 99% to Netflix just because you are intrested in 1% of movies. Ironically the more series and movies they add, the higher is the discount.
In conclusion the number of features can't be the sole basis for determining the price of a product. It should be a big plus when a module offers so many features, not the contrary. There's always something new to try without paying extra money.
It's a free world, anyone can choose to do what they like, including hiring freelancers to re-create features that are already exist in our modules. In this regard, many projects on freelancer.com link to us. Employers direct freelancers to our documentation in the hope that they manage to clone our features.
Most of the times the projects never get finished because the freelancer doesn't have the required skills. We work full time on WHMCS since 2007. That has to count for something, right?
In other cases, the project gets completed in weeks or months. Sometime the employer needs to hire new freelancers as the previous ones have failed at delivering the script. Writing «We're looking for WHMCS experts» doesn't seem to work.
From time to time we receive contact requests from some of these freelancers. They ask us if we can help them at copying our scripts. Or at least explain how we overcome obstacles.
Some even purchase the module in the attempt to reverse-engineer it. Quickly after, they open PayPal disputes asking for refunds. A couple of times they have also offered to split employers' money with us...
The lucky employers that manage to get what they wanted, receive a mere copy of inferior value. No updates and support. They have probably spent half the the price of the module that would have offered hundreds of extra features.
To be honest, as a provider I'd probably just buy the solution that already exists on the market rather than spending days, weeks or months writing my own solution of inferior value. Not to mention problems of working with unknown freelancers. Is it really worth it?