This seems to me to be estimating the cost to get from a fixed spec to "works on my machine (or simulator)" rather than the total cost to go from an idea to shipped product with non-technical stakeholders (whom your estimator is targeting), a diverse product team, changing understanding of the target, i.e., all the bits that investors struggle to understand seem to be omitted or minimized.
I've found in many years of building apps for clients, the easy part is forecasting simple programming costs. The hard part is helping folks understand time spent keying in code is only a small part of shipping successful software--and one of the more predictable ones. So, the cynic in me reacts with: "great, another over-simplification that instills more of those unreal expectations that so often cause failure."
Minor points worth reiterating from others:
* The rates are off for areas other than yours (how about making rates/regions an option?). And, I'd make it much clearer that the viewer is likely looking at offshore outsourcing pricing as that is a very, shall we say, unique approach to new product development.
* "Man" hours is a small, visual irritant due to the problematic gender relations and inequities in our field at the moment.
"Man hours" is not a visual irritant. It is not saying that only men can do work. It is not a statement on gender. It is the most common and easiest to understand way to express an idea. You are being overly pedantic and rabble-rousing for no good reason.
No. I'm making a pedantic (clearly) suggestion about a small visual irritant for the very good reason that because of the (hopefully) temporarily toxic environment in our field, some other human beings I care about might feel a bit put out by the choice of word A over word B. Words or humans? A different word could have been chosen at zero cost and made someone else feel better or less bad; so I'll suggest that door thank you--no it doesn't matter if those put out are being rational, expressing logic compilable by GCC, or otherwise fit with anyone else's ideas about what is proper and right, because it cost nothing to do.
I dislike thinking about stuff like this. It's a waste of time and a distraction from things that truly matter, e.g., Pluto! But, a bunch of jerks already set the stage and the tune and it behooves those of us wanting to profit on that stage to be aware.
If you have data or citations to back up the "most common and easiest to understand" please share, I'm always interested in seeing data. Here's what I have to offer, for what it's worth:
> I'm making a pedantic (clearly) suggestion about a small visual irritant for the very good reason that because of the (hopefully) temporarily toxic environment in our field, some other human beings I care about might feel a bit put out by the choice of word A over word B.
The problem is that an ugly little debate exists outside of this thread. You don't actually get to drag in small pieces of pedantry like that in isolation.
So, on the topic of this debate:
There are serious real problems in the world and in the software industry with people who are jerks, and (in particular, topically) unwelcoming and offensive to women. This is a very bad thing. And there are people who wish to fix this by changing the language we use. That's a legitimate position to propose and advance.
It's also a legitimate position to object to. But there are those come into the discussion wielding the hammer of Moral Authority, and often they suggest that if you fail to join the crusade to change a word like "man-hours" then you're an ignorant bigot riding high on all your privilege (you can already find some posts on this thread suggesting ideas from this group). Really, it isn't strictly about treating women decently, it's about demanding your subscription to and endorsement of a particular worldview and series of political prescriptions... it's about securing power and finding ways to stifle your opponents and detractors.
The essence of privilege is to define and defend a limited default. There is no reason to defend "man hours"; it is less accurate than "person hours" and only slightly longer.
Until those who don't recognise themselves as persons take offense to the obviously bigoted phrase "person hours." This whole argument reeks of fishing for things to be offended by. Any systematic problems women face in the tech industry are certainly not caused by something so insignificant as the use of the phrase "man hours."
The idea that someone must be "fishing for things to be offended by" starts from the assumption that this is not a thing that would legitimately offend anyone.
That's what I mean by defining the default. The default, in your point of view, is the word "man," so therefore anyone who objects to that must be "different" in some way: overly sensitive, manipulative, deficient, etc.
When in reality, "man" is the default because men made it the default. That doesn't mean that it has to remain the default.
I'm not suggesting that we go back and edit Neil Armstrong's words--they were of their time and are amazing. I'm suggesting that we're in a different time now, and starting now, it is within our power to choose the words we use.
The idea is to recognize the history and context of language, not assign all problems to one word. No single drop thinks it is responsible for the flood, etc.
Those are all still developing. "Developer" (as opposed to "software engineer") usually has connotations of being a full-stack role where you do everything needed to get a software product out the door. I've been doing graphic design in Photoshop for the last couple days, for example.
You're using the wrong definition for man to qualify your visual irritant. Man in this case means "human, person". If I say this will help all mankind, I'm not excluding a gender. You simply misunderstood.
I'm more than upset that we can't treat a topic seriously without someone sidetracking on an personal offense for "mandays". The OP didn't even suggest another word, nor does the industry have another established gender-neutral word.
Besides, women programmers are often quickly promoted, so yes there's only men left at the bottom level.
However, it's true that criticizing man hours is not understanding language or etymology.
We could go on with things like cowboy and cowgirl. Why do we call adults boys and girls? On the other hand, they are just terms. Just like husband really isn't interpreted as "house bound". Bound, tied to a house, i.e. not free.
But... people being people we see others getting in trouble when son misunderstand etymology and meaning like when people use synonyms for frugality and people find offense. There will doubtlessly be other words which fall into disfavor for looking or sounding too much like a scoundrel word.
I agree completely. Language is, although defined, still up for interpretation and can be very vague. That's why we have to communicate more when there is some misunderstanding. And also why some of us spend an inordinate amount of time pruning our writing and speech. I hate to lose people just due to miscommunication. I don't want to offend anyone, because then my message is never sent. I get - Protocol error, do not resend!
Yes, "man" in this context is unequivocally gender-neutral. Hence my point that it's a visual irritant due to a very specific situation rather than saying it was an incorrect usage or a discriminatory term.
Sorry I wasn't trying to be flippant or dismissive. I really am trying to point out a simple miscommunication. If the word truly offended someone I worked with I would substitute it for something else. I don't even like the term to be honest. Never have.
Oh, I wasn't really objecting to the content of what you said there... It's open for debate whether or not there's a better expression than "man hours".
I just wanted to point out that said debate would hinge on more than a narrowly semantic question about the meaning of "man".
You can plug in your own rates at the bottom :-) just click "Show Details"
Man hours will be changed to something much more gender non-specific once traffic calms a bit, good spot. We have many female developers and none pointed it out! :-)
"Man hours" is a great sounding phrase. It sounds way better than "person hours". "Person hours" just doesn't flow as well. People aren't going to write song lyrics with the phrase "person hours" in them.
How about an acronym, like "thips", totals hours in persons. Throw a poet a bone.
I consider "man hour" a terminus technicus and wouldn't change it personally. It's only an estimation tool and fine due to that but the term is problematic due to other reasons (mystical man month).
If you feel like you offend someone I think "billable hours" is what fits best (might sound too much like a lawyer though). Person hour et al. sound pretty strange.
I know you are joking, but the last thing this world needs in another acronym? If I was made a dictator in a fantasy world, all future suggested acronyms(related to computing) would have to be vetted by 12 well paid, top notch, Programmers. And only very few acronyms would be approved yearly--even the one that save time. I guess I'm just tired of so many acronyms? Or, maybe I'm just tired?
> Could in theory be done by a really talented member of anothery species
Not sure we'll reach the point of highly intelligent, tool making chimps and New Caledonian crows writing their own applications. "Murderable" (of crows) hours would lead to some humorous situations though.
"Hours" implies that it's all linear; that one task can't go until the previous is done. "Man Hours" indicates that it's the amount of time needed to complete the task, but isn't solely dependent on linear ordering
> You can plug in your own rates at the bottom :-) just click "Show Details"
Didn't see that and it helps.
Still i think the parent comment is important. If what you selling is just UI design and coding hours then you are not selling a completed app. Working with the client to go from a napkin sketch or idea to a shipped product involves a lot more work. Perhaps you could update the footnote at the bottom of the page about hosting costs etc to also mention the costs of requirements gathering and shipping. Nearly all of my past clients assume these costs are marginal at most if they think of them at all. Some of the more naive ones have assumed that ongoing support and training was somehow magicly included for free.
Yep, see your point, though the more detail you add the less accessible the tool is to at least give rough ideas of cost. Some people have crazy ideas of how much it costs to build apps. We had a customer this week who wanted a Kickstarter clone in 3 weeks! :-)
Plugging in rates would seem to be more applicable to me (a professional in the field) than to the target audience (people who don't know about app development.)
Maybe for the audience I think you're targeting: a few big buttons with labels such as "Thailand", "USA", "Western Europe", "Russia", "San Franspesive" and so on?
Biggest issue I have is that for anyone who uses this calculator, they will always see their app as "small" when it's really medium or large. Non-technical project stake holders will never grasp the depth of what they want built.
Second big issue is that there really isn't a good way in this calculator to estimate/account for proper testing and subsequently, time spent when a client changes their mind on a feature and wants to redesign/re-work.
35 person-days UI/UX + 162 person-days dev = $88,650
$88,650 / (35 person-days + 162 person-days) / 8 hr/day = $56.25/hr per person average cost.
Assuming the labor estimate is correct, if anyone knows of iOS developers skilled enough to pull that off for 56.25/hr fully-loaded labor costs I'd like to meet them. (e.g. who is coordinating the work and working with the client on evolving specs/feedback)
I understand and I know it's just an estimating tool but are you saying I can hire your team to deliver a gold-plated does everything iOS app with geolocation, health and sensor inputs, a top-notice design, etc including the detailed functional requirements (we all know what clients think is a complete specification), tested and delivered in the app store for 1,576hrs of billable work at $56/h total cost to me including any overhead you may have (like your market street sf office)?
You have just described why so much offshoring moved back to the US. If you need something cookie cutter that has already been done, sure, but then why are you building something that's already been done? If you have all the infrastructure to take everything else out of the equation except the raw development, then it often still makes sense to have a developer or 2 full time to maintain the app and understand the business needs.
I bet the offshore guys get a lot of work from all of the "I have an idea!" people though.
I think the point was you get what you pay for. $56/hr is probably above market rate in those locations for straight up development work, not the fully loaded costs of a project that size which will need to include requirements gathering, design, UX, testing, integration, etc outside of straight up development work.
from OP : "To be clear, this does not replace an official estimate (we also do not like fixed estimates and prefer agile pricing)"
Which is a very different type of estimate from fixed bid :), and makes this much more achievable especially when you're based out of Thailand. This seems to me like get the client in the door, introductory pricing.
The website looks great, and hopefully they'll get a lot of new leads from it.
I recognize the poster is not in the US but to answer your question:
According to the BLS the average hourly wage (not including overhead) of ALL us software developers is 45.81/hr. I would expect iOS developers to command a premium. Typical overhead of office space, management, equipment, benefits etc could easily add 50-100%
Occupation: Software Developers and Programmers (SOC code 151130)
Period: May 2014
Area name: National
Holy sh... I have to say, I am very bad at making estimates. I don't work freelance but it happened that I had to make some projects for people. I tried to estimate the cost of some applications that I made/make in my spare time and the average is way way way higher than I would have ever charged anyone... I need to reconsider my prices...
Which is amazing to be honest, making prices I really hard for me and a tool like this can be an amazing opportunity to find my value. Thanks
Do you think the results from this tool are HIGH? I went through a couple different apps I know and thought the estimate provided by the page needed to be multiplied by 3-5.
The default rates are $56 an hour. For Android/iOS developers, I know a dozen people making $100-200 an hour.
It's a great tool (and note you can actually adjust your price at the bottom), but I would consider all of the quotes around time & rate as the low end.
duiker's comments were more along the lines of how he's been underquoting.
Extremely common among early (or occasional) SWE freelancers IME, myself included.
IME, you can get to a point where you tally everything up and it comes to $65K, and then you start thinking, well this would be a fun side gig, and I have some free time I otherwise waste, and I sure could buy something cool with even $25K (after tax), and some of my estimates might be a little on the fat side, and this is a buddy (or isn't well funded, or both), and coding is fun enough that I sometimes do it for free anyhow, so I'll bid $45K.
And you've not accounted for the inevitable yak shaves, scope creep items, etc, but you got the work for $30K less than you should/could have.
btw you can actually plug in your own rates at the bottom. We are also going to make this a free tool for other agencies to use with their own feature lists, branding etc
So having done cost estimation before, this is horrible. About all it would be good for is the initial swag at brochure ware. Generally speaking cost estimates should never be a fixed point and should be done in a range, with assumptions (that when violated) would allow the cost numbers to change. In addition, there's no measurement of complexity through requirements. Basically all these estimators are useful for only the simplest software projects with extremely limited requirements and scope. The cost of the software is a function of the known requirements which are carefully enumerated during costing to generate some sort of complexity model. (For example, function point analysis). That's fed into a cost model that translates that complexity model into a dollar range. That interval is then used to generate a final, contractual, number. But notice all the work that went into that estimate. What's more is that the estimate is refined during the work such that new data is incorporated into the complexity model, allowing changes in scope or requirements to be re-priced.
To be clear, this does not replace an official estimate (we also do not like fixed estimates and prefer agile pricing). What it does give though is ballpark ideas for people with no information at all. Oozou is a 6 year old agency, we understand the problem deeply but wanted to give people something to get started without full blown proposals, RFP's etc
I view it as dangerous because it spits out a definitive answer without clear explanation of the model used to generate the estimate. If you look at other cost estimation tools (even closed source tools) will explain the model and assumptions used to generate the estimate. You can then make the determination if the model and assumptions apply to you.
It also doesn't indicate the kind of application (which is probably a largely stand-alone application). You can't stop some clients from going on to these sites and looking up a cost and not understanding what goes into an estimate. What would be even worse, in my mind, is to have other developers use a tool like this to generate a cost and then fail because they grossly underestimate complexity.
It does explain the model - each feature is given a certain number of developer days that are billed out at $450/day. It's all broken down if you click "show calculations".
I personally think their model is pretty shitty, because if you build an app as a checklist of features you'll end up with something users won't want to use, and if you polish all the rough edges and make sure everything integrates well together, you will spend a lot more time on integrations than on implementing the features. (My rule of thumb - across many projects - is that when a project is feature-complete, it is usually between 40-50% shippable. When it ships, it is about 50% "done", where "done" means that all the initial development tasks required to make it stable and useful to users are complete. When it's "done", it's consumed roughly 10% of the calendar time and 50% of the developer time that will ultimately be invested in the project.)
But you can at least judge the model they're using for yourself.
I've also done a ton of cost estimation and I thought this was a reasonably good approach for capturing the "core cost" of development of an app.
What it doesn't capture is testing beyond just design-code-unit-test such as multi-device testing, user testing, user acceptance testing, etc. and all of the change management that goes hand-in-hand with that.
I think that argument is only correct if you have fairly well understood pieces of work. I'm going to build an another on-line social recipe app. People type in recipes, they share those recipes, make comments on those recipes, maybe review the recipes, etc. I think their metrics break down very quickly when you start doing more interesting things like, taking automatically finding similar recipes based on the descriptions of the steps in the recipes. Or maybe performing a recommendation of recipes based on a user's rating of recipes.
Or, for that matter, correctly internationalizing the recipes and conversion of measurement units. (You don't want to have add 3.43272 cups of flour to 0.2347 gallons of water, when translating metric to imperial - you'll need logic to scale up/down quantities and round within a given tolerance - which is often narrow when you start baking pastries). Or there might be a service for this specific example that I'm not aware of, but the point is when you go beyond a very narrow scope, I believe this tool breaks down.
This is a pretty solid resource for freelance devs to mid-sized digital agencies. It falls short for more complicated applications that require custom architecture, a consultation piece, etc.
I think a lot of agencies/shops could benefit by creating a version of this that fits their pricing model based on previous projects -- Not as a hard estimate, but as a ballpark figure.
The cynic in me sees this as a great tool to roughly estimate then send that price times 5 to those pesky "I have this great idea how much could you develop it for" requests from people who think ideas are a get rich quick scheme.
We are the first to combine web and mobile I think. We are also going to make this a free tool for other agencies to use with their own features, figures etc
Double that to get the agency rate, and no one wants an app completely designed by juniors, you'll need at least one senior resource and probably a PM.
Well is not. In fact if you are based in a country other than the US you can arrive to those costs with competent developers. I think we are very competent, you can check us out in www.decemberlabs.com
Hey man I got a great app idea I am gonna let you in on. First, I need you to sign this NDA. I'll buy you lunch and tell you about. When this thing hits big, there could be a job in it for you. But for now, if you build the app I'll give you 5% of the company. When we sell this puppy, you're gonna be rich dude!!
Oh wait....you think that my advertising based business model is completely impossible and consider this the worst idea you have ever heard?? Well, you're clearly not very competent...:)
I hope none of my future clients come to me with a reference to this app for cost estimation. This estimation is vague and garbage. Good effort though.
Lets see... web app... small... click here... click there... one more click... $ 14.000
I don't know what I've been doing the last 25 years but now I know that I need the next 7 years to be a millionaire. Thank you!
Except you won't have the search algorithm, machine learning algorithms, and Hadoop stuff. But at least you'll just have a nice polished UI, with integration with Facebook, Twitter and Google+!
Curiously the page does not work on iPad in built-in HN browser.
Anyway, its priceless since will give exact answer to most of those wanting "my own branded messenger, and I only have €500 for this".
We have a similar concept, with a far less fancy estimator. http://www.decemberlabs.com/appEstimator.html
I think these estimators are good at helping non savvy potential customers tu understand the actual costs of making an app.
What I like about this is it introduces the concepts that can impact mobile app development to a crowd that has no way to know where one feature ends and another starts. If it's meant to be a conversation starter, I bet it might for non-experts.
This is clever but it definitely needs to be backed by real data and adjusted in the future. This would be a great use case for all the data that's been collected for research into programmer productivity!
So, if we go off the market rates for a business consultant skilled at developing a web application ($1k to $2k per day per consultant), and plug in the numbers here:
35 Man Days UX/UI Design -> probably $35k to $70k
178 Man Days Development -> $178k to $356k
The total cost is: $208k to $416k
The calculator's estimate: $95,850
So the actual cost is going to be anywhere from 2x to 5x higher than what this projects.
You're correct. It's just that our field is not in a good state with gender equality at moment, so some consideration beyond the literal meanings found in dictionaries is often worth the tiny effort. See: "to add insult to injury."
I completely understand your sentiment, but common parlance is "man-days" or in a famous example, "man-month". Granted, the commonness might be part of the problem.
I completely disagree. As a woman in the industry I find it excludes people who aren't male. Sure it's a small thing, but that means it's easy to correct. Recently I had a recruiter email me asking if I wanted to come on site and meet the chaps. Great, a men's club, how diverse and welcoming.
i get your point about 'chaps', its a term only ever used to describe a group of men. with 'man hours' its more difficult because the intent is never to talk about gender, just how much time something takes, and there are not commonly understood alternative terms for this (although maybe we need to pioneer an alternative...).
i'm also curious why you are offput from working with a group that is exclusively men because of the use of this term though? you are assuming its some kind of 'old boys club'. i think this is sexism
the perception of sexism won't go away until these groups get some women in them... i would find it hard to believe that there was a sexist intent behind that statement. it sounds like he is trying to be welcoming in fact... and to encourage diversity by not excluding you from this opportunity for such a weak reason as your gender.
I loved reading that in a controlled study simply writing at the top of a PHD level maths paper "This maths paper has been tested to be gender neutral"[1] caused the scores of women to magically change to be equal with men.
Never underestimate social conditioning of outcomes.
[1] I wish I could remember or find a reference for this!
that is fantastically interesting. i'd be curious if the effect was on the men or women or both, as well as if there were any other experiments in similar areas.
it solidifies my belief that most gender inequality today is perceived rather than real. (not that that makes it any less of a problem to solve)
Finally I get to read something like that. I'm not even a native English speaker, but non-sexism would be reading 'man-hours' and implying that men and women are meant, not differentiating both. After all, 'man-hour' is a not a new term that excludes women, like someone else already pointed out.
I'm very sure that excluding women wasn't their intent.
I chose an iOS app with every option, and then added an Android app with every option. The price doubled. I guess that means Oozou will charge you twice for designing or coding assets that'll be reused between platforms.
You can't straight up share most things between platforms. You have to adjust layouts and resources into the sizes and formats dictated by the platforms.
I wasn't suggesting the price should be the same for developing both, just that it isn't double. You can share design assets, logic, algorithms, etc. For a complex app that stuff is actually what takes most of the time - but you only have to do it once regardless of how many platforms you end up deploying to.
There are some outrageous time estimates in this. 7 days to create an auth system with the big 3 social integrations? 6 days for private messaging? 2 days to dump a prefab social sharing blob in your template?! I'd do all of that in a morning.
I'd just be careful if you're considering using this to quote your jobs. If somebody working for me quoted these sorts of numbers, I'd fire them on the spot. I wouldn't even give them a second chance. It would clearly demonstrate you didn't know what you were talking about.
You could do it all in a morning if you didn't do any of the following:
- Create and implement a high fidelity design.
- Include the project-specific requirements that every feature has... the auth system needs to work via ajax, connect with a legacy db, and include animated transitions. Private messaging needs responsive design and realtime updates. Etc. etc. etc.
- Deal with scope creep, clarifications of the specs, and hours of related discussions.
- Write automated tests.
- Do live QA.
- Fix inevitable bugs, browser and device inconsistencies, ux problems, etc. etc. etc.
- System administration and deployment.
- Load testing, caching, performance tuning.
If a client tried to tell me I should be able to do all this in a morning, I'd fire THEM on the spot.
You're not reading what I said. The design is accounted for elsewhere in the calculations (that's actually a bit closer to the mark) and that includes many of the things you're talking about above.
My "morning", is literally plugging django-social-auth, a custom User Model, a private messaging Model and few views to make it all work.
I'll grant you that testing might eat up the afternoon, but these are all solved problems that ship in libraries, many of which include their own tests.
Perhaps the people downvoting need to change how they build stuff.
The result of your single morning would be a clunky ux that no one wants to use (or pay for). No one's saying you can't get a good start on the data model and basic skeleton in a single morning, but only someone who's never produced working, polished software would contend a finished and tested feature of any significant complexity at all could be truly finished in a morning.
Well, it sounds to me like you haven't worked on systems of any complexity. Seven days for a federated auth system that behaves the way people actually want it to behave is very, very low.
And when you're behind, because you keep underestimating difficulty, and the client is tired of your excuses, one of us will swoop in and show them how a real developer works.
I've found in many years of building apps for clients, the easy part is forecasting simple programming costs. The hard part is helping folks understand time spent keying in code is only a small part of shipping successful software--and one of the more predictable ones. So, the cynic in me reacts with: "great, another over-simplification that instills more of those unreal expectations that so often cause failure."
Minor points worth reiterating from others:
* The rates are off for areas other than yours (how about making rates/regions an option?). And, I'd make it much clearer that the viewer is likely looking at offshore outsourcing pricing as that is a very, shall we say, unique approach to new product development.
* "Man" hours is a small, visual irritant due to the problematic gender relations and inequities in our field at the moment.