How to Brief a Custom Software Quote: Scope, Costs, and Acceptance Criteria

Let's discuss your project →

If you need comparable quotes for custom software, do not start with price. Start with the process, the boundaries, and the acceptance tests. A supplier can only quote the same project as another supplier if the brief says what is in scope, what is out of scope, who owns each data set, and how the result will be checked.

That is the practical point of this guide. It helps an SME manager prepare a brief that makes a custom software quote readable before any commercial discussion. Microsoft’s requirements guidance stresses that requirements should be clear enough to test in practice (Requirements phase recommendations). Microsoft’s fit-to-standard and fit-gap guidance helps separate real gaps from habits that can stay unchanged (fit-to-standard and fit-gap analysis). And when you need to assess vendor readiness or delivery evidence, OWASP SCVS is explicit that scope and verifiable evidence matter (Using the SCVS).

If you want to map the service side as well, connect this article to Custom software and integrations, use Strategic IT advisory and governance when the process needs a broader assessment, and keep Contact Dedaloop for the non-confidential project details.

1. What this article is for

This guide is for the person who has to ask for a quote and does not want five suppliers to price five different interpretations of the same project.

At the end, you will have:

a short but complete brief for a simulated project;
a split between mandatory and optional requirements;
a data and integration register;
a cost structure you can ask every supplier to fill in;
acceptance tests that make the proposal measurable;
a simple rule for deciding when standard software is enough.

This is not a general guide to choosing a software house, and it is not a comparison exercise driven by AI. The goal here is narrower: prepare the project brief so the quote itself becomes comparable.

2. Start with the business process, not the feature list

The question is not “what screens do we want?” but “which process do we want to make more reliable?”

If the answer is unclear, suppliers will fill the gaps differently. One will include analysis, integrations, testing, documentation, release support, and maintenance. Another may price only the code needed to deliver a first version. Both can look reasonable, but they are not pricing the same scope.

Simulated case: the project used throughout this article

This is an editorial simulation. It does not describe a real client.

A distribution SME wants to replace spreadsheets and email exchanges between sales, warehouse, and administration with a small internal web application.

The project goal is to track internal requests, approvals, assignments, status updates, and basic reporting.

Field	Simulated content
Project objective	Replace manual files and email handoffs with one internal web application for request tracking and approval
Main users	Requesters, approvers, operators, administrators
Current pain	Duplicate data, different spreadsheet versions, no single status view, no reliable history
In scope	Request creation, validation, assignment, status changes, notifications, basic reporting
Out of scope	Full accounting, advanced CRM, full BI layer, native mobile app
Success outcome	One source of truth for internal requests, with traceable status and change history
Access mode	Browser-based access on desktop
Main constraint	Roles and permissions must be defined before development starts
Delivery question	Can this be solved with a standard product, or does the process justify custom software?

A brief this short is still useful because it answers the first question suppliers need to answer: what exactly are they quoting?

3. Separate mandatory requirements from optional ones

A quote becomes fuzzy when every wish is written as if it were equally important. Split the brief into two layers.

Mandatory requirements

Requirement	Why it matters	Detail to clarify in the brief
User authentication	Without access control, the workflow cannot be trusted	Who creates accounts and how users log in
Minimum roles: requester, approver, operator, administrator	Each role has different permissions and responsibilities	Which actions each role can perform
Request creation with required fields	Prevents incomplete records	Which fields are truly required
Search and filters by status, date, department	Needed to locate requests quickly	Default sorting and filter behavior
Change history	Needed for accountability and auditability	Which events must be logged
Basic data export	Needed for operations or reporting	Format and expected use

Optional requirements

Requirement	Why it is optional	When to keep it for a second phase
Email notifications	Useful, but not always necessary on day one	If the team can check the app frequently
Summary dashboard	Helpful, but not essential for the first release	If core workflow is more urgent
ERP integration via API	Valuable only if data must sync automatically	If manual import/export is acceptable initially
Attachments to requests	Useful, but can complicate storage and access	If the first process can work without files
Configurable approval rules	Stronger flexibility, but more design effort	If approval logic changes often

