I don't remember doing drugs at the time but I must have been pretty stoned to believe I could get away with that concept.
The fact is that software development is hard work and certainly not free. It takes time, research, buying books/training videos, more research, conferences and travel costs, still more research, and plenty of caffeinated beverages. And that's just to create the product! There are many other costs in order to support and market your software and to run your business.
So if you charge $40 for your software and sell 2,500 copies, you gross $100,000. Sweet, right? But subtract taxes, operation costs, outsource fees for services like graphic artists, web development, credit card processing, and accounting and the picture starts to look a bit less bright. Remember too that you took eight to twelve months to get this software out the door and you weren't making a dime on it during that time period and sales from these 2,500 customers happened over several months, so you might have to divide your net income over 24 months.
After shipping 1.0 you have to change hats and support the software by answering customer emails or forum posts, creating tutorials, and pushing out bug fixes. This all costs money and even if you do everything yourself, your time can't be considered free.
You might even be tempted to price your software lower so you can sell more copies. Don't fall into this trap! The more customers you have, the more your support costs rise. Even the best designed software has bugs and even if you squash all the bugs (you are my hero if you achieve this goal), you will want to add new features or adapt the software to a changing operating system or framework.
Remember that software is never finished—developers just take occasional breaks in coding to ship it.
So how do you cover the rising costs of support and the extended development for major changes to your product? Simple: You charge for updates. Now you can't charge your customers for every single change or your software company will die a very public death with a lynching on your user forum and every blog in existence. The trick is to only charge for the big updates and to space them out well.
On the Mac, software convention states that you version your software with at most three numbers separated by decimal points: major, minor, and patch. This means that 1.4.2 is the second patch on the fourth minor release of the first release of that product.
Here are my rules for numbering:
- Patches are for urgent bug fixes and should always be free. These are supposed to be small and easy to test so you can get them out quickly. New features should only be included if absolutely necessary to fix a feature that went very badly in the last release.
- Minor releases are for features and less urgent bug fixes. It feels wrong to charge for minor releases.
- Major releases are for more dramatic changes to the product and usually are only free to new customers who purchased the previous release within a grace period.
Your schedule may get messed up if you are basing your 2.0 release on new features in OS X and Apple delays its release but overall, you can timeline your software changes and make your customers happy while providing your business with enough income to thrive and continue.
How much should you charge for a major release? I like the 40 percent rule of thumb. If you charge $50 for a product, you can charge about $20 without upsetting your customers. If you have done some amazing updates in software functionality, you can even charge more than that. If you're Apple, you can charge the list price.
That's not a cheap shot at Apple's iWork and iLife suites; I have happily paid for updates to those (not each one, but many of them) because the changes are typically significant and the original price was a bargain compared to products from companies like Microsoft and Adobe. To paraphrase Mel Brooks, "It's good to be a hardware company."
How often do you ship a major release? Every 12 to 18 months is a safe bet. If you do it more often, your customers will feel like you are taking advantage of them and too much longer than that period and you'll probably be running low on cash flow. Remember that you are trying to give your customers significant improvements in your products with a major release so they feel good about paying for that update. This means that you'll have to spend significant time in design and development.
You have to balance your geeky code persona with your public marketing face. Every time you go into a coding phase, you need to think about how this affects your release cycle, which for microISVs is our marketing plan. My marketing plan for MoneyWell has been planned out through the 2.0 release.
When I released MoneyWell 1.0, I had a certain feature set in mind for that product. Naturally, I couldn't fit all those into the first release and I had a deadline to meet so I shipped it without everything in it. I decided at the time that I would charge a discounted introductory price of $39.99 instead of the $49.99 I had planned and would raise the price once the feature set was complete.
Development went slower that I wanted so it took until this month and the 1.4 release to meet my initial spec. Instead of eight months, I burned fourteen. It's not the first time I've been behind on a schedule and won't be the last. The upside to this release was that many customers were shocked by the magnitude of features in it. They couldn't believe that I wasn't charging for this release and calling it 2.0.
I probably could have, but I was sticking to my original plan. MoneyWell 1.4 was designed to work under Tiger and the 2.0 will be Leopard specific—I wanted my Tiger customers to have direct connect banking and several of the other 1.4 features. I'm hoping by the 2.0 release that most of them will have decided to move to Leopard and will be able to enjoy the cool stuff I have planned for that product.
In between the 1.4 and 2.0 releases, I'm developing and shipping MoneyWell Mobile for the iPhone. Since it will sync with the desktop version, there will need to be a MoneyWell 1.5 release. MoneyWell mobile will not be free but the 1.5 minor release will. By the time 2.0 ships, our customer base should be large enough to allow the small upgrade fee to cover the development time and expense that was invested in 2.0.
The bottom line: Plan your releases. Plan to charge for some of them. Plan to spend more time and money on all this than you originally planned, and you'll have a business instead of a non-profit organization. The best way to serve your customers is to stick around as a software company so you can give them what they need. They won't mind paying for great service.
Peace.
