Building a Bigger Indie

No Thirst Software LLC has hired its third full-time employee: As of November 22, 2010, Danny Greg joins Michael Fey on my development team. Danny is best know for his work at Realmac Software creating Little Snapper. Here at No Thirst, Danny will be joining us in developing MoneyWell 2.0, which will keep us all very busy for the next few months. After that, our team will shift to development of our MoneyWell iPad release. Now you know one reason I've added two developers this year.

It doesn't matter what kind of company you are running, it's always hard to manage growth. The decision to bring on staff is never trivial and should always be done carefully. My previous company, a dot.com in the late 90's, grew quickly to over ten employees and my company before that expanded to a staff of over 30 people. The latter is still around and doing well and the former popped along with the bubble in 2000. I learned a lot from both of these experiences.

The most important lesson was to take my time picking new additions to a team. The actual phrase I was taught was slow to hire, quick to fire. It means that you should really get to know who you are bringing into a company before you extend a job offer and you should let someone go the instant you know they are not working out. That may sound harsh, but if you made a mistake hiring someone, you're hurting your company by keeping that person around. You're also cheating your new hire from finding a job that fits him or her more perfectly. Don't compound one mistake with another. Being in charge means making the tough choices.

If you have a small company with limited resources, a single interview is not enough to make an important decision like this. In fact, I don't think any company—no matter how big its bank account—should treat hiring casually. Before finalizing your decision, you have to find out how this person ticks and what motivates performance. In my case, I need developers who have a passion for the products I am creating. I refuse to micromanage my teammates, so they need to know how to work autonomously. My job is to inspire, not to babysit. I also want people who won't back down from a fight if they think I'm doing it wrong. I learned a long time ago that I am no where near perfect and I make plenty of stupid mistakes. It's best if I surround myself with people who inspire me to continue to learn and grow.

Before hiring both Michael and Danny, I spent time getting to know each of them. Michael was an early MoneyWell customer that also turned out to be a developer. We talked a bit about development during a small sideline project he was coding and then I was able to spend time with him at a developer conference, WWDC '09, and really get to know him. I discovered what motivates him and why he loves creating software. I also watched him as he designed and released a fairly complex iPhone app for his previous employer. In late 2009, Michael was in the middle of a job change and I was able to bring him on board in January of this year.

Danny and I were introduced when he wrote a review of MoneyWell about three years ago. He and I later chatted during a podcast were were both on hosted by Steve "Scotty" Scott, now the producer of iDTV, which later lead to us starting our own podcast called cocoaFusion:. I paid attention to the projects he managed and the products he released and we talked about development outside of our podcast. Danny was never shy about telling me when he thought some code of mine could use improving or if a product was in serious need of better pixel dressing. I actually tried to coax him away from Realmac Software around the time I hired Michael, but the work environment there is fantastic and he could not be swayed. This time, I threw in a healthy dose of guilt with my offer to get him on board.

The bottom line: I knew who I was getting. There was no doubt about intelligence, work ethic, communication skills, or motivation with these two.

I applied this same process when I hired Tamara Crowe as our contract support person. She was a MoneyWell customer who did an amazing job of sharing and helping on our help center discussions. Tamara had better answers than me some of the time and came across as friendly and knowledgable in her posts. I chatted with her several times before offering her a position and knew by that time that I was not making a mistake.

It was a bit harder when I hired Kevin Kalle to do contract design work for us because I didn't have much time to get to know him. He was referred to me by designers I respected and we began by working together on a trial basis. I explained up front that I wanted him to be strong and opinionated and made sure that he was comfortable with some friction in our working relationship.

For me, the give and take is critical. The best solutions come out of a blending of ideas mixed via a friendly struggle. I hire people smarter than me with different skill sets to offset my weaknesses. I never assume that I have all the answers or can see from every perspective and I listen to everyone's opinions. Conversely, my team knows that I have a very definite vision for what this company is creating and I won't compromise that vision. They also understand that the final decisions need to be mine.

I'm incredibly excited about the team I've assembled and can't wait to show everyone what we are creating. As great as 2010 was for my little indie group, 2011 is going to be even better.

Peace.

P.S.: Stay tuned for my follow-up posts where I'll discuss the financial and logistic concerns of adding employees.

