Methodology

Diagnose. Design. Deploy.

One system, three deliberate steps, applied the same way to every engagement rather than improvised per client.

Most consulting engagements begin with a proposed solution. This one begins with a diagnosis, because building the wrong thing first costs more than the delay of finding out what the right thing was.

01

Diagnose

Name the actual structural constraint before proposing anything.

The problem a founder brings is rarely the problem driving it. The diagnostic phase separates the visible symptom from the constraint underneath it, using the business's own data and structured conversations with the people closest to the work. It ends with a written finding, not a proposal.

  • Runs personally with the founder, not handed to a junior consultant.
  • Uses existing records rather than waiting for a clean dataset.
  • Ends in a named constraint and a priority order, in writing.
02

Design

Build the commercial architecture that fits this business at its next size.

Design starts from what the diagnosis found, which is why the output is not a template. The structure is built for the size the business is growing into, not the size it is at today, and it is deliberately scoped to what the team can actually run.

  • Built around the diagnosed constraint, not a standard framework.
  • Scoped to the team that has to operate it after handover.
  • Sized for the next stage of the business, not the current one.
03

Deploy

Install it so the team runs it without continued involvement.

A recommendation changes nothing on its own. Deployment means the structure is put into how the team actually works, ownership is named, the routine is run with them until it holds, and the engagement ends with the business able to continue without Durvaa in the room.

  • Ownership is assigned to named people inside the business.
  • The routine is run with the team, not handed over as a document.
  • Success is the system still running after the engagement closes.

Principles

The principles behind it

Diagnosis before prescription

No fix is proposed before the constraint is named and agreed in writing.

The diagnoser delivers

The person who runs the diagnostic is the person who runs the engagement.

Deployment is not a separate sale

Installing the system is part of the engagement, not an extra scope afterwards.

Deliberately limited capacity

Three to four engagements run at a time so attention is not split across a roster.

Independence is the outcome

Every system is designed to run without Durvaa, and without the founder in every decision.

Only verifiable proof

Nothing is claimed that cannot be substantiated by the engagement it came from.

The method is the same every time. What changes is what the diagnosis finds.

Start

See the method applied to a specific question.

Each diagnostic and system page describes what Diagnose, Design and Deploy look like for one particular constraint.