org.tech / Services / Forward-deployed engineering In the building. Scoped per deliverable

The higher-value work begins after the foundation is trusted, and it starts by watching how the work is actually done rather than how the process document says it is.

Your way of doing things, turned into governed capabilities.

A platform on its own changes very little. What changes an organization is somebody senior sitting inside the work long enough to see where it breaks, then building that fix as governed software your people own. This is that engagement. It is deliberately not a body-shop arrangement and not a pilot programme.

Book the strategic assessment → 01 How a deliverable is scoped

Sitting in the work, not beside it.

WHAT FORWARD-DEPLOYED MEANS

Observation before opinion

The process document is never the process.

Every organization has a written version of how work moves and a real version, and the gap between them is where the value is. This is the practice of spending enough time inside the real version to build against it: the exceptions people handle without mentioning, the approval that always takes three days, the spreadsheet that is secretly the system of record.

01
Procedures. What is supposed to happen, including the steps that exist only in somebody's head.
02
Exceptions. The cases the procedure does not cover, how often, and who absorbs them.
03
Handoffs and approvals. Where work waits, who it waits on, and what is missing at the moment it stalls.
04
Data sources. What is authoritative, what is stale, what contradicts what, and who owns each answer.
05
Bottlenecks. The constraint that limits throughput, as opposed to the one everybody complains about.

The thinking behind this →For operations leaders

What we are looking forDiscovery

Where velocity is lostWaiting, rework, re-keying, chasing
Where errors are costlyThe steps that must be exactly right
Where knowledge is trappedIn one person, one inbox, one folder
What repeatsFrequency is what makes automation worth building
What is already governedExisting approvals we should keep, not replace

Then, and only then·A shortlist worth arguing about

Both of them limit what we sell you.

TWO PRINCIPLES

Inference is not always the answer.

Some capabilities need a model because the work involves language, ambiguity or synthesis. Others should be deterministic software, and building them any other way is malpractice dressed as innovation. A model that is right most of the time is a liability in a path where being wrong once is unacceptable.

This is not a hedge about AI. It is why most of what runs on a deployment day to day is governed business software, with AI as one capability among several.

PrincipleWhere AI does not belong →

The client defines the outcome.

There is no universal metric here and we will not supply one. One executive is optimizing delivery time. Another is optimizing errors, risk exposure, or the frustration of a team doing work a machine should be doing. Those lead to different builds and different acceptance criteria.

So the first artifact is not a backlog, it is a sentence: what is this organization trying to make true, and how would we know it had happened.

PrincipleYour measure, your baseline

Inference does not belong in a zero-error critical path. AI is sometimes the runtime, and sometimes it is the tool used to build the runtime.The rule that decides what gets built

Chosen, built, accepted.

HOW A CAPABILITY HAPPENS

Nothing starts with a technology choice. It starts with an outcome somebody senior will defend, and ends with a named person accepting the result on the live deployment. Durations vary with the process, not with us, so we give ranges and not dates.

01A few weeks
Observe, map, and shortlist
Time inside the work, with the people who do it. The output is a short list of candidate capabilities, each written as an outcome rather than a feature, with a rough sense of frequency and of what it costs to do by hand today. Candidates that should stay human, or stay deterministic, are marked as such here rather than later.
Gate
Is there a candidate whose outcome the sponsor will put their name to?
Decides: your executive sponsor
02
Define success before building
Acceptance criteria are written first, with the process owner, in language that can be checked rather than argued about. A baseline is recorded, because an improvement claimed without one is a story. Where a model is involved we say exactly what it decides and what a human still decides.
Gate
Can we both state, in one sentence each, what done looks like and what would make this a failure?
Decides: your process owner
03Scoped per deliverable
Build it on the platform you already own
Built as a capability inside your deployment: its own isolated origin, a declared manifest of what it may reach, short-lived credentials tied to a named person, an access record written before any credential is issued, and a content policy on every inference call if it makes one. Not a script on somebody's laptop, and not hosted by us.
Gate
Does it pass validation, and stay inside the permissions its manifest declared?
Decides: the system, before anybody is asked
04
Staging, acceptance, then promotion by you
It lands on staging and the people who will use it try it against real work. Promotion to production is a separate route only a named administrator of yours can take, approving an exact artifact hash. Our own automation cannot promote anything. Then the outcome is instrumented against the step-two baseline.
Gate
Did the named acceptance criteria pass, in front of the people who wrote them?
Decides: your process owner and your administrator