Mac App Store Mania

It's only been a few days since Apple announced the Mac App Store and there are already predictions of rampant software piracy, Apple locking down future version of OS X to only App Store sales, and price drops to 99 cents. Let's calm down and take a step back people.

First of all, pirates will be pirates and if they want to crack your software, they will. Apple's copy protection will be broken just like every other system out there. This does not mean that your sales will drop. The honest truth is that the dishonest people using pirated software wouldn't be your customers anyway. I've lost track of how many illegal download sites display MoneyWell as one of their offerings, but I also don't lose sleep over this problem.

As to Apple shutting down all sales outside the Mac App Store, can we give them time to get it up and running before we start blaming them for something they haven't done yet? I'm willing to give Apple the benefit of the doubt on this one.

Now on to the topic that is a huge issue for me: discount pricing. I can't stand the dollar store pricing on the iOS App Store and it shows because MoneyWell is at the $9.99 price point even though many of its competitors are lower. I think it's worth even more than 10 bucks and the price is more likely go up instead of down as we add features down the road. Our Mac version currently sells for $49.99 and that price will go up when we ship our 2.0 release in early 2011. I'm also not planning to lower it when we start selling on the Mac App Store.

Why? Because our software is worth the price I charge. I also owe it to my customer base to make sure my company is well-funded and continues to provide excellent software and support in the future. The profit curve is not negatively affected by higher prices until you are significantly out of the range of your competition—and by competition, I mean software that matches your software in quality. I've seen too many companies go out of business because they try to compete on price.

I truly believe that the Mac App Store is going to increase sales for every quality Mac product on the market, but we don't know by how much. Assuming that you can cut your price in half because your volume will increase by a factor of five or ten is insane. High volume sales are never guaranteed and you may need the cash reserves you make from an initial sales spike for long term development projects or an onslaught of support.

Just because software is made up of electronic bits doesn't mean that it has any less value than computer hardware or or other electronics. There's an argument that computers have gone down in price and software should do the same, but companies like Apple aren't making less money on each computer sold. In fact, most of the time they work to increase their margins as manufacturing costs drop. Apple doesn't have $51 billion in the bank because they cut their profits in half.

There's an opposing argument which states we can charge a fair price for software because we provide lasting value. What do you pay for lunch or dinner? How about that trip to Starbucks? What's your ROI for that meal or latte and how long does that "value" stay with you? Think about that for a minute. Got a visual? Good.

If I invest in a software tool, I expect it to hang around for more than a day or two and to continue to get a return on my investment of 12-18 months before spending more money on it. Will I pay $20, $40 or $60 for software I use several times a week throughout this timeframe? Definitely. It has real value. I don't buy many games, so most of the software I invest in is either saving me time, improving my communications, or making me money. If I'm using it constantly, I want to use the highest quality software I can get. It should be well-crafted, rarely crash and never lose my data. I'm happy to pay for quality. Building excellent software is hard work and we deserve to get paid for our efforts.

Let's stick to our guns and price our software fairly so we can prosper and continue to give great service to our customers. Let's earn some profits and invest in training to improve our coding and business skills. Let's build some company bank accounts so we can afford to expand our indie companies beyond simple solo acts. Who knows—if we stop tripping over each other to get to the bargain basement—we actually may end up with several hundred more indie developers who can afford to quit their day jobs.

Peace.

If Not You, Then Who?

Running an indie software company is an emotional roller coaster. Some days the code is flowing like water out of a fire hose and you're breaking sales records while other days are filled with blank stares at a debugger and a strange fear that your website must be broken because no one's buying your software. It can be a struggle to keep pushing forward in the face of bugs and support requests. You work your butt off to produce a product update only to be met with jeers and complaints, "You wrecked my software! It's slow/crashing/ugly now" or, "You gave us features a, b and c but I asked for f and g almost two years ago. Why can't you finish your software?"

Okay, it's not like that very often, but if you're like me, a hundred compliments are negated by one complaint. If you're not like me, be happy you dodged a bullet.

