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

Learn how to run a successful iOS Consulting Company in this interview with long-time Mac/iOS developer Kyle Richter! By Ray Wenderlich.

Leave a rating/review
Save for later

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?


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.