By Craig Buckler

How to Charge for Websites: the Agile Way

By Craig Buckler

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?

  • 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.

  • Kali Marable

    Example contract?

  • Justin

    Great post. Thanks, Craig.

  • Edson Hele

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

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

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

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

  • John Verco

    Out of the three methods presented I believe that this is the best one for both developer and client. It avoids misunderstandings regarding the features that will be delivered and it insures that both participants are getting what they need in a timely fashion.

  • Guest

    Search for Agile Contract Primer

  • G

    Overall great article thanks for taking the time to write this, keep in mind you can always get paid upfront whether hourly (upfront retainer, ex 10-20 hours) or when doing a fixed bid I usually do 50/30/20 or 40/40/20, this way after taking a deposit we get to a point of presenting some design concepts and verifying the final details/spec, from there we take a milestone payment which leaves us with 80% of the budget, much better than only 50%.

  • Sam Byford

    Thank you very much! I shall be floating this idea to a prospective client tonight along with options for pph and fixed and see which they like. Personally I like Agile Billing the best! :)

  • Could the author please explain what is meant by this sentence?

    “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.”

    I get the sense that there is a missing clause or semi-colon after the word, “concepts”.

    Thanks for writing this series.

    • Craig Buckler

      It should read “concepts such as”. Sorry.

  • Blazelz

    Question: I already built the website for my client using the fixed price method. But what do I charge for new pages or updates to old pages after the fact?
    This particular client is part of an ever-changing industry that releases new products on a monthly basis and the client wants a new page for each product/service as they roll out. Thank you.

    • Craig Buckler

      Agile could work well if they want continual updates. It ensures you offer a retainer of N days per month regardless of whether they use your services or not. However, since this ad-hoc work could exceed N days, you should ensure they agree to pay hourly charges over and above that time.

      Talk it through with them. They will want a good deal but it sounds like it’s more important that you’ll be available.

  • Blazelz

    Question: I already built the website for my client using the fixed price method. But what do I charge for new pages or updates to old pages after the fact?
    This particular client is part of an ever-changing industry that releases new products on a monthly basis and the client wants a new page for each product/service as they roll out. Thank you.

  • Ilya Geller

    1. I will charge for structuring of websites.
    2. I will charge for websites targeting.

    The structured websites become advertisements and are charged.
    I guarantee they are going to be delivered to those who really want to see them.

Get the latest in Entrepreneur, once a week, for free.