What a good quotation for a software project contains
Abdul Wahed Nur · · 2 min read
In short: A quotation should be a written offer with a number, itemised work, a clear total, one currency, a payment plan and plain terms.
A quotation is not a rough guess sent over chat. It is a written offer: this work, for this price, on these terms. If it is vague, the project will be vague too.
What I put in every quotation
- A number and a date. Each quotation has its own reference (for example
QUO-2026-0001) and, where I set one, a validity date, so both sides know which offer is being discussed and until when it stands. - Itemised work. Not one lump sum. Each line says what is being built, the quantity and the price. You can see where the money goes and ask to remove a line.
- A clear total. The subtotal, any discount shown as its own line, and the final amount. Nothing is hidden inside another line.
- One currency. The price is in either US dollars or Bangladeshi taka, never a mixture, so there is nothing to convert in your head.
- A payment plan. How the total is split over the project (see the post on installments).
- Terms in plain words. What is included, what counts as a change request, and how long the offer is valid.
What a quotation should not do
- It should not promise results nobody can guarantee, such as rankings or sales.
- It should not use pressure such as a fake countdown. If the offer expires, the date is simply written on it.
- It should not change silently. If the scope changes, you get a new version, not a surprise on the invoice.
What happens when you accept
You accept online. The accepted quotation then becomes an invoice with the same lines and the same total, so what you agreed is exactly what you are billed for. Nothing is retyped.
If something in the quotation looks wrong, say so before accepting. Fixing a line costs nothing at that stage.
