Hire App Developers Without Getting Burned

We all make mistakes, but a few years ago I made a big one in my business, the kind of mistake that makes you sick to your stomach years later.

The short version is that I hired a dev shop the wrong way, blew through tens of thousands of dollars, and had very little to show for it in the end.

Ouch.

The only good thing is that I learned from my mistake, and that’s what this post is about.

After this experience, I completely overhauled the way that I engage with clients as a software development consultant myself, and I’m going to detail it out for you in this post.

If you’re looking to hire a dev shop or freelancer to build you an app or website, this guide will show you exactly how to do it while saving time and money, and seriously limiting your risk.

Even if you’re not hiring me or someone who follows a similar practice when engaging with new clients, you might suggest this kind of approach with the firm you are going to work with, and see what their response is.

And if you’re a freelancer or dev shop, I’d encourage you to think about this approach and whether it might work for you.

As to my background and why my experience in this area is relevant: I’m a solo consultant / freelance iOS developer, and I’ve been helping startups build, launch, and grow successful web and mobile products since 2007.

I’ve done substantial work on 100+ websites and apps, which have collectively grown to many millions of users. I’ve also built, launched, and grown several of my own products.

Warning: this article will probably take you 15 or 20 mins to read, so if you’re looking for a “top 5” listicle or something to scan between reading tweets and watching Youtube clips, this might not be a good fit for you 🙂

How hiring a dev freelancer or firm typically works

If you’ve never hired a web or app development firm, there’s a little business development dance that often takes place.

Let’s call it the RFP process, although that’s not always entirely accurate.

So the typical process works like this:

You want an app developed, a website built, a substantial new feature developed, etc.

You collect some names of firms, maybe by Googling, maybe by looking at the websites of your competitors or partners and seeing who built them, asking around for recommendations, etc. You then reach out to these firms with a short description of the project.

Perhaps you also post a description of the work you need done on a site like Upwork (which is usually a waste of time, but I digress).

If you’re a larger organization or come from a procurement background, you might issue a formal Request For Proposals (RFP), which contains details about the project and instructions for how interested vendors can submit a proposal.

Typically, you’ll then be contacted by a number of vendors, each of whom will show you examples of their work, their impressive client roster, and usually try to get you on the phone to get some more details.

You’ll answer a number of questions that you may have not even known about when you started the project. They’ll want to know details about the project features, your budget and timeline, etc. The better ones will want to know more about your business, the core problem you’re trying to solve, the value proposition of the application, exactly why this app or website or feature is the right solution for the problem in your mind, etc. The less good ones will just want to know about the features and what you want built (this is important, we’ll come back to this).

After a week or two of this, you’ll start getting proposals back. Pricing will be a mix of hourly, daily, weekly, and flat project rates. The proposals will vary widely in tone, details, etc.

Your criteria for selecting a firm will be some combination of price, timeline, reputation, likability, previous examples of work, location, etc.

From this process, you’ll then select a firm and commit to spending a chunk of money, usually in the tens or even hundreds of thousands of dollars.

That’s the standard process, and it does work sometimes, but I’ve been on both sides of dozens of large projects for the last ten years, and I’ve figured out that it’s usually not the best way to move forward.

There’s nothing wrong with this process if you’re purchasing a commodity good or service. If you need someone to wash your windows once a week, or you need to buy 100 metric tons of corn, or whatever, then it’s a fine idea to put out a description of what you need, interview folks to ensure they can deliver, and select mostly based on price.

But building an app or a website to solve a core problem in your business or for a startup or to innovate into a new area isn’t a commodity service. It’s more like building a custom home.

Why this approach is flawed

There are a number of big problems with the standard approach I outlined above:

1. It signals a commodity view of design and development

Right off the bat, this approach sends the signal that you (the client) “knows” exactly what you need, and you “just” need someone to build it.

A lot of clients actually think this way, sadly. They think “hey, I have the app all planned out, I just need someone to build it!”

The word “just” there is a huge red flag. It indicates that the client has a very incomplete understanding of the complexity of building and launching a modern mobile application.

