Against the common opinion that one should charge for value as a freelance developer, over the last years Iâve made the experience that I like to charge for time. Here comes why I charge my rate based on time and not on value as a freelance React developer â¦
All of my past clients â who hired me as a React freelance developer â were able to define a plausible scope of the project. However, whenever a project goes on for long enough, say more than one month, every time the scope is only the 80 of Paretoâs 80/20 principle .
Over time, there will be additional project requirements which lead to more work for the hired freelance developer. At this point, either the freelancer re-negotiates the contract or has to keep their mouth shut and go for it. Both options are either stress or cost intensive for the freelancer and can be avoided when charging for your time instead.
If you present a client two solutions â one solution cost effective yet minimalistic, the other solution cost intensive yet sophisticated â a client who is able to pay appropriately (and these are the ones you want to have as clients) will opt for the latter.
These decision makings will happen quite often during the time of a project, so if you have charge for value, this will just add up more work on your plate without any extra gains (or you will have to pushback your client, which doesnât improve the client-freelancer relationship). While if you charge for your time, this extra work will be taken with a smile by you. If you do good work, it will be taken with a smile from the client too regardless of the extra costs.
Remember: Most clients who hire you as freelance developer wonât know what they want until you put something in front of them. And in the end, you as a freelancer want to challenge (and grow) yourself as well, so you want to be in for the more sophisticated solution, right?
Ask a developer about how long a project will take them to implement and you will most likely get an optimistic response. As human beings, we always underestimate a projectâs requirements and overestimate our skills.
Thatâs why Iâm always hesitant to tell a client my opinion on this matter. I can only loose if I name a deadline, because either the client is sad about a deadline which is too far away or the client is sad about a deadline which I can never fulfil. If I charge by time instead, for every party involved itâs clear that itâs an ongoing project with changing requirements along the way.
When starting out with a new project, there are too many unknown constraints which will make your work more difficult. For example, you donât know your co-workers, the APIs you will be working with, the (chaotic or none present) workflow the company has established, or the design mockups you will get from your client.
All of these constraints will not meet your best case scenario expectations. Itâs quite the opposite that most of these unknowns will work against you and your estimations. Working through this freelance developer checklist may clear up things between the freelancer and the client before the project starts.
The fairy tale of âthis product will make (or save) the client $10,000/year so I charge â¦â has been a myth in my last years of freelancing as a React developer. I am not saying that these projects donât exist, but they didnât cross my way. As a web developer, I cannot come up with these estimations myself, because I am not in business analytics. The other way around, if my client comes up with these numbers, I wouldnât know why they would tell me about them in the first place.
For both parties, itâs an uncertain new relationship. If a freelancer charges for value, then itâs almost set in stone that this project will be done (or fail) by this one freelancer. Thatâs what the client most often wishes for, however, not all relationships progress well. It didnât happen to me yet, I finished all the projects for my clients, however, charging by time gives both parties an escape hatch if things donât work out as expected on a professional or personal level.
If charging by value, everything unforeseen (scope creep, feature creep, unknown constraints) becomes your problem. In contrast, if you charge by time, the other party has to think through these scenarios themselves. Itâs not on you to remind the client that this new feature is not in the scope of the original contract or that this unknown constraint hinders you. The client has to work with you, because the clocks runs against your client and not you. In the end, itâs the best outcome for both parties, because both have to actively contribute to the project and no one is left alone.
Every developer wants to deliver quality code. Now when you charge by value, you want to keep the time invested in the project to a minimum, because no one pays you for the extra refactoring which makes the code more readable, maintainable, and predictable for other developers stepping in your shoes.
In contrast when charging by time, you have more freedom to evolve your code, to deliver a better version of it, and to grow as a developer in your skills. You should still get it done though, because your client is charging for the result and not the implementation details. However, in the end itâs still a win-win situation for the client, because the code will certainly be more robust and not break with the next freelancer taking over the project.
Developers just beginning with freelancing always struggle to find the right answer to whether they should charge by value or time. Often you will read that charging for value is more lucrative. However, especially when you begin with freelancing as a developer, you have no clue about the listed topics from above. Therefore you will most likely end up with more work when charging by value.