Before You Sign a Software Quote: 11 Things It Should Include

A software quote usually looks reasonable. Clean layout, a total amount, a timeline, a description of what will happen. The founder reads it, hears the price, feels it fits the budget and is ready to sign.

A quote without scope, assumptions, responsibilities and risks looks clearer than it is. What is in the document is often overestimated. What is missing tends to cost you the most later.

Eleven items I want explicitly written into every software quote before it gets signed. Not because agencies should be distrusted, but because the agreements that otherwise stay unwritten should be made visible.

1. Scope, what exactly is being built

Ask for concrete functional descriptions. Not “a dashboard”, but “a dashboard with these three screens, these four actions and these two filters”. A quote that only lists work packages and hours gives you no measurable way to judge what you are getting.

Without concrete scope, a timeline quietly drifts with the interpretation of two parties.

2. Assumptions

Every quote rests on assumptions. That customers already have an account with a third party. That data arrives in a certain format. That one design system is enough. That the team speaks the local language.

Those assumptions should be in the document. Not to absolve the builder of responsibility, but because they are the basis for the price. If one of them turns out to be wrong, the conversation should restart.

3. What is explicitly not included

This may be the most important section. A quote tends to describe what gets built. What is not included is where the surprises live.

Ask specifically: is hosting included? Domain registration? Application email? A test environment? An initial analytics integration? Accessibility checks? Translation? Browser support for older devices? A staging environment for your own team?

If these are not explicitly included, you will hear later: “That wasn’t part of the quote.”

4. Timeline

A timeline without milestones is not a timeline. What is the first usable moment? When does which functionality ship? When is the test period and how long is it?

Prefer a timeline tied to decisions, not just technical milestones. “Backend done” tells you little as a founder. “First customer can register and complete their first action” tells you a lot.

5. Code ownership

Without an explicit clause, ownership is not automatically arranged the way founders expect. Ask for a clear rule: you become the owner of the code, the designs, the documentation, the accounts and the infrastructure that sits under the agency’s name.

Ask specifically whether the agency uses open-source components or proprietary frameworks with licence terms attached. Those terms should not constrain you later.

6. Dependencies

Which external services are used for authentication, payments, mail, monitoring, hosting? What do they cost? What dependency does that create?

A software agency sometimes chooses services whose price or reliability does not match your stage. Ask before the choices are made, not after.

7. Maintenance

What happens after launch? Who hosts it? Who gets alerts when something breaks? What does the agency do about bugs in the first months? When do they start charging hours?

Many founders discover after launch that maintenance is not included, that out-of-hours support costs extra, or that a fixed monthly amount is expected. Better to talk about that before signing.

8. Testing

Who tests what? Are tests automated, manual, or both? Who reports bugs and who fixes them within what timeframe?

A quote without an explicit test budget usually pushes that work into the launch phase, where the pressure to “go live” beats out diligence.

9. Security

What are the basics being done: HTTPS, secure-by-default headers, password policy, backups, access control to the production environment? Which sensitive data are you storing and how?

For an early-stage startup this does not need to be a full security audit. It does need to be a demonstrable set of basic measures, not “we handle that properly”.

10. Acceptance criteria

When is something done? What has to be true before you accept it? A quote without acceptance criteria gives the agency the right to define what “delivered” means.

Write down acceptance criteria for the most important features. For example: “a new customer can create an account in under 3 minutes and complete their first action on both mobile and desktop”.

11. Change requests

Changes always come up. How are they handled? Who estimates them? Which changes fall within the quote and which get charged separately?

A reasonable approach: small in-scope changes are absorbed; larger changes get their own small quote with an estimate. Not unlimited changes “within reasonable use”, that creates arguments later.

Why the headline total tells you almost nothing without context

Two quotes with the same total can deliver completely different value. One builds three features with care for testing, security and maintenance. The other builds six features, half of them untested, that you will need to replace in six months.

For a founder engaging a software agency for the first time, judging a quote is hard. It is not incompetence, it is a lack of reference points. Other founders who have walked this path recognise patterns you are seeing for the first time.

A quick independent check of a quote often helps more than another week of reading it yourself.

---

Facing this decision?

Send me the context or book a free call. We will look at the most sensible next step before you commit time, money or focus.

Book a free call → · Email directly: hello@yourstartup.expert