Describe the workflow before looking at features
Write down the people involved, the information they need and the decisions they make. Include exceptions such as returns, rejected approvals and missing data. A product feature list is useful only when it maps to that work.
When an existing platform is a good starting point
A platform can be suitable when its standard workflow fits the important parts of your process. Check configuration options, exports, access controls and integration support. Include licence costs and the effort of changing how your team works. Avoid buying many unused features to solve a small problem.
When a custom build deserves consideration
Custom software may suit a distinctive workflow, an unusual customer journey or several systems that need to behave as one. It also brings responsibility for testing, hosting, updates and support. A prototype and a scoped first release help you evaluate those trade-offs before a large commitment.
Compare the full cost and exit options
Ask each provider for a comparable scope and a clear list of assumptions. The lower initial price may not be the lower operating cost. Check who owns the code, how data can be exported, what happens when an integration changes and how support is billed.
- Initial setup or development
- Licences, hosting and transaction or API charges
- Migration and staff training
- Integrations and their ongoing upkeep
- Maintenance, support and future changes
- Data export, access handover and exit arrangements
Use discovery to reduce uncertainty
For a larger project, a bounded discovery phase should produce a workflow map, priorities, a prototype where useful, and a costed scope. You should be able to review those outputs before deciding whether to proceed with development.
Prepared by Articcus as general project-planning guidance. Your proposal should reflect your own requirements and dependencies.