Client Engineering
Client Engineering
Day 12 · The forward-deployed craft
Everything you learned in Days 1-11 makes you an engineer. This chapter is about the other half of the title forward deployed engineer: the part where you build inside someone else's world - their data, their infra, their security team, their politics, their definition of success. Most FDE projects that fail don't fail on code. They fail on a scope nobody agreed to, data that never showed up, or a demo that surprised the wrong VP.
The instinct we're training: you are not shipping a system, you are shipping an outcome the customer can verify. Every practice below serves that.
Outline
- What "forward deployed" means - the job in one diagram
- Discovery - from a vague ask to a shippable one-pager
- Scoping and the acceptance eval - define "done" with the customer, in numbers
- Enterprise integration reality - SSO, legacy APIs, and data trapped in SharePoint
- Security and data posture - answering "where does our data go?" without flinching
- Demos and stakeholder communication - status, bad news, and saying no
- The engagement rhythm - kickoff to handoff, and the artifacts each stage owes
1. What "forward deployed" means
A product engineer ships one system to many customers. A forward deployed engineer ships one outcome to one customer at a time, embedded in their environment. That inversion changes everything:
- Your requirements arrive as a business complaint ("sales ops wastes hours on this"), not a spec.
- Your infrastructure is theirs: their cloud account, their VPN, their approval board.
- Your deadline is a meeting where a sponsor decides whether to keep paying.
- Your test suite includes a human: the person who has to trust the system.
The technical stack is Days 1-11. The FDE stack is: discover → scope → integrate → prove → hand off. Each section below is one stage.
2. Discovery - from a vague ask to a shippable one-pager
Discovery is a structured interview, not a chat. You are extracting four things:
- The pain, quantified. "Manual invoice matching" is a topic. "Three analysts spend ~2 days a week matching invoices, with a 4% error rate that finance re-audits" is a problem you can price.
- The workflow today. Walk it end to end with the person who does it. Ask for a screen share, not a description - what people say they do and what they do diverge.
- The systems of record. Where does the data actually live? Who owns access? What format is it really in? (Assume the answer contains at least one spreadsheet.)
- The definition of success. What number moves, by how much, judged by whom, by when?
Write the answers into a one-pager: problem, current workflow, proposed slice, success metric, data needed, risks, out-of-scope list. The out-of-scope list is the most valuable section - scope creep is the default failure mode of embedded work, and the only cheap time to refuse scope is before you start.
Welzin rule: no build starts without a one-pager the customer has read and confirmed in writing. "We discussed it on the call" is not a scope.
3. Scoping and the acceptance eval
You already know evals from MLOps and RAG Pipelines as engineering practice. In client work, the eval is something more: it is the contract.
Before building, agree with the customer on:
- The eval set. 30-100 real examples from their data (real invoices, real tickets, real queries), with the expected output for each, labelled by their expert.
- The passing bar. "≥ 92% match with the analyst's answer on the held-out set" beats "works well". Include the baseline: what does the current human process score on the same set? (Often lower than anyone expects - measure it.)
- The failure policy. What happens on the 8% the system gets wrong? Human review queue? Confidence threshold routing? Silent failure is never an answer.
This does three jobs at once: it forces the customer to define "good" precisely, it gives you a regression suite for free, and it turns the final meeting from an opinion contest into reading a number off a table. When the model or prompt changes later, the eval decides if the change ships - same as CI.
4. Enterprise integration reality
The bootcamp taught you clean APIs. Enterprises will hand you:
- Data where it lives, not where you want it: SharePoint folders, SAP exports, an Oracle view someone wrote in 2011, Excel files with merged cells. Plan an extract → validate → load step as a first-class deliverable, not a preamble. Validate loudly: reject and report bad rows, never silently coerce.
- Auth that is not yours to choose: SSO via SAML or OIDC, service accounts that take three weeks and a ticket to provision, VPN-only databases. Ask for access on day one of the engagement - access lead time, not code, is the usual critical path.
- Change control: production changes may need a CAB (change advisory board) slot, a security review, or a freeze window. Find the process before you promise a date.
Patterns that keep you safe:
- Read-only first. Your first integration never writes to a customer system. Prove value on reads; earn write access.
- Adapter boundary. Wrap every customer system behind a thin adapter module you own. When their API surprises you (it will), the blast radius is one file.
- Synthetic fallback. Build against a synthetic copy of their data shape from day one, so their three-week access ticket doesn't idle you.
5. Security and data posture
At some point a customer's security lead will ask: "Where does our data go?" You must answer precisely, unaided, without flinching. Know for your own system:
- What data leaves their environment, to which endpoints (model APIs, telemetry, logs), and what never leaves.
- What is stored, where, encrypted how, retained how long, deletable on request.
- Which subprocessors are involved (cloud provider, LLM provider) and what the DPA (data processing agreement) with each says.
- What PII enters prompts, and what you do about it (redaction, pseudonymisation, or a documented decision that it's in scope).
Baseline hygiene you already learned - secrets in a manager, never in source or prompts (Linux, Backend) - now has a compliance layer on top: GDPR if the data touches the EU, India's DPDP Act for personal data of Indian users, SOC 2 expectations if you sell to enterprises. You are not the compliance officer, but you are the person who must not create the violation. When a customer requires it, be ready to deploy inside their VPC or on-prem - which is why the Docker/Kubernetes discipline from DevOps is non-negotiable for FDEs.
6. Demos and stakeholder communication
- Demo the real thing, on their data, every week. A weekly 15-minute demo of imperfect-but-real beats a polished monthly slide deck. It surfaces wrong assumptions while they are cheap.
- Never demo something for the first time in the meeting. Dry-run it an hour before, on the same network, same account.
- Status updates are written, short, and honest: shipped / next / blocked / risk. The "blocked" line is where projects are saved - a blocker reported the day it appears is a schedule note; the same blocker discovered in week six is a crisis.
- Deliver bad news early and with a plan. "The OCR accuracy is 71%, not the 90% we hoped; here are two options with costs" builds more trust than optimistic silence.
- Saying no is a service. Every "yes" to unscoped work is a hidden "no" to the committed scope. The polite form: "We can do that - it's an addition to the one-pager, so let's price and schedule it rather than absorb it."
7. The engagement rhythm
A Welzin engagement owes the customer these artifacts, in this order:
| Stage | Artifact | Owner check |
|---|---|---|
| Kickoff | One-pager (scope, metric, out-of-scope) | Customer confirmed in writing |
| Week 1 | Access checklist + synthetic data shape | Access tickets filed day one |
| Weekly | 15-min live demo + written status | Real data, dry-run first |
| Pre-launch | Acceptance eval report vs the agreed bar | Numbers, not adjectives |
| Launch | Runbook: deploy, rollback, monitoring, failure policy | Their on-call can operate it |
| Handoff | Handoff doc: architecture, adapters, eval suite, open risks | A stranger could take over |
The handoff doc is the professional signature of an FDE. The test: could an engineer who has never met you operate, debug, and extend the system from the doc alone? That standard is also why your Git history and CI/CD hygiene matter - the repo is part of the handoff.
Hands-on Checkpoints
Work these against a mock client brief (your buddy plays the customer; if you're self-studying, write the brief for a business you know, then answer your own discovery questions in their voice):
- Run a 30-minute discovery interview on a vague brief ("our support team is drowning") and produce the one-pager, including the out-of-scope list and a quantified success metric.
- Build a 30-example acceptance eval set from sample data, define the passing bar and the failure policy, and measure a naive baseline against it.
- Take a messy spreadsheet (merged cells, mixed date formats, three shapes of "N/A") and write an extract → validate → load script that rejects and reports bad rows instead of coercing them.
- Write the one-page "where does our data go?" answer for a RAG system that calls a hosted LLM API - endpoints, storage, retention, PII handling, subprocessors.
- Record a 10-minute demo of any project from Days 1-11 as if to a non-technical sponsor: problem, live walkthrough on real data, current metric, next step, one honest risk.
- Write a weekly status update for that same project in the shipped / next / blocked / risk format, including one piece of bad news delivered with options.
These checkpoints feed directly into the Capstone - pick the client-flavoured variant there and Days 13-15 become a full dress rehearsal of this chapter.
Further reading
- The Forward Deployed Engineer - Palantir's original framing of the role
- The Trusted Advisor - Maister, Green, Galford (the consulting-craft half of the job)
- Your AI product needs evals - Hamel Husain, on evals as the deliverable
- India's DPDP Act, explained - the compliance floor for personal data of Indian users
Welzin opinion: The best FDEs are not the strongest coders - they are the engineers a customer would rehire. Rehire comes from scope honored, numbers proven, and zero surprises. Optimise for that and the code follows.