Fair Market Value for a Custom iPhone App?
November 23, 2009 12:18 PM Subscribe
What's the going rate for custom iPhone application development?
I've been asked to do an iPhone app for a local business. I'm capable technically, but I have no idea what the market rate for this kind of thing is. If you've done this/had this done for you, or know of someone in either position, what is a fair price tag?
It's a reasonably basic app, no OpenGL or anything crazy.
I've been asked to do an iPhone app for a local business. I'm capable technically, but I have no idea what the market rate for this kind of thing is. If you've done this/had this done for you, or know of someone in either position, what is a fair price tag?
It's a reasonably basic app, no OpenGL or anything crazy.
It really, really varies. We've spent between $1,200 and $50,000 (and counting!) to develop apps. I think you need to speak to other developers and find out how they charge (per hour? by complexity? flat rate with deadline? retainer?) rather than asking the people who pay for such development but don't know what goes into it.
posted by peanut_mcgillicuty at 1:11 PM on November 23, 2009
posted by peanut_mcgillicuty at 1:11 PM on November 23, 2009
I've recently bid on making a few iPhone applications, and this is the general guideline that I've been using. I assume that there's a known low, medium, and high development rate for your area. No idea whether this is applicable to your circumstances.
1. Applications that can basically be written using UINavigationController, UITableView, and by making a couple custom subclasses of UITableViewCell are generally easy and should be billed according to a lowish development rate for your area.
2. Applications that involve doing a couple other things than that locally are higher just because the iPhone is oriented (imho) to making it easy to make apps on that paradigm.
3. Applications that require substantial network access that there isn't a corresponding library to make it easier (ie: ObjectiveResource to interact with ruby-on-rails-based applications) go up a step. Getting this right and optimized is hard. Getting this wrong is easy. However, right and wrong are relative to your customer's desires and user community.
4. Based on whether or not the website that you're pulling data from can modify/add code to respond to requests is also a factor -- it's way easier to have a decent performing application if you don't have to make a ton of requests to figure out what to display and/or parse random XML. This is a generic network / SOA problem, but it's especially true when dealing with AT&T's network (or Telus/Rogers/whatever)
5. CoreData makes things easier. If you can use core data, everything will be easier.
6. Applications that can't be created using stock controls (which is the Cocoa Touch controls + some things like the 3twenty library + some other things available on the net) are harder.
So, basically, I've been going with the assumption that it will take me a certain amount of time to make each piece of functionality, and then figuring out what the rate is based on the difficulty based on the above criteria.
It seems that certain ways that customers may want to organize/change their apps are different if they're mostly used to dealing with websites in the past, so it pays to get good user feedback prototyping early on especially if you're outside of the NavigationController/TableView/TableCell paradigm. Also, depending on whether your customer has a development/qa process or not may make for an easy time or a hard time getting the app accepted, and don't forget to factor in the time spent playing with the iphone developer program on their behalf if that's relevant.
My opinion, though, is that because there have been large amounts of relatively new developers rushing towards the iphone platform due to the endless amount of free money that drips from the blessed font of steve, etc., the market for iphone devs may be saturated enough to keep rates near the low end in some geographical areas for bidding. My 'kid develops iphone apps' is the new 'my kid is a web designer.'
I'd be interested in getting people's feedback on this. saraswati, you might also try asking this question at stackoverflow which is a community more or less oriented towards having strong, well-informed opinions on this sort of issue.
posted by corprew at 1:54 PM on November 23, 2009 [1 favorite]
1. Applications that can basically be written using UINavigationController, UITableView, and by making a couple custom subclasses of UITableViewCell are generally easy and should be billed according to a lowish development rate for your area.
2. Applications that involve doing a couple other things than that locally are higher just because the iPhone is oriented (imho) to making it easy to make apps on that paradigm.
3. Applications that require substantial network access that there isn't a corresponding library to make it easier (ie: ObjectiveResource to interact with ruby-on-rails-based applications) go up a step. Getting this right and optimized is hard. Getting this wrong is easy. However, right and wrong are relative to your customer's desires and user community.
4. Based on whether or not the website that you're pulling data from can modify/add code to respond to requests is also a factor -- it's way easier to have a decent performing application if you don't have to make a ton of requests to figure out what to display and/or parse random XML. This is a generic network / SOA problem, but it's especially true when dealing with AT&T's network (or Telus/Rogers/whatever)
5. CoreData makes things easier. If you can use core data, everything will be easier.
6. Applications that can't be created using stock controls (which is the Cocoa Touch controls + some things like the 3twenty library + some other things available on the net) are harder.
So, basically, I've been going with the assumption that it will take me a certain amount of time to make each piece of functionality, and then figuring out what the rate is based on the difficulty based on the above criteria.
It seems that certain ways that customers may want to organize/change their apps are different if they're mostly used to dealing with websites in the past, so it pays to get good user feedback prototyping early on especially if you're outside of the NavigationController/TableView/TableCell paradigm. Also, depending on whether your customer has a development/qa process or not may make for an easy time or a hard time getting the app accepted, and don't forget to factor in the time spent playing with the iphone developer program on their behalf if that's relevant.
My opinion, though, is that because there have been large amounts of relatively new developers rushing towards the iphone platform due to the endless amount of free money that drips from the blessed font of steve, etc., the market for iphone devs may be saturated enough to keep rates near the low end in some geographical areas for bidding. My 'kid develops iphone apps' is the new 'my kid is a web designer.'
I'd be interested in getting people's feedback on this. saraswati, you might also try asking this question at stackoverflow which is a community more or less oriented towards having strong, well-informed opinions on this sort of issue.
posted by corprew at 1:54 PM on November 23, 2009 [1 favorite]
How long is a piece of string?
You don't really give any information on what the application requires, so it's pretty impossible to tell you what it would actually cost me to build. But, I charge $65US/hour. There are cheaper programmers out there, but you get what you pay for.
posted by Netzapper at 2:33 PM on November 23, 2009
You don't really give any information on what the application requires, so it's pretty impossible to tell you what it would actually cost me to build. But, I charge $65US/hour. There are cheaper programmers out there, but you get what you pay for.
posted by Netzapper at 2:33 PM on November 23, 2009
Charge by the hour. That way, when they want changes in a few months, you've got a story and they know it will cost them. If you did it strictly as a one time fee, future work will be subject to new negotiations.
posted by chairface at 2:50 PM on November 23, 2009
posted by chairface at 2:50 PM on November 23, 2009
It's a software development project, the same as any other. Quote a fixed price, but base it on a detailed estimate/timeline based on your hours, and include extra costs for changes after the fact.
posted by rokusan at 5:22 PM on November 23, 2009
posted by rokusan at 5:22 PM on November 23, 2009
Best answer: 65/hr sounds okay for first party small projects. but you don't base it on actual time for development, because that's unprofessional. Here's the real process:
1) Interview client, see what they want, draw on some napkins, get a feel for how professional they'll be and then ask what their budget is. If they don't have one RIGHT NOW, walk away. You don't want to deal with people who aren't thinking about money.
2) If the budget is in the ballpark of what you can handle, you tell them the next step is for them to pay for you to create a functional specification, which may be two hours or twenty, depending on complexity. You sell this by saying the functional spec is necessary for your bid so you know what they really want, and if they don't like your bid, they can shop the spec around to someone else, no hard feelings. If they don't want to pay for your spec, WALK AWAY. You don't wan to deal with people who aren't willing to pay for your time creating a spec -- which is the definition of your deliverable. (If they have a functional spec that is detailed enough for you to bid on, skip this step.)
3a) Prepare a detailed estimate, roughly 5-20 line items broken out by functionality, in hours and dollars. This lets the client scale back their project to what you CAN do for their budget if they don't like the bid. Key point: Don't make the quote based on their budget, make it based on the spec they paid you to create. If the quote is way over budget, give a recommendation of what FEATURES can be cut to make it hit the budget, or be close. Do not forget to include time for testing, bug fixes, deployment and post-deployment cleanup. If client doesn't want to pay for those items, or asks why they are there, WALK AWAY.
3b) Prepare a list of milestones with dollar amounts associated with them. And prepare a contract which stipulates in no uncertain terms that monies are due when milestones are hit, and that delayed payments result in delayed milestones. If it's a new customer, include a clause that stipulates all code remains your IP until final payment is made. If they balk, WALK AWAY.
4) Motherfucking deliver that son-of-a-bitch on time and fractionally under budget.
5) Profit.
posted by seanmpuckett at 5:50 PM on November 23, 2009 [8 favorites]
1) Interview client, see what they want, draw on some napkins, get a feel for how professional they'll be and then ask what their budget is. If they don't have one RIGHT NOW, walk away. You don't want to deal with people who aren't thinking about money.
2) If the budget is in the ballpark of what you can handle, you tell them the next step is for them to pay for you to create a functional specification, which may be two hours or twenty, depending on complexity. You sell this by saying the functional spec is necessary for your bid so you know what they really want, and if they don't like your bid, they can shop the spec around to someone else, no hard feelings. If they don't want to pay for your spec, WALK AWAY. You don't wan to deal with people who aren't willing to pay for your time creating a spec -- which is the definition of your deliverable. (If they have a functional spec that is detailed enough for you to bid on, skip this step.)
3a) Prepare a detailed estimate, roughly 5-20 line items broken out by functionality, in hours and dollars. This lets the client scale back their project to what you CAN do for their budget if they don't like the bid. Key point: Don't make the quote based on their budget, make it based on the spec they paid you to create. If the quote is way over budget, give a recommendation of what FEATURES can be cut to make it hit the budget, or be close. Do not forget to include time for testing, bug fixes, deployment and post-deployment cleanup. If client doesn't want to pay for those items, or asks why they are there, WALK AWAY.
3b) Prepare a list of milestones with dollar amounts associated with them. And prepare a contract which stipulates in no uncertain terms that monies are due when milestones are hit, and that delayed payments result in delayed milestones. If it's a new customer, include a clause that stipulates all code remains your IP until final payment is made. If they balk, WALK AWAY.
4) Motherfucking deliver that son-of-a-bitch on time and fractionally under budget.
5) Profit.
posted by seanmpuckett at 5:50 PM on November 23, 2009 [8 favorites]
Sean's milestone descriptions are spot on. I agree that you should not show your hours calculations, but you should always do them for your own benefit... even if that benefit is realizing that next time, you should allow for twice as much time.
posted by rokusan at 6:28 PM on November 23, 2009
posted by rokusan at 6:28 PM on November 23, 2009
This thread is closed to new comments.
posted by DarlingBri at 1:01 PM on November 23, 2009