My Top 5 factors for iOS Contracting Success

About a year ago now, I was contemplating leaving my day job and becoming an indie* iOS developer. My last day working in a cube farm was June 30th, 2011. Now, as I pack to leave for WWDC in the morning, it occurs to me how much my life has changed since I made that decision.

When examining my finances in preparation for this trip, I determined that in my first year as an indie I've made within $1000 of the amount of money I made in salary my last year as an employee, while spending more time with my family and enjoying my work so much more. Personally, I consider that to be a success.

Looking back, I can think of 5 things that I did that I think contributed most to that success, and I wanted to take this opportunity to share them with you all.

• 5. Project Focus

I think of my work (and speak with clients about my work) in terms of projects. I use traditional project management tools (often Gantt charts) to plan my work and track my progress, and I try to arrange for milestones to happen every week or two. That seems to help alleviate any concerns that my customers might have about doing business with a one-man shop. It's helped me develop a "specialty" (if you can call it that) of cleaning up Apps that other bigger but lower-bidding developers (often acquired through Elance/oDesk) have made a mess out of.

• 4. Books/Videos

I read a lot, and I watch conference videos while I'm on a treadmill or rowing machine. I think that's the biggest difference between me and many other developers whose work I often end up straightening out.

My favorite book this year was iOS Recipes by Paul Warren and Matt Drance, although I've read at least a dozen others.

My favorite video was the Core Data Performance series from Marcus Zarra, although the WWDC, NSConference and 360iDev videos were all very useful (and very cost-effective).

• 3. Conferences

If it weren't for the 360|iDev conference in 2010, I would never have had the confidence to try to be an indie iOS developer (full disclosure: I'm Speaking at 360|iDev this September). I agonized over making my reservations for the September 2011 conference, because it meant I wasn't getting paid while I was attending, but I'm so glad I did. I also went to 360|MacDev this February, MicroConf in April, and I'm about to leave for WWDC.

As I mentioned earlier, I buy and watch conference videos for many conferences, so you'd think that it wouldn't be worth actually going to the conferences. I thought so, too, once, but I was wrong. What I get from conferences is networking, making (and renewing) contacts and topping up on the motivation that I need when things don't seem to be going well.

• 2. CocoaCoder/NSCoderNight/CocoaHeads/etc.

Many major areas have meetups where iOS (and sometimes Mac) developers get together to work and learn and talk. I've been attending CocoaCoder Austin for a couple of years now, and I've been one of the organizers for about a year. Austin also has a South group SAiD, and a more entrepreneurial-focused group. These are great opportunities to learn, figure out what's going on in your town. Check Meetup or ask around. If you can't find one, start your own.

• 1. Co-Working facilities

But I think the biggest factor in my success as an iOS contractor was my decision to spend time at a local co-working facility (mostly CoSpace, although I spend some time at Tech Ranch, where we have most of our CocoaCoder meetings, as well).

Co-working isn't just a place to go to get out of the house and have some non-family human contact (although it does do that), but a good Co-working space facilitates introductions and a sense of community. Co-working became a source of contacts and contract opportunities for me, and I can safely say that, if it weren't for some of the people I met while I was there, I would have completed this year having made far less money than I actually have.

Of course, your mileage may vary, but I hope this has been useful. It is possible to give up your day job and make the same money, while enjoying your work more and spending more time with your family - I know, because I did it. It hasn't been perfect, and I've made my share of stupid mistakes, but I'm declaring victory on my first year as an Indie, and I'm going to go enjoy WWDC and look forward to my next year of making my own way in the world.

* Some people may take issue with my characterization of myself as "indie." Some people define indie as "Only works on your own stuff", and that's certainly not true of me (although I do work on some of my own projects). Personally, I choose to define indie as "Not sure month to month (or even day to day) when or how much you're getting paid next."

If you want facts, Indie, I've none to give you, at least not yet.

As I've written before, I'm very optimistic about the state of iPhone and iPad App development.  I've published several apps on the side, and while I've worked on several Apps at my day job, Apps was only part of my day job, and I didn't get a chance to focus on mobile the way I really wanted to.

Well, today, that all changes.

My last day at my day job was the last day of June, I took a long 4th of July weekend off, and now I'm moving into App development full time.  I'm still working on turning my "write iOS Apps from an iOS device" project into a shipping application, and I want to get iCloud-enabled refreshes of some of my existing apps ready for the iOS 5.0 launch this fall.  Hopefully along the way, I'll find some contract work to help pay the bills.  Please let me know if you run into someone who needs to get an App built.

I've done the Indie thing before, although it's been 6 years, last time it was C and SQL instead of Objective-C and Core Data, and I didn't have children then.  But, I'm looking forward to it. It was always more fun and challenging than I expected, and I doubt it will be different this time.

But, at the moment, I have no idea how this is going to turn out, and that's exciting.

Wish me luck.

Mobile Apps - Boom or Bust? Sherman, please set the Wayback Machine for 1994, and then 1853

