Scope is written before signature
The most common failure in consulting is not bad engineering. It is an engagement whose boundary was never agreed, which means nobody can say when it is finished, and the honest answer to “are we done” becomes a negotiation instead of an observation.
So each engagement here is written down first: what is included, what is deliberately outside it, what you receive at the end, what access we need, how much of your team’s time it takes, and the one dependency capable of moving the date. That last one is almost always access provisioning rather than engineering, and naming it in advance is what keeps a two-week engagement two weeks long.
We also price the scope rather than the hours. A rate card sells presence, which is why an open-ended retainer is such a comfortable product to sell and such a poor one to buy at the start of a relationship: it hides whether the work is finished.
Why three shapes and not a menu
Two weeks is how long it takes to read an estate honestly and form an opinion you can defend. Four weeks is how long a governed Azure foundation takes to build as code when the decisions are made in week one. Eight weeks is how long one AI use case takes to go from workshop to something running in your tenant with an owner, an evaluation set and a cost ceiling.
Those three durations are not marketing shapes. They are what the work takes when scope is held still, and they exist in this order because each one produces the input the next one needs.
The three engagements
Two-week assessment. Read-only by design: Reader access, no changes to production, no policy assigned. Two weeks of reading, interviewing and measuring, ending in a written opinion and a backlog ranked by severity against effort, with an estimate in days against each item. About eight hours of your team’s time. You keep the report, the backlog and the diagrams whether or not you engage us for any of the remediation, and there is no clause requiring us to be the ones who fix what we found.
Four-week landing zone build. One outcome: a governed Azure foundation your engineers deploy into. Management groups, policy set, identity model, network topology and pipelines, delivered as Terraform in your own repository. Week one is decisions, recorded with a reason against each. Week four is handover, which means a working session with the people who will operate it, not a document drop.
Eight-week AI agent build. One narrowed use case, taken to production on Azure AI Foundry or Copilot Studio depending on where the data sits. The evaluation set is built before the agent, from thirty to fifty real cases out of your own history, because it is the artefact that outlives whichever model you started on. Ends with a deployed agent, a named owner, a token cost model, monitoring and a written statement of what the agent may and may not do.
What is outside the boundary, on purpose
Ongoing operation is not bundled into a build. Patching, monitoring, budgets and the monthly cost conversation are a separate decision you make after you have seen how we work, and they are described under managed Azure. Licensing is separate again: we are a direct CSP, so we can bill and support your subscriptions, but that is priced apart from consulting on the licensing page and is never a condition of an engagement.
Remediation is not bundled into an assessment either. That one is deliberate: an assessment that quietly starts fixing things loses the ability to describe what it found, and an assessment sold as the first half of a build stops being an opinion and becomes a sales document.
What you keep
Everything, from the first commit, in your Git organization. Infrastructure as code, pipelines, decision records, diagrams, the evaluation set where there is one, the cost model. Stop an engagement in week two and you still hold what was produced up to that point. This is the part of the arrangement we are least willing to negotiate, because an estate you cannot change without the firm that built it is not an asset, it is a subscription.
Where the driver is residency, jurisdiction, key custody or a documented exit path rather than capability, the same two weeks run as a sovereignty assessment under Novarque by Entrazure, and the framework detail sits on the compliance pages. The build engagements stay Entrazure work: landing zone, pipelines, data platform, agents.
Which one fits
If nobody can currently describe the estate, or an audit, a migration or an AI project is coming and you want to know what breaks first, start with the assessment. If the backlog already exists and the foundation is the gap, go straight to the landing zone build. If there is one AI use case with a real owner and a measurable manual baseline, the agent build is the shape.
If the pressure is a named problem rather than a phase of work, the solutions pages are filed that way, and the underlying capabilities are on the services pages. If none of the three shapes fits, tell us the constraint and we will say which of them to bend, or that the work is not ours to take.
Questions we get
What if the work does not fit two, four or eight weeks?
Then we say so before you sign, which is cheaper for both of us than discovering it in month three. Some estates are too large to read in two weeks, in which case we scope the assessment to two or three domains rather than stretching it. Some builds are genuinely a program of several engagements, and we sequence them with a deliverable at the end of each rather than selling one long one.
Is it fixed scope or fixed price?
Fixed scope and fixed duration, with the price set against that scope. A change of scope is a written change, priced, with its effect on the date stated at the same time. What we avoid is the arrangement where the scope drifts quietly and the invoice follows it, because that is how a four-week build becomes a nine-month relationship nobody decided to enter.
Can our own engineers do part of the build?
Yes, and it is usually the better outcome. Pairing on the Terraform during the build costs a little velocity and buys the thing that actually matters after handover, which is a team that can change the estate without calling us. Where that is the goal from the start, we scope the enablement into the engagement rather than treating it as a training session at the end.