“I have an iPhone App that another developer built for me, and it’s 90% of the way there, but that developer is no longer available and I just need someone to do the last 10%.”

I got that call again recently (it seems to happen every month or two). And this time, as almost every time, it turns out they weren’t even close to 90% done.

Although I have paid my mortgage more than one month by cleaning up after another developer, I hate those situations. The client has almost always spent all (or nearly all) of their allocated budget, and they have almost always been led to believe that they were very close to being done.

So I’m writing a series of post about this situation, what your options are if you find yourself in it, and what you can do to avoid it in the first place. The first post is about why it costs so much to clean these up. This post, our topic is:

“Is there anything I can do in my Request For Proposal to increase my odds of avoiding bad developers?”

But, before we get started, first a disclaimer. I am not an impartial observer (and I don’t even play one on TV). I have a vested interest in what I’m about to say, and it’s influenced by my background and opinions. I am going to say some things that people are going to get pissed off about. I am okay with that. If you aren’t, then you should probably find something else to read.

Disclaimer two, the way I’m recommending is not necessarily the cheapest way. If you go with the cheapest developer you can find and you get lucky, you will definitely spend less money than if you follow my advice. But if you don’t get lucky, and have to have it done over again, it can end up costing you far more than your initial estimate.

RFP Technique 1: Require Milestones and Signoffs

I would recommend that you never let your developer go more than about 2 weeks or 20% of your project budget (in time or money), whichever is shorter, without giving you a new build with new functionality and release notes. So if it’s a 10 day project, you should get a new build and release notes every 48 hours or so. If it’s a six month project, you should get 12 or 13 new builds with release notes over the course of the project, at least 2 each month. Each one should have new stuff in it (although the UI might not always be different).

I would also recommend that you require your potential vendors to break the project down into that many individual steps up front and write them down on their proposal. If they can’t tell you up front what the milestones are going to be, how likely do you think they’ll be to have guessed correctly about time and budget?

Now it’s not unlikely that one of those milestones might be late (or the direction of the project may change and ). That’s not necessarily the end of the world. But wouldn’t you rather know and have that conversation with your developer at that point than the day before you think they’re supposed to be done?

Now this is more work for the developer, and they’re not going to like it. They’re going to tell you it’s more work (and it is) and it’s going to cost you more (and it is). But it reduces your risk, and you have to decide what your risk is worth to you.

Also, don’t let the developer save the hard stuff until the end of the project.

Have the developer tell you what the hardest part(s) are going to be for them. And then ask them how they can move those items as soon in the schedule as possible. Maybe the first build you get doesn’t look like your App at all, but has one screen with one big button that says “Upload big data file to server”. You push it, and then you go look at the server and make sure the file showed up. That might be okay.

A lot of projects are done this way: Money to developer up front, followed by the first milestone of a UI mockup that doesn’t do anything but look kinda pretty (at which point the developer gets more money), followed by several weeks while they “work on the backend stuff” (background processing, talking to servers, facebook, etc, etc). At which point you get what’s supposed to be the final build and it works or not.

It’s not that mockups aren’t important, they are, but most idiots can build a mockup and if not, there are a ton of Apps developers can buy that almost do it for them. Mockups are not a point of risk. You don’t need to check the status of things that are really easy. You need lots of milestones in the middle of the parts that can actually go badly.

Then if you see things starting to slip, you’ll know as soon as you can. And there are an entire category of developers that won’t even bother to bid on that kind of project, because they don’t like people looking over their shoulders. Those people you probably don’t want.

And if the project does go badly and you have to pull the plug, hopefully you can pull the plug earlier rather than later, and you have some documentation about what the developer was doing and thinking and planning, which will help (at least some) in the event you have to call someone else to bail you out.

Thank you for reading, and I hoped you found this post useful.

Please check back soon, and read the next post in the series, which is about Why bad iPhone developers don’t like RFPs that require test code .