“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 .

“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. But in fact, even the best developer in the world couldn’t take the pile of code they currently have and make it into what they wanted by their desired release date. And worse, there’s no way any developer could make a living by being paid only what was left over after some charlatan took half the budget up front and wasted their time.

So I’m going to write 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. This post, our topic is:

“Why would it cost as much (or more) to finish this App that almost works than the amount I was quoted to develop it in the first place?”

Well, I know it can seem counter-intuitive, but usually bad code is worse than no code at all. And even good code that you’ve never seen before can take as long or longer to figure out than it would have to start over from scratch.

We’re going to talk about Bad Code and the Bad Programmers that Write It in my next post, but for now, let me explain that, even if the code that exists really is 90% done (and trust me, it’s not, but that’s another post), that it would still take the new guy you hired significantly more time and money than the 10% you have left.

That seems impossible to a lot of people that I talk to. I think that’s because a lot of people who don’t write code for a living think of software as being made up of more or less interchangeable blocks. A lot of people think of programming like construction. They think there must be the equivalent of two-by-fours and bricks and sheet rock.

They expect that if the guy painting your house gets sick and he wasn’t intentionally trying to rip them off, any other housepainter can tell immediately where the new paint is and what hasn’t been painted yet, open up the unused cans of paint and finish in roughly the same amount of additional time that the first guy said it would take.

And virtually everyone knows that when they call someone to change out the appliances and cabinets in their kitchen that it shouldn’t cost 80–120% of the market value of the entire house.

So what’s the disconnect here?

First, let’s start with an analogy

Let’s say you walk into a restaurant and the restaurant owner immediately grabs you and drags you into the kitchen. There’s something sizzling in a pan on one of the burners, a pot bubbling away on another one and something roasting in the oven. You are told “we have a banquet starting in two hours and our cook just quit, can you just finish this up real quick?”

You don’t have the recipe that the original cook was working from, just the description of the item from the menu and, if you’re lucky, a picture of the finished dish from a restaurant brochure. You open the drawer where you keep your kitchen utensils so you can grab a spoon and try to taste what’s in the pot so that maybe you can guess whether it’s supposed to be a soup course or the sauce, but that drawer is full of placemats and napkin rings. You start looking in other drawers and cabinets, but nothing is in any organizational pattern you can determine. The knives all have tiny handles because the previous cook apparently had much smaller hands than you, and the spatulas and tongs are all three times longer than you have at home, because the previous cook apparently had much shorter arms than you.

You might be able to imagine an expert chef (which I’m not) quickly taking inventory of the drawers and cupboards, carefully tasting each thing that’s cooking, guessing at what was yet to be done, working around the differences in the utensils and getting something completed and out to the diners.

But you can also, I hope, imagine an expert chef in that situation running (or sending someone) next door to the store to grab the ingredients and utensils that they use dozens of times every day, starting over, and putting together a dish much like one they’ve cooked before from a base recipe they have made many, many times, and just adjusting the flavors and presentation to match the description from the menu.

Which of those dishes is more likely to taste better? Which of those dishes is more likely to have a mistake made that causes it to be inedible? Which is more likely to be confidently and safely served to a diner that turns out at the last minute to be violently allergic to peanuts (or some other ingredient)?

While admittedly not a perfect analogy, there are definitely some similarities between programming and cooking. And I certainly find that people are generally more familiar with the process of food being made than the process of software being made.

The secret sauce (so to speak)

So, here’s the thing about developers in general – we save time by reusing the same techniques and code that we’ve used before. Some piece of functionality that could take 3 weeks for “the average programmer” (if there is such a beast) might only take me 5 minutes – if I already spent 3 weeks writing it on my last project and I still have the code lying around and I can just drop it in. Likewise a single line of Unity3D code that would take a competent Unity3D programmer 2 seconds to drop in could take me weeks to figure out – because I’ve never written an Unity3D program in my life, and I’d have to read a book or something to even know where to start.

As a matter of fact, it’s so common for programmers to reuse the same techniques over and over that some smart people wrote a bunch of them down and coined the phrase “ Design Patterns” and wrote a book about it. And it’s so common that the book sold a bunch of copies, and generated a bunch of spinoffs (I think I have six different variants of “ Programming Language Design Patterns” or “Design Patterns in Programming Language” books in my office).

But when we developers are asked to take over a project already in progress, we don’t get to use our favorite techniques. We don’t get to grab our most weathered recipe card from where it stays pinned to the refrigerator with a magnet and just get to work. Instead, we have to taste everything that’s already cooking and try to figure out what the other guy was thinking. And that’s a lot of work, and takes a long time (and it’s as much fun as sorting someone else’s underwear drawer). And worst of all, it’s error prone – sometimes we guess wrong, and don’t realize it until we already started down a path, and then we have to reverse course, wasting time and money (yours and ours).

And then, well, then there are the other cases. You see, ummm…

Some developers…

Well…

They just aren’t any good. And some of them are worse than just not any good.

And this post has already gone on too long.

So come back soon, and read the next post in the series, which is about How to avoid hiring bad iPhone developers .

“I really think I need an App for my business.”

I hear that a lot, these days, whenever I meet a businessperson and tell them I make Apps for a living. Usually, I ask what they would want their business’ App to do. Most of them don’t have a firm idea past just “I need an App”.

Through having many of these conversations, I’ve decided that the same themes keep coming up over and over, so this is the first in a series of blog posts about those themes.

