How to Charge for Websites: the Agile Way

This entry is part 3 of 3 in the series How to Charge

How to Charge

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?

How to Charge

<< How to Charge for Websites: Pay-Per-Hour Projects

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Ngoc Phan

    I love your post, can you continue please?

    • Craig Buckler

      Continue writing? I certainly will!

  • sharpshot88

    I hadn’t heard of agile billing before. I love the sound of it. I think I might try it along side fixed price. Thanks!

  • goldhat

    I like this idea I had thought of something similar we could do which is have a team of 2-4 developers work on a site for say 3 days, a really fast sprint to produce the best possible site in that limited timeframe.

    • Craig Buckler

      That’s one of the good things about it. Your price can be based on the number of resources/people required during that billing cycle. You can adjust the developers accordingly, i.e. reduce the number of developers as the project approaches completion.

  • Justin

    Great post. Thanks, Craig.

  • Edson Hele

    I have to say only THANK You! Great serie of post.

  • http://www.am-graphix.com/ Alison Meeks

    I really like this concept. Thanks so much! It would sure help with the scheduling and steady cash.

  • http://www.ericlin.me Eric Lin

    It is really great for large projects, easier for estimating per sprint rather than per project.

  • http://mcnitt.com mcnitt

    Equally interested if anyone can point to a sample agile billing contract.

  • Guest

    Search for Agile Contract Primer