From a requirement to a system your team relies on.
Five stages, each with defined input from you and a review point before the work moves on. What is delivered, and what support looks like afterwards, depends on the scope agreed for your project.
01
Discover
The operation walked through and written down as a requirement.
You confirm the requirement
02
Design
Workflows, screens, handheld steps, data, and interfaces.
You approve the design
03
Build and validate
Built in stages, each tested by us then worked through by you.
You accept each stage
04
Deploy
Migration, integration, training, and a planned cut-over.
You sign off the cut-over
05
Support
Support for the live system and changes as it grows.
Arrangements agreed in writing
01
The five stagesDiscover, design, build and validate, deploy, support.
For each stage: what we do, what we need from you, and the point at which you review or approve before it continues.
Discover
We work through the operation with the people who run it — how goods and orders move, where the process breaks, what is worked around, and which systems hold what. The output is a written requirement in your language, not ours.
- Your input
- Time with the people who do the work, access to see the floor or the process, and sight of the systems and data involved.
- Review point
- You read the requirement back and confirm it describes your operation before any design work starts.
Design
We translate the requirement into a system design: the workflows, the screens and handheld steps, the data it holds, and the interfaces to your other systems. Interface and workflow designs are walked through with the people who will use them.
- Your input
- Review of the workflows and screens, and decisions on the points where two ways of working are both defensible.
- Review point
- You approve the design, including the interface and workflow reviews, before build begins.
Build and validate
Development and configuration proceed against the approved design, in stages rather than one delivery at the end. Each stage is tested by us, then put in front of you to work through with realistic data.
- Your input
- People available to try each stage and say plainly whether it matches how the job is done.
- Review point
- Each stage is reviewed with you, and the last review confirms the system is ready for deployment testing.
Deploy
Configuration is finalised, integrations are connected, data is migrated and checked, users are trained, and the cut-over is planned in detail — what happens on the day, in what order, and what the fallback is.
- Your input
- Agreement on the cut-over plan, staff released for training, and someone on your side who can make decisions on the day.
- Review point
- You sign off the cut-over plan, and confirm acceptance after the agreed post-go-live checks.
Support
Once live, we handle support for the system and the changes the operation asks for as it grows. Issues are logged, prioritised with you, and dealt with in the order agreed.
- Your input
- A named contact on your side, and a route for your users to report issues.
- Review point
- Support arrangements, including how issues are prioritised, are set out in the agreement rather than assumed from this page.
02
The pieces of workFrom requirements to a working system.
The work a project is actually made of, in roughly the order it happens.
Requirements
Written from sessions with the people who do the work: the steps, the exceptions, the volumes, and what must not change. It is the document everything later is checked against.
Interface and workflow reviews
Screens, handheld steps, and process flows walked through with their users before they are built, so disagreements surface on paper rather than after go-live.
Development and configuration
Much of the fit comes from configuration — locations, rules, roles, and workflows. Development covers what configuration cannot express.
Integrations
Interfaces for orders, stock records, accounting information, and shipment updates, built against what your existing systems actually expose.
Testing
We test each stage; you test it on your own data and scenarios. Both happen before deployment, and issues found are fixed and retested.
Deployment
Environment set up, data migrated and validated, integrations connected, and a cut-over run to the plan you approved.
Training
Sessions for the roles that will use the system, on the workflows they will actually run, with material they can keep.
Which of these apply, what each produces, and how support is arranged afterwards depend on the scope agreed for your project. Nothing on this page sets a timeline, a price, ownership terms, a service level, or a standard set of documents — those are agreed in writing for each engagement.
03
IntegrationsIntegration, in practical terms.
Integration is mostly a set of decisions about which system owns a record and how the others receive it. Four kinds of information cover most of what needs to move.
Orders
Stock records
Accounting information
Shipment updates
04
QuestionsPractical questions we are asked first.
Can we start with one workflow instead of the whole operation?
Yes, and it is often the sensible order. Replacing one process — receiving, or picking, or stock counting — gives the team something to judge before more of the operation depends on it.
What matters is that the first workflow is one whose data the later ones can build on. We work that sequence out during discovery.
Do we have to replace the systems we already use?
Not by default. Where an existing system works and can exchange information, the usual approach is to leave it in place and define which system owns which record.
Whether that is practical depends on the interfaces and access your system provides, and on how consistent the data in it is. That is checked during discovery rather than assumed.
How should we prepare for a first discussion?
Bring how the process runs today, including the workarounds, an idea of volumes at normal and peak times, a list of the systems involved and who owns them, and what is causing the most trouble right now.
You do not need a specification. Describing the operation is enough to establish whether we can help and what it would depend on.
How are requirements agreed?
We write the requirement from the discovery sessions and give it back to you to read. It is revised until it describes your operation accurately, and it is the reference the design and later testing are checked against.
Changes after that point are normal; they are handled as changes to agreed scope rather than quietly absorbed.
What do we get to review and test before launch?
Interface and workflow designs before build, each build stage as it is completed, and the configured system on your own data before deployment. Your team runs its own scenarios, not a scripted demonstration.
What does implementation involve on our side?
Decisions on configuration, help getting data into a usable state, staff released for training, and someone able to make decisions during the cut-over.
The cut-over plan sets out what runs where on the day and what the fallback is. Replacing an operational system carries risk, and the plan exists to contain it.
What happens after go-live, and when we need changes later?
Support covers the live system: issues logged, prioritised with you, and handled in the agreed order. Changes as the operation evolves are scoped like any other work.
Response arrangements and what support includes are set out in your agreement. We do not publish a standard service level on this page.
05
Start hereStart a project.
Covers your process and the systems around it. No specification required.