Engagement lifecycle
A delivery process built around visible decisions.
Organizations do not only buy code. They need clarity, responsibility, security, acceptance evidence and continuity. Kerah uses a defined engagement lifecycle while tailoring the system inside it.
The process is the same for a discovery phase and for a multi-phase build. What changes is how much of it a given engagement needs, and that is agreed at the start rather than discovered later.
The shape of an engagement
- 01
Qualify
Establish the problem, the sponsor and whether Kerah is the right fit.
- 02
Discover
Map users, processes, systems, data, risks and a practical first phase.
- 03
Approve the Blueprint
Agree scope, exclusions, milestones, acceptance criteria and change control.
- 04
Mobilize
Set up the delivery environment, owners, governance and documentation.
- 05
Build in Demonstrable Increments
Working software shown frequently, with decisions and test evidence recorded.
- 06
Accept and Launch
Acceptance, training, migration reconciliation, rollback and formal handover.
- 07
Operate and Evolve
Into the agreed support model, release rhythm, live backlog and roadmap.
Seven stages
Every engagement moves through these in order. Nothing is skipped silently — if a stage is not needed, that is a decision recorded at mobilization.
Qualify
Before anything is proposed, we establish the operational problem, who sponsors it, how urgent it is, the constraints, the procurement route and how sensitive the data is. If Kerah is not the right fit, this is where we say so.
At the end of this stage: A shared understanding of the problem, and an honest answer on fit.
Discover
A paid phase with a defined duration. We map users and processes, inventory systems and data, name the risks and assumptions, agree the success measures and set out a target architecture with a phased roadmap.
At the end of this stage: A blueprint you can approve, phase, price or decline on evidence.
Approve the Blueprint
Scope, assumptions, exclusions, milestones, responsibilities, acceptance criteria and change control are agreed in writing. Exclusions matter as much as scope — most project disputes concern something that was never discussed.
At the end of this stage: An approved scope with acceptance criteria both sides have read.
Mobilize
We establish the delivery environment, assign owners on both sides, set the working cadence and governance, and complete the commercial and data protection documentation the engagement requires.
At the end of this stage: A delivery setup with named owners and a scheduled review rhythm.
Build in Demonstrable Increments
Working software is demonstrated frequently, decisions are recorded as they are made, and test evidence accumulates as the system develops. A long invisible build is how projects fail without anyone noticing until it is expensive.
At the end of this stage: Working software you have seen, plus a written decision record.
Accept and Launch
Acceptance testing against the agreed criteria, training where required, data migration with reconciliation you can verify, operational readiness checks, a rehearsed rollback, documentation and formal handover.
At the end of this stage: A launched system, formally accepted, with a handover pack.
Operate and Evolve
The system moves into the support arrangement agreed for it, with a release rhythm, an owned backlog and a roadmap reviewed on a set cadence.
At the end of this stage: A maintained system with a route for its next stage.
What runs alongside delivery
Governance and decision-making
Delivery is reviewed on a fixed cadence rather than when something goes wrong. Each review covers scope, milestones, risks, quality, staffing and — most importantly — the decisions Kerah needs from you.
- A scheduled delivery review with a written record
- A named decision-maker on each side
- An escalation path agreed at mobilization, before it is needed
- Risks recorded on a register that is actually read
Change control
Scope changes are normal. Undocumented scope changes are not. Every change request is assessed for its effect on price, schedule, acceptance and risk, and approved before the work begins.
- Impact stated in terms of cost, schedule, acceptance and risk
- Approval recorded before implementation starts
- No change discovered for the first time on an invoice
What Kerah needs from you
The engagements that go well share a pattern: the client side is genuinely available. Delivery risk concentrates in decisions that wait.
- A sponsor with the authority to decide, available at the agreed cadence
- Access to the people who do the work being systematised
- Timely access to systems, data and third-party suppliers
- Named reviewers for acceptance, security and legal sign-off
- Decisions within the agreed window, or an explicit deferral
Ownership and licensing
Ownership and licensing are defined clearly in each statement of work. Business-specific deliverables are transferred or licensed as agreed, while Kerah retains its pre-existing tools, frameworks and know-how. Anyone contributing to an engagement assigns the relevant rights to Kerah beforehand, so what is transferred to you is clean.
Security and quality throughout
Security and data questions are raised in discovery and revisited at each stage, rather than being handled as a pre-launch checklist. Test evidence is produced as the system develops so acceptance is a review of evidence rather than a fresh exercise.
- Data classification agreed before architecture is fixed
- Access and permission model designed alongside the workflow
- Test evidence accumulated during delivery, not assembled at the end
- Security review at each significant architectural decision
Handover and continuity
A system you cannot operate without Kerah is a system Kerah has failed to deliver properly. Handover is treated as a deliverable with acceptance criteria of its own.
- Architecture and data-model documentation
- Runbooks for the operations the system requires
- Administrator and user documentation
- Knowledge transfer sessions with your team
- A documented exit, including data export
Why Kerah does not publish enterprise prices
A price set before the problem is understood is either padded to cover the unknown or wrong in a way that someone pays for later. Kerah prices a discovery phase up front, because its scope is genuinely knowable, and prices implementation against a blueprint you have read and approved.
That also makes the decision after discovery a real one. The blueprint is a deliverable you keep, whether the build continues with Kerah or not.
Start with the problem, not the specification.
A short description of what is not working is enough for a useful first conversation.