Today, I’m going to talk about “What kind of App you might want for your business.” Specifically, I’ve spent some time looking at the App Store space, and I’ve come up with five loose categories of Apps that work for at least some existing businesses.

1. Novelty Apps

To the right here is a screen shot from the Zippo iPhone App.  It’s one example of what I call a “Novelty App”.

Games that are branded with the name of your company would also be considered a “Novelty App” for these purposes.

Pros:

These can be great for brand awareness if they’re done well, and marketed well, and they go viral, and they take off.

Cons:

If they don’t take off, they were probably a waste of time, and you’re unlikely to get your money back.

Other Examples:

MacHeist did a brilliant game to market themselves.

Audi made a fun driving game.

 

2. Content Apps

I call our next category “Content Apps”.  These are apps that contain information provided by your business that the user can carry in their pocket and associate with your company.

To the left here, we have a screen shot of iRescuer, an App we wrote for Texas Rope Rescue, which encapsulates their expertise on what to do during search and rescue operations for Emergency Medical Technicians and Rescue Personnel.

Texas Rope Rescue sells training classes to Rescue Personnel, so this App is useful to their intended audience, and has helped them to spread awareness of their classes.

Pros:

This kind of App provides value to your customers, hopefully making them like your brand or company more, and more likely to do business with you.

Publishing information in this format provides credibility to your company.

Cons:

You have to be somewhat careful not to give away so much content in your App that people don’t need you any more.  I would argue that, if your content is good and your service has value, people will still spend money on your services for the convenience of letting you do the work (which is why we can have both cookbook and restaurant industries simultaneously).

You have to provide something in the App that the user couldn’t just get off of your website, or Apple won’t allow the App to be published on their AppStore.

Other Examples:

The Mayo Clinic has several Apps like this.

Jamie Oliver has a cookbook App.

3. Tracking Apps

“Tracking Apps” are what I’m calling Apps that provide a mechanism for the user to conveniently record information that they can later refer to.

Here we have a screen shot from the Calorie Tracker from LIVESTRONG.com, an App one of us worked on at a previous job.

It helps users track what they eat and when and how much they work out.  This promotes a healthy lifestyle, which is what LIVESTRONG.com is all about.

Pros:

This provides real value to your customers.  Like the content App, only more so, it should endear your brand to your customer base, if done well.

Cons:

You have to find something that your customers get value from tracking, or it’s just busywork, and they won’t use it.

This is more complicated than just a content App, so more expensive to build.

You need to do more testing, because the user will get very upset if you lose or mess up their data.

Other Examples:

Nike+ GPS lets users track their runs.

4. Social Apps

“Social Apps” are what we’re calling Apps that facilitate interactions between your customers about or around your brand or company.

Here we have a screen shot from the  Amazon App.   This App does a fantastic job of making it easy for you to find out about products wherever you are ( It’s been said that 30% of consumers have researched a purchase with their mobile phone while they were in a retail store. and I bet most of those were using Amazon to do their research).  You could argue that Amazon’s website took this practice into the mainstream.  But it could work with many product and service businesses.

Note that despite the name “Social” here, and though many of these Apps can connect with existing social networks like Twitter or Facebook, that’s not a distinguishing feature of the category.  Facebook and Twitter may increase an App’s odds of being adopted (somewhat), but that’s true of almost any kinds of App in any category, so don’t think it’s unique just to what I’m calling “Social Apps”.

Pros:

This can both provide a real service for your customers and provide a valuable feedback mechanism for you to gather information.

These also encourage users to share these Apps with their friends, increasing your visibility without you having to work at it.

Cons:

This will require ongoing work and curation on your part.

There will be things the users don’t like that you might prefer they didn’t talk about.

You have to be careful not to appear to be censoring the community, or the users will likely revolt.

Other Examples:

Yelp is a classic App for letting users talk to each other about products and services.

5. Service Apps

The final category, I call “Service Apps” or “Customer Service Apps”.  These are Apps that allow your customers to use their phones to take actions that otherwise would have do be done in a way that is less convenient for them.

Here for an example, we have the Domino’s Pizza App, which lets you order pizza and see where their pizza is in the ordering and fulfillment process.

This could also apply to Apps that have coupons for the customer to use, or look up order status or package tracking or anything else that otherwise your Customer Service Staff (or website) would have to handle.

Pros:

This is a win-win.  The customer feels more connected to you, and you get better data from the customer.

Cons:

Wouldn’t be appropriate for all businesses.

Creates an expectation of responsiveness to customer demands that you need to be willing to live with.

Again, you have to make sure not to ruin the experience by having a bad App.

Other Examples:

Chipotle lets you order with an App now.

UPS and FedEx let you get information on your packages in transit with their respective Apps.

6. All of the Above

You don’t have to limit yourself to only one of these categories.  Some tracking Apps, for example, also contain content (The LIVESTRONG.com Calorie Tracker, for example, not only lets customers track foods, but has the nutritional information for those foods).  But even if your App falls in more than one of these categories, focussing on just one will help you make a better App.

You could probably think of others…

but these, we think are the major categories that are likely to fit with existing small to medium-sized businesses.

We hope this post has give you something useful to think about.  If you have any questions or comments, please leave them below and we’ll try to respond in kind as soon as we can.

And if you want to talk to someone about an App for your business, please:

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.

*Note.  This post was originally published on Carl Brown’s personal blog.