Everyone loves to complain about how much things cost, and developers are no exception. It's not very common to hear someone say that a developer tool is priced fairly and rare indeed is the developer who will come out and say that a tool is underpriced.
Faced with these attitudes, it can be easy for software vendors to underestimate their worth. They may second-guess the pricing they originally envisioned and cut their costs in the hope that it will draw more developers to their service or platform.
But in many cases, that would be a big mistake. And here's why.
The ever-present pricing worry
Setting prices in the software industry is tricky – much trickier, in fact, than it is in many other industries. If you want to know how much a head of lettuce is worth in the retail market, you can turn to a produce price index. Similarly, you can look up the median cost of housing in different markets easily enough. But there is no price index or national database for logging services, or deployment automation tools or other software that developers consume.
Sure, a software vendor might be able to gain some insight by looking at the pricing of competitors. But that information is not always public or consistent (some software vendors stick to case-by-case pricing models where costs vary widely from one client to the next). And even if it is, it's hard for an outsider to know how well that pricing is actually working. Your competitors may well be just as confused as you are about how much to charge.
Because of this uncertainty, it can be easy for software companies – especially for newer vendors who are just getting started and don't have a lot of hard data yet on adoption or renewal rates for the applications or tools they offer – to race to the bottom when it comes to pricing. They seek to undercut their competition at all costs. Or they are driven by anecdotal complaints about their pricing to slash it, because they mistakenly believe that those complaints represent the opinions of all of their target users.
Cheaper is not better
Cutting prices aggressively is rarely the path to success in the software industry; cheaper is not better. If it were, no one would be paying for Microsoft Windows when they could use Linux instead. For that matter, no one would pay for a Mac when a Windows-based system is typically a lot cheaper.
Striving for the lowest prices above all else is an ineffective strategy for two reasons:
Despite their propensity for complaining about prices being too high, many developers are not actually that price-sensitive about the tools or services they consume. Their budgets are not as tight as they would have you believe.
After all, in an age when even CFOs have heard the mantra “software is eating the world” justifying investment in whichever tools developers feel they need to do their jobs is usually a relatively easy sell. This is especially true when development teams emphasize that the tool or service they want to buy will help them do more with fewer developers – because developer salaries usually cost much more than the tools they use.
So, yes, developers might claim to be worried about the price you charge as a software vendor in the developer ecosystem. But they're probably not actually that worried.
Absent other information, price signals value. Cutting prices risks signaling to customers that your tool or service isn’t worth paying much for. You could make it seem less unique and special. Developers could end up viewing it as they would view any commodity (like corn or oil) – cheap and expendable, and of the same quality regardless of which vendor they get it from.
To put this another way, when the price of software gets so low as to become negligible, developers stop believing it has any real value at all. There is a reason why companies spend huge sums of money on, say, SQL Server when they could get basically the same exact thing by using open-source MySQL. Or why they pay for Red Hat Enterprise Linux when CentOS, which costs nothing, is literally the same code base. Some of it has to do with support, sure. But it also has a lot to do with the simple notion that that which is free must be inferior.
Whether you agree with that notion or not, the reality is that it shapes the way many developers think. When your service becomes too cheap, they assume they may as well not buy it at all.
How to set service prices for developers
At this point, you may be thinking, "So, what should I actually charge, then?"
Obviously, there's no specific answer to that question. Pricing will always vary from one tool to the next.
But what shouldn't vary – at least not for tools designed for long-term adoption and success – is a commitment to making it clear to developer-buyers that whatever price you charge is worth it.
You do this by showing that your service offers value that solves specific problems faced by the developers you are targeting. You also want to demonstrate your service’s ability to remain scalable as users’ needs grow. As an example of demonstrating scalability, consider adding SSO to your tool, which makes it easier to adopt and scale in a large-scale enterprise environment. And you want to enhance and develop the service on an ongoing basis so that your users feel confident that they are buying into a tool whose value will only increase over time.
Once you commoditize, it's very hard to dig your way out of the hole you made for yourself.
In short, some developers will complain all day long about the prices you charge. But they'll do that no matter what your pricing structure is. Some developers even complain when a product is free. Don't let the fear that you've set prices too high get in the way of doing the things that bring true value to your product.
<div class="blog-cta"><h3 class="blog-cta-headline">Build and manage your pricing plans with Manifold</h3><a class="button button-brand" href="/build"><div class="button-text">Check out the Plan Builder</div><img src="//assets.website-files.com/5d5acff74a2e86484bb721fc/5d7bbab3af998bd22c394550_arrow_right.svg" alt="" class="icon"></a></div>