It seems like you are using an ad blocker. To enhance your experience and support our website, please consider:

  1. Signing in to disable ads on our site.
  2. Sign up if you don't have an account yet.
  3. Or, disable your ad blocker by doing this:
    • Click on the ad blocker icon in your browser's toolbar.
    • Select "Pause on this site" or a similar option for lancecourse.com.

50% to start and the rest at the end: a bad deal?

Re-hello friends. I am really sorry I take some time these days before posting. I've been putting a few things together.

Today I would like to talk about a topic/case most developers or designers face and how to handle it; at least show you how I handle it.

This concerns how we sign a deal with a client. In most deals, we have they're usually oral contracts. When a client gives you a list of things he needs, and you make a price. Once you agree on the price, all of you decide on the payment method and when it should be done. Then, you proceed to your job.

The problem usually comes with the when. In most jobs I had, people were required to pay me half of the price we decided, and then the remaining half once I completed it. I suggested it to my clients many times. It had to be done that way for some reason:

  • Clients need something to trust you. If you have to disappear with their money, it should be half, not all.

  • Trust your work. Most clients need to know if you are good enough to offer them what they're expecting. That way they can change their mind on the way and cancel the deal, losing just half again.

  • Some clients just don't want to pay a bulk of money once. Either they have it or not. Those ones would not allow you to have their money in bulk once. Some will be looking for your half while to are doing the job.

But, the big issue with such type of deal is that the payment of that half is always causing problems: a long delay or a never-coming.

You might tell me: nooo!, if he asked for a blog I create a blog and deliver, that's all.

Yes I agree, you create a blog, but that isn't all. It's not because the client said a blog that you can make any blog and deliver. The client will definitely have to say: Yes, I like this one before you can deliver it to him. After all, a blog is a blog. But there is no standard defining a blog in its form and functions

One thing I noticed in my career as a web developer/designer is that it's almost impossible to define when exactly a project can be considered complete, especially if the client is the one to say, Yes, it's OK. Trust me I thought of this many times. There are two dimensions to this situation:

- The developer's side

The client gives you his needs. Based on that you choose your tech, workflow, tools, time frames, etc. Then you start transforming the client's ideas into something real, smooth, and well-organized. And so far, all this can still be opinionated. Because the client might not like it that way. And you must go back to work.

- The client's side

One big problem with clients is they realize their real needs as you are coding their project. This is, therefore, a big danger for the developer. Because the client has to say Yes to something he seems to ignore.


Two antagonist decisions to make which make a project always be in the development phase. A never-ending process. Hard to say -yes- we're done. In the end, we have to tolerate and accept something as such and move on to the next.

How do I handle such cases?

It's straightforward. You take 100% before starting and 0% at the end, or you take 0% to start and 100% at the end.

Let me explain that. Most clients I had remotely paid me at the end. This requires a trust. You need to make sure the client is definitely going to pay. And for that be agile with them. Always let the client follow you up and give you their opinion as you are progressing. If your work is bad, they will let you know, otherwise, they love it, and they are ready to pay for it at any time.

Individuals and most companies in Africa are not that trustworthy. Besides, most of us won't have enough means to support a project with our own money. In that case, you need to take something from your client at the beginning.

How do I get the other half?

There are many ways, depending on the situation. What I actually do is to make sure the client doesn't get the work until the payment is done. If it's a website, for example, work with a sub-domain. Once payment is done, move it to the client's domain. Otherwise, the client will start enjoying the site and will feel lazy to pay. And you need to get a way to make the client see that what he asked for is done, and call it finished.

Another good thing to do is to always work for a milestone before showing it to the client. For example, you can design the website to some point before showing it to him. If you stop at each little step to show, he will keep on bringing in new ideas. You need to avoid that because it will slow you down and give the client have that impression of work not done yet and therefore delay your payment. r And the last important thing is concerning us developers and designers. We tend to get very overwhelmed or personal on some projects to the extent that we wish we could implement all sorts of flowers(features) just to prove ourselves or by curiosity. It's great, but this may make a client overuse you. As you bring in more ideas, it also wakes up the client on more things he could need.

Go straight to the point. Implement the basic things the client asked. He needs a blog, cool. Let him know where to add new posts. Make him agree on how to list the posts and how to read them. Provide the sharing buttons and put in place a little commenting system and you are done.

Your client will not complain about this, although you can still improve it in many ways. So far you've concluded your deal. Now you can give him suggestions to improve the service. I know most people here will say that it's not maybe good work. Let me stop you there. We all know how complex a website can be. There is almost no limit to features or to how a feature can function. Something has to be agreed on in order to go further. That's what I am talking about.

Wrapping up

This is of course based on my little experience with clients in this field. It's also based on the context and my location. It's, therefore, an opinionated solution. Many people I know go for written contracts. I personally don't deal much with contracts, except the project is extremely huge and it involves a lot of money. I take work specs, that's all.

In most cases, it's your relationship with your client that will determine how fast you will get the other half.

Note, the goal here is to avoid having some half hanging around. So, be time-conscious and deliver on time. It's probably the best way to make a client pay you in time.

If you like this post, please share it with your friends and clients ;). It will help us a lot. Thanks for reading.