2. It’s based on insufficient information

Would you hire a custom home builder by saying you want a house with 3 bedrooms, sort of looks like these houses, costs about $250k, and you have a few incomplete sketches of some of the rooms? No! You might hire an architect that way, but not a builder.

Sadly, that’s all too common when hiring dev shops. At the point when you’re looking to engage with a dev firm, you almost never have enough information for them to know with any accuracy what it’s going to cost.

Most firms try and paper over this ambiguity by volume and padding in their estimates. They don’t know exactly what they’re building or how long it’s going to take, so they estimate liberally. This drives their close rate down, because they’re churning out higher quotes, so they make up for it with volume. They might only win 20% of their proposals, so they just churn out as many of them as possible.

You might think that the right approach then is to plan out the entire app in great detail before you approach firms for estimates, then? If so, read on 🙂

3. It’s often based on faulty assumptions

To continue from the above, in my experience, clients are typically looking to hire someone to build the wrong thing in the first place. They’ve probably left out a bunch of important things, planned something that can’t be built at anything remotely close to their budget, or most commonly, picked a solution that is inappropriate for the problem they’re trying to solve. I can give you a quote for what you think you want, but 9 times out of 10, you’re wasting money and you’ll end up with something that sort of solves the problem, or even something you have to scrap and start over from.

4. It increases everyone’s overhead

So there’s too much room for ambiguity during this process, and on my side as a consultant, it’s very time-consuming to work through that ambiguity upfront. So all that time gets factored back into every project budget in the form of overhead. Basically, the proposals I do win have to have enough margin to cover all the proposals I don’t win. And as a client you pay for that padding across all the firms you’re having bid for your project.

5. It’s a market for lemons

The result of all of the problems above is a problem that you can’t really see from inside this process: all the best firms don’t participate in this messed up process.

As firms get more and more experienced, in-demand, and wiser, they quickly figure out that the standard RFP process is a terrible investment for them, and they just don’t engage in it. So you’re left with just marginal firms and developers submitting bids. Is that really what you want?

The exception is firms with six figure minimums, which they have so that they can roll five figures of business development into every project. So if you’re looking to spend $500k, then this process might work, but I still think there’s a better way.

My own mistakes when hiring

Even though the bulk of my time is helping mobile-focused startups build their MVP, I also sometimes find myself on the other side of the table, hiring devs and / or designers to work as subcontractors on larger client projects, or hiring on my own projects.

A few years ago, I had to hire someone for some large updates on a web application I purchased as an investment. I would have done it myself, but:

  1. I didn’t really have time
  2. I’m not as skilled in Ruby on Rails as I would have wanted for this project.

So it was time to find someone and shovel some cash their way to get the results I needed.

All of the issues listed above were apparent in my own mistake that I outlined at the start of this article. While I had a list of things I wanted to get done, they weren’t very well organized or scoped out, they weren’t connected to a larger breakdown of the business objectives I had, and there was no discussion of the time / cost tradeoffs for these items.

I had a grab-bag of fixes and improvements I wanted to make, so I put out the call through my network to find someone who would be a good fit. I got a half dozen responses from solid individuals and firms, most of which put a considerable chunk of time into understanding my needs and coming up with a proposal for me.

In the end, I picked a firm whose proposal was somewhere in the middle, which was still pretty expensive, and off we went.

Things were great at first, but after a few months of working together, I finally called it quits. The project wasn’t a disaster, but I just wasn’t getting what I wanted out of it.

To be completely clear here, this failure is 100% my fault. The firm wasn’t amazing, but they weren’t terrible either. I did a poor job of hiring them and managing them, so the fact that I got some poor results isn’t that surprising.

The upside here is that having to navigate the murky waters of paying someone tens of thousands of dollars to do something you don’t fully understand has been very helpful in understanding what my own clients go through.

A better approach to hiring

OK, so let’s assume you’re convinced that this typical process isn’t the ideal way to select a vendor. But you still do need to get this website or app built, so what’s the alternative?

