Software
Custom Software Project Discovery Checklist
A useful software brief defines the work people need to complete, the records involved and the conditions for accepting the result. Start with a concrete user journey before estimating delivery.
Describe one user journey in full
Identify the user, the event that starts the journey and the needed result. For an illustrative partner portal, the journey might include signing in, submitting a document, checking its status and receiving a correction request. Map staff tasks as well as customer-facing screens.
Record workarounds, duplicate data entry and missing information. These reveal whether a new application, configuration of an existing product or a small integration would address the problem. Explain the decisions each screen supports.
Define records, permissions and integrations
List record types and the authoritative system for each. Decide who can view, create, change and approve information. Include corrections and removal of access.
For every integration, identify the interface owner, permitted data, update frequency and failure handling. Connecting a CRM requires clarity about its API, account permissions, record identifiers and duplicate handling.
- Users, roles and approval responsibilities
- Source records and authoritative systems
- Required interfaces and access owners
- Migration and reconciliation needs
- Behavior during outages or incomplete inputs
Turn requirements into acceptance checks
Write checks a reviewer can perform with representative data. For the portal example, verify permitted document uploads, staff-only review, current status visibility and useful explanations for invalid submissions.
Include duplicates, missing fields, expired access and unavailable external systems. Decide which issues block release and who confirms completion. A feature that looks finished must still support the actual workflow.
Compare options and agree ownership
Compare a configured product, custom application and integration against the same journey. Include licensing, setup, migration, training, changes and maintenance. The initial price alone does not establish total ownership cost.
Keep optional features separate from the first release. Document compromises such as manual approval of unusual requests. Agree who manages hosting, access, monitoring, updates and support, and what documentation will be delivered.
A consultation can turn the brief into a scoped proposal. Dates should reflect requirements, available interfaces, review responsibilities and agreed release checks.