A practical rule: if a requirement does not change how the process works, but only how comfortable it feels, it is usually optional for the first quote.

4. Declare data ownership and integration boundaries

Quotes become impossible to compare when suppliers have to guess where the data comes from and who is responsible for it.

Data and integration register

Data or system	Data owner	Source of truth	Integration mode	Open question to resolve
User directory	HR or IT, depending on company structure	Corporate directory or internal account management	Import or sync	Manual import or automated sync?
Departments	Operations or administration	Approved master list	Read only	Who maintains the list?
Cost centers	Administration	Accounting or ERP system	Read only	Which system is authoritative?
Request status	Project workflow	New application	Native to the app	Which status values are allowed?
ERP customer/product data	ERP owner	Existing ERP	API or scheduled import	One-way or two-way sync?
Email notifications	IT or project team	Mail service	Outbound service integration	Which service handles sending and failures?

If two systems disagree, the brief must say which one wins. If that is not known yet, mark it as an open question rather than letting each supplier invent an answer.

This is also where a short fit-to-standard check helps. If the standard product already owns the authoritative data and the workflow is close enough, custom software may not be the right first move. If the process depends on company-specific rules or cross-system coordination, the gap is more likely to be real.

5. Ask suppliers to price the work as a structure, not as a single number

A single total is not enough. Ask for the same cost structure in every quote so the offers can be compared line by line.

Cost structure to request in the quote

Cost area	What it should include	What the brief should ask suppliers to state clearly
Initial analysis	workshops, requirements gathering, process mapping	number of sessions and included deliverables
Functional design	workflows, wireframes, data model, permissions	how many review rounds are included
Core development	implementation of the agreed scope	what belongs in the first release
Integrations	API work, import/export, connectors	which systems are included and on whose side
Testing and acceptance support	technical tests and user acceptance support	who writes the test cases and who signs off
Release	environments, deployment, configuration	how many environments and release windows are included
Training	user and admin training	format, duration, and materials
Security and access control	hardening, permissions, audit logging	baseline security responsibilities
Documentation	technical and user documentation	depth and update expectations
Maintenance	fixes and support after release	support hours, response model, and exclusions

This does not produce a price, and it should not. It produces comparability.

6. Define change control and maintenance before development starts

The biggest source of scope drift is not bad faith; it is the absence of a rule.

Use a simple change-control rule in the brief:

the request for change is written down;
the supplier assesses impact on time, cost, and testing;
the change is approved before work starts.

For maintenance, do not accept generic phrases like “support included” without detail. Ask the supplier to separate:

defect fixes from new features;
support requests from change requests;
response time from resolution time;
support channels from escalation channels.

Code ownership and access: points to settle in the contract

This article is not legal advice. It is a checklist of topics to avoid surprises later.

Ask the parties to clarify:

who owns the code produced for the project;
what usage and modification rights the client receives;
who controls repository access and deployment credentials;
who maintains third-party dependencies and updates;
what happens at handover or if the supplier changes.

If these points are missing from the discussion, the quote is incomplete even if the development price looks attractive.

7. Use acceptance tests that can be checked without interpretation

Microsoft’s requirements guidance is useful here: the requirements should be clear enough to be tested in a practical way, not left as vague intentions. Below are acceptance tests for the simulated project. They are deliberately simple and operational.

Acceptance test 1: create a request

Item	Content
Input	The requester enters title, description, department, priority, and an attachment
Expected result	The system saves the request, assigns a unique ID, and shows it as “new”
If it fails	The brief should state which field was invalid and whether partial saves are allowed

Acceptance test 2: missing required field

Item	Content
Input	The requester leaves the department field empty
Expected result	The system blocks submission, highlights the missing field, and creates no incomplete record
If it fails	The form rules are not precise enough and need to be rewritten

Acceptance test 3: authorised status change

