Fulfilling a Dream

The year was 1984 and the new computer that was rumored finally arrived at my local Apple reseller. I had drooled over the Lisa for months, but knew that its $10,000 price tag was way out of reach for my newlywed budget. Lisa’s newly announced little brother had some promise; I could buy it if there was a way to score an Apple credit card. After some begging for a co-signer, the 128K Mac was mine.

Fast forward to a year later and I was in Houston in Apple training learning how to sell Excel on the Mac. I pulled the sales trainer aside and inquired about how I’d get a job at Apple and were there any local developer opportunities. He politely said no and I wasn’t brave enough to try for a California move after having left Buffalo, NY just three months earlier, so I tucked my dream away for later.

Then three kids and several moderately successful startups later, I assumed that dream was dead and I would continue in my role as an indie developer and create apps for the devices I enjoy using.

But recently, everything changed. A sad passing of my wife’s dad, who lived with us for several years, gave us an opportunity to start the process of readying our home for sale so we could downsize. Our kids are all in their twenties and were moving towards more independence (even though much of it was precipitated by arm-twisting from their parents). That meant that Judy and I had options that we haven’t had in decades.

An email contact from an Apple recruiter kicked off a journey that I though I’d never take: Interviewing for a position at the tech company that I’ve loved since I first touched a computer.

I’m thrilled to announce that I have accepted a position and am now an Apple employee. These are exciting times for me and my family and I’m looking forward to growing and learning from all the brilliant people at Apple.

I’ll make sure that MoneyWell and Debt Quencher have a good home and will continue to improve and have a bright future—I rely on MoneyWell for my own budgeting and banking and don’t want it to go away either. While the transition is in progress, those two products will be sold and supported as they always have. There will be more details about that in a future post.

For now, I’m living the dream and life is good (a bit crazy at the moment, but very good).


Apple’s Swift New World

As a developer who makes his living off of creating software for Apple devices, any announcement that Apple makes can dramatically affect my future. At WWDC 2014, Apple’s annual developer conference, my universe was rocked harder than I can remember.

This year’s announcements empowered developers by giving us more access to important hardware, like Touch ID, and the ability to communicate with other apps. Just these two enhancements alone will allow me to create solutions for my customers that I could never have imagined way back in May.

Add to these the thousands of new ways I can improve my apps by targeting the forthcoming iOS 8 and Yosemite releases and it was a banner WWDC for those of use that write apps. The real winners will be the people consuming the new and improved apps I and other developers will be writing. Apple deserves a huge round of applause for their multi-year development efforts that went into this event.

A Swift Future

But that wasn’t the end of the story, Apple also announced a new programming language called Swift.

I was expecting Apple to replace Objective-C, the current blessed language for all App Store app development, but I thought that change was still three years or more in the future. Shocked is too tame a word for my response to hearing this… I needed help to pry my jaw off the floor.

Now I’ve been writing software since the early 80’s and have used dozens of different languages on hundreds of combinations of hardware and operating systems over the years and I can tell you that great software is about the person writing it more than the platform or language used. That said, Swift is a game changer for several reasons with the top three being:

  1. Swift is a safe, modern language. This means it removes software failures caused by accessing memory that can lead to security problems and crashes.
  2. Swift complains early about coding mistakes. Having a compiler tell me that something is amiss is far better than a customer shouting at me my app has screwed up. The faster I can spot mistakes, the faster I can correct them.
  3. Swift has playgrounds. Much like when I started with computers1 that booted up to an interpretive language console, playgrounds allow me to sit down, type some code, and get immediate feedback. I can test new concepts quickly and noodle on possible solutions without building an app. Playgrounds are also an amazing educational tool and will be an enormous asset for teaching new developers how to write code.

Overall, Swift will allow me to create stable apps more quickly for my customers. I win, they win, and frankly, Apple wins. It’s good all around.

The Great Debate

With every new tool, framework, or language comes much debate amongst developers (we love to argue about the silliest things) and Swift is no different. I don’t think it’s such a hard decision about sticking with Objective-C and when to start using Swift:

  • If you are working on existing apps written in Objective-C with short release cycles, don’t mess with success—keep writing in Objective-C.
  • If you are adding new functionality to an existing app and will be releasing it on a more relaxed schedule, I’d write new views and logic in Swift to get myself ramped up with the new language—but for the love of Pete, don’t go nuts and rewrite all the code.
  • If you are creating a new app, write it in Swift. It’s the future. Seriously, don’t kid yourself thinking that Apple is on the fence about which language will survive long term. Swift has the lock on that prize.

