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.