Question 1

How should a software development quote be structured?

Accepted Answer

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.

Question 2

Fixed bid or time-and-materials?

Accepted Answer

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.

Question 3

How granular should the scope description be?

Accepted Answer

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 is the single biggest source of project margin loss; granular scope sounds tedious but pays for itself the first time a feature request lands mid-project.

Question 4

Should I quote for code ownership or licensing?

Accepted Answer

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.

Question 5

How do I handle production support and SLAs?

Accepted Answer

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."

Question 6

What about acceptance criteria and sign-off?

Accepted Answer

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.

Question 7

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

Accepted Answer

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."

Question 8

How long should a software dev quote stay valid?

Accepted Answer

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.

Software Development Quote Template

Built for Engineering Work

T&M With Cap

Role-by-Role Rates

SLA Tiers Built In

Solo to Shop

Freelance Engineers

Custom Software Shops

Mobile Development

DevOps / SRE Consultants

Software Quote FAQ