Item	Content
Input	An approver opens a “new” request and approves it
Expected result	The request moves to “approved” and the event is recorded in the history
If it fails	The roles or status transitions are not defined clearly enough

Acceptance test 4: filter and search

Item	Content
Input	The user filters requests by “in progress” status and a date range
Expected result	Only matching rows are shown, in the order defined in the brief
If it fails	The search behavior and default sorting need to be specified

Acceptance test 5: unauthorised change attempt

Item	Content
Input	A user without administrator rights tries to change global settings
Expected result	Access is denied, no change is saved, and the event is logged
If it fails	Permission boundaries are missing or too broad

Acceptance test 6: export basic data

Item	Content
Input	The user exports requests for a selected period
Expected result	The export contains the agreed fields, in the agreed format
If it fails	The export scope and format were left too vague

These are not “nice-to-have” examples. They are the mechanism that prevents the quote from turning into a debate after delivery.

8. Know when standard software is enough

Custom software is not automatically the best answer.

A standard product may be enough when:

the process is common and does not create competitive advantage;
there are only a few exceptions;
custom work would mostly copy existing habits;
maintenance of a custom system would cost more than the benefits it creates.

That is where a fit-gap review earns its place. If the standard product covers most of the process and the missing pieces are small, a custom project may be the wrong first step. If the missing pieces are structural—specific rules, integrations, permissions, or workflow logic—then the brief should make those gaps explicit and measurable.

If you want to frame the decision internally, Strategic IT advisory and governance is the right place to look for a broader analysis. If you already know the process needs software work, Custom software and integrations is the service path that matches this kind of brief.

9. Troubleshooting: why quotes still come back incomparable

If you still receive quotes that cannot be compared, the problem is usually one of these:

No single process owner

Symptom: different departments describe different goals.

Fix: appoint one person to approve the brief and settle open questions.

Hidden integrations

Symptom: the supplier discovers a dependency only after sending the quote.

Fix: list every system that touches the process, even if the integration is only read-only.

Mixed mandatory and optional items

Symptom: the quote is high because every nice-to-have was treated as essential.

Fix: keep the first release lean and label future-phase items separately.

No acceptance criteria

Symptom: everyone agrees on the need but not on when the work is finished.

Fix: write concrete input/output tests, even if they are simple.

No decision on source of truth

Symptom: the same data exists in multiple places.

Fix: assign one authoritative system and say what happens when data conflicts.

No evidence standard for the supplier

Symptom: the proposal sounds good, but there is no way to compare readiness or delivery evidence.

Fix: ask for the scope of work, the evidence they will provide, and the assumptions they are making. OWASP SCVS is useful here because it puts scope and verifiable evidence at the center of the assessment (Using the SCVS).

10. What to send for the first discussion with a supplier

For the first conversation, do not send confidential data or credentials. Send only non-sensitive but complete information:

the process objective;
the users and roles involved;
the systems already in use;
the integrations you think are needed;
the top three problems to solve;
the two outcomes the project must deliver;
any security, audit, or release constraints;
what is already covered by standard software, if anything.

A useful first message can be as short as this:

We want to replace manual spreadsheets and email handoffs with one internal request workflow. The main users are requesters, approvers, operators, and administrators. We need authentication, roles, request tracking, search, history, and basic export. The current systems involved are [name them]. The main unresolved point is whether the workflow should stay inside a standard product or become custom software.

If you are ready to discuss the project, use Contact Dedaloop to share the process description and the integrations you need.

11. Final check before you ask for quotes

Before sending the brief, confirm that these five points are all true:

the process objective is written in one sentence;
in-scope and out-of-scope items are both listed;
data owners and source-of-truth systems are named;
acceptance tests are written in input/output form;
change control and maintenance are not left to assumptions.

If one of these is missing, the quote will likely be hard to compare.

If all five are present, the supplier can do something useful with your brief: they can estimate the same project, not five different interpretations of it. That is the difference between asking for a number and asking for a quote you can actually evaluate.