Growing Pains

I believe the two hardest periods of a new company are when you first start it and when you grow beyond being able to handle every task yourself.

When you give birth to a new business, you have to work hard to save pennies and handle as much of the operations yourself to survive financially. This is good because you get to design every part of your new venture and structure it to be mean and lean.

For a software start-up, this usually means automating as much as possible. As sales grew with No Thirst Software, I went from hand generating license files with AquaticPrime to PHP scripts that generated and emailed those type of files to a full database back end that simply emailed license codes and sent the license files directly to our software when it pinged the server.

This was easy automation to do because I'm a programmer; I write code and this was just code on a web server talking to code in my Mac software. No big deal.

Other roles are harder to automate. I have a CPA to file my tax paperwork and do the heavy lifting in accounting, but I still have to maintain the books, track expenses, and fill out paperwork (and I hate paperwork). The bookkeeping automation really needs a person, which means hiring and management duties. It's not as comfortable a task as adding some PHP scripts. I'd love to have my wife, Judy, jump in here and tackle this role but she's pulling in a steady paycheck with health insurance benefits for the family so that's a tough call. Are we ready to completely depend on our little company for all our financial needs?

Another time sink is support. I love doing support because it helps me understand how our customers use our products and I find ways to improve them. MoneyWell would never have grown as fast as it has in the direction it has without me doing tech support. I have been toying with the idea of delegating some of this to a part-time person for a while but it was incredibly hard for me to let go for several reasons.

Fear and Workflow

The first was a concern that our support quality would drop. I worked hard to create a reputation for outstanding support and I didn't want that to get lost.

The second concern was my time to train a support person. Handing off support is great if the person taking it can answer the questions asked. Delegation without education is like asking my CPA to finish my Objective-C code—both crazy and stupid.

The third concern was workflow. My workflow was impossible to scale up past two people and even then not really effective. I used IMAP services to file emails into various folders for resolved issues, those needing action, and those needing to be fixed via code changes.

This workflow issue was the biggest of the concerns by far. If I couldn't automate the workflow more, I couldn't hand off support. In the past when I had a larger company with a few dozen employees, I wrote my own customer service system. I liked it because I had control over it and could improve it whenever we needed new functionality. Today, I have plenty of software to write that could be making me money so the thought of spending my time writing an internal app was out.

I looked at other products I had used in the past but they didn't fit my desired flow. I also looked at FogBugz, but the design felt too complicated and alien to the simple design of both MoneyWell and Debt Quencher. I really tried to like it but I knew that I'd never adopt it.

Then I started to use Lighthouse to track my bugs and features because there was a cool OS X front end for it, Lighthouse Keeper. Even without Martin Pilkington's desktop interface, Lighthouse was really nice to use. It didn't have every feature, but what it did have was implemented nicely.

I found out that Active Reload/ENTP was creating a customer support system to match up with Lighthouse. It was still in beta so I held off riding this bleeding edge of technology and pushed the task of delegating support onto the back burner.

The Wakeup Call

My wakeup call came in two parts. First I was asked to include MoneyWell in the MacUpdate MUPromo Spring 2009 Bundle. About 43,500 bundles later, I learned a lot about how well my sales and licensing automation was built and how little code I was writing when handling a minor avalanche of support. Halfway through this bundle, I left for San Francisco to attend Apple's World Wide Developer Conference (WWDC)¹ where I fully woke up.

It was in a talk given by Wil Shipley at an overcrowded Cocoaheads meeting held at the SF Apple Store. Even as Wil talked about not doing support as a developer, I resisted. In my head I kept saying, "I need to stay connected to my customers. This has helped me improve my software." He finished and I pretty much had blown him off. Then later that evening I started thinking about all the code that I was not writing and how I was cheating my customers of new versions. I wasn't as worried about my competition as I was about not shipping the very best products because I was devoting my developer skills to support instead of new code. Late that night, I pulled up the Tender Support website and signed up.

Letting Go

While at WWDC, I talked to Judy about hiring a support technician. We tossed around a few ideas and I resolved to make sure it happened once I got back home. Four days after I landed at Houston Intercontinental Airport, I had a support person—my son Patch. He had worked with me before redesigning the No Thirst Software website so I knew what he could do when he put his mind to something, but I wasn't going to push him into the business if he wanted to go a different direction. Thankfully, Judy had discussed this option with him while I was away and he came to me asking if he could help.

