Let's say a client asks for a new development/feature, how do you calculate or estimate how much to charge them? Do you do it in advance (making a budget/estimate) or do you charge for hours worked?
Most times we need to make budgets for clients, how do you do that? How do you make sure you don't charge less or more than you should?
We've been kinda struggling with this for a while and decided to check if any of you has any good tips!!
Top comments (8)
If it's you as freelancer, break fratures into little tasks and estimate each by your experience level point of view.
Then apply some containment to it (10% min, 25% max).
Finally check the market price for an hour (gross or net, depending on the base you're using on the calcs) and do the math:
(Estimated + containment) * price.
It's said in Agile that "points" describe effort and not time, but as you need to set up some milestones, deadlines and so plus you'll charge the client by worked hours (just like in any other technical job)... You'll need a conversion guide between both.
Try it on a sideproject of yours and refine that conversion and estimations.
If you end up working less hours than expected, good for you! As the budget has already been accepted and you already get a part of it to start the project it's ok to keep it the same.
It can be that you estimate less than needed and in such case you'll need to "pay" that difference with your time unless dev time extended by client requests, of course. In such cases the process is the same... Estimate, add containment, multiply per hourly price and sum it up into the main budget.
On the other hand, if you need yo handle other services such hosting, email service etc you'll need to add this costs plus a maintenance cost (recurrent) to the client contract and budget.
This comment does not cover all the use cases, possible costs nor situations but I feel it can be a good starting point.
Hope it helps
Interesting, this is more or less what we're currently doing.
I'm not freelance though, we work at a consulting agency, but we're kinda new in this kind of stuff. I just wanted to check if we're doing it correctly or if there's some other way of doing this. We've improved quite a bit since we started, but it always feel weird or wrong to do it in this way...
Well in consultancies the thing is a bit more difficult (not necessarily difficult but it implies more bureaucracy and process polishing along the time).
It depends on your business model at the end.
It can be a resource assignment with no end date planned for the project (just milestones with deadlines each) so you need to calc the salaries, infrastructure costs etc etc etc plus the availability of the resources and a percentile that will be the benefit for the company itself.
I'm not so involved in this stuff to be considered an expert but you'll find information about that online, sometimes a bit obfuscated though, as each company has it's private way of dealing with this and a specific business model that relies on the target market sectors of the companies they work with/for.
Just to clarify I'm using "resources" to speak about "people" (human resources) that includes devs and any other professional profile as a generic word: security experts, software architects, data guys, designers... quite dehumanising and not my favourite word but... In this context I can't find other that defines it better.
Makes perfect sense, thanks! It definitely has a lot more bureaucracy, I freaking hate that part xD
I will share this comment with my colleagues, we might take some ideas from it!
As with agile, customer collaboration is more important than contract negotiation. When calculating your costs, make sure you draw out a plan that gets the customer involved. I prefer payment in increments on every sprint/feature. That puts both you and the client in a safe space. You can easily let go at the end of an increment if you cannot both work together. Implement a CI/CD pipeline on the get-go so customers can test almost immediately as features are released. Many customers would tie some balance of an increment to successful testing that might keep you in the project for longer. So, let the testing be from the get-go.
Usually, the first increment for me would be the UI prototype since it also serves as acceptance criteria, then a stateful UI, infrastructure setup, and automated deployments. Then each sprint/feature that concerns the backend and connection with other components comes next.
I think the best way would be to estimate the feature, ask 30% of it, and reevaluate the real cost at the end of the future and bill the rest. The idea would be also to incremental by implementing small to medium features instead of a big one. The client keeps an eye on how it goes, and the developer/company is payed regularly.
But nowadays clients are more accustomed to have a big estimation of the project, so: the developer is losing money because the project has been wrongly estimated, or the client is losing money because the developer has added a big margin to avoid losing money.
Anyway, when I need to estimate, I chop it quickly into features and try to estimate easy one in half days. I don't want to pass to much time on it so to avoid losing time and money on something that have a big uncertainty factor (client acceptance, unplanned changes or issues,...). I also add some margin if I feel the need to.
Cheers! The first approach sound quite interesting, I doubt we could do it in this way at our company, as many times clients have to ask for funding to goverments or organizations, and must cover the whole development.
I do it like this demonstration shows. linkedin.com/feed/update/urn:li:ac...