Skip to content
All articles
Working togetherSample

What a software quote should contain before you sign it

A price with no scope attached is not a quote, it is a guess. The seven things a written quote must state if it is going to protect either side.

4 July 2026 · Siddique Haider Hashmi

SAMPLE ARTICLE. Seeded content so the journal is not empty on day one. Replace or delete it before promoting the site — edit src/content/journal/what-a-quote-should-contain.mdx.


Most disputes over software projects are not really about quality. They are about two people holding different pictures of what was agreed, discovering the difference late, and each being genuinely convinced they are right.

A written quote exists to make that impossible. Here is what it has to contain to do the job.

1. What is being built, in specifics

“A website” is not a scope. “Five pages — home, services, about, contact, and a blog listing with article pages — with a contact form that emails you” is a scope.

If a line could mean two different amounts of work, it will eventually mean the larger one to you and the smaller one to whoever is building it.

2. What is explicitly not included

The most valuable section, and the one most quotes omit.

Writing the copy. Sourcing photography. Ongoing hosting costs. Translation. Migrating your old content. Any of these can be included — but only if someone says so in writing.

3. The number of revision rounds

Unlimited revisions sounds generous and is the fastest route to resentment. Two rounds at the design stage and two after build is normal. State it, so the fifth request is a conversation about scope rather than a grievance.

4. Timeline, with your obligations named

A five-week build assumes you supply content in week one. If that slips by a fortnight, the timeline slips by a fortnight, and this should be written down before it happens rather than argued about afterwards.

5. Payment schedule tied to milestones

Not dates — milestones. “On approval of the design” is verifiable. “On 15 March” pays for time regardless of what was produced.

6. Who owns what at the end

The code, the design files, the domain, the hosting account. The correct answer is almost always you. If a quote is silent on ownership, ask before signing, not after.

7. What happens after launch

How long are defects fixed for free? What counts as a defect versus a new request? What does ongoing support cost, if you want it, and are you obliged to take it?

The test

A good quote is one where, at the end of the project, both parties can read it and agree the thing described is the thing delivered.

If a quote you have received cannot survive that test, ask for a better one. Any developer worth hiring will be glad you did — the ambiguity protects neither of us.

Working on something like this?

If any of the above applies to a project you are planning, I am happy to look at it with you.