Another part of the debate is about which language is harder to learn. Frankly, programming is hard and languages are just something to adjust to for that task. I’ve forgotten more programming languages than most new developers will ever learn, so I’m happy to learn another if I can get my apps shipping faster.

Swift can get complex, as will any powerful coding language, but overall I believe it beats Objective-C in approachability. At my core, I’ve been a C programmer and have used some variation of C more than any other language. I’ve grown accustomed to include files, declaration duplication, semicolons, and pointers. These are not things that developers should have to deal with today and Swift eliminates much of what seems pointless to a new developer who has not been marinating in a K & R2 doctrine for decades. Read the Swift manual and experiment with playgrounds. You’ll start to see why this language has such potential to free us from working around C syntax restrictions.

Is Swift perfect? Nope.

Can you write bad code in Swift? Yep.

It’s just a programming language, so let’s not get all religious about it. Remember that Swift is a 1.0 release of a brand new tool that we can look forward to evolving with for years to come. It’s a chance to reboot our brains and come up with even more creative solutions without much of the baggage that we’ve been dragging around for years.

This old dog is learning some new tricks and I am fired up about the future of app development. I hope everyone focuses on the positives and we can all grow together. Now you’ll have to excuse me; I have Swift code to write.


  1. Yes, we had fire and the wheel back then.
  2. “The C Programming Language by Kernighan and Richie”

In-App Purchase – The Future is Here

Back in March 2013, I wrote The Future of Software Pricing, which talked about the disturbing trend of bargain basement software prices on the App Stores and ways to combat the problem. At the time, we had released MoneyWell Express to test out the in-app purchase (IAP) waters and our results were positive. Since MoneyWell Express is a companion app to our Mac version, I was cautious about our conversion percentages because existing customers are more likely to buy the IAP.

The real test has just begun. We recently released MoneyWell for iPad, which is also a free app with an IAP, but this app can stand on its own and can be sold to customers who have never used MoneyWell and might use an iPad as their primary computer.

I believe that IAP is a powerful tool that allows us to raise the ceiling on our app pricing. Unfortunately, the primary apps using IAP are games and the publishers have abused the power of IAP. If I could download a game and use IAP to unlock levels, that would be fine. I’m thrilled when I can try a game for free and then pay to unlock more advanced levels. What drives me crazy are the games that bombard me with ads to buy consumables—even to get through the first few levels. Having to constantly dismiss prompts for purchases takes away from the game play and I have deleted these abusive games without paying a dime. Obviously, I’m not the norm because the top-grossing apps in the App Store are these same games. People are paying hundreds of dollars over the lifetime of a game, but they still balk at a $20 upfront purchase.

In a way, I don’t blame people for not wanting to risk their money. The limited information a prospective customer has prior to a purchase is one of the problems with Apple’s App Store. People are supposed to fork over money for apps, but only get to see five screenshots and a few paragraphs of text before making a decision—that just doesn’t cut it. My goal with IAP is to allow potential customers to try all the core features of MoneyWell, which allows them to make an informed purchase. If you can download transactions, create a budget, and review your spending activity for free, you will know if our personal finance techniques fit they way you do your banking and budgeting.

Deciding which limits to put in an app to be unlocked with IAP is a tricky process. I didn’t want people to feel like we were extorting money out of them so they could continue to use the app. Instead, the limit we put on MoneyWell has to do with the number of active bank accounts: The free version allows only one bank account and our “Unlimited Accounts” IAP unlocks the ability to use as many accounts as you’d like. This means that you can install MoneyWell for free, use it completely with one account and decide that it’s a quality app for your needs.

This IAP design also gives us the ability to deliver a free app to those customers who only have a single account. You don’t need to pay anything at all to use MoneyWell because there are no other limits. You also won’t get hit with ads to purchase Unlimited Accounts. The only indication that you have any restriction comes when you add more than one account. The accounts list shows a passive “Locked” badge instead of the account balance and if you tap one of those locked accounts, you are then told there is an IAP to unlock them. If you are a person who only needs one account, you’ll never have a clue that you need to pay us anything.

Yes, we will lose some money, but I think it’s a worthwhile tradeoff. There is no barrier to try our app and the free download opens us up to a much wider audience. The risk of earning no money is small because people who only have a single bank account are the minority and most likely will add other accounts in the future. When they do, they are more likely to pay for our IAP than to switch apps.

