How to charge our clients?

Published in

Kamil Lelonek - Software Engineer

5 min readDec 14, 2015

And why we are bad at it.

Software developers, either individually or as a company, usually work for external customers. We sign different contracts between us and them which specify how our projects are billed.

Currently, there are two the most popular kind of agreements:

Time and Material
Fixed Price

Each of them can fit perfectly a particular use case because they are fundamentally different, and different clients may need different solutions.

What is the problem?

The difference between fixed-cost and T&M is in who takes the risk of spending money and getting nothing in return.

The problem is that our client always lose, no matter what they chose.
And money is not always what they lose.

Fixed Price

A fixed-price contract is a type of contract where the payment amount does not depend on resources used or time expended. Or maybe it depends on them but it’s calculated upfront.

If a company completes a job early, it’s a bonus for developers (and a client overpays). If the developers don’t deliver the software on time then, the company loses.

Every developer knows that accurate software estimation is not possible even when perfect information is available about project requirements (i.e. practically never). That’s why the first case almost never happens.

The bottom line is a client paying for an outcome in a fixed price contract instead of simply paying for someone’s time. The client specifies the “what” and leaves it to the developers to determine the “how” for the most part. A company assumes the risk of delivering the outcome which customer wants.

In fixed-price a client feels secure — “if a price is fixed, how can I lose?”

The loss is in quality.

At the very beginning, developers may pay attention to a codebase. They sometimes even write tests. However, when the deadline approaches or when the project is running out of hours, the quality suffers. There’s no time to write tests and no money for code-reviews, quality checks and taking care of code separation and modularization. Just make it working.

Time and Material

In T&M a client will simply pay and pray.

In the Time And Material pricing strategy, a company work on a project and bill for every hour worked without regard to any financial constraints. An estimate may have been created, but since developers are paid regardless of whether they exceed the estimated amount, they don’t do more than just track their time.

No matter how good or bad the code written during a month — a client still has to pay the bill. How many more invoices will they get until the product is done? Nobody knows.

In this scenario, the client is taking on an entire financial risk. The client will most likely have an internal budget they are monitoring to ensure the actual amount worked is tracking to the estimated amounts. Unfortunately, what is missing here, is what scope has actually been completed. Without this information, the client cannot accurately gauge the progress of the project and thus does not know if the estimate is going to exceed the estimate until it actually does.

Is there a solution?

You may wonder right now — how to solve it? Is there any kind of invoicing that both a client and a team can be happy? Well, there are some ways to achieve that.

Incremental billing is a suggestion proposed as the most profitable here. Instead of charging customer upfront or unpredictable, we invoice for what we really delivered.

As the project progresses, we track our hours worked on the project and the features completed there. We work closely with our clients, meeting with them weekly to discuss the current status. Part of that weekly discussion involves reviewing the financial health of what we’ve agreed. We are upfront on the amount of budget that we have consumed and the progress we have made towards completion of the project.

By the end of the week, the client gets an updated version of a project plan, with a re-estimated budget. Thus, they see what was done so far and how much needs to be done, according to estimations.

How does this help to not waste money? Here’s how:

client fully controls their budget
the client pays only for the work completed
the client tracks the progress with few-minutes-granularity
the client doesn’t pay for unrelated chats, lunches or coffee breaks
programmers stay very motivated since they are paid by result
there is no long-term commitment, it can be stopped at any time
every increment passes all quality checks

The final outcome is a better product that better meets the needs of its users. Because we are actively monitoring and managing the budget, the client has the information necessary to feel comfortable with these scope changes, and we can determine the impact the changes will have on the budget.

The financial risk is now better managed and does not fall solely on a single entity.

Summary

As software developers, it is our responsibility to provide clients with a realistic estimate of a project’s scope and budget (i.e. probably much higher than they think) and to explain why close collaboration and communication are much better vectors of project success than an arbitrary fixed price.

What is a risk in this approach? Our customers may decide to walk away and offer the work to a competitor. Sometimes, if we don’t want to agree on a fixed-price contract, many clients won’t trust us.

This is a case we need to discuss and decide if producing a high-quality product is worth that risk. I think it is.

Subscribe to get the latest content immediately
https://tinyletter.com/KamilLelonek

If a company offers a fixed price for a complex, poorly specified project and it seems to good to be true, it probably is.