The best way to create price quotes

Header image photo by Brett Jordan on Unsplash

I've worked in two web agencies ( for about eight years in total ) and am a private consultant. I've worked as a project manager, developer, tech lead, analyst and even as a Chief Business Development Officer during those years. Over the years, I've even consulted a few other web agencies on how to run their business better. Right now, I consult companies as a product owner or CTO, and the aim of my work is always not to create code or projects but to solve problems. I created this post here to see how others work and perhaps initiate a discussion on how to make better price quotes and keep our relationships with the clients better.

How I create price quotes has changed quite a bit over the years. I've grown to value preparation more than anything else. I never launch into development before I've written a document for the client, which states what the problem is and what kind of user stories cover the whole project and solve the problem. This serves as a basis for the quote, but its primary importance is ensuring you're always on the same page with the client. I've found that most problems with the client come from the "I thought you would do that too" type of issues. That kind of work should also never be done for free as the document would not only be the basis for future project development but also serve as backup should you change the developer or board another employee who wants to know what can be done with the project/tool, that you've built.

Once that work is done, though, here's how I create my price quotes.

1. I always state what the client gets due to the work done based on the quote.

There is no need to dazzle the client with many technical details. The client is hiring you to solve a problem they have. So state what kind of problem will be solved and what the client can do due to your work. Your work might be done in phases, so if you have created a project spec for the client before, then make sure you spell out which user stories will be delivered.

An example would be something like this:
As a result of the work done based on the price quote, you'll be able to "Log in to the application and see the data acquired from XYZ API". The quote covers stories 1, 2, 50 and 51 from the attached product spec.

2. Open an Excel sheet and write down all the technical details that need to be done to cover those stories.

The point of this step is to list all the nuances and ensure you understand everything that needs to be done. If you don't have the information for this - you're working in a web agency setting - then have a developer or tech lead create this list for you. The reason for this is still not dazzling your client with technical words. This list will serve as a basis for the next step and for understanding what the correct price for the work will be.

3. Create columns following the task list to determine the accurate pricing for each line.

The columns I created are "Have I done this before? If yes, then how much time did it take then?", "Complexity", "unknown", "hours", "price"

Then, enter the numbers into the table. The value in the first column should be the hours/days it took to achieve the goal when you did it the last time.

The columns "complexity" and "unknown" should be filled to highlight the things you do not know about the task at hand. You probably have done something similar before and know what to expect. But perhaps you've not, and especially then, you should be completely honest about the complexity and unknown of the task. It would be best if you always strived to reduce complexity and unknown. But sometimes, due to different constraints, it is not possible.

I usually use values between 1 and 3 for both columns, so for me, the table might look something like this by now:

What I do next is estimate the hours for the rows with "complexity/unknown" and multiply it by values in both "unknown" and "complexity" columns. So API Authentication is usually relatively trivial, so I might enter an hour or two in the "hours" column and multiply it with the values in the "complexity" and "unknown" columns.

If the result seems or feels too big, there are a few things you can do to reduce it:

1. See if you can be even more specific and divide the task into smaller steps. If you can, you've probably reduced the complexity or unknown for each split line. You can see if the sum of those divided tasks adds up to the amount you wrote behind.
2. You can remember that sometimes, the client does pay for your learning process and uses that knowledge to resist the temptation to lower the price/amount for that specific task.
3. You can choose to lower the price for the task because you'll gain reusable skills/knowledge. Something that'll pay off in the future. I've found that the value that you write off rarely materialises in future projects, though. It'll appear in your confidence, though and speaking with confidence about problems you've solved might pay off later. But it might not.

In the end, I'll be very, very careful about reducing the planned time for a task. You'll almost always end up needing a buffer. Which brings us to the last point:

4. Put the first and last column into your price quote, but before doing that, add a buffer.

You'll almost always need it for different things - exchanging emails with customers, explaining things - and communicating. Remember that communication mainly decides if the project is successful or not. This is why you need to plan time for it. Name it project management or anything else. It would help if you prepared for that. You'll also need it for reading the documentation of other services. Seeking help, and so on. And you'll need it for things you've forgotten but are either written in your user stories or end goal. It would help if you had it for different nuances you failed to consider.

One last thing about the buffer - all developers are optimists. Based on my experience, all developers ( even the most experienced ones, including myself) estimate their abilities and speed by about 25 to 50%. If you don't use a time tracker and don't know how much time doing something has taken you in the past - estimate it, but add a buffer to cover for your optimism. But there is a downside, explained by Parkisons Law in 1955. The law states that "that work expands to fill the time allotted for its completion". You need to add some buffer to cover for your optimism, but you must also keep the Parkinsons Law in mind and push yourself to complete the task within the allotted time.

5. Concatenate some of the lines you wrote, reduce the final technical buzzwords and tie the technical implementation together with what the client is getting.

Using the example picture, the final list of quoted work might be something like this:

• Project and server setup - X amount including:
  • project dev environment setup.
  • repository and automatic quality assurance and project deploys
  • Nameserver changes
  • server setup at AWS/DO
• Authentication & registration - Y amount including:
  • Facebook authentication & registration.
  • user registration with email, name and password.
  • email and password authentication.

The goal here is not to give the client too much detail. They tend to get stuck in more information like - "Why does X take so much time?". You'll want to list everything you'll do to seem professional but also not appear to add a price to every single thing. The client might read the list and want to remove some of the items from the list to reduce their costs.

6. Some other general pointers I've learned along the way:

• You'll always be able to quote the things you've done before the most accurately.
• You'll do better if you add a clause to the price quotes where you say, "I serve the right to review the quote after the design for the project has been confirmed". When you create user stories and the design is made based on those user stories, the stories become alive for the customer, and they'll get a better understanding of what they'll get. They might also ask for new features or changes, and they need to understand that your work will also change. Stop a feature creep as early as possible by training to say, "I need to review the quote based on the changes you asked".
• You'll be able to get more accurate price quotes sometimes when you do not go into too much detail but rather compare the current project with some previous ones with the same size and complexity. To be able to do that, you'll need to keep track of the time you've spent on those projects, though. Always keep track of where your time goes.
• The most demotivating thing you can ever do is to fail to prepare and end up working on a project that is overtime and over budget with a risk of not being paid but still needing to deliver the work.
• The technical rep on the client side is heaven-sent. Someone who can understand what you're quoting, why things take so long and what needs to be done to complete work - and if they can explain those things within their company. Those people make projects fun to develop.
• Never make a plan that forces you to work more than 6 hours daily. The reason is that the quality of your work takes a sharp decline after working 6 hours per day. And the more you work past those 6 hours, the more time you need to recover, putting the ability to work 6 hours at maximum efficiency in jeopardy. The more you work over 6 hours per day per week, the more your average quality declines and the more you need to ask from your client per task, making you more and more inefficient. And if you wanted to work 8 hours per day, you would not be a freelancer, like me, right?

Anyway. That's how I work. Let me know your process for creating price quotes you do not exceed and where you don't feel like you've delivered more than you were prepared to give.