I was talking with a co-developer.

He has a client that wanted to make sure that he delivers on time. The client wants repercussions for missed deadlines.

While I do not do freelance work, I couldn't give an answer.

So, my question is:

What repercussions do you (freelancers) agree upon with your client if you miss deadlines on your deliverables (aside from being fired)?

  • 2
    He would be foolish to accept any penalties, at least without a get-out clause based around changing requirements. Task estimation is hideously inaccurate at the best of times, before taking into account change management. Basically. Run
    – Matt D
    Aug 20, 2013 at 6:18
  • 4
    So the client would have a financial interest in having you to miss the deadline? Does not sound like a really good idea. This will only make sense if the client has also a hard financial loss when you are late (like in the example of MainMa).
    – Doc Brown
    Aug 20, 2013 at 6:23
  • 2
    This seem perfectly acceptable to me. I am quite surprised by the comments. You expect people to pay for work, with either no deadline and no incentive to meet the deadline ? "Task estimation is hideously inaccurate" - it doesn't have to be. Aug 20, 2013 at 6:28
  • @DocBrown the client presumably has a much larger finacial interest in meeting the deadline, hence paying for the work with a deadline. I find programmers dislike of deadlines and structure amazing sometimes. Imagine getting a new kitchen fitted and the shop says oooooo no we can't tell you when it will be finished, will just charge you by the hour. I'd run a mile from that. Programming is not qualitatively different to any other project. Aug 20, 2013 at 6:29
  • 5
    If you're getting a new kitchen fitted, you will be quoted for the build as spec'd. If you start changing the cutting surface, the tiles, the faucets and the sink materials you'll be charged extra for both materials wasted, and time spent. It's easy to understand why you're charged in this instance, there's a physical relationship. Changing software requirements often doesn't come with this same understanding, and any contract which requires you to deliver X by Y where X is not nailed down exactly is asking for trouble. Things will change, being unable to account for that is foolish.
    – Matt D
    Aug 20, 2013 at 6:48

1 Answer 1


One of the most effective ones: penalty by day of delay. This is also what is done for large projects, the penalty being sometimes thousands of dollars per day.

If a precise deadline matters (for example if one develops for Olympic Games a web app which will handle the broadcast of the event in 2014, the deadline would be the beginning of the Olympic Games in 2014), then the effective measure could be that in a case when the project is late, the company is not paid at all, and should also pay a penalty.

If such drastic measures are not appropriate, then the sole fact that a well-paying customer will leave if the project is late can do the trick.

Note for the customer:

  1. Many delays are the fault of the customers themselves. Causes can be multiple:

    • No SRS, but instead two paragraphs describing losely what the customer imagines being his needs (and of course, the customer don't want to pay for requirements gathering, considering this step a loss of time).

    • Coming two weeks before the final deadline and telling that it doesn't matter that the project was done in Java until now and used Oracle: it is imperative for it to be rewritten in Python and use MySQL, because the customer have read a magazine yesterday telling that those technologies are the future.

    • Coming with a fresh set of requirements at every meeting. Bonus points when those requirements contradict nearly every requirement given until now.

  2. Good communication is essential for a good project.

    Many other delays are due to the lack of communication. Practices where the customer has no communication whatsoever for months with the company and expects to be contacted only once the product is finished and polished invite a disaster.

  3. You get what you pay for.

    There are specific procedures which help keep the project organized, and actually, programming should take only 10 to 15% of time for large projects and 15% to 20% of time for medium projects. Those projects should also be done by people who know what they are doing.

    In practice, customers are not willing to pay $800/day an analyst who will create architecture and software design, and they don't want to pay for other steps neither. A newbie Albanian programmer who is happy to work for $50/day seems much more advantageous.

    Don't complain that the project is a disaster when you're only ready to pay for disastrous projects.

  4. Don't negotiate time required to do the job.

    I often encounter the discussions like that:

    Developer: given the requirements, I can deliver that in four months.
    Customer: it is impossible. The project should be done in two months.
    Developer: well, unless you cut out some features...
    Customer: I can't! All features are needed. Why can't you do the job in two months? I contacted an Indian programmer, a friend of mine, he can deliver that in one month and a half, and asks only half of the price!

    Negotiating time is a recipe for disaster.

  5. Know your priorities.

    Take in account the 90%-done rule. When the project is managed incorrectly, it is not unusual to see developers telling that they have done 90% of the project a month after starting the project. Then, a month later, it's still 90%. And a month later.

    This can have two causes:

    • When the project is not done correctly, i.e. 100% of the time is dedicated to programming, which leaves 0% for requirements gathering, architecture, design and testing, what happens is that programmers have no idea about the work to do, and they discover new tasks during the whole life of the project. Preparing the project would help having a larger understanding of all the tasks which should be accomplished.

    • When the customer is in hurry, it is not unusual for some companies to deliver fast some crap, then spend an enormous amount of time solving bugs. Some companies work only like that, which helps them staying competitive and say that they accomplished a given project in three weeks, even if later, they spent three years solving the mess.

    By putting priorities straight and requiring the project to be done correctly helps eliminating those companies from the list of candidates.

  • 3
    "Don't complain that the project is a disaster when you're only ready to pay for disastrous projects." Can I use that? This is a great post btw, and nicely sums up the risks from both sides.
    – Matt D
    Aug 20, 2013 at 7:01
  • +1 Very good points. Also, a pleasure to read :) Aug 20, 2013 at 7:02
  • 5
    @MattD: answers on Stack Exchange are licensed under Creative Commons Attribution-ShareAlike 3.0 Unported, so yes, you can. Also, feel free to read a related post on my blog: Quantifying time and cost: Why do we always get it wrong?, as well as the answers to my question here: programmers.stackexchange.com/q/158640/6605 Aug 20, 2013 at 7:04
  • Why isn't there a part 4, 5, 6 etc. to that blog post ? Aug 20, 2013 at 11:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.