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.
*Note. This post was originally published on Carl Brown’s personal blog.