MoneyWell is an especially tricky product when it comes to making people happy. Personal finance software is very… personal. Everyone has their own way of managing their finances and no single tool will satisfy every need. I built MoneyWell for one person: me. There were certain needs I had that weren't being met by my current tool, Quicken, and no other software I tested was idiot-proof enough to help me control my spending. So like a good programmer, I wrote my own. When designing the feature set, I did consider if others would like certain abilities, but in the end I based all my decisions on what worked best for me. That may sound selfish, but I've been in companies where software was designed by committees and frankly, it always sucked.

When releasing version 1.0 of a product, flaws and missing features are often forgiven, "It's a one-dot-oh release, I'm sure it will get better." But as your customer base grows and your product matures, the slings and arrows come at a faster pace and hit closer to vital organs. You might start to doubt your vision or struggle to hear your internal voice over the din of the crowd. You might start to doubt your ability to succeed based on what you have planned or fall prey to feeling overwhelmed.

I've ridden the roller coaster plenty of times over the past four years. There were times when I wondered if my design was correct or if I even knew what the hell I was doing. I'm no financial genius so who am I to tell others how to run their books?

What struck me recently and inspired me to keep on the path was a simple question: if not you, then who? Are there any software products out today that I would use instead of my own? No, there are not. And why not? Why do I still like my finance software better than anything else?

There are millions of software developers in the world and many are better or smarter coders than me, but none are me. None of them have had the same financial failures I have had or experienced the same exact frustrations. No single person has gone through all the same life trials as I have. I'm the only one who has lived my life and that makes me unique. My blend of skills and experiences gives me an edge for the software I'm passionate about.

I'll never write the next great word processor because I don't have a burning desire to build it. I've struggled with debt and blown budgets, not page formatting issues. My software comes from my history. It is better because I care about it and how it can improve my life. My greatest desire is that what I create can also help millions of others as well.

You too have a history that gives you a unique perspective on a need. Your life experiences have molded you to see things that others would overlook. What could you contribute to a software design? What do you desire in a product? What are you passionate about?

In other words, don't build what others have envisioned—create from within yourself. Your design process will be much more enjoyable and the final product will scream "you." This will mean that you'll have to endure complaints and say "no" more than you like to enhancement requests, but you will love your work because it feels organic. And even if it doesn't make you rich, it might make you happy.

Here are the rules in summary:

1. Seek knowledge from others, but make decisions from within — don't let the noise drown out your thoughts
2. Ignore the naysayers — haters are gonna hate and there's nothing you can do about it
3. Believe in yourself — trust that what you have to give to the world is unique and worthwhile
4. Put passion before a paycheck — doing work you love trumps more money any day of the week and twice on Sunday

Every so often, I get lost and let the one or two negatives swallow up all the good creation happening in my life. It's easy to feel discouraged because your software is in use by hundreds instead of thousands or thousands instead of millions. It's easy to feel overwhelmed because you don't have the time to see your vision in full bloom. It's easy to give up and let someone else deal with creating the solution, but don't do it. You'll be cheating the world out of an experience only you can provide.

Peace.

Indie Multitasking

As much as we'd like to think that we are capable of multitasking, we are truly more like an iPad than an iMac. We may have a dozen or more things we have in our queue to do at the moment, but we can only focus on one task at a time. To multitask and actually get two tasks done at once, you need to be two people.

For an indie software company, this means taking a large step and hiring someone—either contract or full time.

This is by no means a trivial decision, but eventually one that has to be addressed. At some point the long days and late nights start to affect the quality of your work or destroy your personal life. And whether you believe it or not, sleep is critical to your health.

Adding staff is hard for several reasons:

• It costs money


• It requires trust and flexibility


• It requires management


• It requires collaboration tools and processes

Let's take a look at each of these a little more.

Cash Flow

As an indie developer, you probably aren't rolling in extra cash that you can just flash and get more staff. You have to be careful about raising your monthly burn rate. The flip side is that you may be hurting cash flow by doing tech support or marketing when you should be writing code and shipping for-fee updates—I consider myself somewhat of an expert in this type of mistake.

Be smart and take baby steps. Instead of hiring a full-time person, you can pay hourly for contract labor. Last year I contracted with Matt Long to help me with MoneyWell for iPhone development, and recently I hired Ash Ponders, who bills me for the hours he logs keeping our support queue well maintained.

The nice part about contract labor is that you can throttle your spending more with them than you could a salaried employee.

