Freelance software developers: How do you charge for your work? It can be difficult to structure your billing so that you get paid on time in a way that makes economic sense for you and your customer. How can you do it?
Time-based billing by the hour or the day is one way, but it has its downsides. If you're really good at what you do, then you put yourself at a disadvantage, because you'll be highly productive on the job while earning a set amount. The more productive you are, the less profitable your work is for you. The other problem with an hourly or daily rate is your scalability. Time-based invoices come with a ceiling. There are only so many hours in the day, and days in the week. You limit what you can earn, unless you keep increasingly your hourly rate.
Project-based costs are another option. Charging a set fee for the whole project enables you to capitalise on your productivity. Getting it done quickly while hitting the project requirements enables you to increase your earning potential. But this carries two dangers: scope creep, and cashflow issues. The bigger a project is, the more difficult it becomes to accurately scope the requirements and the harder it is to get clients to stick to them. And while some clients may be prepared to lay down a significant advance up front, many won't be, meaning that you don't eat until you're done.
One other way to charge stems from agile development processes that break programming jobs down into more manageable chunks. It involves partitioning the project into
user stories. A contractor friend of mine who works remotely and for multiple clients does this on a regular basis. User stories break down the functionality of a program into small tasks that correlate to tasks that the users of the system would understand and identify with.
A user story for an online library system could be "As a user, I want to renew a book so that I can read it for longer". Another could be: "As a user, I want to reserve a book so that I borrow it when it becomes available".
These stories are understandable enough that the client will feel comfortable about what they are paying for, and small enough that they can be coded in a couple of days and billed for in a granular way. They also provide freelance programmers with a way to more easily reuse code, as many user stories may use the same underlying functionality.
There are doubtless some projects that this won't work very well for. It might be inefficient in terms of time to break down very small projects that only involve a week of work into different user stories. And projects that users never see (perhaps certain embedded systems, or complex back-end financial algorithms) might not be a good fit. But for straightforward projects such as web applications, this could be a good way to charge the client equitably and clearly - while also providing a structure for yourself to tackle the project in the process.
