The conditions behind every number
Every software estimate rests on things the estimator treated as true: how many users, which languages, who supplies the content, how standard the payment gateway is. When those stay in someone’s head, the first wrong one becomes an argument. When they are written down and confirmed, it becomes a re-quote.
That written list is the assumptions register.
What one looks like
| Assumption | Status |
|---|---|
| English only | Confirmed |
| Under ten thousand users | Confirmed |
| You provide the content | Confirmed |
| The payment gateway has a standard API | To confirm |
Short, specific and checked by you before the price is final.
Assumptions are not exclusions
Both belong in a quote, and they do different jobs:
| Assumptions | Exclusions | |
|---|---|---|
| What it states | Conditions the price rests on | Features the price does not include |
| Example | “Under ten thousand users” | “A second language is not in this release” |
| If it changes | A pre-agreed trigger to re-quote | You add the item at its stated price |
More on the second list: What is an exclusions list in a software quote?
What a good assumptions register does
- Written — part of the quote you sign, not an email.
- Specific — “under ten thousand users”, never “normal usage”.
- Confirmed before pricing — you have seen and agreed every line.
- Tied to a rule — a wrong assumption triggers a re-quote of what it affects, and nothing else.
A template you can ask any vendor to fill in
| Assumption | Confirmed by you? | If it turns out wrong |
|---|---|---|
A vendor who fills this in has told you what their price depends on. A vendor who cannot is asking you to find out later.
How Pricient handles it
Every Pricient quote ships with its assumptions register alongside the specification, the Not in this release list and a three-tier itemized price. You confirm the assumptions before pricing, all of it arrives before you pay anything, and the quote is locked for 14 days.