Process
Discover. Define. Build. Deploy. Evolve.
Five stages, in this order, on every project. The sequence does not change. What happens inside each stage is defined with you — which is why scope, milestones and acceptance criteria exist before any code is written.
The five stages
Each stage has a defined purpose and a defined output. You always know which stage a project is in and what happens next.
01
Stage
Discover
Every project starts with understanding, not design. We learn how the business works today, what breaks, who is affected and what a better outcome would look like. This is where we tell you if the problem is worth solving in software at all — and if it is, what solving it properly will require.
In this stage
- Business and commercial context
- The actual problem behind the brief
- Existing workflows and how work moves today
- Users and roles involved
- Current systems in use and what each one is for
- Pain points, workarounds and the cost of leaving them
- Desired outcomes and how success will be recognised
- Constraints: budget, deadline, legacy systems, regulation
You receive
A shared understanding of the problem, written down and agreed before scope is proposed.
02
Stage
Define
The problem becomes something buildable. We specify what the software will do, what it will not do, how it will be structured, who is responsible for what, and how we will know each part is done. Scope here is treated as a promise — which is why it is written down precisely enough to be held to.
In this stage
- Requirements and user stories
- Scope: what is included and explicitly excluded
- Feature definition and priority
- Deliverables and acceptance criteria
- Technical architecture and integration approach
- Timeline, milestones and dependencies
- Responsibilities on both sides
- Security level assessment (see Level 1–3)
You receive
A defined specification, scope boundary, milestone plan and set of acceptance criteria.
03
Stage
Build
Work proceeds in increments you can see and use, rather than a long silence followed by a reveal. You see progress, give feedback against the agreed scope, and we adjust while changes are still inexpensive to make.
In this stage
- Interface and experience design
- Development against the defined scope
- Integration with existing systems
- Testing: functional, integration, and the security practices appropriate to the level
- Client review and demonstration of working increments
- Iteration against agreed feedback
You receive
A working application that meets the agreed acceptance criteria, demonstrated and reviewed with you.
04
Stage
Deploy
Launching is its own stage, not an afterthought. We deploy to production, verify the real environment rather than assuming staging matched it, document it, and hand it over properly — including the credentials and infrastructure you own.
In this stage
- Production deployment and environment configuration
- Live integration and payment configuration
- Production testing and verification
- Documentation and handover pack
- Ownership transfer of client accounts, credentials and infrastructure
- Cutover plan and rollback position
You receive
A production application, the source repository, credentials, and the documentation to operate it.
05
Stage
Evolve
Software that is never improved becomes a liability. Live systems need upkeep, security updates, performance work and — as the business changes — new capability. We support what we build, and we separate maintenance from new development so nothing is ambiguous.
In this stage
- Maintenance and technical upkeep
- Security updates and dependency maintenance
- Performance and reliability work
- Improvements driven by real usage
- New features and major changes as the business evolves
- Proactive reporting on what needs attention
You receive
Software that keeps working, keeps improving, and stays aligned with the business.
Working rules
What keeps the process real.
A process only matters if it changes something. These are the commitments it enforces.
01
Visible progress
You see working software during the build, not only at the end.
02
Scope is a promise
What is agreed is what gets built. Anything else is a change request.
03
Defined done
Each part of the project has agreed acceptance criteria.
04
You own it
Code, accounts, infrastructure and documentation belong to the client.
Feedback window
5 business days
Client feedback on delivered increments is expected within 5 business days. Feedback shape is developed around that window.
Included work, and what happens outside it
Most project friction comes from vague boundaries. These terms are defined up front so nothing is ambiguous when it matters.
Shown here because the distinction affects cost and timeline. The binding definitions live in your project documents.
- Included work
- Work delivered inside the scope, requirements and acceptance criteria agreed for the project.
- Change request
- New functionality, or a change to agreed requirements, requested after scope is set. Considered for impact on cost, timeline, scope and milestones before it is approved.
- Warranty
- Correction of agreed functionality that does not work as specified. Distinct from new development.
- Maintenance
- Ongoing technical upkeep: hosting, monitoring, security updates, dependency management, backups and fixes to existing behaviour.
- New development
- New functionality or major changes beyond maintenance, scoped and priced separately.
Decided at Define
Security level is chosen before the build starts.
Risk assessment happens during definition, when the cheapest decisions are still available. Changing the security level after the architecture is built costs far more than deciding it up front.
Level 1
Standard
Normal business applications and lower-risk projects.
Level 2
Enhanced
Projects requiring stronger security controls and additional practices.
Level 3
High security
Sensitive, high-risk or regulated projects requiring significantly stronger controls and potentially specialist involvement.
Commercial structure
How projects are paid for.
Structured by size, because a four-week build and a two-year programme should not be financed the same way.
01
Small projects
50% upfront · 50% before go-live
Single-phase delivery. The balance falls due before go-live or handover.
02
Medium projects
30–40% upfront · milestone payments
Paid in defined milestones as agreed work is delivered and accepted.
03
Large projects
Paid discovery phase · project-phase payments
A paid Discovery and Define phase first, so scope is set before build commitments are made.
04
Recurring work
Monthly, in advance
For ongoing maintenance and continuous development.
Discovery
The first stage is a conversation, not a sales call.
Tell us what is going wrong. We will ask about the process, the constraints and the outcome — and tell you whether this is a software problem at all.