Approach
Every stage closes on something you can reject.
Aevis runs delivery as a sequence of reviewable stages rather than a percentage. Each one hands over an artefact — a design, a runbook, a measured baseline — that a client can read, disagree with and sign off before the next begins.
- Discover
- Design
- Build
- Operate
What the method rests on
Four decisions taken once, so they are not re-argued weekly.
These constrain how an engagement is scoped and staffed. They are the reason the stages look the way they do.
The process before the platform
We establish who owns a decision and what the workflow actually is before configuring anything. A platform built around an undecided process encodes the indecision and charges twice to undo it.
Reviewable output over reported progress
A stage is complete when it has produced something inspectable. Percentages are a summary of work; artefacts are evidence of it, and only one of the two can be wrong quietly.
Supported patterns over clever ones
Customisation is debt taken on the client’s behalf. Where we depart from the supported pattern we record why, and what it would cost to reverse.
Designed for the handover
Documentation, runbooks and access are built during delivery rather than assembled at the end, because an engagement that cannot be handed over has not finished.
The eight stages
What happens, in order, and what you get at each step.
Not every engagement uses all eight — a managed service starts further along than a greenfield build — but the order does not change, and no stage is skipped silently.
Discovery
Establish the current state: what runs, who owns it, where the work actually slows down, and which constraints are real rather than assumed.
What you get to reviewCurrent-state assessment and a prioritised list of what is worth doing first.
Who is involvedProcess owners, platform administrators, service management.
Design
Agree the target operating model and the technical design against it, including the integration boundaries and what stays authoritative where.
What you get to reviewSolution design with decisions recorded against their rationale.
Who is involvedArchitecture, security, and the accountable business owner.
Plan
Sequence the work into releases the organisation can absorb, with the dependencies, risks and rollback positions stated.
What you get to reviewRelease plan, RAID log and an agreed definition of done.
Who is involvedDelivery management and the client’s change function.
Implementation
Build and configure against the agreed design, protecting upgradeability and recording any departure from the supported pattern.
What you get to reviewWorking configuration in a non-production environment, with the design decisions traced.
Who is involvedPlatform engineers and the client’s technical reviewers.
Integration
Connect the systems the workflow needs, and prove the data contract in both directions rather than only the happy path.
What you get to reviewTested interfaces with failure behaviour documented.
Who is involvedIntegration owners on both sides of each interface.
Validation
Test against the acceptance criteria agreed at design, including the security and performance criteria, not only the functional ones.
What you get to reviewTest evidence and an explicit list of what was not covered.
Who is involvedClient testers, security, and service acceptance.
Transition
Move the service into operation with the runbooks, access, monitoring and support model in place before go-live rather than after it.
What you get to reviewRunbooks, support model and an agreed responsibility boundary in writing.
Who is involvedService desk, operations and the incoming service owner.
Operations and optimisation
Run the service against its commitments, measure how it is actually used, and resolve the friction that suppresses adoption.
What you get to reviewService reporting against a measured baseline, with an improvement backlog.
Who is involvedNamed service owner and the client’s service management.
How the work is governed
The commitments that hold when a delivery goes badly.
A method is tested by what it does under pressure. These are the parts that do not flex.
A written responsibility boundary
Every engagement states what Aevis operates and what remains with the client, before work begins. Ambiguity here is what turns an incident into an argument.
A named owner who can be escalated to
Managed engagements carry a named service owner with the authority to commit. Accountability that routes to a mailbox is not accountability.
Reporting against a baseline we measured
Service reporting is set against a baseline taken during transition, so improvement claims can be checked rather than asserted.
An exit that does not depend on goodwill
Documentation, access and knowledge transfer are contractual deliverables maintained throughout, not a closing task. A client can leave.
Scope, commercial model and service levels are always confirmed against your environment during scoping. Nothing on this page is an offer or a guarantee of outcome.
Try it on something real
Bring the delivery that is not going well.
The method is easiest to judge against a specific problem. Tell us what is stuck, and we will set out how the first two stages would run against your estate.