This made sharing the support role easier. It wasn't going far, just to another room in our house, and I could pull Patch into my office to give him training whenever necessary. If he hadn't stepped up, I would have advertised on our company user forum and this blog for a person to fill the role. After Patch, my preference would have been a MoneyWell user that didn't need training on the operation of our flagship product.

Tender Support

It's only been a week of working with Tender and a few days of having it live for our customers to use, but I'm thrilled with it. The discussion forum is much more structured than our old Google Groups forum—we can mark issues as open or resolved, assign priority queues to issues, and, best of all, support emails go to the forum so they can't get lost in a cluttered inbox. It's not as large and in charge as FogBugz, but that's part of its appeal. We're even more committed to offering timely and effective support as our customer base continues to grow, and Tender will help us stay on top of our game. My next blog post will talk more about this customer support tool and why it fits No Thirst Software so well.




1. If you're a developer on the Mac or iPhone and you haven't attended WWDC yet, put it on your calendar for 2010 and start saving money now.

Sharpening the Saw

As a Mac ISV, I'm fairly isolated here in The Woodlands, Texas. That's why I love it when I get a chance to get out and meet with other developers and small business owners to discuss ideas and sharpen my skills.

Last year was my first time to attend Apple's WWDC and it won't be my last. There was plenty of learning to be had from the speakers at the conference but I gained just as much knowledge, if not more, from other developers who I met there. The fellowship was worth the price of attendance alone and the connections I made are still reaping rewards.

One conference that I'd love to go to but just don't have the time and budget for right now is the NSConference run by Steve "Scotty" Scott of The Mac Developer Network fame.



The speaker list is great and there are so many developers that are going to be there that I'd love to hang with. Unfortunately, I don't think I could sneak away to Europe again without taking my wife (I've been there several times and she hasn't at all). I think my daughter would have a throw down fit too so the budget wouldn't be just the inexpensive conference and lodging costs plus a bit of airfare but instead, it would turn into a family vacation with all the requisite tourist activities—more than I care to spend right now.

But if you are in Europe or can invest a little time and money on travel, plan on attending this conference. Then you can come back and leave comments here about all the cool stuff I missed and make me very, very jealous.

Peace.

Giving Back by Podcasting

The Mac developer community is amazing. So many developers share ideas, advice, and even code that I felt immediately indebted to do this myself after being helped by so many of them.

Unfortunately, it's hard to share advice when you're not sure if you have any but after a couple years of coding Objective-C, the OS X language of choice, and Cocoa, the OS X development framework, I'm excited to become more like those generous code warriors.

With a lot of help from a very bright, young Mac developer, Danny Greg, my contribution to the community is a developer podcast that has just gone live. Check out cocoaFusion: and let us know what you think.

The goal is not for us to come across as "experts" in the field of Cocoa development but instead to share our struggles with this framework and solutions we've found. Hopefully, this will be a good start to giving back to the community that has given so much to us.

Peace.

P.S.: I also have to give huge props to Scotty (a.k.a., Steve Scott) at the Mac Developer Network for introducing me to Danny and for creating such enjoyable podcasts that I wanted to follow in his footsteps. If you're a Mac developer and you're not signed up for MDN your a) insane, and b) missing out on a wealth of knowledge in a very entertaining format.

Free or fee?

It's impossible to survive in the software business without charging for updates. Early on in my career I remember thinking, "We'll have so many customers that we can offer free updates and support for life!"

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:

1. 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.


2. Minor releases are for features and less urgent bug fixes. It feels wrong to charge for minor releases.


3. 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.

Version numbers are not pure science; they are really for marketing. Developers have build numbers for tracking the absolute order of code changes so we don't need the version for code management. Since the versioning is for the public then, why not plan your development based on a marketing timeline. Version 1.0 will be released in January 2009 with three or four minor releases to follow and a 2.0 release in July 2010. And you can charge for version 2.0.

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.

Let's Talk About Marketing

If you're interested in marketing at the microISV level or just like listening to geeks trying to sound professional while talking over Skype, check out the latest installment of The Mac Developer Network Year One podcast hosted by Keith Alperin of Helium Foot Software:

