Running a Successful iOS Consulting Company: A Top App Dev Interview

Ray Wenderlich

Kyle Richter

Welcome to the second article in our Top App Dev Interview series!

In this series, we will interview the best of the best mobile app or games developers that have recently nailed a hit in the top charts of the App Store.

Each interview will be focused on one Top Developer who will tell us his or her inspiring story and share valuable tips and insightful information on how they made it to the top.

For our second interview we have Kyle Richter, co-founder of Emperical Development.

Kyle has been a Mac developer since OS 8 and has been successfully running an Mac/iOS dev shop since 2004. He has been involved in shipping more than 750 apps for iOS, including apps mentioned 4 times on stage at WWDC, more than a dozen featured apps and commercials, and numerous top grossing/top free apps.

Kyle has a lot of great info for you, particularly about the running a successful software iOS consulting company, growing a business, and making great apps.

Keep reading for some practical and inspiring advice!

About Kyle and Empirical Development

Could you tell us a little about yourself and your company as it stands now?

Empirical Development

In 2004, I started my own software consulting company called Dragon Forged Software. In 2012, we merged with Marcus Zarra’s company to form Empirical Development, and we’ve now grown to over 2 dozen full-time developers.

I like to remain an active member of the indie development community and have written several iOS development books as well as speak across the globe at conferences on development and business.

I currently live on a small island just outside of Key West because when you can work from anywhere, you might as well pick a nice anywhere!

The Business of Software Consulting

What did you do before you started doing consulting work, and what were the first few steps you took to get started?

Before I was a software developer I was in the US Army where I served as an active member of the Airborne Infantry. In 2003 I was wounded and began the long process of rehabilitation and medical retirement from the armed services.

When I was a kid I loved to tinker on code on my Mac SE and Commodore 64k using BASIC, so this was an opportunity to return to that early childhood passion. I picked up a couple of books and began reading and learning as much as I could.

Most importantly I wrote a lot of software and spent a lot of time exploring what I could do with the frameworks. Each little application that I wrote was slightly better than the preceding one, and it was that real time feedback that pushed my drive to stick with development turn it into a career.

How did you find your first few clients?

TopPaid

My first few clients came through personal networking. I had a family member or a friend who knew someone who needed some software. One of the first projects I wrote for someone else was providing an administration backend system for a local high school, which was a referral generated by a family member.

When starting out I had no idea what to charge for my services and drastically underbid myself for at least the first couple of years. As I did more work and got more and more comfortable I started taking bigger projects at larger cost.

I’ve found that happy clients are your best marketing tool. To this day we get more work from clients advocating our services than any other source.

Do you prefer fixed bid projects, or hourly – and why?

If I had to pick one I would say hourly. When you work hourly you are free to develop solutions that aren’t bound to your estimates. For example if you bid out a function at 20 hours but to do it right it would take 100 hours, you are more inclined to take shortcuts. With hourly projects, when the client comes back to you and wants to add in new functionality or redesign the app, it is much easier.

Fixed bid quotes are a guesstimation game. We’re often estimating things that we may have never done before. Sometimes we are over and sometimes we are under – with fixed bids, the goal is for everything to even out at the end.

However, clients seem to prefer fixed bids. They often have budgets handed down from up high that they need to adhere to, and they like to know exactly what they are getting themselves into.

What was the worst client you’ve ever had as a contractor?

I would be amiss to call anyone out as a bad client. I think that when a client-vendor relationship breaks down there is always fault on both sides of the fence. Over the years I have gotten better at setting expectations and letting the client know where the trouble spots are early on.

With that being said:

  • Over the years we have had a small number of clients not pay us on time or dispute invoices for various reasons.
  • Some of the smaller clients such as startups or small business owners don’t quite understand the way software development works. You have to be careful to position things like bugs, change orders, timelines, and user issues up front or it will bite you later.
  • Then there are always clients who don’t understand the limits of software and think you can do anything such as bend the laws of physics, these can be very frustrating to deal with as well.

I have found if you are upfront with a client in the beginning and set realistic expectations then everything goes well. Never put yourself in a position where you will be surprising a client with bad news.

Growing a Company

When did you know it was the right time to hire your first employee, and how did you find your first employee?

I started working with freelancers well before I brought on my first employee. The first thing I really needed help with was graphic design. If I could even produce developer art I might of been happy, however my stick figures are even pretty grotesque. Through message boards and local meet ups I got introduced to a number of designers, some of which I liked and kept working with.

