Common—and commonly frustrating—payment terms for site builders
usually consist of this equation: half the total amount up-front, and the
other half paid at the completion of the project. The trouble with these
terms is that it’s often the client, rather than the developer, who
determines when the project is approved and concluded. So the developer
may have completed the whole project and presented it to the client for
review, without having seen any money since the initial deposit months
before. Unless the client agrees that the site is complete, the developer
is unable to send a final invoice for payment. So what do you do to avoid
this situation?

The remedy is a different payment structure. I encourage my web
developer clients to ask for a substantial up-front payment, between
one-third and one-half of the total job. After that, progress payments
tied to certain milestones make good business sense, such as design
approval, delivery of key site aspects, or presentation of a whole test
site. Receiving a progress payment before proceeding on the project will
help keep a developer from straying too far ahead of the client.

A project needs to be clearly defined at the outset. Otherwise,
little extras that a client requests along the way may be hard to identify
and charge for. One of the best investments of time and money you can make
for your web development business is a standard services contract. Have
one that covers all the bases, but allows for modifications as required
for each client. It will provide a point of reference for the scope of the
project, and keep any scope
creep from happening at your expense.

For example, if a site’s CMS includes a blogging module, does it
also cover social media integration with Twitter and Facebook? Does an
ecommerce site involve integration with QuickBooks or other bookkeeping
software? If the contract fails to cover these sorts of issues, a client
might assume that more features are included in the project’s price than
the developer intended to provide.

Developers often use subcontractors for certain aspects of a
project. Unless the client has paid enough of the project fees up-front,
the developer can end up owing its subcontractors money yet to be received
from the client. In order to protect cash flow, consider a “pay when paid”
provision for subcontractors along the lines of “I will pay you when the
client pays me.” While it won’t speed up the client’s payment, it will
keep you from having to dip into your own pocket.

It’s vital that developers stay within range of their client, and
avoid progressing too far on the project without the client’s approval.
For instance, if the developer is ready to deliver a whole site, and the
client has only paid for the initial wireframes, the developer has
extended a great deal of credit to the client. Unless there is some
security for the payment, the investment may never be recouped. Manage
your invoicing, work in progress, and payment timing in such a way that
the amount of credit afforded the client remains under control.
Establishing larger advances from your client, as well as more frequent
progress payments or periodic billing can be effective. Then, if your
invoices fail to be paid, it might be time to consider discontinuing work
on the project.

Retain control of the project until you’re paid in full. It’s
probably the best way to keep a client motivated about making payments to
you. You should include provisions in your service contract that make
payment necessary for the transfer of copyright licenses for using the
graphic design and underlying code. You may want to also consider hosting
the site on a server that you control during development; then you only
make the site live and transfer it to the client’s servers upon payment of
the agreed amounts.

Work in progress (WIP) can be a developer’s worst enemy if the
client—for whatever reason—loses focus on the project. If a progress
payment requires a client’s feedback before billing, the developer may be
in for a long wait. A good service agreement allows the developer to send
an invoice for current work in progress even when the client is silent for
a period of time, enabling the developer an opportunity to square up the
accounts ledger.

Nobody can force a client to pay attention and provide feedback, but
being able to seek out payment when confronted with a wall of silence can
assist a web firm when sitting on a large, unpaid piece of work, and save
them from having to wait until the client tunes back in.

If a client falls behind with payments, consider whether you’d be
willing to accept partial payments over a period of time. This might help
make a cash-poor client view your costs as a series of smaller, more
reasonable possibilities, instead of one large impossibility. For example,
if you were to divide an outstanding amount into four parts, and only the
first two portions end up being paid, this little bit of restructuring has
brought you halfway closer to home than you would have been—before having
to undertake some serious debt collection.

Just like projects, clients come in different in shapes and sizes.
The difficult part, of course, is that problem clients are less obvious
from the outset. By putting a thorough development agreement in place
before starting work, and taking care to extend minimal credit during the
development process, developers can effectively manage these risks.

Feature image by
seanmcgrath.