Mac Software Business Year One Episode 3: Marketing

In addition to Keith, Steve "Scotty" Scott and Gus Mueller return for this third installment to discuss their marketing efforts and related microISV wisdom. Of course, I'm in the mix too (probably talking too much) but don't let that stop you from checking it out.

Also while you're there, make sure to join the The Mac Developer Network and support all the wonderful content that Scotty and his crew collect and produce for the Mac developer community. It's great stuff!

Peace.

Fighting the Fear

I have a confession: I'm afraid.

After all my bold statements that the only true failure is quitting and doing nothing, I'm a bit paralyzed by fear trying to ship MoneyWell 1.4. There's the fear that I didn't do enough to make this an amazing release. Fear that the known issues are deal breakers and will cause negative reviews. Fear that there is an unknown issue that will turn out to be a huge bug and cause major support issues.

Insidious fear. Fear that causes my world to feel cold and dark.

Of course this is crazy thinking but because my brain is dealing with it, I have to do something about that. My wife's suggestion was to blog about it, and since she's usually right about these things, here I go.

I do know that the best way to eliminate fear is to expose it to light—fear hates the bright light of truth.

FEAR: I didn't do enough in this release.

FACT: The feedback from beta testers is that 1.4 has so many enhancements and additions that they can't believe this is a free minor upgrade instead of a 2.0 release with an upgrade fee.

FEAR: Known issues (a.k.a. bugs) will be everyone's focus and cause negative reviews.

FACT: Yes, there are a couple of features that I wish worked better, but there are too many great new additions to let these problems stop this release from happening. If these problems keep 10 percent of the customer base from using a feature but 90 percent still benefit, then why shouldn't I ship and help the majority? The truth is, there isn't a good reason.

FEAR: An unknown bug is going to be big enough to hurt customers, cause mass complaints and refund requests, and bring down the company with it.

FACT: Every software product has bugs and historically I have fixed the bugs in our products very quickly with patches. The reason MoneyWell is built with an automatic update service is so customers get the latest and greatest release as soon as it's published. Plus, version 1.4 has had the longest beta cycle of any product release and has had over 200 beta testers actively using it—the most we've ever had!

Being afraid is natural. Letting fear dictate what I do or don't do is just plain nuts. Writing about it makes me wonder why I even gave fear this much time and energy when I have so much productive work to complete.

That said, there are some new toolbar icons being designed by a talented graphic artist to replace my amateur hack job and lots of documentation to finish. It's no longer fear keeping me from pushing the button. Once these two tasks are done, so is MoneyWell 1.4. Glancing out the window, I just noticed it's a beautiful, sunny day. Life's looking pretty good right now.

Peace.

Where'd You Go?

No, I didn't die and I'm not in a coma, per se. I'm trying to finish MoneyWell 1.4 and ship it.

This has been a very difficult release because I started the beta process very early. There was a method to my madness though: I wanted people testing the new direct connect downloads from financial institutions, so I added that feature first and published a beta.

Our beta testers, therefore, have had to put up with several "alpha" cycles of MoneyWell that normally aren't pushed to the public. Normally when I develop software, I try to put all the features in it before beta so that everyone knows what the final release looks like and they are just waiting for the reported bugs to be fixed. This has not been a normal beta test.

If you're a developer and you want to get really sick of looking at your software, just try testing it for over three months straight. I rarely even run the 1.3 release so I've forgotten how much has changed in the new version. I keep thinking, "Did I actually do anything in this release?" Glancing down the new feature list helps me realize that I have and that this will be a very good version of MoneyWell.

I've also been blessed to have a great group of beta testers. Not only is it the biggest I've ever managed (over 200 people have tested 1.4), but they have been very quick with bug reports and have given me great detailed steps and sample data files. If this were a movie, someone would be standing right now starting that slow clap for the MoneyWell beta team while everyone else stood to join in.

I will do a proper blog post after this release is out and try to avoid another coding coma. It will be hard though since I'm already working on the iPhone version of MoneyWell and that will most likely consume my time through the end of the year. And we have lots of video tutorials and web site enhancements planned. And then of course coding will start on MoneyWell 2.0. And there's also…

Let's just say, I don't foresee any boredom in my near future.

Peace.