How much should a dev charge his client for a project?
First things that come to mind are questions like:
How big is the project?
How ...
For further actions, you may consider blocking this person and/or reporting abuse
How many working hours to finish the project? How much do you charge per hour (dont answer the latter question in public, it will bite you in future)?
Do the math based on the above questions. And in case you cant estimate, use these questions:
Can you estimate the needed working hours based on the requirements? Or at least the MVP?
The MVP could be your milestone for charging, and software never finishes; the client will ask for more for sure... you can agree then on another milestone and different number of hours or even different rate per hour.
Actually I do not have an answer for the "amount per hour" question because I never thought that this is the way to calculate cost.
Is it really valid as a method? What if you are not tht familiar with the tech that is used and half of your working days you are googling basic stuff. Is that included in the final price?
How much could an average amount per hour be?
We're all constantly googling basic stuff. All of us. Time is the only thing that matters when it comes to setting a rate.
You could try backsolving from annual salaries in job postings which describe similar responsibilities to what you're undertaking to get some ideas, but the fundamental question is "what is your time worth?".
That's a very debatable point of view. From a developer's perspective, this might sound reasonable, but the client will not be happy if you tell him "I don't know much, but you will pay me a hefty hourly fee to look it up on Google". Yes, everyone has to look up things, but I believe that you should treat productive hours (coding, doing real research etc) different than catching up with things you should know when you are the technology expert for the client.
The second reasonable perspective is the customer value you bring. If you can save the customer 100k per year, it's easier to charge something in the neighborhood of the first year's savings than if you calculate based on yours estimated hours and the client's savings of the next 20 years will be spent on the project. If that's a reasonable price though, the client might have to re-evaluate if it is worth for him to run the project. It's not the duty of a developer to do it with a loss just so the client can afford it.
But it gets even more complex: if you are new and want to expand your freelanceship, you might start cheaper to Hain a track record. Or to get a foot in a door with a client with great potential. Of course, the goal is in both cases that future projects will compensate for that, which is not always the case.
As last point, there might be developers with same hourly rate that work faster than you. If you just base your prices on the hours, you might not get the project if others can offer a better price, because they are more familiar with the technology.
I'm not sure if this really helps as an answer, but finding a reasonable price is really hard. If you have a good and trustful relationship with the client, you might agree on an agile model, think about an MVP and a maximum price where you would stop to re-evaluate. Until that point, it was be billed by the hour. And afterwards add feature increments with their own value.
That completely depends on the situation. I totally agree that cutting the hourly rate will be much harder to debate later on. As I wrote, it does not have to turn out as expected if you try to get a foot in the door, but if you lower your estimate on the time (= don't bill every hour) in the first place, you can learn the technology on the way, become an expert in the area and charge every hour with the same rate for follow-up projects.
I agree with that, if you need to put in extra hours to catch up with a technology that you said to the client you already know seems unfair to include in the final cost.
Also I understand that my hourly rate can't be the same as someone's who has many years of experience in the field. But I can "get my foot on the door" now and raise the rate gradually as I get more experienced, right?
Not just that Kostas, you charge depending on:
Your experience (entry level, junior, mid, senior).
Your current job status (working now, looking for a job, urgent job)... you won't stay with no job to work on, and it might be okay to lower the price to have something in hand instead of free hand (same goes to a client who wants urgent work done while you work on something else, you will raise the bar).
Your location (if you are in India, your customer already came cuz he knows they pay less there)... how much they pay for the dev of your experience in your country?
Your client location, he won't accept an unreasonable price in his point of view... he might have a price already and he thinks that's the standard since it's like that in his country (different in remote case).
Who is the client? a normal guy wanting his blog ready? or a bank wanting a blog for marketing their latest tech? (silly example, but you see how to deal with different people).
As @asparallel wrote, this can bite you later. If you start working with a client and raise the hourly rate later on, they will probably want an explanation. But you can use the estimated time to maybe compensate for lack of knowledge at first and later align this with the real time you need as you get experienced in that area or established in the market in general.
You should always charge the client for research costs. I've been coding for 15 years but that does not matter I need more or less googling then you do. You probably know tricks I don't and Visa versa. The client pays your hourly rate for doing work. And if that work is writing code or looking stuff up it does not matter.
I still would say that it depends on a few factors. If I would research how to write a loop in JS for half an hour, I would probaly not bill that. If I research edge cases of support vector machines to evaluate if they are suitable for the client in this case, then yes, research should be billed.
Saying that every hour we spend should be billed it's our egoistic developer perspective ("I worked for an hour and the hour must be payed by someone"). The client perspective most likely is that they hired an expert who knows things they don't and is an expert in his field. So they will most of the time not be happy to pay us to learn things we should know in their perspective. So, as often, it's about finding a balance and being honest about what you offer for the hourly rate.
Damn and I thought I could get by without time tracking software haha.
So yes, that balance is what I am looking for. Charge for the "important" research and maybe not charge for the hours remembering the selected language's syntax.
If you are a developer that has to research how to write a loop in JS for half an hour your hourly rate should reflect that.
In my country you can get developers from 10 euro an hour to about 250 an hour. The hourly rate reflects the skill and expertise of the developer.
When I take for-profit side projects, I tend to consider hours worked on that project as overtime on top of my day job, so it stands to reason that the hourly rate would be higher, depending on how much you value your free time.
Now, sometimes that might mean that the figure will be too steep for your client. That's fine. If you need the money, consider how low you can go before it's not worth the bother. On the other hand, you may just need the money. Either way, you can start a conversation, but at least it's from an elevated position going down, not digging a hole in the basement.
To estimate your (day job) regular hourly rate, you can use something like yourrate.co/ to get a feel for the ballpark figure, then adjust as you see fit. Multiply by the number of hours you think the project will take and you have a good idea of what to charge. Heed my advice and don't low-ball this estimate, a client will always try to negotiate down. This gives you enough of a buffer to not get burned, and protects you from unforeseen problems that might delay your project.
If you don't have a regular hourly rate, or if you think it's not representative, ask around, or look at online job ads for remote jobs that post an annual salary range.
Of course, sometimes the project might be a good learning opportunity regardless of the amount you charge, in which case it might be worth considering doing it for a lower cost, or in the case of non-profits (and assuming you can afford it) go pro bono, which allows you to not fully commit and walk away with no consequences if the project ends up going belly up – a very real possibility even in commercial development!
That's about as practical advice as I can give without specific context. :) Good luck!
So are you proposing to compare the hourly rate with the day job salary to make an initial estimate or I got that wrong?
Also sometimes I find online job ads to be a bit exaggerated, but I will try finding something similar anyway.
Thanks for the advice!
As a rule, I would do two things:
It's hard to source good data points on salaries apart from job ads, but here's a global survey of people who have anonymously contributed their salaries, along with contextual data about locations, roles and company sizes:
docs.google.com/spreadsheets/d/1VO...
This comes from Remotive, I highly recommend you sign up for the mailing list, and consider the Slack community there. They sound exactly like the people you'd like to compare notes with. :)
Make both hourly rate estimates, and compare. How low you can go is something you'll have to figure out given your circumstances. But I would recommend that you err on the side of caution and always give a higher estimate, since you'll inevitably run into late submissions and last-minute changes, and they'll always talk you down anyways.
If you don't factor these things up-front and your contract doesn't stipulate an on-going hourly rate along with a clear list of contractual goals, you'll struggle to defend yourself when the client demands more work and says that you haven't delivered everything. Don't make the beginner mistake of assuming the happy path, that almost never happens if you don't have experience managing a project.
And remember, you are your only ally; don't sell yourself short. The client will have plenty of time to make the project not viable for you, it's your job to make sure that if that happens, you're getting paid for the time you invest. If you do a good job, no one will second-guess your rate, whatever you charge and they accept. And sometimes the best thing you can do is walk away from a toxic client.
You may want to have a look at Mike Monteiro's talk, Fuck You Pay Me:
vimeo.com/22053820
He (and his lawyer) explains much better than I can the pitfalls of the reality of business for creatives and information workers.
Thank you very much for the spreadsheet, I was looking for something similar for quite some time! Bookmarked every link.
The contract I make with the client has to be divided into parts or milestones to better protect myself and get paid? Or should I go for a 50% upfront, as someone else suggested in this post, and the rest after the project is completed?
Which one you this is better for what situations?
The way I approach projects in general is to create a list of features and their requirements (and prerequisites). This gives you information about the ordering of features that can be delivered.
Let's take a news aggregator app as an example. Take the user-facing features as milestones and order them based on prerequisites:
The most important thing about ordering these features is that all the prerequisites of a feature are above the feature in question. You also want to deliver the most critical milestones first, and depending on the needs of the client, you want to move those up whenever possible. That will increase the client's confidence in the process and will quickly build trust from their side, since you're prioritising their needs.
You can use something like a Trello board to break down the milestones into tasks, and share that board with your client so that they can keep track of progress, or maybe even leave feedback if you continuously deploy your application as you complete more tasks. This also enables a fast feedback loop, but you HAVE TO always keep in mind that these conversations will often go out of scope of the current task. Remind them that those changes need to be negotiated as an additional milestone if they go out of scope of what was already agreed upon.
For each milestone, you can then set a price given your estimation of the amount of work, and agree with the client to pay for the milestone upfront. That way, the client has the option of paying upfront for the next couple of milestones in case individual payments carry a high cost (in time or money) to them, or just decide to pay for each as you go. If things go south or the project is cancelled, you still get paid for the chunk of work they committed to.
Other than that, keep to the advice given in the video, and make sure to keep in mind that each milestones needs to have a tangible deliverable for the client. That's the golden rule to managing client relationships and keep them happy and satisfied.
Again, thank you! You have been very helpful!
Another way to go about this is to charge by the project. This is the model that most large agencies use and I have used for years. Here is the process I use -
Work with the client to determine the scope of the project. Do they just need coding or does the project also need planning/ design? These don't nessisarily need to be done by you but you can certainly use your expertise in planning and if you do you should charge for it. How much functionality is needed? Do you have a clear set of requirements? If not this can add to the scope. Determine this stuff first before you price because it will affect how confident you feel in how many hours the project may take.
Determine a fair market value for your time per hour. Everyone charges per hour in some way or another, with the method of charging a flat rate like I am telling you here you are adding up what the hourly rate would be and then adding some for overage. The rate you charge is a little bit of a subjective thing and if you don't feel comfortable charging a ton of money per hour that's ok since you are just starting out. But also charge enough that it is worth it, otherwise you might end up resenting the client. As a benchmark I am in the US and when I started by hourly rate was $20 an hour. Now 11 years later my hourly rate is $150 per hour.
Multiply your hourly rate by how many hours you think the project will take you to complete. This time should include everything, research, planning, coding, everything. You don't want to be doing work for free. Unless you do, in which case this discussion is irrelevant.
Add 25% for overages. You will always encounter things you didn't expect in a project, this allows you to give yourself a buffer.
Whatever number you come to is the flat price you charge the client. You can charge the price all at once or in phases if you think the project will take a long time. At the very least get 50% up front, this will let you know the client is serious.
Sound strategy! Thank you for your answer!
There are three ways of pricing anything:
You should do "value-based pricing", as a general rule. But never go below your cost, and don't go too far off the price of your competitors of course.
This is not helpful advice, of course - it's really saying "do all three".
But let's assume you're a student, and your general living expenses are covered, so cost-based isn't much of a worry. That leaves comparative pricing and value-based to consider.
There's two ways that someone might pay for a bit of automation software. They might want to pay for it all up-front, once delivered. Or, they may prefer to pay for it as a service, on a monthly fee. A lot of software - and I mean, a heck of a lot - is a mixture. People pay for an initial "license fee" or similar, and then pay for a "support contract". These correspond to "CapEx" (Capital Expenditure) and "OpEx" (Operational Expenditure). Different businesses have different priorities here, but most will want to push toward high CapEx and lower OpEx - because lower OpEx leads to higher long-term sustainable profit.
Okay, business finance lesson over.
If you want to go a value-based route, try to estimate how much money this software will save (or earn for) the customer, and aim to take a cut of that (10% or so). You can then decide how much to take as "support" and how much as "development" - in general, the further in the future your OpEx saving would be, the less it would be when converted to CapEx. This way, you'll be able to say "This project will pay for itself within X weeks" - where X is usually going to be a pretty low number. By doing this, you'll literally never overcharge your customer.
But in this case, I suspect you want to run it like a consultancy - so you're going to charge a "day rate" during development, and hand over the result unsupported at the end.
This leaves two questions:
The first is best answered with an estimate (from you), and an agreement that the software is delivered on an agile basis, with your customer involved in the sprint process, week by week, on a pure T&M basis. In other words, there's no hard minimum or maximum, but the customer has a good guide price and clear involvement across the entire development process. They can stop at any time they want.
The second question is where we go "HOW MUCH!?!?!!", because typical day rates run from €250 to €1000, depending on the rarity of the skillset. You can, of course, go lower if you want (or, indeed, higher).
So do the CapEx/OpEx guesswork above, then estimate how long it'll take you, divide one by the other to get your day rate, and then decide if that amount of money works for you.
Confused? Yeah, so am I, which is why I keep out of pricing discussions and don't do consultancy work anymore.
I think I got your points! Thank yoy for the comment!
Nice. Had the same questions and ended not dealing with people I did not "feel".
It is usually hard to put a "price tag" on you when you feel limitless :D
Also it feels unrestricted because it is a project price and not a salary! It is difficult to find something similar and compare the cost. Not as easy as finding an average salary for that kind of position and adjusting.
And it is more of mile-stones than an 8-5.
How much to charge to do it faster? Leave others and focus on your project? Etc.
The existential questions in pricing a code project.
Very sensible to include tax tips. I assume you follow this checklist as well when talking to customers.
Have you ever had a problem with a customer changing the specs to make this list?
Thank you very much! I'm keeping this!