Run a customer engagement end to end: technical discovery with a buyer in the room, an integration that survives their systems, a deployment somebody else can operate, a security review you pass, a production AI feature behind an eval harness, and the value conversation that decides whether any of it mattered.
Begin with: Use the sales call to establish what you can actually deliver
Start free lesson →20 min · Free · no account needed
Syllabus
Free lessons need no account. Sign in free for Plus lessons. Premium unlocks the full course.
Technical discovery
Working alongside a sales team without becoming one, finding the deal-killer before the contract is signed, and writing a pilot proposal that survives the first surprise.
Enterprise integration
Connecting to systems that predate the web, proving who you are to four identity models at once, and building pipelines that survive schema drift, backfills and replay.
- Choose the integration path that meets the workflow and can be operatedVideo explainer · 11:3024 minfree
- Carry the caller’s permissions through every data and action boundaryVideo explainer · 12:5028 minsign in
- Make replay, quarantine and reconciliation part of the pipeline contractVideo explainer · 10:4130 minsign in
A model of their world
The layer between raw integration and anything useful: objects and links in the customer's own vocabulary, actions that make the model do something, and the discipline that stops it becoming a second schema nobody maintains.
- Give business definitions an executable homeVideo explainer · 8:5628 minsign in
- Keep link evidence, uncertainty and history in the queryVideo explainer · 8:4730 minsign in
- Make named actions safe to authorize, retry and recoverVideo explainer · 9:2730 minpremium
- Project: the query runs, the number is wrong, and finance cannot say whyproject75 minsign in
Deploying in their environment
Choosing where the software runs, getting it there reproducibly, and seeing what it does from outside a boundary you cannot cross.
- Choose a deployment you can operate under the actual constraintsVideo explainer · 8:3826 minsign in
- Recreate the release and prove that its state can recoverVideo explainer · 10:1928 minpremium
- Build the diagnostics you will need when you cannot log inVideo explainer · 10:0428 minpremium
- Lab: rehearse a customer release and prove the way backproject120 minpremium
The security review
Getting through the review that decides whether any of this goes live: how it actually fails, the findings you can predict in advance, and the questions nobody has good answers to yet about a model.
The model in production
What changes when the AI feature has to run every day: an eval that can block a release, a cost and latency budget that shapes the architecture, and the quiet quality regressions that nothing alerts on.
- An evaluation becomes a harness the day it can block a releaseVideo explainer · 11:2524 minpremium
- Cost per unit of their work is the number, and it decides the architectureVideo explainer · 12:2425 minpremium
- Every dashboard is green and the system has been getting worse for a monthVideo explainer · 11:2625 minpremium
When the answer is a model
Not every prediction problem needs machine learning, and the ones that do fail on data rather than algorithms. Choosing between a rule, a model and a prompt; building training data that does not leak; and operating a model whose accuracy decays without any error being raised.
Agents with authority
Letting a system act on a customer's workflow without giving it a blast radius: bounding what it can do, surviving the run that stops halfway, and earning autonomy one rung at a time.
- Bound agent actions by authority, consequences and shared limitsVideo explainer · 9:1230 minpremium
- Recover partial runs without guessing whether an action happenedVideo explainer · 9:3730 minpremium
- Promote an action only when its evidence and operating controls are readyVideo explainer · 9:5230 minpremium
- Enforce every agent's authority at one checkpoint the registry controls30 minpremium
Proving it was worth it
The part of the engagement that decides whether there is another one: choosing a number the customer already believes, showing the change was yours, and putting it in front of the person who funded the work.
- Measure the baseline and distinguish time, capacity and cashVideo explainer · 9:4428 minpremium
- Separate observed improvement from evidence of causationVideo explainer · 11:2530 minpremium
- Write the review memo around a decision the evidence supportsVideo explainer · 12:2128 minpremium
- Lab: reconcile the pilot result before recommending expansionproject90 minpremium
The craft around the work
What decides whether a technically successful engagement continues: not being single-threaded on one person, refusing the wrong request without losing the room, and building something that keeps running after you leave.
Capstone
Assemble the freight engagement into one dossier: every artifact the modules had you draft, completed, made consistent, and defended in a mock review. The output is an engagement you can talk about for an hour.
About this course
Before you start: Foundations of Forward Deployed Engineering, or a year or two of relevant experience. You should be comfortable reading an unfamiliar system, scoping a thin slice, and shipping something small into someone else's environment.
Foundations covered the first week of an engagement. This course covers all of it: the arc from a sales call where nobody has agreed what success means, to a system running in production that somebody else operates, to the review meeting where you find out whether it mattered.
The difference from the first course is that nothing here is a clean exercise. Every module works against a system you did not build, inside constraints you did not choose, for people whose incentives are not identical to yours. That is the job at this level, and the technical content is inseparable from the judgment around it.
One customer runs through the whole course. The project lessons follow a single fictional engagement, a composite built from the shape these deployments usually take rather than any real company. You will scope it, integrate it, deploy it, get it through a security review, put a model in front of it, and argue for its value. By the end you have a set of artifacts that fit together, which is a far better thing to bring to an interview than a pile of unrelated exercises.
Read the modules in order. The sequence is the engagement, and later modules assume the decisions made in earlier ones.
When you finish, you can
- Run technical discovery alongside a sales team and write a pilot proposal that de-risks the deal
- Build an integration that survives a legacy system, real auth, and a network you do not control
- Deploy inside a customer environment and pass a security review without stalling for a month
- Take an AI feature to production behind an eval harness, a cost budget and real guardrails
- Give an agent authority over a workflow without giving it a blast radius
- Measure the value you created and defend it to the person who funded it
- Hand the whole thing over so it survives a reorganisation and your departure
- Leave the capstone with a complete engagement dossier: nine artifacts, reconciled, defended against a skeptic