Trust and Flexibility

After I contracted with Matt, I began to think that the amount of code that needed to get written at No Thirst Software was much more than I could do in a timely manner and too expensive as contract work. There was a huge potential for revenue from an iPhone release and a paid upgrade for a 2.0 version of MoneyWell but the overhead of running this company was cutting into my coding time and my schedules were slipping badly. If I had a full-time developer besides myself, I could ship these new releases sooner, which would be a huge win for both the company and our customers.

I've hired developers many times before in my previous companies and I knew the pitfalls. Hiring a skilled developer is important, but even more important is hiring someone you trust and can work with. I've hired prima donnas that code well but are impossible to work with and nice guys that really can't produce the code needed—neither hire is good.

I like to hire developers that I've already spent time with and have learned about how they code and think. That meant my list of potential employees was very short. To shorten my list even more: all of them had good jobs already and didn't have a strong desire to jump ship.

The stars aligned for me and one of them became available at the perfect time. I hired Michael Fey (a/k/a the infamous MrRooni who started a rumor about spotting Steve Jobs at WWDC 2009) as my first full-time employee in January 2010.

Check this out: I first knew Michael as an early MoneyWell customer who was generous and helped out by answering questions on our support forum. I later found out he was a Mac developer and then was lucky enough to spend some time with him at WWDC and really get to know him. This is one more reason why you need to socialize and network. You never know if you are going to meet a future employee or employer. Needless to say, I'm thrilled to have someone who knows our products, is a skilled developer and is joy to work with on a daily basis.

Now, this is where the flexibility comes into play. When you bring in someone else to do the work you once did in your isolated "me" universe, you'll find that they'll do the same tasks a bit differently that you did. If you can't deal with that fact, you can't have employees and you can't ever expand your company. You have to be flexible and accept that your way isn't the only way to get something done. I've learned something from everyone I've ever worked with—without exception.

Managing People and Resources

The minute you add any person or service to your operation, you become a manager. It's your job to steer the ship and control the future of your company. This doesn't mean that you have all the answers, it just means you have to make the final decision. With employees comes payroll. With contract work comes more payables and tax paperwork. There is overhead to even adding one person.

There's also mentoring and training. If you fail to properly mentor your new hire in the company processes or train your support technician in your software, you can't expect that person to perform well. This is your primary job as a leader. and ignoring it is like planting a garden but failing to feed and water the plants. All your initial effort will wither on the vine.

Tools and Processes

Before you expand beyond a one-body shop, you have to invest some time in collaborative tools and processes. For an indie software company, the three biggies are support, bug/feature tracking and source code management.

Email-only support systems are incredibly hard to maintain with more than one person. Did that email get answered? Was there a response? Who's checking for new emails? Has this customer had similar issues before?

We use Tender to manage our support because it gives us a way to coordinate and assign support. It also suggests Knowledge Base answers when customers post questions so some customer get immediate, automatic support. It also has custom queues that notify specific people in our company when help is needed. This way, our frontline person can get emails for all support issues and the rest of us only see what has been escalated. Additionally, the discussions can be public—the customer can choose to make it private—so other customers tend to jump in and help. I'll take all the help I can get and often, our customers know better answers than we do because they have personal experience with the question.

For bug/feature tracking, we chose Lighthouse, which happens to work well with Tender because ENTP makes and runs both. What I needed most in issue tracking was a quick way to create requests when customers report bugs or asked for features. Because Lighthouse and Tender integrate perfectly, creating a ticket in Lighthouse requires only a couple of clicks upon reading the Tender discussion post.

There are many different needs for both these tasks and you may need a more intense issue tracking system. I like to avoid complexity as much as possible and that was a driving force in my choices.

Picking a source control management system is like choosing an operating system or development framework. You're not going to convince a .NET guy that Cocoa is better any more than you can tell someone who loves Mercurial that Bazaar is better. It really doesn't matter what you choose, but pick a distributed system that has a cloud presence. I used Subversion, then switched to Bazaar and finally ended up with Git.

The primary reason for going with git was Github. I had to collaborate with other developers and they were already using Github so I was flexible and adapted. Once I learned the (sometimes weird) ways of git, I was productive and happy. Moreover, my team was able to work together easily. I needed four developers in three different parts of the country to work out of the same repository and Github made that happen.

