A custom software quote should help you decide what will be built, how you will accept it and what you will need after launch. A list of screens and a total price are not enough to compare suppliers. Neither is a request to “build a bot” or “connect the CRM”: each supplier may be pricing different behaviour.
I start with the business process and separate discovery, implementation, production setup and maintenance. This guide helps you prepare a brief and assess software or automation proposals without assuming rates, deadlines or savings that have not been established.
What I need before preparing a quote
You do not need to write a complete technical specification. I need to understand who does the work, what information they use and where they get stuck. Start with this brief:
- Problem: the task that fails or needs manual work, who performs it and the business consequence.
- First workflow: what starts the process, what it should produce and who accepts the result.
- Systems and data: current tools, available access and an anonymised sample of inputs and outputs.
- Volume and exceptions: typical load, known peaks and cases that currently need a human decision. Mark anything unmeasured as an open question.
- Constraints: an available budget if there is one, the deadline and its reason, access requirements and what can wait.
- Owners: who answers business questions, supplies access and runs the system after delivery.
That context helps me decide whether to adapt an existing tool, scope an integration or build a product. It is the starting point for how I approach a project before writing code.
What a custom software quote should include
Ask suppliers to quote the same first release. Mark each item as included, optional, excluded or subject to discovery. An unresolved item needs a decision before you can treat the total as a fixed commitment.
| Item | What to document | How to verify it |
|---|---|---|
| Scope | Users, complete workflow, data and exclusions. | Demonstration of the agreed flow, including permissions and failures. |
| Integrations and migration | Systems, data direction, cleanup and duplicate handling. | Sample migration and connection failure tests. |
| Delivery | Milestones, test environment, reviewer and approval conditions. | Evidence for each criterion before accepting a milestone. |
| Production | Deployment, configuration, logs, alerts and necessary recovery. | An operational walkthrough and failure procedure. |
| Running costs | Hosting, licences, external usage charges and who pays them. | Usage assumptions and costs separated from the build. |
| Support and handover | Coverage, fixes, improvements, source access and documentation. | An account inventory and handover the team can use. |
Payment milestones and the process for approving scope changes also need to be explicit. If one proposal includes data migration and another delivers an empty application, the totals describe different purchases.
A scope and acceptance test example
Hypothetical example: a company wants to send enquiries from a form to its CRM. The first release includes one form, one CRM, agreed fields and an exception queue for operations. Two-way sync, historical imports and AI classification are excluded.
Before accepting that delivery, I would agree tests such as:
- A valid enquiry creates a record with the agreed fields and owner.
- Sending the same enquiry again does not create a second opportunity; the identifier used to recognise it is defined.
- If the CRM is unavailable, the enquiry remains pending and an operator can see what happened.
- Once the connection returns, the pending item can be recovered without lost data or a duplicate operation.
- Incomplete input goes to review with a visible reason.
- A person without permission cannot view the enquiry data.
Volume, acceptable processing time and recovery attempts need agreement based on the actual process. They are not universal guarantees. The data pipeline to a CRM article explains these dependencies in more detail.
Fixed price, discovery or staged delivery
A fixed price fits when inputs, access, behaviour and acceptance are defined. If an API has not been tested or nobody knows the quality of historical data, I prefer a bounded discovery phase first. Its output should resolve the uncertainty: a connection test, a data sample and a revised scope.
For staged delivery, each milestone needs an outcome, an agreed spending limit and a review point. For time-based work, agree how usage is reported and who authorises continued work. No model eliminates change; it should make the effect on budget and schedule visible.
The software development estimation guide covers effort and uncertainty. The decision here is which delivery you are approving and under which assumptions.
What I separate from the initial build cost
I distinguish building the system from running it. Infrastructure, external services, API usage, support and new features can have different terms. A fix against an agreed acceptance criterion and a new feature should also be distinguished in the proposal.
For automation, I check what happens when a source changes or access expires, who receives the alert and how work resumes. The Adslyfy case study shows execution records, attempts and screenshots used to investigate failures. It is evidence of those operational components, not a pricing or savings benchmark.
How to choose between proposals
I first check that proposals cover the same workflow, then review the open risks. Ask for clarification on a deliverable you cannot verify, a recurring cost without an owner or a dependency without confirmed access. Explicitly reducing scope can be a sensible decision; leaving it ambiguous makes the purchase harder to assess.
If you need an independent technical review before choosing a supplier, that fits my fractional CTO work. If the scope is already clear, we can discuss implementation.
Prepare the next step
I build custom software and SaaS products and business process automation. To assess your project, send the current workflow, the systems involved and the first outcome you need. If you already have proposals, summarise their differences without sharing credentials or customer records.
We can start by reviewing your project scope and identifying the information needed for a useful proposal.