Web developers building a site under contract typically choose one of two methods for compensation:

• Charging a flat fee, based on the estimated number hours it will take to complete the site.
• Working for an hourly rate, invoicing the client at the end of every period.

 Both systems have well-known deficits:

• Estimates are notoriously inaccurate, often leading to the developer working overtime on projects.
• Clients will often hold back final payments, demanding further changes to the site.
• Freelancers can find it difficult to chase up clients with invoices for ongoing work.
• Clients often don’t understand that “small” requests can inflate development hours.

Rather than choosing one of two bad options, I’d urge web developers to consider an alternative: a “time pool”.

The idea is simple: you know that any time estimate for a site is going to be a rough guess. You also know that the client will almost inevitably come back with additional requests that will expand the scope of the project. Rather than providing a fixed fee, offer a time pool system, based on your regular hourly rate. For example, if you charge $35 per hour, negotiate with the client to make an up-front payment of $700 for the site, which gains them 20 hours of your time.  This has several advantages:

• The client sees what they get for their money: they receive exactly 20 hours of work.
• There’s no “hold over” of funds. The client has nothing to dangle: if they’re dissatisfied with the results from the work done to that point, they’ve only paid for that amount of time, and can walk away.
• Contracts are easier to negotiate. If a client makes a change request, they can be told how long the new work is estimated to take, and can pay for it immediately, without needing to renegotiate or rewrite the original contract.
• No chasing after payment. Work stops once the pool runs dry. It’s up to the client to refresh it.
• Work can be sustained longer. As I’ve written in the past, there is no such thing as a “one and done” website any more. Websites are in a constant state of development, adaption, and flux. With a pool system, there’s no “end” to a site, and clients can easily re-engage the developer for updates, providing a constant residual income.

The only demand of this system is one of better communication: the client deserves to see regular work updates, as that is what they are paying for. In the next set of articles I’ll look at ways to make that happen, including tools to gain better management of time and distractions.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.