Galactic Headquarters

The Galactic Headquarters of No Thirst Software LLC are in my home office located in The Woodlands, Texas. My full-time developer is near Syracuse, New York, contract work is done from yet another state, graphic design is coming from Europe and Ash is doing support from who know's where on the planet. I have to admit to a bit of envy towards my globe trotting support ninja.

My point is that the days of renting office space and hiring employees locally so that they can show up to work in a central location are long gone. It makes no sense financially and only offers a slight collaborative advantage over Skype and video conferencing. When you pick tools or decide on processes, make sure you think global.

We have office chatter over Twitter, share documents on Dropbox, manage projects on Lighthouse, review support issues on Tender, share source code on Github and hold meetings on Skype or iChat—our work day revolves around information stored on or shared over the internet. I've never run a company this efficiently with such a small amount of overhead. It's a great time to grow your operation and expand beyond yourself.

Peace.

The Computer for the Rest of Them

If you're a software developer, designer, or a high-tech computer user—Apple doesn't care about you.

Oh sure, Apple wants you to write, design and create software and products for the Mac, but you are not the target audience for the iPad. I've read so much negative backlash about Apple's latest device and all I can think is, "These guys just don't get it."

As software developers, we thrive on complexity. We have dozens of applications lit up in our Docks. As I'm writing this, I have 20 applications running, each with one or more windows open in four virtual workspaces using Spaces.

I'm a geek. I love this stuff. I even know all the keyboard shortcuts for switching apps and spaces and windows. I am a software developer with an engineer's brain. I am not the person Apple was thinking about when they built the iPad.

So who did they build it for?

The rest of them.

Have you ever watched someone who is not a geek use a computer? I have. My father-in-law lives with us and I'm his support tech, so I get an up close and personal view of the anti-geek at work. Here's a typical session for him:

• He clicks on Mail to look at his email;


• He reads a few emails and closes the window with the red dot in the upper left corner;


• Then he clicks on Safari and looks at some websites in one window;


• when he's done, he closes that window with a click in the upper left corner.

He doesn't quit any application. As many times as I've told him that he can simply hold down the Command key and press 'Q' to quit, he clicks the red dot. He doesn't try to multitask, he doesn't understand overlapping windows, and he gets very confused when he moves a window by accident and it doesn't show up well on his screen.

When I showed him the video of the iPad though, he said, "I'd love one of those. It looks so much easier for me to use. My sister could even use one of those."

For my father-in-law and millions of other people, clicking to run an application on the iPad, pressing the Home button to leave it so another application can be run is perfect. Millions of people spend all their time focused on one app. They read email, or browse the web, or live in Facebook, and the iPad gives them exactly what they need to do those tasks. The fast new Apple A4 chip inside makes changing from one task to another quick enough that there is no need for multitasking—especially with people whose eyes glaze over when you start explaining the concept behind running multiple applications.

The fact is: Real people don't try to multitask, so they don't see the iPad lacking this ability.

Personally, I love the idea of the iPad because I do all my RSS feed reading on my iPhone. When I take a break from writing software and working on my computer, I find a comfy place to sit and read on my iPhone. If I can grab my iPad instead, I'll save eyestrain and my iPhone battery while improving my casual time. For me, it's a no-brainer. I want one.

Is the iPad perfect? Nope. I think it needs front-facing video at least, but I do agree with John Brownlee that Apple probably left this out because it would make you look fat. This is the first generation of a new type of computing—the computer for the rest of them. Expect amazing growth in this space over the next couple of years.

Peace.

Indie+Relief: Mac Indie Developers Helping Haiti

I love the Mac developer community for many reasons and Indie+Relief is just one more example of how great it is.

Much thanks to Justin Williams and Garrett Murray for making this happen and to the 150 or so indie developers that are participating. You all rock!

No Thirst Software is participating as well, so tell everyone you know to hold off and buy software tomorrow, Jan. 20, 2010, if they were thinking about doing it anyway and help heal Haiti.

If you don't want software, but still want to help the Haitian people who are suffering from so much death and destruction, you can find a reputable charity by using Charity Navigator.

Peace