[fullwedgewhale]

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.

[dynjo]

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

[fullwedgewhale]

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.

[nostrademons]

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.

[numbsafari]

A ballpark estimate should be given within a range.

If you aren't communicating the probability of it either being less or more expensive, then you are setting a false expectation.

[jayvanguard]

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.

[fullwedgewhale]

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.

[jayvanguard]

Very true. It doesn't leave any room for exploration of requirements or the usual customer waffling.