In the last few days, I've seen reports that Mobile Apps are repeating the 1996 expansion, and reports that Mobile Apps don't provide a viable business model. I think that  there are elements of truth in both articles, but I don't think either is an adequate depiction of what I'm seeing. Let me see if I can explain.

Like others, I feel like I've been here before, but for me the year wasn't 1996, but 1994. That year, I was a consultant in Dallas Texas, mostly hooking up Internet connectivity and web servers for companies that nothing to do with technology. At one point I literally couldn't introduce myself to people without having them say, "Did you say that you do websites? I've got to get a website for my business. Can you help me?"

Back in the present, I've recently gotten my third phone call in as many months from a person I've never heard of, saying "I heard from (a mutual friend) that you write iPhone apps. I've got to get an iPhone app for my business. Do you think you could help me?"

Now it's definitely true that most Apps don't generate enough revenue to make back their development costs. But that's okay. In 1994 (or 1996 or 2011 for that matter) most websites don't generate enough revenue to make back their costs. And I haven't seen any evidence that people are no longer building websites. Most companies these days see having a web presence as a necessary cost of doing business. And many are starting to look upon Mobile Apps with the same thoughts.

To me, the example for making a viable business out of Mobile App development is to think not of 1996 or even 1994, but California, 1853. Gold had been discovered and the Gold Rush was on. Prospecting for gold, like the App Store, was "not a viable business." Very few of the people that went prospecting ever made a lot of money, and many of them ended up in debt. You've likely never heard of any prospectors, but you've heard of at least one viable businesses from the period: Levi Strauss & Co.

Then, as now, the people looking to strike it rich will largely fail to do so, but now, as then, a viable business can be made from providing services to the prospectors.

Fixed Price iPhone App Proposals - One Contrary Consultant's View

I've seen a some traffic lately about billing and proposals for writing iPhone apps. Most of what I've seen revolves around hourly rates, but I think that's not a helpful way to go, so I thought I'd chime in with my opinion.

I've been a consultant off and on for the better part of my career, starting with EDS in 1993. I've worked for different consulting shops and independently and I've read extensively on the topic. Lately, I've been applying a lot of that experience to consulting for companies who want iPhone apps created.

My preferred way to set up contracts for iPhone consulting is to do fixed price work. The prevailing wisdom seems to be that this is too risky, but it doesn't have to be. The problem with the way most people do fixed price work is that they set their scopes way too high, their projects too way long, and the amount of money and time at risk too high to make mistakes.

I haven't always liked fixed price work. The thing that changed my mind was a book called "Million Dollar Consulting" by Alan Weiss. It's not a book about tech, he's a management consultant, but much of his advice is quite applicable, and I recommend it as highly as I can for anyone who is in the business.

So why fixed price? Well, there are several reasons, and I'll probably expand on them in future posts, but for now, here is the important one: it completely changes the nature of the relationship with the customer:

It's really hard to argue with "but I can get someone from (insert country here) for $40 per hour cheaper, how are you worth so much more than them?", so try not to compete apples-to-apples.

• You never again have to justify to anyone how you spent your time. Isn't that one of the reasons most most indies quit working in the corporate world in the first place?
• Working faster, smarter and better makes you more money, not less.
• You can discuss options with your customer without either of you having to wonder how it will affect the amount you're getting paid.

So, assuming you'll agree that there are some advantages to fixed price work, how do you reduce the risk to you and your customer? Do more frequent, shorter fixed price chunks.

This technique came to me when I was reading a combination of books on Agile programming techniques (specifically week-long sprints around user stories) and To-do and project management books (specifically parts that talked about breaking down larger tasks into smaller chunks until you could feel comfortable about your estimates). I've been using it for a few years now, and it works well for me.

A typical engagement for a brand new app for me starts with a client meeting to talk about what they have in mind. Then I go away and write up a fixed price proposal for what feels like two or three days worth of work to me. Maybe it's a sketch of potential screens for the app with a work flow of how they might fit together. Maybe it's a potential development project breakdown. Maybe it's a quick prototype. The main thing is, I want to propose to show them I do good, reliable work and convince myself that the customer is serious with only a few hours of my time and a few hundred dollars of the customer's money at risk.

If they accept the proposal, then I do the proposed work, and I give it to them, and write up a few other options about what small-sized chunks they can have me do next. If they like my work, they'll pick one of the other proposals for me to do. If not, they are free to walk away with the deliverable I gave them for a lot less money than it usually takes to figure out if someone knows what they're doing.

This has worked well for me, but it has its disadvantages. Primarily, you end up writing a lot of proposals (but you get better at it with practice). Also, it makes it harder to get jobs from those sites where you bid for a project where the prospective customer has already made up their mind that they want to pay hourly (to me, those projects sound like nightmares, so I avoid them anyway).

There is a place in my world for hourly deals, but only under the circumstances where the customer is likely to change their mind a lot, but that's a topic for another day.

Stay tuned.