00Methodology
How we work
Every project moves through six phases, with a written scope and deliverables you review before moving on to the next.
Not every project goes through the six phases the same way: it depends on the engagement model and on what already exists.
- Phases
- 06
- Engagement models
- 03
- Base deliverables
- 04
- Timelines
- Indicative. Each project’s timelines are set in writing in its proposal.
Six phases, one system that grows
Six phases. Durations are indicative and depend on the scope.
Phase 06 of 06Operation and evolution
Each phase builds on what the previous one left: what is decided in the diagnosis is still visible at handover. The blue points mark what this phase adds.
An illustration of the method, not data.
- Objective
- Understand your goal, what already exists and its risks before proposing a solution.
- Deliverables
- Diagnosis document
- An inventory of what exists and whose name it is in
- Your involvement
- One or two meetings with the people who know the problem, and read access to what already exists.
- Decisions and output
- Whether to go on, and with which approach. If you go ahead with the project, the diagnosis fee is credited against the proposal.
- Indicative duration
- Set in each project’s proposal.
- When it varies
- With a block of hours, it can shrink to a one-off review.
- Objective
- Set out in writing the scope, what is left out, the milestones, the cost and the engagement model.
- Deliverables
- Signed proposal
- A list of what is out of scope
- Your involvement
- Review the proposal and agree on any changes before you sign it.
- Decisions and output
- Scope, model, schedule and price.
- Indicative duration
- Set in each project’s proposal.
- When it varies
- This is where each project’s timelines are set, in writing.
- Objective
- Decide the architecture, the flows and the interface before building.
- Deliverables
- Prototype and architecture decisions
- A log of technical decisions and their reasons
- Your involvement
- Validate flows and priorities with the people who will use the system.
- Decisions and output
- Architecture and build order.
- Indicative duration
- Set in each project’s proposal.
- When it varies
- Only when the project needs it. In infrastructure work, design is mostly architecture.
- Objective
- Build in short cycles, with a version you can review at the end of each one.
- Deliverables
- A preview every cycle
- Change log for each cycle
- Your involvement
- Review each version and decide the adjustments for the next cycle.
- Decisions and output
- Priorities between cycles. If an adjustment changes the scope, it is reviewed in writing.
- Indicative duration
- Set in each project’s proposal.
- When it varies
- Cycle length is agreed in the proposal.
- Objective
- Go live and transfer what was built to your company, with its documentation.
- Deliverables
- Handover record
- Repository, documentation, access and infrastructure in your company’s name, per the contract
- Your involvement
- Name the people who receive the access and review the record.
- Decisions and output
- Acceptance of the handover.
- Indicative duration
- Set in each project’s proposal.
- When it varies
- What is transferred, and how, is set by each project’s contract.
- Objective
- Maintain and improve what is in production, if you sign up for it.
- Deliverables
- Periodic reports
- Changes delivered under the agreed SLA
- Your involvement
- Prioritise improvements and review the reports.
- Decisions and output
- What gets improved, and in what order.
- Indicative duration
- Set in each project’s proposal.
- When it varies
- Only applies if you take a retainer or a block of hours.
Durations are indicative; each project’s timelines are set in its proposal.
Who does what
Your part is small, but it is named in every phase.
| Phase | Korhy | You | We decide together |
|---|---|---|---|
| 01Diagnosis | Korhy: Understand your goal, what already exists and its risks before proposing a solution. | You: One or two meetings with the people who know the problem, and read access to what already exists. | We decide together: Whether to go on, and with which approach. If you go ahead with the project, the diagnosis fee is credited against the proposal. |
| 02Proposal | Korhy: Set out in writing the scope, what is left out, the milestones, the cost and the engagement model. | You: Review the proposal and agree on any changes before you sign it. | We decide together: Scope, model, schedule and price. |
| 03Design | Korhy: Decide the architecture, the flows and the interface before building. | You: Validate flows and priorities with the people who will use the system. | We decide together: Architecture and build order. |
| 04Iterative build | Korhy: Build in short cycles, with a version you can review at the end of each one. | You: Review each version and decide the adjustments for the next cycle. | We decide together: Priorities between cycles. If an adjustment changes the scope, it is reviewed in writing. |
| 05Handover | Korhy: Go live and transfer what was built to your company, with its documentation. | You: Name the people who receive the access and review the record. | We decide together: Acceptance of the handover. |
| 06Operation and evolution | Korhy: Maintain and improve what is in production, if you sign up for it. | You: Prioritise improvements and review the reports. | We decide together: What gets improved, and in what order. |
Working rules
- You see progress that worksEach cycle ends with a version you can review, not with a report.
- Scope changes in writingIf an adjustment changes what was agreed, it is reviewed and signed before we do it.
- Decisions are written downEvery technical decision is documented with its reason, so your team understands it later.
- Documentation from day oneIt isn’t written at the end: it grows with the system and is handed over with it.
Three ways to work together
We don’t publish prices: they depend on the scope. Response times, where they apply, are set in the contract.
| Criterion | AFixed-scope projectEnquire with this model: Fixed-scope project | BMaintenance and operations retainerSelectedRemove: Maintenance and operations retainer | CBlock of hoursEnquire with this model: Block of hours |
|---|---|---|---|
| When it is useful | When the goal and its limits are clear. | When something that already works needs ongoing care. | When the work is occasional or variable. |
| How it works | Scope, exclusions, milestones and price agreed in writing before work starts. | A monthly fee to maintain and improve platforms in production, with an SLA agreed in writing. | Prepaid hours you use task by task, with a log of what was used. |
| What you receive | The deliverables in the proposal and the handover record at the close. | Corrective and evolutionary maintenance, a periodic report and up-to-date documentation. | The hours log and the documentation for each task. |
| Contract terms | Price and schedule are set in the proposal. Scope changes are quoted separately. | The monthly scope and the SLA are agreed in writing in the contract. | How long the hours stay valid, and on what terms, is set in writing. |
- A
Fixed-scope project
- When it is useful
- When the goal and its limits are clear.
- How it works
- Scope, exclusions, milestones and price agreed in writing before work starts.
- What you receive
- The deliverables in the proposal and the handover record at the close.
- Contract terms
- Price and schedule are set in the proposal. Scope changes are quoted separately.
- B
Maintenance and operations retainer
- When it is useful
- When something that already works needs ongoing care.
- How it works
- A monthly fee to maintain and improve platforms in production, with an SLA agreed in writing.
- What you receive
- Corrective and evolutionary maintenance, a periodic report and up-to-date documentation.
- Contract terms
- The monthly scope and the SLA are agreed in writing in the contract.
- C
Block of hours
- When it is useful
- When the work is occasional or variable.
- How it works
- Prepaid hours you use task by task, with a log of what was used.
- What you receive
- The hours log and the documentation for each task.
- Contract terms
- How long the hours stay valid, and on what terms, is set in writing.
What you receive, and where the line is
When a project closes you receive four things: the repository, the documentation, the access and the infrastructure. The register shows, row by row, what passes to you, what depends on the contract and what is not transferred.
Ownership and transfer terms are set in each project’s contract. Tools we had before the project, third-party software and licensed assets are not transferred automatically.
Handover register
Illustrative template · no date, signature or client
| Code | Deliverable | Passes to you | Per contract and model | Not transferred |
|---|---|---|---|---|
| EN-01 | RepositoryThe source code and its history, in a repository your company owns. | Passes to you | No | No |
| EN-02 | DocumentationHow the system is built, why it was built that way and how to get it running. | Passes to you | No | No |
| EN-03 | AccessAdmin credentials and permissions, handed to the people you name. | Passes to you | No | No |
| EN-04 | Infrastructure in your nameCloud provider accounts in your company’s name. The exact arrangement is set by the contract. | No | Per contract and model | No |
| NT-01 | Our own tools from before the projectInternal accelerators we already had. You use them under a licence; they are not assigned. | No | No | Licensed for use per contract |
| NT-02 | Licensed third-party technologyServices and software from other vendors that the solution uses. | No | No | Subject to the vendor’s licence |
- EN-01RepositoryThe source code and its history, in a repository your company owns.Passes to you
- EN-02DocumentationHow the system is built, why it was built that way and how to get it running.Passes to you
- EN-03AccessAdmin credentials and permissions, handed to the people you name.Passes to you
- EN-04Infrastructure in your nameCloud provider accounts in your company’s name. The exact arrangement is set by the contract.Per contract and model
- NT-01Our own tools from before the projectInternal accelerators we already had. You use them under a licence; they are not assigned.Licensed for use per contract
- NT-02Licensed third-party technologyServices and software from other vendors that the solution uses.Subject to the vendor’s licence
In addition, depending on the model
- Fixed-scope project
- The deliverables in the proposal and the handover record at the close.
- Maintenance and operations retainer
- Corrective and evolutionary maintenance, a periodic report and up-to-date documentation.
- Block of hours
- The hours log and the documentation for each task.
Quality and verification
We don’t claim certifications. Here we separate what we already do and you can check on this site from what we propose as a commitment and define in each proposal.
- Evidence · applied on this site
- Proposed commitment · pending A-10
- Illustrative example
- 01
Code review
- Proposed commitment · pending A-10
Someone else reviews every change before it is merged into the main branch.
- Proposed commitment · pending A-10
- 02
Appropriate automated testing
- Proposed commitment · pending A-10
More tests where the risk is higher. Their scope is agreed in the proposal.
- Evidence · applied on this site
On this site: type checking (tsc --noEmit) on every change.
- Proposed commitment · pending A-10
- 03
Accessibility checks
- Evidence · applied on this site
On this site: an axe review, a keyboard walkthrough and a reduced-motion check in every iteration. Target: WCAG 2.2 AA.
- Proposed commitment · pending A-10
On each project, the accessibility level is set in the proposal.
- Evidence · applied on this site
- 04
Architecture review
- Proposed commitment · pending A-10
Architecture decisions are reviewed in the Design phase and written down with their reasons.
- Proposed commitment · pending A-10
- 05
Documentation
- Proposed commitment · pending A-10
Written during the project, not at the end, and kept in your repository alongside the code.
- Proposed commitment · pending A-10
- 06
Security considerations
- Proposed commitment · pending A-10
We review access and dependencies, and leave an inventory of who has access to what and how to revoke it.
- Proposed commitment · pending A-10
- 07
Deployment verification
- Evidence · applied on this site
On this site: a production build and a check of every route before each release.
After deploying: the version responds, the logs show no new errors and there is a tested procedure for rolling back.
- Evidence · applied on this site
None of this amounts to meeting a standard on a specific project. What is verified, with which tools and against which acceptance criteria is set in each project’s proposal.
06Next step
Everything starts with a diagnosis.
Book a callIn development
Online scheduling is not available yet.
Your enquiry
This goes with you to the contact form. The link only carries the model you chose.
- Source
- How we work
- Model
- Maintenance and operations retainerRemove or change the model
- Destination
- /en/contact?model=retainer