An honest note on status

Client capability modules today run on the staging channel. The production promotion path is built and exercised on our own deployment, and the first client-authored build is a pilot. That is the status today, stated so you can plan against it. Detail on modules and developer modules.

Four named owners, or we decline.

WHAT YOU BRING

This is the one condition we hold firm on. Without these people named, priorities drift, success gets defined after the fact, sources go stale, and nobody can say whether it worked. In a smaller organization one person may hold several of the roles, but each role needs a name against it.

Role	What they own	What we need from them
Executive sponsor	Strategic outcomes and the priority order between them	The sentence that says what the organization is trying to make true, and the authority to change the order when we learn something
Process owner	The definition of success for each capability	Acceptance criteria written before the build, and their presence at the acceptance itself
Content or data owner	Source quality, permissions and currency	A commitment to keep sources current, and a straight answer about which source wins when two disagree
Finance owner	The baseline and whether the result was worth it	Validation of the baseline before we build, so the review afterwards is a measurement rather than a debate
Deployment administrator	Grants, promotion and the authority to pause	Someone named who will approve the exact artifact going to production, and who can stop it

The administrator is listed separately because the role is structural rather than commercial: promotion is administrator-only by construction, and our automation has no route to it. Who owns what across the whole relationship is on shared responsibility.

Every engagement feeds the platform.

WHY THIS GETS CHEAPER

A consultancy bills the same hours for the same problem at the next client. We would rather the second time be faster, which means the work has to leave something behind in the product and not only in your deployment.

01
Patterns become part of the kit. A shape we build twice becomes a scaffold, a validation rule or an example in the authoring kit, so the third one starts further along.
02
Exceptions become product. A repeated exception says the platform is missing something. Improving the scaffold, the documentation or the validation beats taking the implementation back in-house.
03
Your capability is yours regardless. What is built for you runs in your account and belongs to you. What goes back into the platform is the general shape, never your logic, your data or anything that could identify you.
04
The direction of travel is enablement. The intent is that your people eventually build the small things and we build the hard ones. That is a pilot today, not a claim; developer modules says where it stands.

Commercial shape

Work is scoped per deliverable: a named outcome, acceptance criteria written first, a price agreed before it starts. Longer engagements sit in the range of one junior technical hire, without the permanent headcount, and are broken into deliverables so you can stop between any two. We publish no figure because a figure without a scope is a number pretending to be a quote. See pricing.

The ones worth asking early.

QUESTIONS

01How is this different from hiring a contractor?

A contractor builds what you ask for. This starts by questioning whether the thing you asked for is the thing that moves the outcome, and it delivers onto a governed platform you already own rather than into a new corner of your estate. It also ends: each deliverable is bounded, and there is no headcount to unwind.

02Will you promise a percentage improvement?

No. We have no measured business-outcome results to quote and we will not invent one. We will agree the measure and the baseline with your finance owner before building, so the review afterwards produces a real number about your process. A vendor quoting an average improvement has told you about their marketing.

03What if the answer is that this should not use AI at all?

Then we build it as deterministic software, or we tell you it is not worth building. Treating that as a failure of ambition is how zero-error processes end up with a model in them. See enterprise automation for the test we apply.

04Do we need managed operations to do this?

In practice yes, because a capability nobody keeps current stops being trustworthy quickly, and the release path it rides on is the one managed operations maintains. If you have your own cloud team and want to own that, say so at the assessment.

05How much of your time do we get?

Enough to deliver the scoped deliverable properly, and we will tell you when a scope needs more time than we have. org.tech is a small senior practice: one principal with a small bench. The limit is capacity, not competence.

The claim this page makes

The goal is organizational velocity, not AI activity.

Counting models, pilots and tools measures effort. The durable advantage is the governed ability to turn how your organization works into new capabilities, repeatedly, on infrastructure you own.

01
Outcome first. Named by you, with a baseline, before anything is built.
02
Deterministic where it must be. A model is one option, not the default.
03
Accepted by a person. Promotion to production is your administrator's decision, never ours.

⎯⎯ Book the strategic assessment ⎯⎯

Your private AI, inside your control ·

The assessment produces the first capabilities shortlist, tied to an outcome you choose rather than a use case we brought with us.

Book the strategic assessment →See the engagement path →