Marco Arment’s Underscore Price Dynamics post points out how skewed the general public is about software pricing. His article discusses that any upfront app cost can be a huge barrier to a purchase. Many software companies choose to charge $5 or less for their apps to reduce this obstacle. As I’ve stated before, unless you have hundreds of thousands of customers, you can’t run a software company on a $2, $5, or even a $10 app. It’s time consuming and expensive to create and support great apps, and I’d really like to see software companies take a stand and charge a price that’s fair to both them and their customers.

MoneyWell for Mac is a $50 app, which is a lower price than what some of our competition charge. Our target with the development of MoneyWell for iPad was to produce an app on par with, or better than, our Mac app. In my mind, a full-featured finance app is worth the same price no matter what platform it’s on. MoneyWell for iPad is lacking a few features when compared to its sibling on the Mac, so our price point for it is $40.

MoneyWell for iPad - IAP Conversion Rates

It’s early to talk about conversion rates—ten days just isn’t a large sample—but I think this will be worthwhile to reflect back upon in six months or so. This chart is also skewed because our current marketing is primarily to existing customers. We’ll expand our marketing to a wider audience in the next few weeks, which will most likely drop the percentage as more people try MoneyWell that have had no experience with it before. Still, I think the chart above is worth a look. Overall, we are seeing a 25 percent conversion rate. That’s a fantastic number that I don’t expect to see a year from now, but wouldn’t mind at all if we were anywhere near close to it.

We’ve already had some pushback on the $40 price point, but that was expected. Our initial 50 percent off sale is ending September 30 and that may also cause our conversion rate to drop. I’ll keep tracking our progress and reporting it here on my blog. I truly believe that IAP is the future and if I’m wrong, it will be a very public failure. Stay tuned.


All the Apps Have Been Written

“All the marketable software has already been written.”

That sounds like a true enough statement. How am I going to make any money writing software when all the app ideas have been taken and the established software companies are already controlling the market? What software can I write that will allow me to earn a living?

