Fixed-price software projects: what must be in the scope

Hook: Vague requirements in a fixed-price software build guarantee a disputed final invoice.

If you run an Australian business, you want certainty before funding a custom software build. A fixed-price contract promises financial safety, but only if the scope is ironclad. Without absolute clarity, your team and your vendor will disagree on what “done” means. You walk away with an unfinished product, or your vendor walks away broke.

This guide shows you how to structure a fixed-price software scope. You will learn the specific documents and definitions required to align expectations. By the end, you will know how to separate strict deliverables from assumptions to ensure your business gets exactly what it paid for.

Table of contents

• Detailed functional requirements
• Non-functional requirements and constraints
• User stories and acceptance criteria
• Strict deliverables
• Out-of-scope items
• Assumptions
• Change control process
• Practical examples
• What this costs and what it takes
• Common mistakes
• Decision checklist
• FAQ
• Next steps

Detailed functional requirements

Functional requirements state exactly what the software must do. They form the core of your build.

If your system needs an admin panel, the scope must list the exact actions an admin can perform. “Admin can manage users” is too vague. You need “Admin can create, edit, suspend, and delete user accounts”. Every button, form, and data point must be documented.

When you leave functional requirements loose, vendors guess. Their guess will be the cheapest option to build. If you require complex workflows, spell them out step by step.

Non-functional requirements and constraints

Non-functional requirements dictate how the system behaves under pressure. This covers performance, security, and scalability.

Your scope must state the expected load. If you expect 500 concurrent users, say so. If pages must load in under two seconds, specify it. Security standards, especially for Australian businesses dealing with the Privacy Act 1988, must be clear. Specify the encryption standards for data at rest and in transit.

Constraints also sit here. If the software must run on AWS or integrate with a specific local gateway like eWAY, lock it in.

User stories and acceptance criteria

User stories define the value of a feature from a specific perspective. Acceptance criteria define when that feature is complete.

A user story looks like this: “As a warehouse manager, I want to scan barcodes so I can update stock levels instantly”. The acceptance criteria for this story make it measurable. “The scanner must beep on success. The database must update within one second. An error message must show if the item is not found”.

You cannot approve work without clear acceptance criteria. They remove subjective opinions during final testing.

Strict deliverables

Deliverables are the tangible items you receive at the end of the project. The code is only one part of this.

Your scope must list every expected output. This includes the source code repository, deployment scripts, database schemas, and API documentation. If you expect user manuals or training videos, add them.

Without a list of deliverables, you might get a working application but no way to host it yourself or train your staff.

Out-of-scope items

Defining what you will not build is just as important as defining what you will. Out-of-scope items protect the vendor from scope creep and protect you from delays.

If you are building an MVP, explicitly state that mobile apps are out of scope. If the system integrates with Xero but not MYOB, write “MYOB integration is out of scope”.

Listing exclusions stops debates halfway through the build. You can always refer back to the one page scope that gets grant and build aligned for a tight summary.

Assumptions

Assumptions are the facts you believe to be true but cannot control. They highlight risks.

If your software relies on a third-party API, an assumption might be “The provided API documentation is accurate and the endpoint is available 99% of the time”. If the API fails, it is not the vendor’s fault.

Documenting assumptions ensures everyone understands the external dependencies that could delay the project.

Change control process

Even the best scopes need adjustments. A change control process dictates how you handle new ideas.

When a new requirement arises, it must be costed. The scope should explain who requests the change, who estimates the impact on time and budget, and who approves it.

A formal process stops casual requests from derailing the timeline. If you prefer fixed budgets but flexible scopes, you might want to look into the fixed price product studio model.

Practical examples

Consider an Australian logistics company building a tracking portal.

A bad scope says: “Customers can track their orders”.

A good scope says: “Customers enter an 8-digit tracking number on the public portal. The portal queries the local database and displays the current status (Dispatched, In Transit, Delivered). The query must return results in under two seconds. Driver GPS tracking is out of scope”.

This level of detail ensures the logistics firm gets a functional tracker without paying for unnecessary maps.

What this costs and what it takes

Scoping a custom software project takes significant effort.

You should expect a thorough scoping phase to take 2 to 4 weeks. For an enterprise build, it can cost between $10,000 and $30,000 AUD just to write the scope. This phase often involves workshops, technical architecture design, and UI wireframing.

Paying for a scoping phase reduces the risk of the actual build. It is an investment in certainty.

Common mistakes

Many businesses fail to scope correctly. Here are the main traps:

1. Relying on wireframes alone without written rules.
2. Using words like “fast”, “secure”, or “scalable” without numbers.
3. Forgetting to assign an internal product owner to answer vendor questions.
4. Ignoring data migration from legacy systems.
5. Assuming the vendor will write the legal terms of service for the app.

Decision checklist

Use this checklist before signing a fixed-price contract:

• Every feature has functional requirements.
• Performance metrics and security standards are defined.
• User stories have measurable acceptance criteria.
• Tangible deliverables are listed.
• Excluded features are explicitly named.
• External dependencies are documented as assumptions.
• A formal change request process is agreed upon.

FAQ

What happens if we forget a feature in a fixed-price scope? You must submit a change request. The vendor will provide a separate quote and timeline for the new feature.

Should wireframes be part of the scope document? Yes. Wireframes remove visual ambiguity, but they must always be paired with written functional requirements.

Can we change our minds during development? Yes, but it will cost money and time. Fixed-price contracts penalise changes to protect the agreed budget.

Who owns the source code at the end? Your deliverables list should state that you receive full ownership of the custom source code upon final payment.

How do we handle bugs after the project goes live? Your contract should include a warranty period (usually 30 to 90 days) where the vendor fixes bugs against the original scope for free.

Next steps

A tight scope is the foundation of a successful software build. If you need help defining your next project, book a scoped call with Zimozi. We will help you turn your business requirements into a technical roadmap that guarantees delivery.