Practical guide · Genitechs
Prepare a custom application project.
A useful project brief describes the work, users, data and constraints. It helps you compare proposals with the same scope before choosing a technology.
Published October 4, 2026
Describe the work before the features
Describe the current situation and desired outcome. For example, a team receives email requests, copies them into a spreadsheet and follows up manually. An application might centralise intake, assignment and tracking. This is an illustrative example, not a client case study.
Identify users and responsibilities: who creates a request, processes it, approves it and views results? These roles determine user journeys and access permissions.
Choose existing software, configuration or custom development
| Option | Consider it when | Questions to ask |
|---|---|---|
| Existing software | The process fits available features | What is the total cost and what are the limits? |
| Configuration or a low-code platform | Changes fit within the platform’s capabilities | Who maintains it and where does the data live? |
| Custom application | The process or integrations require specific control | Which needs justify development and ongoing maintenance? |
Define a useful first release
Separate features needed to complete the process from improvements that can wait. An initial release should let users complete real work, even if some exceptions remain manual.
State exclusions explicitly. An integration, data migration, report or mobile application is not included simply because it seems related. Its scope needs to be agreed.
Validate integrations and migration
For each connected system, identify its owner, available APIs, permissions, data formats and usage limits. Choose the system of record where information exists in more than one place.
If data needs migrating, plan cleaning, a trial migration, reconciliation checks and recovery. Confirm actual system access before fixing implementation commitments.
Understand what affects cost
User journeys, business rules, integrations, data quality, access requirements and testing all affect effort. The number of screens is rarely a sufficient measure.
Separate initial development from recurring hosting, licensing, maintenance, monitoring and support. Compare deliverables, assumptions and responsibilities as well as price.
Prepare acceptance and ongoing operation
- Agreed test scenarios and acceptance criteria.
- People responsible for acceptance and launch.
- Code rights and handover conditions stated in the contract.
- Documentation and access needed to operate the application.
- Backup, maintenance and support responsibilities.
- A process for reporting defects and requesting changes.
A six-part project brief
- Context: which problem are you trying to solve?
- Users: who does the work and who approves it?
- Process: what are the main steps and exceptions?
- Systems: which tools and data are involved?
- Constraints: budget, timing, access and internal requirements.
- Outcome: how will you know the first release is useful?