Software development quote template

Software quote FAQ

How should a software development quote be structured?

Most engagements quote three things separately: (1) Discovery / scoping work as a fixed fee: typically 5-10% of estimated total, (2) Build phase as either fixed-bid (well-defined scope) or T&M-with-cap, (3) Ongoing support / SLA as monthly retainer. Itemize roles and rates if relevant (architect, senior engineer, junior, QA), sophisticated clients expect this.

Fixed bid or time-and-materials?

Fixed bid for tightly-scoped work where requirements won't change (e.g. "build a CRUD admin for this existing API"). T&M for anything exploratory, anything touching legacy systems, or anything where the client doesn't yet know what they want. T&M-with-not-to-exceed cap is the compromise: client sees a budget ceiling, vendor isn't on the hook for unknown unknowns. Most experienced shops do T&M-with-cap by default.

How granular should the scope description be?

Granular enough that an arbitrating party (client's CTO, your lawyer, a court) can determine whether something is in or out of scope. "User authentication" is too vague; "User authentication: email/password, password reset via email, session expiry at 7 days, no OAuth, no MFA" is unambiguous. Vague scope costs you margin. Writing it out in detail feels tedious, but it pays off the first time a feature request lands mid-project.

Should I quote for code ownership or licensing?

State explicitly. Standard pattern: client owns final delivered code on full payment; developer retains rights to reuse generic libraries / patterns developed during the engagement. For SaaS-style work where you're building a vertical product, you may quote a per-seat or per-volume license rather than transferring ownership. Be explicit in the terms, IP ambiguity is litigation-grade risk.

How do I handle production support and SLAs?

Quote separately from the build phase as a monthly retainer with tiered SLA: Bronze (next-business-day response, 2-week resolution target), Silver (4-hour response, 48-hour target), Gold (1-hour response, 8-hour target). Each tier has a monthly minimum + bucket of hours; overages billed at hourly rate. State the scope of support clearly: "Bug fixes for code we wrote; new feature work quoted separately as change orders."

What about acceptance criteria and sign-off?

Every phase / sprint / deliverable should have written acceptance criteria in the SOW. The quote is the financial agreement; the SOW (or contract) is where acceptance lives. Reference the SOW from the quote ("per acceptance criteria detailed in SOW dated 2026-04-22"). Without explicit acceptance criteria, projects drift into perpetual revision; with them, sign-off triggers payment and closes scope.

Should I quote infrastructure costs (AWS, hosting) as pass-through?

Generally yes: pass-through at-cost during build, then transition to client's own AWS/cloud account at production go-live. Don't bake cloud spend into your fee; it grows independently of your work and creates billing disputes when AWS hands the client a $4K bill they didn't expect. State explicitly: "Cloud infrastructure (AWS/GCP) billed pass-through at cost during development; transitioned to client's account at launch."

How long should a software dev quote stay valid?

30 days is standard; some shops do 60. State expiration explicitly. Engineering rates change quarterly, capacity fluctuates, and tech stack assumptions you made during scoping go stale. A 6-month-old quote based on a particular framework version may need to be re-priced. Lock pricing for 30 days, re-quote thereafter.