Of course I said this in 1982 when I was mainly doing contract development on Apple ][, CP/M, and the newly popular PC-DOS machines. There were multiple word processor, spreadsheet, and database apps already in the marketplace. People rarely bought a computer for fun; they had to completely justify the expense.

I had convinced myself that I couldn’t make enough money in the shrink-wrapped software1 market because there weren’t enough customers to go around. I was doomed to contract development for the rest of my life. If only I had started a couple of years earlier before all the good software had been created.

Looking back, I see just how foolish I was. I let my own fear cloud my vision. There was plenty of room for new app ideas and the existing apps weren’t that perfect that they couldn’t be replaced. At the time, dBase was the most popular database tool and I made a decent living writing apps in it. The truth is that it was a limited piece of crap and I had written my own database tool with my trusty Aztec C compiler that was better in many ways. I just didn’t think I could sell it. I was only one guy and wouldn’t even own my own computer until the Mac came out in 1984.

There couldn’t have been more than 100 popular apps back in the early ’80s. Sure, distribution was much more difficult then, but I didn’t back off because of that. My fear was based on rejection. What if I spent time writing a program—a common term before “apps” was coined—that no one bought? Could my frail ego take it? And what about the wasted time? I needed to earn real money and be a responsible adult.

I want to take a time machine back to when I was 20 and Gibbs-slap2 myself… hard.

Fast forward to today and I hear similar comments from other developers. They see app stores with hundreds of thousands of apps and toss up their hands. It can be hard to look past the numbers. It’s also easy for an app to drown in the growing flood that is the Apple App Store.

Ignore all that. Ignore fear. Ignore the odds. Ignore the naysayers. Find your passion.

What does passion have to do with success? Everything. The most successful people in history were deeply passionate. They were divisive, flawed, and left a trail of failures in their wakes, but their passion kept them moving forward.

I wrote some advice in an interview with App Camp For Girls recently, “Find something in your life that is broken and write software to fix it.” The best software is personal. It’s something you need. It heals a wound in your life and makes you happy.

When you are doing client work, you are (hopefully) driven by a desire to deliver the best product you can for that person or company. Your reputation is on the line and you want referrals and repeat work.

When you are writing an app as an indie, you don’t have that same motivation. As a software developer, riches and fame are in no way guaranteed. Your motivation has to come from within because external motivations fade too easily. When you are struggling with a complex pattern or bug, knowing that the effort it takes to find a solution might make money several months in the future is horribly weak incentive. It won’t drive you to pull an all-nighter or push through days of feeling like an idiot.

I wish I had gotten paid for feeling like an idiot. I could so retire right now.

But if it’s personal—if you are curing an ill of your own—then your motivation breeds internally. Making money becomes a secondary motivator. When I started No Thirst Software in 2006, I began with Debt Quencher—a snowball credit card debt reduction app. Why? Because I had debt that totaled nearly $80,000 and the developer that wrote the app I was using disappeared along with his app.

It was very personal. I was in pain and I knew others had to be as well. I couldn’t be the only guy with a Mac trying to find a solution to eliminate my credit debt.

After shipping Debt Quencher, I asked myself what other software would I like to have—what software was causing me pain? Quicken. First, I tried to replace it with apps already available for the Mac, but none fit my needs. They all were annoying to use in one way or another. Additionally, most of them managed budgets in the same way—the way that contributed to me to become tens of thousands of dollars in debt. I didn’t love any of them.

I hated how Quicken didn’t let me select multiple transactions to adjust them. It annoyed me no end that I couldn’t tell how much I had left to spend without running a report. The available apps either cluttered my screen with dozens of windows or limited functionality. I knew I could do better. So I designed MoneyWell to fix all those irritations from other apps.

After my research, I was sure that I wasn’t the only person unhappy with the state of personal finance packages on the Mac. How many others were in the same pain as I was? If I can cure this pain my life, maybe I can help them as well.

It took ten months to design, acquire funding, and ship the 1.0 release. In those months, there were dozens of episodes where I felt too stupid and lacking the Cocoa skills I needed to get MoneyWell completed. I’m sure my wife was exhausted in her roles as cheerleader and therapist. It’s a damn good thing that I made this personal.

These apps became as much an extension of me as my own children. They were being created to improve my financial future. I wanted a cure for my agony and because I wasn’t just doing this for a paycheck, I would push past every wall that appeared before me. I was a on a mission.

In the seven years since this journey began, I’ve had to fight against some incredible odds. Technology doesn’t stand still, which meant going back and redesigning and rewriting my apps. I’ve made plenty of mistakes during those years and have had to humble myself so many times that I’m surprised I am left any ego at all. My biggest motivator was my relationship with my apps. Because they have been an integral part of my life, I was able to continue to work on their code. If my only motivation was external, I probably would have given up long ago.

As it is, I haven’t and my apps have changed my financial future—directly by my own use of them and indirectly by thousands of others buying them. And I’ve only scratched the surface. There are half a dozen related pains still in my life that I know I can cure and I’m dying to work on those apps, too.

What ails you? What apps do you use today that piss you off? What apps are incomplete or missing from your favorite device (mine being my iPad)? Make a list. Pick the most personal ones and load up Xcode. Trust me, there are thousands of apps that haven’t been written yet.

Developer, heal thyself.


  1. Before app stores, having your software boxed, shrink-wrapped, and sold on computer store shelves was the best way to make a living
  2. Fans of NCIS get it

Focus on Your Product, Not History

History isn’t written in the present.

While we are in the middle of change or struggling with adversity, we can’t always see the upside of the situation or an eventual positive outcome. All we can do is give our best effort, push forward, and leave the documentation to the historians.

Reading Marco Arment’s accounting of the Tumblr story, I can relate to how easy it is to second-guess decisions and have doubts about the future while in the middle of product development and funding issues. What stood out for me in that story was the intense focus of David Karp, the founder. He knew what was most important and made sure that other concerns didn’t get in the way. His focus was on his product.

As tech companies go, Tumblr already has a decent saga for historians to write.

Who would have guessed that Apple would be the most important tech company in the world from the perspective of 1997. It took the return of Steve Jobs—one of the most focused individuals to ever start a company—to resurrect the flailing corporation. Writing the story of Apple during their “doomed” years1 would have been a complete waste of time.

Every lengthy development cycle stresses individuals in a company. That’s because most of the feedback is in the form of bug reports and design criticisms. It takes a strong point of view to keep a product on track and push it out the door. It takes ignoring the premature writing of history and focusing on what’s important right now.

My team is in the process of developing MoneyWell for iPad. We just finished minor updates for our Mac and iPhone releases and those were incredibly difficult for me. Not because the development was tricky, but because I had to ignore requests for changes to those apps and focus on what we needed for our iPad version. It required saying “no” to customers and to myself over and over again.

It’s tempting for me to try and fix everything, especially when in my head I can see where our products will be in 12 to 18 months. It’s ego busting to field criticism for flaws that I know exist and know will be eliminated—later. I can’t defend my decisions today, but instead have to take the punches, apologize, and ask for a bit more patience.

I have to leave it for historians to decide if I was focused enough to produce excellent software. Time will tell if the choices I make today were poor, mediocre, or amazing. There’s no time for me to beat myself up for past mistakes, I have to give 100 percent of my energy and effort to my team and my customers through my product design today.

Living in the past opens me up to drowning in self-pity and time spent projecting any possible future is mental folly. I can only change what I’m doing right now. I can only make decisions for my next action. I can choose to see this as limiting or liberating.

Today I choose to be liberated and continue to improve our company and our products.


  1. Yes, I know that Apple will forever be “doomed” for some tech writers

Five Sure-Fire Ways to Sabotage a Release

In March of 2012, I gave a talk at NSConference 4 and lifted my kilt and invited attendees to learn how not to go about shipping a software product. Luckily for them I was wearing pants and what I lifted was a virtual kilt, but it was still a disturbing presentation.

I may or may not have made them stare at “Baby Hoctor”1 for an extreme amount of time.


My goal in airing my dirty laundry was to prevent other developers and entrepreneurs from making the same mistakes that I made. In case you missed NSConference and haven’t seen the videos2, here is a synopsis of that talk.

#1 Announce Features Early

Back in 2008, our customers were comparing MoneyWell to Quicken and asking for investment support. Not wanting to disappoint anyone, I innocently said, “Sorry, investments won’t be supported until 2.0.”

Boom. I talked about a product release that I hadn’t even started planning and I didn’t stop there. I talked about dozens of future features and didn’t even say they’d have to wait for a major release. At the time, it seemed innocent enough. Customers were asking questions and I was answering them to the best of my ability. I truly believed that I was shipping a 2.0 release in the next six to eight months, so why not tell them that they’d have to wait?

The problem with talking about functionality not in the current release sets expectations and distracts from marketing what’s already wonderful about what you’re selling. All you’re doing is diminishing the product you’re selling. You are also making a promise to your customers that you may need to break down the road if priorities change (or Apple implements new OS features that force your hand).

#2 Cannibalize Features for Free Releases

Being a people pleaser, I fell victim to the trap of feeling guilty for not giving my customers more features. No one was yelling that MoneyWell was horrible, but in my head I had a vision for the functionality that I wanted in the 1.0 release. This vision caused me to steal features that should have been in a paid upgrade and release them in dot releases, which were free.

MoneyWell 1.4 could have easily been a 2.0 release. 1.5 could have been a 3.0 release. Let’s not even talk about 1.6 and 1.7—all free releases. I should have stopped at 1.1 (what 1.0 should have been), rolled my 1.2 through 1.4 features into a 2.0 release, and charged for it. That income could have been used to hire a designer and improve the quality of new releases. It would have been a win-win for my customers; instead I hijacked my marketing budget and stretched cash flow thinner than necessary.

By allowing my misplaced perception of value to get in the way of the business side of development, I cheated my customers out of better software. What I thought was generosity was instead a tradeoff of short-term features for long-term benefits.

#3 Rewrite All the Code

After four years of shipping free updates, work finally began on MoneyWell 2.0. The year before, I had hired Michael Fey to help me develop MoneyWell for iPhone and I added Danny Greg to our team to accelerate the work on our new release. Both these guys are sharp developers who were knowledgeable in the latest Objective-C and Cocoa techniques and ready to fix all the “old guy” code. I was embarrassed by some of my ancient code—written in my early days of Cocoa development—and quickly gave the nod to replace some of that code.

My lack of focus on code reviews and my desire to create the best MoneyWell possible made me vulnerable to rewrite suggestions, and some of the “old guy code” was actually pretty good. There were also external forces at play. At WWDC, Apple announced OS X Lion and I decided that we could remove a ton of custom code by ditching support for 10.6. This wasn’t a bad decision, but it was painful to discard nearly six months of work. If I had planned a more focused 2.0 release, we could have shipped 2.0 before WWDC11 and avoided much of that pain.

#4 Do Documentation Last

Because my project plan for MoneyWell 2.0 lacked focus and included so many features, this release was running months late. By February 2012, I felt pressured to ship it quickly even though there were bugs and incomplete features. But the most embarrassing mistake was the total lack of documentation. I had no 2.0 manual, no videos, no online help—nothing. I relied on a short in-app guide to train new customers and assumed our simplified interface would be easy for existing customers to adapt to the changes.

It was a huge mistake. New customers were confused, existing customers were pissed, and I was depressed. Because I had spent months of development time using 2.0, my understanding of how much had changed was skewed—MoneyWell 2.0 was old hat for me. There was so much to be proud of in our new release, but no one knew about those features. All people knew was that lots of things had changed and some features were missing.

A bigger issue with waiting until the end to write documentation was the loss of customer perspective. If I had to explain features with documentation as I was writing them, I would have seen several flaws in my design logic. There were components of the new spending plan that I would have scrapped if I had tried to explain them to a non-technical audience. I was seeing my app completely from a developer viewpoint. What a disaster—I had let everyone down.

#5 Extend “Crunch Time” for Months

This project was full of blind spots for me. I wanted my old code cleaned up, which caused me to give thumbs up to unnecessary rewrites. Features that seemed “almost done” were weeks away from completion. The project changed directions a couple of times with changing the OS target and feature creep. I started the development crunch time before WWDC and we didn’t ship for eight months. It’s okay to push a team for eight days or even eight weeks, but eight months is insane. Completely. Insane.

The Right Way

So what’s the right way to run a software company?

  1. Keep your mouth shut. Don’t talk about features until you are ready to ship. Save them for a teaser video and use “leaks” for marketing.
  2. Don’t give away software. You deserve to get paid. Customers deserve to have you around to support them for years. Hang on to features for major paid releases and give you and your customers a great future.
  3. Never rewrite functional code. If it works, don’t touch it. If it works, don’t touch it. FOR THE LOVE OF PETE, DON’T TOUCH IT!
  4. Build software and documentation together. If you don’t have time to write documentation, you have too many features. Writing how software should be used while writing the code will make your code better. Make time for it.
  5. Minimize crunch time. You and your team have limited energy. Long days are fine at the end of the development cycle, but not for months. Cut features if you need to ship faster. Don’t kill yourself or your team.

I made way too many mistakes for a guy that has been doing this for over three decades. Learn from my errors and ship awesome software. I’m trying to do the same.


  1. Blame Phil Letourneau
  2. I highly recommend buying the videos


It’s both a blessing and a curse. The disease that drives me to create software, has cost me GPA points and bank account dollars.

I’ve always struggled to let go of a problem. Even as a small kid, I would take apart electronics when they didn’t work as advertised and try to fix them—no skills, no training, just a basement full of rusty old tools and hyper focus. My parents weren’t happy when my projects failed to go back together as easily as I took them apart, but that never stopped me.

I always felt confident that I could fix anything. Even as a teenager, I decided that I could fix the busted two-speed Powerglide transmission in my ’68 Camaro. The one in my broken down Bel-Air of the same year was similar. How hard could swapping linkage and transmissions be?

My first attempt broke the same front pump gear that stopped my Camaro from moving in the first place. My second attempt was better, but my pretty blue Camaro only went in reverse… slooowly. The third attempt was spot on (although I was annoyed having to replace the transmission fluid again). With only a minimum wage job at Taco Bell, I had much more time than money (the Bel-Air was a $150 car and the Camaro an expensive $800 investment) and plenty of incentive to focus on fixing my wheels.

In college, I used to spend hours camped out on a computer terminal until they kicked us out at midnight. A few of us Computer Science (CS) majors convinced the engineering students that we could help them with their programming projects in exchange for access to their exclusive room of five terminals. The big terminal lab was always full of “lowly” Data Processing students working on their clumsy COBOL code, but having this private space to work fueled my obsession.

Even away from the terminal, I would churn on a software problem. I’d wake up in the middle of the night with solutions and have to write them down. My goal was to have my project submitted early with extra features—I wanted to be the best programmer no matter what the cost. Consequently, other classes suffered if they happened to require my focus during a development cycle. Being hyper-focused made me a top CS student with an average overall GPA.

Fast forward to today and my ability to hyper focus has been a great asset for my software design. MoneyWell would not have been as innovative if I took a casual approach to creating it. The problem is that selling software isn’t all about the code; you need to promote it, document it, and manage a company infrastructure.

Unfortunately, I’m only hyper focused with things that I like doing and I like doing the software design the most. Structuring a company is easy enough—I’ve done it several times over the past three decades so I can knock that out without much focus. Accounting, payroll, taxes, and corporate paperwork are boring as all get out, but I can outsource those tasks. It’s the promotion and documentation that tends to lag with me.

Now I love a great looking website and clean, clear documentation, but both those jobs get pushed off in favor of improving the code. I should spend more time on both, but once the bare minimum is done, I lose focus.

Marketing is my real weakness. I think I’m good at marketing, but it’s so painful to do sometimes. The most difficult part is promoting my products when I’m not 100 percent happy with them. Even if they are better than many of the competing products, I struggle to write ad copy. I start and then think, “I could fix this portion of the code and then I’d really have something to brag about.”

It’s a sickness. I completely admit it. But I am working to improve.

The next few rounds of software releases will be the proof that I have some control of this problem. The prospect of higher sales revenue due to better marketing is decent incentive, but that means I have to step back from my coding tools to make it happen.

We make great software that has dramatically improved the financial futures of thousands of our customers, but if people don’t know our software exists, what good is all that engineering effort? I have to keep reminding myself that marketing doesn’t just happen. It requires me or someone else in my company to take action. Apple may give us boost now and again, but that’s just one small piece of the marketing puzzle. I have to stop pretending that the next release will simply be so wonderful that it will get rave reviews by every news source and talked about by every blogger. Promoting software requires planning and needs someone to execute those plans.

Speaking of which, I have new releases of MoneyWell and MoneyWell Express that are nearly ready for App Store submission and I haven’t written press releases or updated the documentation yet. I’d better focus on that.


The Future of Software Pricing

I think everyone can agree that we won’t survive long as indie developers if we can only charge one or two dollars for our apps. I don’t even think $15 is enough unless you have an enormous audience. So what do we do? How do we compete with the “race to the bottom” inspired by the App Store? I don’t have all the answers, but I do have my opinions and I’m willing to back them up with evidence through my business actions.

Doubling Down

Michael Jurewitz gave a great talk on the economics of software pricing at Çingleton and expanded that talk at NSConference 5. You need to watch the videos to see all the details, but the high point for me was when he said, “Take your current price and double it. If you lose less than 50 percent of your unit sales, you’re making more money.”

Less tech support and more revenue. That sounds good to me. When others were telling me that I should lower the price of MoneyWell when the Mac App Store appeared, I refused. I know what my software is worth and what I need to grow my company and a $50 price is as low as I’ll go for an app that could save my customers hundreds of dollars a year and improve their financial futures.

Back in the ’90s at one of my previous companies, I wrote vertical market estimating software for the construction industry. We sold our software for $2,995 when our competitors were selling their products at four to five times our price. Were we making five times as many unit sales as them? No possible way.

So we hired a sales consultant to improve our techniques and he immediately asked why we were selling a premium product at discount pricing. He said, “Double your price and I guarantee you will only make more money.” Nervously, we announced to our customers that the new price would be $6,000 and to buy additional seats before June 1.

The result? A very healthy seven-figure sales month for May and then unit sales leveled off to exactly what they were at half the price. We doubled our revenue. How much freaking money had we been leaving on the table all those years? What could we have done with our products with that added money? Shame on us.

Not every market can handle a 2x price increase, but the experiment is worth it for so many developers.

Subscription Pricing

Another wise developer and friend, Manton Reece, talked about subscription pricing. He gave us examples of how well this works with the new Microsoft and Adobe pricing and also with his some of his own software, which he was too modest to pitch, so I’ll do it for him. Check out SearchPath, Tweet Library, and Watermark—they are great products.

Chatting with Manton after his talk, we discussed what software this model works for best and the simple answer is any software with a cloud back end. It’s not going to work for simple device-centric apps, but if you can fit this model, it’s a great option. Think about being able to lower the price point of acquiring your product and then having more balanced revenue figures for each month throughout the year. I know I wouldn’t mind few valleys amongst the hills.

In-App Purchase

Since my price point is pretty solid and my products don’t fit the subscription model, I’m choosing too go a different direction: In-App Purchase (IAP).

One of my biggest frustrations with the App Store is lack of trials or demos. Offering a “lite” version of an app just adds clutter and confusion, so we have a trial version on our website for our Mac app to allow customers to try MoneyWell before shelling out 50 bucks. This is not an option for iOS so I needed another solution.

Chatting with Michael Jurewitz at WWDC 2012, we came to the conclusion that IAP could work well for No Thirst apps. Last month we shipped MoneyWell Express and proved that it is a viable option with a consistent 25 percent IAP purchase rate.

MoneyWell Express is a companion app that syncs with MoneyWell on the Mac and allows for quick entry of your transactions during checkout at a store or restaurant. The fact that most people installing it are most likely existing customers skews the IAP units numbers a bit, but I’m still very happy with this adoption rate. We’ll get more interesting figures when we release our iPad version, which will be standalone.

It’s important to choose wisely with IAP divisions in your app. For MoneyWell, we played with different features at lower prices adding up to the price we wanted, but it got too messy. Instead we decided that the free version would allow for access to all the features and just limit the customer to a singe bank account. Most people have checking and savings accounts with a credit card or two so we were confident that they would want to purchase our “Unlimited Accounts” IAP and not settle for the limitation.

If a customer did only have one account, they would never be nagged to purchase anything. Those that did have multiple accounts would get to use all the features, but only one account would show a balance in their Accounts list. The others would have the word “locked” there instead. Tapping one of those locked accounts presented the IAP screen where a purchase removes any hint of IAP in our app.

It’s a very soft sell and lets us charge more for the app than we could without that initial free experience. I want to keep our iPad app pricing in line with our Mac apps because they are going to be nearly feature equivalent to each other. Why charge less for the same functionality?

We have not seen a serious uptick in support and our ratings have been averaging four stars, but if your app has a serious learning curve, the IAP model may cost you in sales or support. I’ll report back on our iPad experience when we ship it later this year. I’m optimistic that it will be excellent.


Befriending Apple

You’re writing an app that you hope will lead to fame and fortune or at least will pay the bills. If you have any hope of succeeding, you need to make friends with your platform manufacturer. For the iOS and OS X universe, this is Apple.

Like it or not, you will always have more success if people at Apple are rooting for you. They have influence over your App Store promotions, which is your best shot at free, effective marketing. This thought was brought to the forefront of my mind as I was listening to talks by Michael Jurewitz and sharing my own story with other attendees at NSConference 5.

Back before we called software “apps” and sold them through Apple’s central pipeline, we had to sell software via our own websites. It was hard to get people to notice your product so download sites were a valuable marketing resource. Apple Downloads was the biggest and the best of these.

In 2006, I built a product called Debt Quencher to help me eliminate my credit card debt using the snowball payments process. It was the software that launched No Thirst Software. I knew this $15 tool was not going to lead me to any fame or fortune and it barely paid my website hosting bills at first. It was my toe in the water so I could decide to jump into the deeper waters of bootstrapping my new company.

I filled lots of paperwork to acquire a $50,000 small business loan and dove into development of MoneyWell, a personal finance tool that would fix all the problems I was having with Quicken. While developing my flagship app, I needed help making sure I had the infrastructure to sell it—one that would withstand selling thousands of copies instead of the manually emailing licenses process I had for Debt Quencher. The best place to hang out was the MacSB group on Yahoo, so I was very active there.

At the same time, I wanted feedback on my app design and the sister group, MacGUI, was perfect place to get peer reviews. I started talking about my unique single-window design for MoneyWell and posted some screenshots of alpha versions. In addition to excellent advice from designers and developers, I was contacted by a guy from Apple. He said, “I am in charge of the Business and Finance section of Apple Downloads. Could I get more screenshots or see a beta version of MoneyWell?” I replied, “If you work for Apple, I’ll be happy to give you the source code if you want.”

In August of 2007, my government-backed loan had run out (actually, it ran out much earlier, but I did some creative financing and spending reductions) and I had to ship what I had completed as 1.0. Let’s just say it wasn’t the software I wanted to release, but it was the software I needed right now.

As promised, I had included my new best friend at Apple on beta versions. As best friends go, we didn’t talk a lot, or at all really, but I was sure that in his own quiet way he felt as much love for me as I did him (call me). I didn’t expect much from this relationship since I was a nobody in the Mac developer world. I was just covering my bases.

I released MoneyWell and submitted it to all the various download sites including Apple’s. I was thrilled to see it listed and getting healthy downloads—double digits each day! Two days later, I was shocked to see it featured as the main app on the Business and Finance section of Apple Downloads. Even better, it was also the featured app on the front page. I may have had to change my underwear, I’m not sure.

My website didn’t give me realtime statistics, but I was able to see them the following day. It said there were over 20,000 downloads. I recounted the digits in that number three times. I called my wife over to look at it to make sure I wasn’t having a dyslexic fit.

Twenty. Thousand. Downloads.

Holy unexpected server activity, Batman!

And this continued for the week that I was featured giving me a total of over 160,000 downloads in the first month. Unfortunately, it wasn’t the version I wanted everyone seeing. It was crap in my eyes. Features were missing. It lacked half what I had planned for it, but my funding ran dry and I had little choice.

My brain toggled between praising and damning Apple. But it honestly was a fantastic gift from the Fruit Company and proved that there was a huge market for Mac software no matter what the naysayers repeated throughout my development process. All this because I followed up with an opportunity to work more closely with Apple during my app development and release.

How much bigger is the potential win today? What size win can you have by cultivating your relationship? Say hello to your Apple Developer Relations team members. Talk to engineers at WWDC and show off your products. Be an active member of the Cocoa community and share what you are doing and have learned. You never know when someone with influence over App Store placement might be watching.

And I’m not saying you shouldn’t be critical of Apple, there is plenty of room for improvement. Just do it without being an asshat.