Custom software cost depends on what staff must be able to finish in the system, which existing records and tools it must work with, and who will keep it running after launch. A useful budget separates the initial delivery cost from ongoing ownership, with explicit allowances for uncertain work.
Before comparing headline prices, check whether each quote delivers the same usable business process. A system that lets staff create a job but cannot correct it, reassign it or find its history may leave the spreadsheet doing essential work.
One job record, different useful views
Do the work
See what matters
See the operation
Reduce the number of tasks in the first release before removing the steps needed to finish each task. That is usually a better starting point for controlling scope than asking for the same feature list at a lower price.
Start with the process you want to replace
A generic price range cannot tell you whether your budget covers your business. Start with a short description of the work, supported by a sample spreadsheet, form or document with sensitive information removed.
- Starting point: what triggers the work, such as an enquiry, approved order or new job?
- People: who enters information, approves it, corrects it and needs to see it?
- Volume: how often does the task happen, and are there busy periods or simultaneous users?
- Completion: what must happen before staff can consider the task finished?
- Exceptions: what happens when information is missing, somebody makes a mistake or a request is cancelled?
- Existing information: which records, attachments and histories must remain available?
Check whether an existing product can handle that process through configuration before commissioning custom software. Compare the complete workflow, including workarounds and ongoing administration, rather than the appearance of the screens.
The GAO Cost Estimating and Assessment Guide treats scope, assumptions, documentation and updates as foundations of an estimate. It is not a source of commercial software prices, but the principle is useful here: an early budget should change as uncertainties become defined work.
What changes the cost of a first release?
The number of screens is a weak guide on its own. A simple approval screen can contain complicated rules about spending limits, delegated authority and who may change a decision.
Workflow rules and access affect how much behaviour needs designing, building and testing. One staff role following one process is different from several departments with different permissions and approval routes.
Connections to other tools add questions beyond transferring information. What happens if the accounting system is unavailable? Can a retry create a duplicate invoice? Who investigates a failed transfer? If connections are a substantial part of the proposal, use this guide to what an API integration quote should include to examine them separately.
Existing records need an explicit decision. Importing clean current jobs is different from combining years of inconsistent spreadsheets and attachments. Someone must define which records move, resolve duplicates and check the imported results.
Quality and operating requirements also change the work. Specify the devices staff use, accessibility needs, sensitive information, acceptable downtime, backups and recovery expectations. A browser-based office tool and a system that must work without an internet connection are different scopes.
Ask suppliers to separate understood work from assumptions that need investigation. A short paid discovery phase can be sensible when a critical connection or data problem is uncertain, provided it produces usable requirements and a revised estimate.
Worked example: replace job approvals without keeping two registers
Illustrative scenario, not a supplier quote: an operations team records job requests in a spreadsheet and asks a manager for approval by email. The first release will cover one team using desktop browsers. It will hold current jobs, record approval decisions and let staff find the latest status.
A narrow but complete version would let staff submit a request, return it for correction, approve or reject it, record cancellation and search its history. It would define who can change an approved request and whether that change needs fresh approval.
A cheaper screens-only proposal might cover submission and approval but omit corrections and current records. Staff would then need the spreadsheet for unfinished jobs and changes. The lower quote would buy a different outcome.
For this example, defer customer access, additional departments and advanced reporting before removing routine correction paths. An accounting connection could also wait if an agreed export and named staff member can handle that hand-off without maintaining a second job register.
A reusable budgeting worksheet
Ask each supplier to price the following work separately, using the same assumptions. These are budget headings, not assumed market prices.
- Definition and design: confirm approval rules, staff roles, screen layouts and acceptance tests.
- Development: build the complete request-to-decision workflow, search, correction paths and decision history.
- Data migration: import current jobs from one agreed file format, test the import and reconcile records. Identify who cleans the source file.
- Connections: specify whether notifications or exports are included. Price any live accounting connection separately, including failures and retries.
- Testing: cover permissions, routine exceptions, supported browsers and staff acceptance testing, with time to resolve defects.
- Launch and handover: include deployment, training, instructions, account setup and the move away from the spreadsheet.
- Hosting and services: identify recurring infrastructure, storage, email and other subscription charges.
- Support and maintenance: define monitoring, updates, incident handling, backup checks and responsibility for recovery.
Calculate the launch budget by adding the agreed one-off delivery items and any separately priced transition work. Build the operating budget from recurring services, the agreed support arrangement and planned improvements over your chosen budget period. Keep unresolved items visible as provisional allowances rather than hiding them inside a single total.
For the example, launch acceptance should include reconciling imported jobs and completing representative requests, including a correction and cancellation. Give the old spreadsheet a clear cut-off: historical access may remain read-only, but staff should know where all new updates belong. Any temporary parallel running needs an owner and an end condition.
Replace the Approval Spreadsheet With a Complete First Release
Before: approvals split across tools
Built: one complete approval task
Fund ownership separately from the build
Your custom software development budget should distinguish keeping the system working from extending what it does.
Running costs include hosting, storage, third-party services and licences. Ask what usage assumptions apply and what could increase the bill.
Maintenance includes updates, monitoring and responding to changes in connected services. Agree who checks backups and who can restore the system. Do not assume that paying for hosting includes these responsibilities.
Support needs defined hours, contact routes and response expectations. Clarify the difference between fixing a defect under warranty, investigating an operational incident and charging for a new requirement.
Also budget internal time. Staff may need to clean records, test workflows, attend training and make decisions during delivery. Those obligations should appear in the plan even when they are not on the supplier's invoice.
Compare quotes against the same launch outcome
Use the worksheet above as a common scope, then mark every item in each proposal as included, excluded, provisional or your responsibility. Ask suppliers to explain differences before negotiating the total.
- Usable outcome: can staff finish the agreed task, including corrections and routine exceptions?
- Delivery coverage: are discovery, design, project management, migration, testing, deployment and training included?
- Commercial terms: is the price fixed, time-based or phased? How are changes approved, and when will uncertainty be reviewed?
- Acceptance: what must work before the release is accepted, and how are defects handled?
- Ownership: who controls the source code, data, hosting accounts and third-party subscriptions? What is needed to change supplier?
- After launch: what recurring charges and support obligations apply, and which work is explicitly excluded?
A fixed price does not resolve an unclear scope. A time-based estimate needs reporting, review points and a clear approval process for additional spending. In either case, ask what would change the estimate.
I would first ask each supplier to demonstrate how their proposed scope handles one ordinary job, one correction and one failed hand-off. Then check how existing jobs enter the system and what lets staff stop updating the spreadsheet. Those answers reveal more about the value of the quote than its headline price alone.
Define a first version you can budget for
Show ZappFlow the process you want to replace, the tools it uses and any quotes you are comparing. We can help clarify what the first version needs to include and what can wait.