The first full time developer hire seemed more natural, the time felt right, there was enough work coming in to justify two full time people. Bringing on my first real employee was, to say the least, a hurdle. Suddenly your company cost doubles, if not more. If you bring someone on too early and need to pay them a fixed weekly amount you better be prepared to float that amount for at least 6 months if not longer. I have seen far too many development shops hire people before they can afford to and it usually ends in disaster.

Over the years I have gotten better at finding employees, the first few I found were through conferences or local meet ups such as CocoaHeads. I would listen to people present what they are working on and get to know them a little bit at drinks afterwards. If they seemed like they were smarter than me (never hire anyone who isn’t smarter than you) and we got along I would offer them some contract work. If they worked out I would ask them to come on full time.

Note that this system doesn’t scale very well, so we have designed a rather grueling and intricate interview and screening process that we now use called Dragon’s Test.

Can you tell me more about the Dragon’s Test?

Robot Cyborg Dragon Vector Illustration art

Our interview process consist of four parts. We take hiring very seriously at Empirical Development and each time we hire someone the process gets a little harder for the next person.

Dragon’s Test is the practical coding exercise of our interview process, but is sometimes tossed around as a name for the entire process. The Dragon’s Test itself is an iOS app that consist of 5 tabs, each section of code is broken in a known way. The applicant is given the source code and a timer is started. Given a list of known bugs (there are some unreported issues as well) they are tasked with fixing it.

This exercise replicates a standard day to day experience at Empirical Development. Once they have completed the test we look at the time taken to return the results as well as have our senior engineers “grade” their fixes. In 10 years no one has come close to a perfect completion.

How did you handle the administrative aspects of your business when you were first getting started (legal, accounting, payroll, etc)?

Unless you are venture capital backed or have trust fund money you will most likely not be able to hire people to handle all your support services in the beginning. I handled all of those services and still handle some to this day, such as payroll. I believe learning how to perform those task and developing systems to streamline them has made me the better business owner and manager. I would highly recommend that you perform as many of the supportive task as possible when you are beginning, it is crucial to understanding how the whole system works together.

Legal is a tricky one, unless you are a lawyer you probably don’t want to be doing the legal side of the business. I have lost a good deal of money, and some court actions, due to writing my own contracts in the beginning. Lawyers can be expensive and its hard to determine when you need one. While we grew to the stage were it made sense to have an attorney look over everything we lived off services like Legal Zoom to provide boiler plate documents like NDAs.

Making Apps

Do you ever make your own apps?

Slender App

We started out making our own apps and did a lot of that before the consulting side really took off. Empirical Development has a product division arm called Dragon Forged Software, where we mostly make tools for iOS and Mac developers such as Resolve and Slender.

We also have some games, notable EOL products such as Transactions and Handshake, and even a data recovery app. We try to scratch our own itches with our products and write tools that we will use everyday.

When we see an empty spot in the market and we want software to accomplish something we just go ahead and make it. We also have a whole host of internal non-public products that we use to help us create bid documents and track employee effectiveness.

Your company all works remotely, correct? What tools or tricks do you use to effectively communicate as a team while making apps?

Yes we are a purely US and Canadian based remote team. It has taken many years to get the systems working to a point where we are more effective than an under one roof team. While we use many tools in order to get the job done some stand out more than others:

Resolve App

  • We use Adium/iChat/Messages for one on one communication, as well as email.
  • For group collaboration we use 37 Signal’s Campfire with the Mac OS X Propane written by our own Trevor Squires.
  • Freshbooks is used for tracking time and budgets as well as payroll and invoicing.
  • For ticket tracking we use LighthouseApp with ResolveApp, another one of our own products.
  • A shared group calendar is also heavily used for time off and vacations as we are also a flextime with unlimited vacation company.
  • Facetime and Google Hangouts have also become an important tool for us, sometimes you just need to see people face to face.
  • In addition we try and foster an active employee community through an in house wiki and a company wide weekly Team Fortress 2 death match.

I have worked in many offices both large and small and the systems we have setup provide a very personal close community of employees. If I could start everything from the ground up again I would go telecommute again for sure.

To what do you attribute the success the apps your company has created in the past?

