How a fixed-price software quote is actually built

When a studio quotes a fixed price for custom software, clients often assume the number came from a spreadsheet of hourly rates. It usually did not. Here is what actually goes into one — and what you should ask for before you sign anything.

1. A scope, not a wish list

The quote is only as good as the scope behind it. A usable scope names the screens, the user roles, the data that gets stored, and the third-party services involved. “An app like Airbnb” is not a scope; it is a direction. The first job of a scoping call is to turn the direction into a list you can both point at.

2. Assumptions, stated out loud

Every fixed price rests on assumptions: that your payment provider approves the account, that the client supplies content by a given date, that the existing API behaves as documented. Written assumptions are what keep a fixed price fair to both sides. When an assumption breaks, the price conversation is about that one assumption — not about the whole project.

3. Milestones, because nobody should pay for a black box

Long projects get split into milestones of roughly two weeks. Each one ends with something you can click and a payment tied to it. If a milestone slips, you find out at the end of that milestone, not three months later.

4. An explicit change process

Scope changes. The question is what happens when it does. The healthy answer: changes are written down, estimated, and approved before they are built. The unhealthy answer: an hourly meter that quietly absorbs them.

What to ask any studio before you sign

• What exactly is in scope, and what is explicitly out?
• What assumptions is this price based on?
• What does each milestone deliver, and what does it cost?
• What is the process — and the rate — for changes?
• Who owns the code, and where does it live during the project?

If a studio cannot answer those five in writing, the fixed price is not fixed. It is just a number.