Method

Four engineering gates stand between a demo and production

We break the work into steps you can check. When a step fails, we tell you rather than pushing on.

Why most AI pilots stall at the demo

More than 60% of enterprise AI attempts never leave the pilot stage. The reason is rarely model capability — it is the distance between a demo environment and a production one. That distance has four parts:

Real data is not demo data

Demos run on cleaned samples. In production the same field arrives in three formats with five sources of missing values, and the history contains business rules that were retired years ago. The work of connecting data often exceeds the work of connecting the model.

System integration and permissions

The table the model needs may live in three different systems, and the only two people who can read it — one has left. Mapping permissions and integrating interfaces is unglamorous, and it decides whether the system ever actually runs.

The process has to change, not just gain a tool

If the new system is not embedded into existing workflow, it becomes one more page somebody has to maintain. Real deployment means people change how they work day to day, and that requires the business side to be involved rather than IT pushing alone.

Nobody owns it after launch

Models drift, data distributions shift, business rules change. Without a named owner and a regression testing routine, accuracy decays around month three and the system is quietly switched off.

Our three-phase delivery process

Each phase has defined outputs and a stop condition. Continuing is never the default.

Phase 1

Assess and define

1–2 weeks

We watch the process on site, meet the people who will actually use it, and map the existing systems and data. Output is a written judgement: whether this is worth doing, where it will stick, and roughly what it takes.

Outputs

A feasibility judgement, including an explicit recommendation not to proceed where that applies
Inventory of existing systems and data
Draft scope and acceptance criteria

Stop condition

If the answer is that you should not build this, or that we are not the right team for it, we say so and explain why.

Phase 2

Pilot and validate

3–8 weeks

A fixed-scope pilot running on real data with real users. The goal is to prove it works under production conditions, not that it works in a demo.

Outputs

A running system
Evaluation report on real data
Recorded user feedback
Launch and rollback plan

Stop condition

If the agreed thresholds are not met, the pilot ends there. We settle by phase rather than pushing into the next one.

Phase 3

Compound and hand over

Overlaps phase 2

We extract the generalisable parts of the delivery: connectors, prompt templates, evaluation sets, failure cases. This determines how long the next similar use case takes.

Outputs

Inventory of reusable components and connectors
Technical and operations documentation
Notes on reuse for similar use cases

Stop condition

Where something cannot be reused because it depends on logic specific to you, we label it as such rather than pretending it is a general capability.

Outsourcing, project work, FDE: where the line is

The difference is not whether anyone sits on site. It is what remains when the project ends. This is the industry-wide test, and we hold ourselves to it:

What is left when the project ends	What that is called
A system that runs, and knowledge that leaves with the people	Outsourcing
Knowledge that came back but cannot be reused — the next client starts from zero	Project delivery
Domain knowledge, stripped of your information, turned into reusable components, connectors and templates	Forward deployed engineering
Delivery cost for the next similar client drops measurably	Forward deployed engineering at scale

The test is concrete: if the first client takes ten person-months and the tenth client in the same industry still takes ten, the model has not worked. A second red line: if a single client permanently consumes 30–40% of delivery capacity, the business has quietly become high-end staff augmentation.

What "compounding" actually means here

Compounding easily becomes a slogan. In practice it runs in two directions, each with concrete outputs and one hard boundary:

Towards the client: turning tacit knowledge into something a system can use

The rules, exceptions and judgement calls in your team's heads are usually written down nowhere. We turn them into knowledge bases, rules and workflows a system can call — documented so your own staff can read and maintain them.

Towards us: turning project experience into components the next project can use

How a particular system integrates, which step breaks, what kind of test catches it, which approaches proved useless — captured as reusable connectors, templates and a failure library.

Hard boundary: nothing of yours enters the reusable part

Client data, business rules and system detail do not enter our reusable assets. What is reused is the general method and components, never your specific implementation. That has to hold in the contract and in the engineering, not merely in a promise.

Handover design: what has to stay with you

This section covers a question that rarely makes it into a proposal: when the engagement ends, which things — beyond the code — determine whether you can maintain the system yourself. The sharpest framing of the risk in the industry is that the danger is not using outside help; it is using it in a way that leaves the enterprise less capable and more dependent when the engagement is over.

Monitoring and logs

You need to keep seeing what the system is doing: what it called, where it failed, whether quality is decaying. If that lives only with us, the visibility walks out of the door when we do.

The evaluation suite