Attention to detail. There is really no great secret to being a successful developer other than that. It is easy to write code that performs a certain task, it is much harder to write something that performs quickly, responsively, with a low memory front print and looks beautiful while doing it. If you don’t care about the products you are making there is nothing setting you apart from everyone else.

You need to always be asking yourself what can be better, what other options are there, is this really the best we can do? I often tell my staff, “Not good enough”, which shouldn’t be taken personally, its a challenge to keep pushing yourself, keep your standards high and hold others to them.

When a piece of code works as intended, for a lot of developers its the end of that task, for us its just the beginning. If you are just copying and pasting in code from Goggle and throwing in whatever open source libraries you can find without fully understanding what they are doing how can you be confident in your product. Your software is a reflection of you, what do you want it to say about yourself?

Final Advice

What advice would you have for developers just starting their own consultancy?

Make friends, your friends and connections will determine whether you succeed or fail. Attend conferences, meet ups, CocoaHeads, become active on the forums and newsgroups. When you are in a rough spot you want to be able to reach out to a network of well wishers to get help with a bug, bringing in an extra hand, or asking for a client referral.

Over the last decade there are many times where a friend has stepped in and saved us from certain disaster. Being outgoing and friendly to everyone you meet, especially those that seemingly can’t help is one of the most valuable things you can do to ensure your success.

Where To Go From Here?

And that concludes our second Top App Dev Interview. A huge thanks to Kyle for contributing!

If you are an app developer with a hit app or game in the top 100 in the App Store, we’d love to hear from you! Please drop us a note anytime.

We hope you enjoyed this interview, and that you take Kyle’s advice to heart and become a part of the iOS community!

Ray Wenderlich

Ray is an indie software developer currently focusing on iPhone and iPad development, and the administrator of this site. He’s the founder of a small iPhone development studio called Razeware, and is passionate both about making apps and teaching others the techniques to make them.

When Ray’s not programming, he’s probably playing video games, role playing games, or board games.

User Comments

6 Comments

  • This was such an interesting reading. Personally the bit that hits me the most is the one related to the quality of your job. As a still-junior iOS developer I tend to go myself with the first thing that works out, relieved that it did, and move one. I know that in order to become a really good developer I need to avoid the urge to keep going and work harder at making my code better. Every time I read how important is to care about every detail it affects me (because I know it and I usually don't do it) but I'll definitely try to work on this every day until I feel more in control and less overwhelmed by the vast amount on knowledge to absorb.
    juan294
  • Nice article, as per usual. Thanks again for being such a terrific resource for the developer community.
    Mad River
  • "Your software is a reflection of you, what do you want it to say about yourself?" - that hit me pretty hard, something I'll keep in mind for a long time.

    Please have more of these interviews, there is a lot to learn from those who are successful.
    askar
  • Thanks Kyle for a candid interview, managing client expectations is always a challenge.
    regards,
    raj nataraj
    rajnataraj
  • Hi, Appreciate the great advice here -- I'd love to hear more about developing your companies processes that you mentioned. From sales to marketing to project sizing and software architecture. Thanks!
    amblatx1
  • Very thoughtful and very wise decisions and nicely delivered to us. This interview was perfect, it covers what I always wanted to know. Thank you Ray and Kyle for sharing such a wonderful experience.
    Chinab S.

Other Items of Interest

Ray's Monthly Newsletter

Sign up to receive a monthly newsletter with my favorite dev links, and receive a free epic-length tutorial as a bonus!

Advertise with Us!

Vote for Our Next Tutorial!

Every week, we alternate between Gaming and Non-Gaming tutorial votes. This week: Non-Gaming!

    Loading ... Loading ...

Last week's winner: Best iOS Animations in 2014. [Read Now]!

Suggest a Tutorial - Past Results

Hang Out With Us!

Every month, we have a free live Tech Talk - come hang out with us!


Coming up in October: Xcode 6 Tips and Tricks!

Sign Up - October

Our Books

Our Team

Tutorial Team

  • Jean-Pierre Distler
  • Barbara Reichart
  • Corinne Krych

... 49 total!

Update Team

  • Ray Fix
  • Andy Pereira

... 15 total!

Editorial Team

... 22 total!

Code Team

  • Orta Therox

... 3 total!

Translation Team

  • Vitaliy Zarubin
  • Wilson Lin

... 32 total!

Subject Matter Experts

  • Richard Casey

... 4 total!