Hi all
how do you estimate the price of a RoR application.
Do you calculate the value:
- counting the days or hours you worked in, and multiply that by a
rate? - estimate a price for the whole applicatiion using other criterias?
Pepe
Well this is more of a matter of opinion than anything. It really also
depends on what purpose you’re trying to evaluate it for. If it’s for a
single one time sell to another business you would calculate the worth
of
the application based off the potential income it will bring to that
buyer.
If you’re trying to determine the value of an application as far as what
it
would cost to duplicate it - you would base it off a formula of hours *
avg.
industry pay rate * 50% (overhead). You might also base the price on the
current income it’s generating * 4 years.
The method for calculating the price of a ROR app isn’t any different
than calculating it for any other web app. In my view, since developing
time is shorter than other frameworks/languages, I can charge more per
hour than say a PHP or .NET application. That’s if you choose to charge
based on estimated development time.
On Dec 29, 2006, at 3:23 PM, Jose P. wrote:
Pepe
Hi Pepe,
The subject is so complicated, I don’t think a good answer is
possible without referring you to other sources. (e.g., the book,
“Eric Sink on the Business of Software” is a good one.)
With that said, I’ve been doing this for a few years. Here’s some
stuff to think about:
-
What are your competitors charging? Adjust your prices to how much
better or worse you are than them. For example, if you’re 50%
better, charge 50% more. It’s not perfect, but it’s a reasonable
place to start. -
Almost everyone equates price with quality. Cheap = bad.
Expensive = good. If you undercut your competitors because you
really need the money, your customer is going to second-guess
everything you do and expect you to work weekends and nights. If
you’re expensive, they’ll let you work in peace and when you make
suggestions, they’ll actually listen to you. -
Some corporations have rules that require them to take a discount
if one is available. You can use that to your advantage by offering
a discount if they pay in advance. Most of my bids are paid for in
advance. (I offer 15% off.) -
Per hour rates are scary for clients. What’s to stop you from
taking your time? It’s like a blank check. -
A flat price is much easier to get accepted. It’s
straightforward. But it’s dangerous for you. You’re going to have
to really protect yourself. Specify exactly what is going to be done
for that price. Don’t be vague about anything. Because in the
middle of the project, when they ask for something not in the
original agreement, you’re going to have to be firm from the start.
Say something like, “That’s a great idea. But I’m going to have to
run some numbers and get back to you on what it’s going to cost.” If
you give them anything free, they’ll ask for something else, then
something else, then something else, then the next thing. And
there’s going to be hurt feelings when you finally put your foot
down. You can avoid all of that by being firm the first time they
ask, then they’ll respect you as a professional.
Good luck!
- Michael J.
Micahel’s got a lot of great points.
We tend to do it one of two ways: Lump sum or in phases.
With lump sum, we feel that the requirements are complete enough to
give them a hard bid for the deliverable. We are picky about ANY change
to the scope as clients love to creep the scope. If the client doesn’t
know the scope enough, they usually know the basic core. So we say
we’re going to do the work in phases with very high level phases
(releases) mapped out. This also gets something released in the
client’s hands faster.
They can spend money to a point they’re happy with (a few thousand vs
$20k +) and have something to show for it that allows them to get more
funding. We find this to be a big problem in the non-profit world,
where a non-technical person budgets a tech project and the project
manager’s hands are tied for that fiscal year.
We have a good working relationship with a non-profit in town so that
they call us and ask us to help them scope a project. We’ve done about
8 different database driven sites for them in the past few years, one
of which was a massive content site that we bid poorly. Client got a
great deal. But we learned the hard way.
-John
www.boboroshi.com | www.meticulous.com
Michael, John thank you very much for you advice.
One of the big limitations in our job – developing RoR or other IT
applications- is that requirements are rarely complete. And it is hard
to find customers that are able to specify them clearly. Also new Agile
development techniques, explain that requirements do not need to be
completed before starting a new project, and are part of the iterative
process where requirements, analysis, design and coding loop until the
project is completed, creating releases, milestones and versions.
Do you apply any Agile to estimate the cost of a project?
Do Agile methodologies help you estimate?
Pepe
Where can I get any information about the average industry pay rate for
developing RoR applications?
How do you know that when equating price with quality, that you are not
on the Cheap = bad level?
thank you
Pepe
Jose P. wrote:
Do you apply any Agile to estimate the cost of a project?
I am not sure what you mean? what is Agile method has to do with
pricing? Seems like you are trying to sell consulting services. Tell
your customer X number of hours needed for Y and then charge the amount.
I prefer to be honest with customers cos that customers keep coming back
for more… Which is far more important then another extra 20%… If you
are trying to make a one shot delivery and don’t want to see your
customer thats another story…
Do Agile methodologies help you estimate?
NO… Agile is not a life saving method… its a way of
developing/delivering projects thats all.
Pepe
On Dec 31, 2006, at 5:33 PM, Antonio E. wrote:
Do you apply any Agile to estimate the cost of a project?
I am not sure what you mean? what is Agile method has to do with
pricing? Seems like you are trying to sell consulting services.
Tell your customer X number of hours needed for Y and then charge
the amount. I prefer to be honest with customers cos that customers
keep coming back for more… Which is far more important then
another extra 20%… If you are trying to make a one shot delivery
and don’t want to see your customer thats another story…
Problem with agile methodologies is they assume the project takes
shape via short iterations, they are more adaptative. That’s the
selling point. Nobody knows in advance enough about the project to be
able to give a price based on features/effort. You have a more or
less vague high-level vision of what they want, and perhaps a time
constraint, and start working from there. Less docs, less formal stuff.
The answer to that is that since the client gets involved and sees
the evolution of the project by first hand, (ideally) they will
reasonably agree about the scope within the price as the project
takes shape.
– fxn
On Dec 31, 2006, at 8:39 AM, Jose P. wrote:
Where can I get any information about the average industry pay rate
for developing RoR applications?How do you know that when equating price with quality, that you are
not on the Cheap = bad level?
There’s absolutely zero need to know the average industry pay rate.
The only important metric you need to know is how much you can get
for a given job from a given customer.
This information is not easy to come by.
Basically no amount of research will help you determine it, other
than getting in from of potential customers and finding out how much
they’re willing to pay you, and how much you can convince them to pay!
This discussion comes up in development forums all the time, and I
always see technical people giving technical answers. These answers
are often detailed, logical, based upon (their) experiences, and are
almost always dead wrong.
The question you’re asking is not a technical question. It’s
largely a question of (gasp!) sales and marketing.
Assuming you live and work in a free market economy, the only
correct answer to the general question “How much should I charge for
a job?” is the simple and painfully obvious “As much as you can.”
My answer will likely get flamed, as it tends to make technical
people very nervous because it makes obvious the truth that the
question does not have a technical answer, only a social answer. 
If you try to apply a technical answer to this problem, there’s a
very high likelihood that you’ll either charge too little, or not
work enough, to make ends meet. You’ll be continuously befuddled how
other companies that you know, who are far less technically adept
than you are, continuously win the juiciest bids and live in the
nicest neighborhoods.
–
– Tom M., CTO
– Engine Y., Ruby on Rails Hosting
– Reliability, Ease of Use, Scalability
– (866) 518-YARD (9273)
An example …
http://www.payscale.com/research/US/Industry=Consultant/Hourly_Rate
Cheers
On 12/31/06, Jose P. [email protected] wrote:
Where can I get any information about the average industry pay rate for
developing RoR applications?How do you know that when equating price with quality, that you are not
on the Cheap = bad level?
No clue… something you have to learn by doing …
On Dec 31, 2006, at 8:20 AM, Jose P. wrote:
Do you apply any Agile to estimate the cost of a project?
Do Agile methodologies help you estimate?
A fully Agile development shop would, almost by definition, charge by
time and materials.
Truly agile development means there’s no way to estimate time and
energy in advance.
–
– Tom M., CTO
– Engine Y., Ruby on Rails Hosting
– Reliability, Ease of Use, Scalability
– (866) 518-YARD (9273)
Hi,
On Dec 31, 2006, at 8:20 AM, Jose P. wrote:
Michael, John thank you very much for you advice.
One of the big limitations in our job – developing RoR or other IT
applications- is that requirements are rarely complete. And it is
hard to find customers that are able to specify them clearly. Also
new Agile development techniques, explain that requirements do not
need to be completed before starting a new project, and are part of
the iterative process where requirements, analysis, design and
coding loop until the project is completed, creating releases,
milestones and versions.
(I don’t know anything about the Agile methodology. But I
understand what you’re saying. Not every project you’re asked to bid
on has clearly defined requirements [e.g., how much would it cost to
make a web 2.0 community website for _____ who are interested in ____?])
These kinds of projects have always been disasters for me.
It makes sense now that I think about it. I’m a developer. I make
people happy by selling solutions to problems. When the customer
can’t describe their problem, how am I supposed to solve it? How
will we both know if I succeed? What if it’s not a real problem, but
a hypothetical one, meant to be sold to hypothetical people, in a
hypothetical market, and the customer doesn’t know anyone real who
has experienced the problem, so we can’t even ask anyone about it?
That’s madness.
Kind regards,
Michael J.
I agree with Tom in large measure. I don’t estimate Rails apps any
differently than C++ or whatever. I charge time & materials at a rate I
can
live with (and I don’t refer to what anyone else is making). When a
client
wants to know what it’s likely to cost, I (at their expense) break out
stories (components of functionality) as well as startup, design,
outside
dependencies, configuration, and deployment. I make some adjustments to
include having good tests. Then I apply the usual arithmetic and attach
the
BIG CAVEAT that depending on the way the project goes, it could be less
or
more but this is a dart at the wall.
Back to what everyone else is making. As a consultant, you may want to
consider this in determining your hourly rate, but I recommend against
it.
Again, if you decide you are worth $x because you’re a good developer
and
have experience in lots of problem domains, then if someone balks at it,
that might be business you don’t want. How would that potential client
react
to you if you didn’t bring the project in on budget? Shopping for a
developer is not like shopping for detergent where the best price wins.
Low
cost solutions can turn into high cost ones very quickly if the wrong
people
are applied to the task.
Just my $.02
Zaheed Haque wrote:
Where can I get any information about the average industry pay rate for
Posted via http://www.ruby-forum.com/.
–
View this message in context:
http://www.nabble.com/-Rails--How-do-you-estimate-the-price-of-a-RoR-application-tf2896999.html#a8110106
Sent from the RubyOnRails Users mailing list archive at Nabble.com.
On Dec 31, 2006, at 2:37 PM, Michael J. wrote:
design and coding loop until the project is completed, creating
It makes sense now that I think about it. I’m a developer. I
make people happy by selling solutions to problems. When the
customer can’t describe their problem, how am I supposed to solve
it? How will we both know if I succeed? What if it’s not a real
problem, but a hypothetical one, meant to be sold to hypothetical
people, in a hypothetical market, and the customer doesn’t know
anyone real who has experienced the problem, so we can’t even ask
anyone about it? That’s madness.
This is what time and materials is all about.
I’ve recently come to realize that project based billing makes no
sense! It guarantees, even under the best of circumstances and
customer relationships, that you and your customer are at odds from
day one, regardless of how well you perform.
You want to finish the job as soon as possible, which maximizes the
value for you. The customer wants as many features and polish as
possible, which maximizes the value for them.
And if the situation is less than ideal, there’re problems as well.
If you’re early, the customer will, in a sense, feel cheated. Even
though they decided to pay X amount for Y project, if the hourly/
monthly/yearly income that generates for you seems too high to them,
they’re going to feel gouged.
And, if the project goes over time, the customer is pissed because
it’s late, and you’re pissed because your income is dropping below
expectations.
The only way that project based jobs can be entirely successful is if:
- You estimate the time time and value perfectly
- That time and value match the customers’ expectations
- Your value matches the customers expectations of your value.
- You have a perfect plan at the beginning
- The customer is satisfied when you execute the plan perfectly.
This seems like it would be a truism, but rarely is! Very often, if
you produce what the customer communicated, they will end up unhappy.
Now, as previously stated, you must realize that what’s right isn’t
necessarily what works.
The Rails community would do the web development a larger favor
bringing in time and materials billing, based upon Agile development
practices and the Getting Real business mechanics, and leave fixed
bid billing far, far behind.
I do not expect this will happen, however.
–
– Tom M., CTO
– Engine Y., Ruby on Rails Hosting
– Reliability, Ease of Use, Scalability
– (866) 518-YARD (9273)
Jose P. wrote:
UML, UP and Agile methodologies can help implementing a project, but stay
in my opinion very confusing in the beginning of a Project to initiate and
plan the famous iron triangle: cost, time, quality.
UML is not a methodology, and UP can be used as an Agile methodology.
They are confusing around the project estimation “phase” because they
don’t
lie (unlike some methodologies). Instead, they cast light on just how
confusing this topic is. You cannot set a quarterly schedule for 1,000
features, and then hit your ship date. You must estimate in terms of
“horizons”, where the near-term features are specified in detail, and
the
long-term ones are just general goals.
Sort features by business priority, do the highest value ones first,
demonstrate them to your goal-donor early and often, and let them
calculate
your velocity and make the predictions. The best estimate is a
measurement.
The iron triangle looks like this:
- Time
- Treasure
- Talent
- Technique
- Target
You should only try to vary Target (scope). Your goal-donor’s job is to
intercept and censor as many requirements as they can. If you think you
need
a tree-view, they will order you to get by with a simple list box, for
example.
To keep your velocity fast, over time, you must keep your Technique
(quality) as high as possible. In Rails, that means adding tests, in
every
test rig, for every feature, no matter how trivial.
–
Phlip
Redirecting... ← NOT a blog!!!
Thank you for all these excellent answers. They cover aspects that I
have not though about, before I read them.
I am currently working in a group that is trying to define standards for
IT people that are involved in software development. We already had
several meetings where we decided that the subject must be split in
three different parts
• Technical standards: such as coding conventions, database naming
conventions, web application templates, and other tools that can
simplify development tasks
• Software life cycle standards, that cover requirements, analysis,
design, coding, testing, delivery, and maintenance
• Project life cycle, where aspects of cost, time and quality (scope).
One of the major questions is about how to estimate the cost, duration
of a project, and also when several projects are in a waiting list, how
to define priorities to select one versus the other.
UML, UP and Agile methodologies can help implementing a project, but
stay in my opinion very confusing in the beginning of a Project to
initiate and plan the famous “iron triangleâ€: cost, time, quality.
Jose P. wrote:
very interesting. Thank you!!!
Read one of the Lean Software Development books by the Poppendeicks.
–
Phlip
Michael J. wrote:
- Almost everyone equates price with quality. Cheap = bad.
Expensive = good. If you undercut your competitors because you
really need the money, your customer is going to second-guess
everything you do and expect you to work weekends and nights. If
you’re expensive, they’ll let you work in peace and when you make
suggestions, they’ll actually listen to you.
This piece of advice is gold, as it took me a long time to appreciate.
Several times in the past I submitted very low bids to projects I wanted
to ensure winning. I learned the hard way that if you charge too little,
your customers won’t respect you.
By charging too little, you are communicating that:
-
You are worth less. Your work’s quality is less than your
competitors’. Which can naturally lead to the customer thinking he can
and even must supervise you, with his own IT department or even himself.
Also, think for a second: do you really want to work with someone who
aims for low-quality product for (usually relatively insignificantly)
lower cost? Most serious enterprises would pay a lot more for a quality
product. Usually, paying the developer even the best salary would still
be chump change compared to what they stand to earn off your work
assuming it is good. -
You are somehow weak, or in difficulties. Or both. Which, amazingly
enough, leads him to be more neglectful of your meagre pay than what he
would have been if you charged more. They do that either because these
sums are so small, they can’t possibly be important to you. Or because
they assume you make too little to be able to legally threaten them with
lawsuits, especially over such relatively small sums. Or because they
generally disrespect you. If you are in financial difficulties, and this
project is the only thing that stands between you and the street. Which
leads to the next point - -
You will put up with abuse. They assume you are less important than a
normal developer; therefore you are not a factor in their
considerations. They won’t listen to you, on the contrary: they’ll
happily hurl many arbitrary decisions at you, without consulting you.
Specs would change more often, without proper notice. You will be put in
inconvenient situations, and nobody would bother or care to make you
feel better about anything. In particula: -
Your time is less valuable. In fact, they’ll totally disregard the
amount of your time anything takes: your time has become a free,
unlimited resource. I usually throw in an extra 5%-10% uncharged time to
good customers. They usually appreciate it a lot, and it’s very much
worth it in the long run; the customer will feel good that you gifted
him with 10-20 hours of your expensive (!) time for free, and next
project would accept a higher bid from you since he enjoyed the
experience. But if your time is very cheap, what’s to appreciate?
Moreover, because of 1 and particularly 2, they’ll assume you can’t cut
off. So you easily end up working 150%-200% or more of the time in the
original bid, for the same bad pay. And the icing: they won’t appreciate
it. At all. Hey, your time is virtually free, why would they apprecite
you spending it?
-Chris
On 1/1/07, Phlip [email protected] wrote:
The iron triangle looks like this:
- Time
- Treasure
- Talent
- Technique
- Target
I thought triangles had 3 sides…that looks more like an iron pentagon
to
me.