What a custom software project should include
The components of a custom software project: discovery, scope, design, development, testing, launch and evolution.
Direct answer
A custom software project should include process discovery, scope and acceptance criteria, experience and architecture design, reviewed development, testing, data and integration preparation, launch, documentation and explicit support terms. The depth of each stage varies with risk, and no general checklist replaces the project proposal and contract.
Key takeaways
- Scope should describe observable behavior, not a list of screens.
- Include data, permissions, integrations, errors and non-functional requirements.
- Every delivery needs acceptance criteria shared by business and technology.
Discovery and scope create the frame
Discovery identifies users, decisions, data, exceptions and existing systems. Its output should not be a pile of notes but a shared explanation of the problem being solved.
Scope turns that understanding into priorities. It states what will be built, what remains outside, which dependencies exist and how a function will be accepted.
Design and architecture reduce ambiguity
Experience design organizes workflows and information before investing in every technical detail. Prototypes let users review decisions and expose gaps earlier.
Architecture defines boundaries, data, integrations and quality attributes. The goal is not speculative complexity but support for the usage and evolution the project actually expects.
Development and testing produce evidence
Intermediate releases allow the system to be reviewed in realistic context. Each review should connect to agreed criteria and record changes.
Testing covers rules, permissions, errors and critical workflows. Responsibility is shared: the technical team verifies the product while business participants validate that it represents the operation.
Delivery should prepare the operation
Publishing the system does not finish the work by itself. Data migration, account setup, owner training and a gradual transition may still be required.
Documentation, intellectual property, licensing, warranty, support and evolution should be written down. This separates a technical handoff from a sustainable operation.
Bynotek analysis
The seven layers of a complete scope
A defensible scope covers actors, primary flow, exceptions, data model, permissions, integrations and operations. For each layer, state what ships now, what is deferred and which assumption supports the decision.
Add measurable non-functional requirements: expected availability, response time, volume, retention, recovery, accessibility and security. “Make it fast” is not verifiable; “search responds in under two seconds at the agreed volume” can be tested.
Keep a decision record. NIST SSDF recommends maintaining security requirements, risks and design decisions; the same habit reduces scope disputes because it explains why each constraint exists and when it should be reviewed.
Applied example
Acceptance-criterion example
Instead of “user module,” specify: a branch administrator can invite staff, assign only roles authorized for that branch, revoke access and review an audit log; a revoked user cannot start a new session. That wording can be designed, tested and accepted.
Checklist
- 01Actors and permissions
- 02Happy paths and exceptions
- 03Data, migration and retention
- 04Integrations and failures
- 05Performance, security and support
Sources and references
- [1]
NIST
Secure Software Development Framework (SSDF) 1.1 ↗A framework for incorporating requirements, design decisions, protection and vulnerability response throughout development.
- [2]
OWASP
API Security Top 10 ↗A reference for reviewing authorization, authentication, resource consumption, configuration and API inventory.
Related guides
Next step
See the Engineering approach →