Scope
Scope the business problem first. The feature list comes second.
A feature list describes the software someone imagines. Scoping describes the business: how work moves, where it stalls and what that costs. What we build comes from that.
What scoping looks at
- How the process runs day to day, including the exceptions and workarounds
- The systems people open, and the spreadsheets and email that sit between them
- Where data is re-keyed, checked or chased
- Where delays, errors and rework happen, and what they cost
- Which parts need custom software and which should stay in the products you already use
- Where AI would remove effort, and where a person needs to stay in the decision
What you have at the end
A written account of how the process runs today and what the new system needs to do, in language your operations team will recognise.
A design for the system: what is custom, what is integrated, what is automated, and who is responsible for each decision. Alongside it, a build plan with the scope, sequence and commercial terms for the work.
Is custom software worth it here?
Custom software makes sense when the current way of working has a real operating cost: staff hours, errors, delays or lost revenue. Scoping puts a figure against that cost before you commit to a build.
If the numbers do not support a custom build, we will say so. Sometimes the better answer is a configuration change, a single integration or a different off-the-shelf product.
From scoping to a running system
- Discover: we sit with the process and the people who run it.
- Design: we agree the smallest system that holds the process and show you the operating model before we build.
- Build: we build the application, integrations and automation against the agreed scope.
- Deploy: we put it into production with hosting, access, monitoring and a cutover plan.
- Train: we train the people who will use it every day, including those who handle the exceptions.
- Operate: we host, monitor, maintain and support the system.
- Improve: we refine the system as real use shows what to change.
What to bring to the first conversation
- The process causing the most trouble, described in your own words
- The systems and spreadsheets involved
- Roughly how many people touch the process, and how often
- Where it breaks: delays, errors, rework or complaints
- A requirements document is optional. A clear account of what goes wrong today is more useful.
Start a conversation
Start with the process, not the software brief.
Book a call with an engineer. Describe the process and the systems around it, and we will outline what scoping would cover.
Talk to an Engineer