How to Charge for Websites: the Agile Way

In the final part of this series we’ll discuss agile pricing — a relatively new charging mechanism which helps prevent fixed-price and pay-per-hour problems such as:

• requirement changes
• costly delays
• unfinished or unpaid projects.

Clients want a final cost figure but can not know or appreciate every requirement. Even with a clear specification it’s difficult for developers to estimate large project schedules. Accuracy is futile when you consider that the client’s requirements will inevitably evolve. Agile charging is based on agile development techniques but it’s not as technical as it sounds. Billing is based around “sprints”; a fixed block of time when a number of features are implemented.

Billing Cycles

Typically, a billing cycle is a two-week period with a defined start and end date. During every cycle you endeavor to:

• implement a number of identified features, and
• be available at certain times, e.g. Monday to Friday, 9am to 1pm. Avoid offering a full 40-hour week — you’ll need time for side tasks such as administration, inquiries and other client projects.

There’s only so much you can achieve within each cycle so development estimate margins of error are reduced. No other features are normally considered during the cycle so client interruptions are minimized. If a single feature is estimated to take longer than one cycle the problem should be broken down further. This will be especially evident at the start of the project but remember to include time for planning the current and next cycle. The first cycles may be requirements gathering, analysis and planning only. Ideally, you should provide a working product at the end of every cycle. It need not be feature-complete, but it must be usable so the client can consider their priorities and provide feedback. Aim to complete a minimum viable product within the shortest practical time.

Payment Terms

If you’ve ever struggled with cash-flow you’ll like this part: the client pays for your time in full at the beginning of every cycle. If they don’t pay, you don’t provide any work and they must wait until your next available billing cycle. The charge is non-refundable, although some element of flexibility should be considered. Understandably, the client will still want to know how much the whole project will cost. A rough estimate of the number billing cycles can be provided but the client should appreciate that it will be revised and become more accurate as the project evolves. There are several benefits to the client:

• There’s less risk. If they don’t like your results, speed, processes, attitude, etc. they can stop at any point. They need only commit to the current cycle.
• Clients know what to expect and when it will be delivered in smaller, manageable chunks.
• They can view and assess progress at the end of every cycle, not just at the end of the project.
• It’s not possible to over-pay for work. When a feature is deemed good enough, development and associated costs can be ceased.
• If necessary, clients can buy extra features or improvements as their budget allows.

How much you charge per cycle is up to you. You could base it on your typical hourly rate but vary it according to cycle availability, i.e. the earlier a client books you, the less they pay. That said, your cash flow should improve because clients are unable to withhold payment and their delays cost them, not you. You’ll discover clients have a renewed urgency to make decisions.

Flexible Exceptions

A client may have a clear specification but are unsure of when or how to proceed. In those situations, you could consider offering a smaller retainer of a few hours per week to assist with their inquiries until work starts. This avoids offering free consultancy and time estimation services before starting the project. A set of deliverable features can be defined on day one of the cycle. Remember that clients are able to use your services as they wish throughout the period — be clear that additional requests for meetings, discussions, advice, new requirements, feature changes etc. will have an impact on what can be achieved. Development issues will inevitably arise. Something you expected to take a couple of hours extends into several days owing to browser-specific quirks or unforeseen complexities. Such situations should be reported to the client so they can issue a temporary stop-work order to assess the feature and revise priorities. These should last no longer than a day or two which can be added to the end of the project at no additional cost to the client. You can consider billing cycle payments to be non-refundable in the event a client cancels or delays work. However, be pragmatic. A client canceling a cycle one month in advance — who has never done so before — could receive a full refund. Another who continually delays progress at the last minute may receive nothing.

The Downsides

Agile billing is ideal for larger projects with many requirements. It’s not necessarily practical for smaller projects, especially ones which can be completed in less than one cycle. Those clients will prefer a fixed price. Similarly, there may be situations when a client wants a small number of updates to an existing project which are best priced with an hourly charge. While some of your working week can be used for such tasks, you may need to consider reserving a single cycle every few months for ad-hoc projects and updates. Just be careful not to slip back into hourly/fixed-price charging. Finally, we’re left with one major hurdle: few clients will understand the agile payment model. Most expect to see a perfect fully-completed solution and won’t appreciate the benefits incremental delivery. Going back to the car metaphor, it’s akin to delivering the body, wheels, engine and trim at regular intervals. However, the car will be drivable before the seats, stereo, heating and windows are fitted — they can use it sooner and make adjustments as necessary. Ensure your contract explains the model in clear, concise, jargon-free, plain-English. It won’t be easy but there’s no need to include tough fixed-price/pay-per-hour concepts such scope creep, unreasonable demands, late payments, etc. Agile billing cannot solve all billing woes or be applicable to every project but it directly addresses the complexities of software development. My suggestion: try it for a few new clients and learn from the experience before adopting agile for everyone. Have you tried agile billing? Did it work for your company?

Frequently Asked Questions (FAQs) about Agile Billing