How do you estimate the price of a RoR application

rubyonrails-talk
1

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 Judge

2

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

3

An example ..

http://www.payscale.com/research/US/Industry=Consultant/Hourly_Rate

Cheers

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 ..

4

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

5

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. :slight_smile:

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. :slight_smile:

6

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.

7

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:

8

Hi,

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 Judge

9

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:

1) You estimate the time time and value perfectly 2) That time and value match the customers' expectations 3) Your value matches the customers expectations of your value. 4) You have a perfect plan at the beginning 5) 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. :slight_smile:

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.

10

Jose Pepe 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.

11

Jose Pepe wrote:

very interesting. Thank you!!!

Read one of the Lean Software Development books by the Poppendeicks.

12

Chris wrote:

This piece of advice is gold, as it took me a long time to appreciate.

I don't know if the following advice is good or bad, but here goes.

Each week, I review the project with my customer, then ask what to work on the next week. Each thing he says I write on a card. Then I write acceptance criteria for each item, and (alone without the customer), I think of an "ideal hours" for each time.

Then I present to the customer a list of features, each with its line-items and their ideal hour estimates. The customer censors any line-items he doesn't want.

Then I charge that many hours for that week.

This way, if I get stuck on a bug or an irritating piece of research, I don't need to worry about charging the customer for my stupidity. I can take my time, receive interruptions, clean up the garage for no apparent reason, hang out at the mall with my family, noodle around on a notebook while watching TV, etc. I don't need to log each danged minute that I'm making "progress".

Without this "ideal hours" system, we expect such research to average out over time, but I don't want to wait for that average. I want the customer to own the feature requirements and their priorities, and I want him to censor any item that would slow down a delivery.

13

I thought triangles had 3 sides…that looks more like an iron pentagon to me.

14

subimage interactive wrote:

> - Time > - Treasure > - Talent > - Technique > - Target

I thought triangles had 3 sides...that looks more like an iron pentagon to me.

What do I look like? A Pragmatic Programmers author?? Who invents catchy backronyms all day???

It's the Iron Triangle, and they all start with T. Triangle, T, get it??!!

15

I think this is a bad policy.

A lot of developers think they shouldn't charge for "learning" or "debugging" time.

Everyone needs to learn or we'd all be writing FORTRAN, and everyone needs to debug, or TDD wouldn't be important!

It's like a painter not charging you for masking and cleanup.

It's *part* of the job.

16

But if I'm paying for their learning process I want some evidence that these guys are super-learners (and not the usual crop of lazy, indifferent, narrow-minded slobs that I know number out there in the millions)

17

R K wrote:

But if I'm paying for their learning process I want some evidence that these guys are super-learners (and not the usual crop of lazy, indifferent, narrow-minded slobs that I know number out there in the millions)

Hence I split the difference.

"Why is the chat feature 15 points?"

"Because I gotta research how to send a tiny message over unstable Ajax pipes in 1/3rd second"

"Just do it within 10 seconds"

"Okay. Three points."

18

I agree with Tom. Charge for your learning. If your project needs to do some AJAX, and you know that RJS will help out but you’ve not used RJS, you need to learn it. You’ll learn it by implementing it on their project, therefore they should be charged accordingly.

If you’re good (read: able to learn quickly and adapt) then you won’t burn too much time learning. If it makes you feel better, do your learning at a lower rate. If you don’t think you’re able to learn on the fly, then do something to boost your skills or confidence.

When I hire a developer, I know they don’t know everything. I hope they know how to find out what they don’t know.

19

Brian Hogan wrote:

When I hire a developer, I know they don't know everything. I hope they know how to find out what they don't know.

Find Out What You Don't Know

You forgot to hope that they are willing to :slight_smile:

-r

20

Phlip wrote:

R K wrote:

> But if I'm paying for [...] the usual crop of lazy, > indifferent, narrow-minded slobs

Hence I split the difference.

"Why is the chat feature 15 points?"

"Because I gotta research how to send a tiny message over unstable Ajax pipes in 1/3rd second"

"Just do it within 10 seconds"

"Okay. Three points."

Where did this conversation happen? School for the gifted programmers? Please re-read my description. :slight_smile:

-r