One of the challenges we faced when starting the Devshop was figuring out how to bill clients for work. If you remember from our story on how we began, we were mostly a group of developers who had no previous knowledge of developing commercially. Naturally, we lacked background in the commercial aspects.
A few years on, we have certainly learnt a lot about how to approach it. Different clients will require different billing methods but here are a few we have used over time.
Some Billing Methods
This is the most common kind of billing with local developers from our experience. This method of billing involves initially assessing the amount of work to be done. The client is then billed a fixed cost for the entire project.
- Clients tend to prefer this method of billing. It makes them able to plan ahead by knowing how much to set aside for the work.
- If you are a very skilled Developer you can finish projects that may take longer for other developers and consequently get more out of your time.
- When dealing with “sticky clients” whose changes constantly evolving you will spend a lot of time on a single project which results in you getting less out of your time.
- Work done must be well understood prior to engagement or it may be undercharged.
As a general guideline for developers choosing to take this approach, it is good practice to create a specification sheet or a Software Requirements Specification before billing. In addition to helping you to be able to understand the amount of work, it will also help you in planning the project.
Featured based billing (may be referred to as Functionality based) is in many ways like Project-based billing except instead of the whole project, you bill per feature. It has some added advantages over the Project-based approach.
- The method works best for projects with incremental release cycles. If you are adding functionality on an existing project that may have been built by someone else this method would work.
- The nature of the feature-based approach does not give much room for misunderstanding requirements which reduces ‘sticky clients’.
- Work is easier to measure for a feature than for an entire project.
- Billing paperwork is more frequent so time doing paperwork increases.
- Mostly works on bigger projects (Cannot really break down a website into features, can we?).
Apart from the overhead of additional paperwork, this is a generally a good method to adopt. It eliminates some of the problems with Project-based billing
Hourly billing is a great way to cost projects. This method typically involves recording the hours spent on a project and the sending an invoice based on that.
- Works for clients whose requirements are vague.
- Addition of requirement by the client does not cost the developer.
- Different skill levels of developers may need to have different hourly rates. More seasoned developers would generally finish work fast so would have a higher hourly rate. There is no sure way to calculate such a value.
Generally hourly billing has a lot to offer for developers. It gives the client reasons to be more succinct in their requirements. Work moves through the pipeline faster. It does require for the client to have some assurance that you are making use of their hours efficiently.
Daily and Other Time-based Methods.
Time-based methods generally share the same advantages as hourly-rates. The key difference is, as the time-period becomes longer there is increased need for accountability. For example a client on a daily billing schedule may want to is you are spending the entire working day writing code.
There are multiple ways to approach. The truth is there is no one perfect way to approach it. There are projects that will require a mix of two approaches (Hybrid Billing Models). While this is not a very specific guide to billing, we hope it will help you get started.