The evaluation data, the pass criteria and the scripts that run it. Without them you cannot tell whether a change made things better or worse, and you cannot confirm the system still works after a model upgrade.

Integration logic and configuration

How the systems connect, how fields map, how exceptions are handled. If that exists only in someone's head, or in a configuration file only we can change, you have not really received the system.

Runbook and decision record

How to handle common failures, which parameters must not be changed casually, and why it was designed this way. Without a decision record, whoever takes over next repeats the mistakes we already made.

The cost model

What the system costs to run each month, where that money goes, and what would make it jump — a doubling of call volume, a model generation change. Most proposals price the first part and treat the following eighteen months as a given.

A practical test: ask a provider what you will and will not be able to change after they leave. If the answer contains a lot of "that would need us", it is not a technical limit — it is a commercial design.

Acceptance checklist

Acceptance criteria are agreed before work starts, not discussed at handover. This is what we confirm line by line on every project:

Function and result

The business problem is written down, with a measurable indicator for it (handling time, accuracy, rate of human intervention)
An evaluation set is built on your real data and frozen at project start, with a copy held by each side
A minimum acceptable result and the method of measuring it, including who measures, when, and by what definition

System and integration

Every existing system that must be integrated is listed, with a named owner for each interface
The permission model is explicit: what identity the system uses to read data, who approves it, how it is audited
A launch and rollback plan, including who responds to a failure and within what time
Monitoring and logging belong to you, so you can still see what the system is doing after we leave
The evaluation suite — its data and its pass criteria — transfers to you rather than staying with us
Integration logic and configuration are handed over in a form you can maintain, not as a black box only we can change

Organisation and use

The actual end users are identified, and they took part in designing it
Who maintains it and takes feedback after launch is written into the documentation, not agreed verbally
A review point three months after launch — passing acceptance once is not evidence that a system is being used

Who is responsible for what

Projects rarely fail on technology. They fail because the two sides understood their own responsibilities differently. So we settle this table up front:

We are responsible for

Judging the use case and the technical approach, including telling you plainly what cannot be done
Building the system, integrating it and supporting launch
Compounding reusable assets, and labelling honestly what is not reusable
Surfacing risks and bad news early rather than on the delivery date

You are responsible for

Naming a domain expert and protecting their time — this is the single most common place projects stall
Granting access to production data and systems, and completing your internal approvals
Naming one counterpart with decision authority, so requirements do not arrive from several directions
Bringing your IT team into interface and permission work

If any of these four cannot be arranged, the project will most likely stall in its later stages. We would rather establish that during assessment than discover it halfway through.

Scope change is normal — here is how we handle it

An important new requirement appears during the pilot

We record it and do not absorb it. Finish the current scope and treat it as input to the next phase. Scope creep is the main reason pilots fail.

A key assumption is disproved — the data turns out to be unusable

Stop and reassess rather than doubling down to rescue it. If the conclusion is not to continue, we settle for the work completed.

An organisational commitment cannot be met — the domain expert has no time

Pause the project and say so in writing. Continuing only produces a system nobody uses and nobody signs off.

Four things we do not do in delivery

We do not start projects without acceptance criteria. If success cannot be defined, it should not begin.
We do not walk away after launch. We come back for a review three months in.
We do not run projects with unbounded scope. Requirements can change, but changes become the next phase rather than being absorbed into this one.
We do not deliver code without understanding. Documentation and knowledge transfer are part of the deliverable, not a favour.

Common questions

How long does a typical engagement take?

Assessment usually takes one to two weeks; a pilot three to eight. The total depends on how many existing systems are involved and how usable the data is — unusable data is the most common cause of delay, which is why we check it during assessment.

Who owns the system after launch? Do we get the source code?

Code and data belong to you, and the contract states it. What we retain is general method, components and templates with your information removed. Exact terms are confirmed clause by clause at contract stage.

What if we discover halfway that the direction is wrong?

We stop and reassess. We settle by phase and will not ask you to keep paying for a direction that no longer holds. That is precisely why the work is split into three phases rather than one large project.

Will you clash with our internal IT team?

This deserves a straight answer. In practice the most common resistance to an embedded engineer comes from an internal team that reads the outsider as a judgement on their work. Our approach is to treat IT as a party that must co-deliver: interfaces, permissions and release process are decided together, and the outcome carries both names. If your structure makes that impossible, we will say so during assessment.

Want to see how we judge whether a use case is worth doing?

Describe what you are trying to push forward. The assessment produces a written judgement — including, where it applies, a recommendation not to proceed.

contact@mail.kchangai.com