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 ...
Scope Creep
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.
Feature Creep
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?
Wishful Estimations
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.
Unknown Constraints
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.
Domain Knowledge
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.
Weak Ties
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.
Responsibility
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.
Get It Done
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.
