Technical Discovery for Software Projects: What to Assess Before Estimating
What technical discovery covers before a software estimate: existing systems, integrations, data, non-functional needs, security, risks and spikes.
What should technical discovery assess before an estimate?
Technical discovery should assess existing systems and code, every integration and its API, the data to migrate or use (volume, quality and ownership), non-functional requirements such as performance, availability, security and accessibility, compliance and data location constraints, and hosting, then test the riskiest assumptions with short technical spikes. The output is an architecture outline, a risk list and estimate ranges with stated assumptions. It makes estimates honest rather than hopeful.
This guide is for buyers commissioning software and for technical leads. For validating the product idea, see software product discovery; for reviewing an existing system, software architecture review.
Key takeaways
- Investigate the riskiest technical unknowns before estimating.
- Check integrations against real API documentation and sandboxes.
- Look at real data, not descriptions of it.
- Write non-functional requirements down.
- Expect estimate ranges with assumptions, not single numbers.
What discovery assesses
| Area | Questions |
|---|---|
| Existing systems | What exists, who owns it, how it is built and hosted, what must be kept? |
| Integrations | Which systems, which APIs, limits, authentication, sandbox availability, data ownership? |
| Data | Volumes, quality, duplicates, migration needs, retention and privacy? |
| Non-functional | Users and load, response times, availability, accessibility (WCAG 2.2 AA), browsers and devices? |
| Security and compliance | Personal or sensitive data, Privacy Act, industry rules, data location? |
| Hosting and operations | Where it will run, who supports it, monitoring and backups? |
| Technical risks | Unknowns that could change the approach or cost significantly? |
Technical spikes
A spike is a short, time-boxed experiment to answer a specific technical question, such as whether an accounting API supports the needed fields, whether a legacy database can be replicated, or whether a mapping library performs on a mid-range phone. Spikes turn the largest risks into evidence before the estimate. See API integration for common integration questions.
Outputs
- Architecture outline and key technology choices with reasons.
- Integration map with API findings.
- Data assessment and migration approach.
- Non-functional requirements.
- Risk register with likelihood, impact and mitigation.
- Estimate ranges with assumptions and exclusions.
- A phased delivery plan, starting with the riskiest parts.
Preparing for discovery
Gather documentation, access to systems or sandboxes, sample data (de-identified where possible), a list of integrations and constraints, and the people who know how current systems behave. Be open about known problems; hiding them only moves the risk into delivery. Decide who will make decisions when trade-offs appear.
Hypothetical example: a field operations platform
This example is hypothetical. A services company asked for an estimate to replace its job management system. Discovery found that its payroll system's API did not expose the award interpretation data needed, that 15 years of job history had inconsistent customer records, and that technicians often worked without mobile coverage. Spikes confirmed an export-based payroll integration and an offline sync approach. The estimate was given as a range with these assumptions, and the plan started with data clean-up and offline sync.
Common mistakes
- Estimating from feature lists alone.
- Assuming an API supports what is needed without checking.
- Ignoring data quality until migration.
- Single-number estimates for uncertain work.
- Discovery with no agreed questions or outputs.
Related guides
- Custom software development in Australia for the wider project.
- Product requirements documents for capturing what to build.
- Data migration for assessing data early.
- Legacy software modernisation for replacing older systems.
Conclusion
Technical discovery is the cheapest point to find the problems that make projects late. Assess systems, integrations, data and non-functional needs, test the riskiest assumptions with spikes, and expect estimate ranges with explicit assumptions. For public sector projects, see UK public sector software procurement and delivery.
Need an estimate you can trust?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on web applications, mobile apps and AI and automation. If it would help to scope the technical side of your project, we are happy to talk it through.
Common questions.
A short, structured investigation of the technical side of a project before committing to an estimate: existing systems and code, integrations, data, non-functional requirements, security and compliance, hosting and technical risks. It complements product discovery, which validates the problem and users.