It’s very simple. Instead of engaging with a firm to build out the product, you engage with them to put together a plan for building out the product. In essence, you just break off the first chunk of the project and do that as its own mini-project. You’re not paying for anything extra; this is work that needs to get done one way or another.

For example, in my own business, due to all the negative factors around proposals listed above, I rarely write proposals anymore. Instead, I start the client relationship with a roadmapping engagement where the client and I deep-dive into what they’re building, why they’re building it, whether there are better ways to accomplish their goal faster and with less cost, and we plan out the actual architecture.

I charge $2k – $5k for this, depending on the apparent complexity of the project, and at the end of it, the client has the architecture of their app planned out, a list of options and recommendations for the best way to build it, including cost and time tradeoffs, and the confidence that a very experienced app architect / developer has vetted the idea from a technical and product perspective. From there we can both evaluate whether we want to work together on the full build.

In order to reduce any sense of risk, I fully guarantee these sessions. If the client isn’t totally satisfied with the roadmapping engagement, I immediately refund them. To date, I’ve never had a client ask for a refund.

This solves almost every problem with the standard RFP process. We both get to work together on a very small engagement to see if our working styles mesh. The client is risking nothing, as the roadmapping session is guaranteed. And I have a chance to put in enough time and thought to know that I’m giving the client a fair and accurate quote, without inflating my overhead and driving up prices for the client (and all my other clients).

Case study

Let me give you an example from my own business.

I recently connected with a potential client who wanted to build a fun utility app to promote her business. The client had a budget in the $xx,xxx range, and wanted to get an idea of exactly how much it would cost, how long it would take, how a few different parts would work technically, etc.

Well, there were two problems for me. First, I found out she was talking to half a dozen other developers and firms about building the app. And second, there were some tricky pieces to the app that would take time to plan out in order to be able to give an accurate quote.

In my old model, which I suspect all the other firms were following, I would invest a bunch of time discussing the app with her and then putting together a full proposal. In spite of the time invested, I would only have a small chance of winning the project since so many firms were bidding. I have to cover the cost of all those proposals somewhere, so that gets factored into my project minimum and what I add to each proposal for overhead. I need to make a certain amount of margin on every project I do win to cover the substantial cost of putting together proposals for all the projects I don’t win.

The other alternative would be to just throw out a high number, one high enough that I’m pretty confident that if the client goes for it, I’ll be able to build the app for that. The client probably won’t go for it, but at least I won’t have wasted much time getting to no. If you email a project to 20 dev shops out there, probably half of them will pull this, just to avoid engaging unless you’re serious.

Well, I don’t like either of those options. They’re bad for me and bad for the client.

So instead I told her that I offer a fully guaranteed roadmapping session for $2k, during which we’d plan out the architecture of the app, and probably do some light prototyping work for the pieces that were tricky, just to get a feel for how much time and money we should allocate there.

She went for it immediately. From her perspective, it’s a no brainer. She gets to test the waters, ensure she’s getting a quote that’s backed by a full understanding of the project, and in the event she’s not satisfied, there’s no risk.

Just due to the parameters of this project, our roadmapping session resulted in a working prototype of the core feature of the app, giving us both full confidence that it could be built and function the way she envisioned, and she immediately booked the full project with me. The app is nearing completion as I write this, and the client is thrilled with the results.

Conclusion

I’ve talked about the typical vendor selection process for app development, and why I don’t think it works very well. I’ve also outlined an alternative approach that has worked extremely well for my practice, helping build strong long-term relationships with my clients.

I would highly recommend giving this approach a try. If you’re hiring someone to build an app for you and you’re looking to get quotes from a number of firms, you might try starting the conversation with each one by asking if they offer any kind of roadmapping or architectural planning service, what the cost is, and whether it’s guaranteed. That’s a much better way to signal at the start of the relationship that you value their expertise and that you don’t expect (or want) them to put a lot of time into a proposal that you’re unlikely to select because you have 127 other firms doing the same thing.

I really wish I had done this myself when I was the client. It would have saved me months of time and tens of thousands of dollars. I won’t make that mistake again.