100x · FDE Roadmap
Map view0/6 milestonesTake the assessment

The north star

Become a Forward Deployed Engineer.

A Forward Deployed Engineer sits with a customer, finds the process inside their business by hand, builds the AI system around it, and proves it worked to someone who did not build it.

  • Length12 weeks at a standard pace
  • PaceSelf-paced, about 8 to 10 hours a week
  • Milestones6 pass/fail checks

Before you start

Take the 25-minute readiness assessment.

Eight skills, one short written answer, closed book. Your result sizes this roadmap: blocks you already know move fast, blocks you are new to get extra time. It is the first step of Week 0.

Take the assessment →Start at Week 0 without it

The first principle

Input, process, output.

Every piece of software is an input, a process and an output. At a customer, the input is what you learn in discovery, the process is the system you build, and the output is a result the customer can verify without you. The whole job is finding the process in between, then building the machine so it runs without you.

Input

Discovery

Who does the work today, where the time goes, and what good looks like, measured before you build.

Process

The system

The steps that turn the input into the output. Each step is a rule, a model, or a person.

Output

A verified outcome

A result checked against the baseline by someone who did not build it.

Inside the process

Look inside any process and every step is one of three kinds. The design question for each step is which kind it deserves.

Deterministic

Same input, same output, every time. Interfaces, APIs, databases, deployment.

Which steps deserve rules? Block 1 →

Probabilistic

A prediction, not a guarantee. LLMs, tool calling, retrieval, memory, evals.

Which steps deserve a model? Blocks 2 to 4 →

Human

A person stays wherever a wrong answer costs more than a slow one. Agents built for people, approvals, handover.

Which steps stay human? Block 5 →

How do you find the process in the first place? By doing it by hand. That is why Week 0 asks you to talk to real people and run the process once yourself before any tool is opened. The manual run is the map; every block after it automates what the map shows. See Week 0 →

The road

One block at a time.

Each block is a kind of component, in the order a deployment needs them. Take the assessment and the road resizes to you.

Week 0

Find the process

Discovery to a manual MVP

The output of Week 0 is not an app. It is a process you have run once by hand for a real person, with a number attached. That manual run is the map; every block after it automates what the map shows. You also take the readiness assessment here, so your roadmap is sized to you.

What should you build, and how will anyone know it worked?

Week 0

Check
Take the readiness assessment
  • Know where you stand across the eight skills an FDE uses.
  • Get a plan sized to you: which blocks to move through fast and where to slow down.
Start the assessment →

On the jobCalibration is the job: an FDE who knows what they do not know asks better questions on day one.

Concept
Orientation: what an FDE actually does
  • Explain the FDE role: embedded with a customer, accountable for an outcome, not a ticket.
  • Explain why the verifier is the job: every step is checkable by a rule, by judgment, or not at all.
  • Name the three kinds of step inside any process: rule, model, person.
Build
Discovery: find the process by hand
  • Interview real people about one repeated task, and write down who does what and where the time goes.
  • Take a baseline: minutes per run, runs per week, and what a mistake costs.
  • Run the process once by hand for a real person and record what you did, step by step.
A notebookA spreadsheetA real person
Meet Aarav, your first customer →

On the jobThis is the first week of every real deployment: before any code, you learn the customer's process better than they can describe it.

Block 1 · Weeks 1 to 4

Ship the first system

Interfaces, APIs, data, deploy

One component type at a time: the interface a person uses, the API that does the work and keeps the secrets, the database that remembers, and the deploy that puts it in a stranger's hands. All deterministic: same input, same output, every time.

Which steps deserve rules?

4 weeks at a standard pace. Take the assessment to size this block to you.

The first interface

Concept
What an interface is, and UI as the first interface
  • Explain the anatomy of a full-stack system: frontend, backend, API, LLM, database.
  • Turn your manual run's input, process and output into the outline of a system.
  • Take a simple tool apart, name every component inside it, and say why it breaks without each one.
Build
Building UI: design to deploy
  • Write a one-page spec and build a chat UI from it in Python.
  • Use Gradio or Streamlit, and know when to pick which.
  • Deploy your first app and share a public link.
PythonGradioStreamlitHugging Face Spaces
Lesson hub →Notes →Build guide →Practice set →

On the jobYour first deliverable at a customer is usually a working interface in front of a real user, not a slide.

The second interface

Concept
APIs: the second interface
  • Explain why the frontend cannot store or protect data on its own, and what an API is for.
  • Specify an endpoint's address, action, key and package, and read the code and package that come back.
  • Diagnose common status codes and authentication errors, and call an LLM API.
The Request BuilderAarav's APIGroq
Lesson hub →Request Builder →Notes →Practice set →

On the jobMost of a deployment is integration: reading someone else's API at 11 pm and knowing which of the six parts is wrong.

Build
Building APIs and the backend
  • Separate what the frontend does from backend logic, secrets and controls.
  • Build and validate the core input-process-output function before exposing it.
  • Create and test FastAPI endpoints locally, then deploy the backend and connect it to the UI and an LLM.
PythonFastAPIRender
Lesson hub →Notes →Practice set →

Data that survives

Concept
Databases and domain modelling
  • Tell temporary in-memory state from persistent storage.
  • Find a product's entities, attributes and relationships before any table exists.
  • Design a relational schema with primary keys, foreign keys and the right relationship types.
PaperThe Modelling Lab
Lesson hub →Modelling Lab →Notes →Practice set →

On the jobA customer's data model is their business written down. Getting it right on paper saves a rebuild in week three.

Build
Connect the backend to a database
  • Explain when an app needs a database instead of variables or files.
  • Turn your domain model into tables, types and keys.
  • Save linked conversations and messages, fetch the right history, and show the data survives a restart.
FastAPISupabase

Launch

Build
End-to-end MVP: build and deploy
  • Turn your Week 0 process into a core function that solves the user's problem.
  • Define output quality as written criteria, and check against them.
  • Use an AI coding agent with reviewed plans and explicit specs.
  • Deploy the full stack, then add authentication, usage limits and cost per user.
GradioFastAPISupabaseRender

On the jobShipping to a named stranger is the moment a prototype becomes a deployment.

Block 2 · Weeks 5 to 6

Make it think

LLMs, model choice, tool calling

What a language model can and cannot know, how to choose one for a customer on evidence rather than hype, and tool calling: the model asking for an action, your code taking it.

Which steps deserve a model?

2 weeks at a standard pace. Take the assessment to size this block to you.

Models from first principles

Concept
LLMs from first principles
  • Explain learning as goals, attempts, errors and feedback.
  • Explain next-token prediction and the stages that turn a base model into an assistant.
  • Tell self-supervised learning, supervised fine-tuning and preference alignment apart.
  • Explain why data quality and the system around the model matter more than the model alone.
Build
Choosing a model for a customer
  • Build a small test set from the customer's own examples, with known good answers.
  • Compare two or three models on quality, latency and cost per task, and write down the pick and why.
  • Know when data residency, volume or a classical model changes the answer.
PythonA hosted model APIAn open-weight model

On the jobCustomers will ask "which model?" in the first meeting. The FDE answer is a measured comparison on their data, not a brand.

Tool calling and MCP

Concept
Tool calling and the road to MCP
  • Explain how missing context causes hallucinated answers, and when live external data is needed.
  • Design the three-layer flow: model, backend execution, deterministic tool.
  • Describe tools with names, descriptions and schemas; separate the model's decision from the backend's execution.
  • Explain how MCP standardises tool discovery, and when a direct integration is enough.
Build
Build a tool-calling loop
  • Implement the loop: model decision, backend execution, tool result returned, final response.
  • Write precise tool descriptions and argument schemas to reduce ambiguity.
  • Expose one tool over MCP, and test routing between tools using real failures to improve the contract.
PythonGroqFastMCP

On the jobConnecting a model to the customer's systems through tools is most of what an FDE builds.

Block 3 · Weeks 7 to 8

Give it the customer's data

Retrieval, memory, enterprise data

Retrieval puts the right part of the customer's knowledge in front of the model at question time; memory keeps what was learned across conversations. Both have to respect who is allowed to see what.

Why can't the model answer from the customer's documents by default?

2 weeks at a standard pace. Take the assessment to size this block to you.

Retrieval

Concept
Retrieval-augmented generation
  • Explain retrieval, augmentation and generation as separate stages.
  • Diagnose context-window limits and retrieve only what the question needs.
  • Compare indexing, metadata filtering, keyword search and embedding search.
  • Use representative questions with known answers to choose a strategy and check correctness.
Build
Build a RAG app
  • Measure token usage before sending retrieved text to a model.
  • Implement chunking, metadata indexing and query-specific filtering.
  • Show one answer that cites its source chunk, and compare token use before and after optimising.
  • Diagnose whether a failure comes from missing knowledge, stale information, scale or model behaviour.
PythonSupabase (pgvector)

Memory and the customer's data

Build
LLM memory: build a second brain
  • Explain memory as persistent state with rules for writing, retrieving and resolving contradictions.
  • Spot stale memories, wrong stored facts and context pollution.
  • Build a second brain that answers a question about something told to it a week earlier.
PythonSupabase
Concept
Enterprise data: access, privacy and residency
  • Enforce each user's permissions at retrieval time, not after generation.
  • Redact or restrict personal data the answer does not need.
  • Ask the questions that decide where data may live and which model may see it.

On the jobThe first security review at a customer is about data, not models. Pass it by design.

Block 4 · Weeks 9 to 10

Make it reliable

Harness, evals, fine-tuning, observability

Connect the dots into a harness of rule, model and human steps, then measure it: evals with written rubrics, judges you have checked, fine-tuning only when it is the right answer, and traces that let you explain any output.

What decides reliability: the model, or the arrangement around it?

2 weeks at a standard pace. Take the assessment to size this block to you.

The harness and its evals

Build
Connecting the dots: harness engineering
  • Draw the control graph of your system: deterministic, model and human steps.
  • Explain why the arrangement, not the model, decides reliability.
  • Reproduce one failure and add the step that catches it.

On the jobCustomers do not buy a model. They buy a system that fails safely and visibly.

Build
Evaluating LLM systems
  • Define task-specific quality criteria and gather test prompts, ideal outputs and edge cases.
  • Compare benchmarks, automated metrics, LLM judges and human review.
  • Check an LLM judge against human grades, and show one case where the judge was wrong.
  • Use eval failures to improve prompts, data and behaviour.
A spreadsheetPythonAn LLM judge

Model behaviour and operations

Concept
Fine-tuning, and when it is the wrong answer
  • Choose between prompting, examples, retrieval, workflow design and fine-tuning based on the actual gap.
  • Explain supervised fine-tuning and preference alignment, including RLHF and DPO.
  • Compare full fine-tuning, LoRA and QLoRA on cost, memory and effect.
Build
Data preparation
  • Clean and normalise a small dataset, remove duplicates and redact sensitive fields.
  • Prevent leakage between training and evaluation data.
  • Improve coverage of edge cases and validate quality before use.
PythonA spreadsheet
Build
Observability and cost per user
  • Trace every input, output and retrieval step of a request.
  • Report cost and latency per user and per task.
  • Set an alert for the failure that would hurt the customer most.
TracingLogsA dashboard

On the jobWhen the customer asks "why did it say that?", the trace is your answer.

Block 5 · Weeks 11 to 12

Deploy it with a customer

Agents for people, the FDE operating model, capstone

Agents built for the people who use them: where a person has to stay, what an agent may do alone, and how it asks. Then the job itself: scoping a pilot, reporting to stakeholders, and handing over a system the customer can run without you.

Which steps stay human?

2 weeks at a standard pace. Take the assessment to size this block to you.

Agents built for humans

Concept
Agents for humans
  • Explain the agent loop: reason, call a tool, observe, decide, stop.
  • Decide when a fixed pipeline beats an agent, and when an agent earns its cost.
  • Place a person wherever a wrong answer costs more than a slow one.
Build
Guardrails and human checkpoints
  • Separate instructions from untrusted input to defend against prompt injection.
  • Give tools least-privilege permissions and keep an audit trail of every action.
  • Add human confirmation before high-impact or irreversible actions.
PythonYour tool-calling loop

On the jobTrust is earned in the first incident. Guardrails decide whether that incident is a log line or a lost customer.

The FDE operating model

Concept
Scoping a pilot and running the engagement
  • Write a one-page pilot scope: the user, the process, the baseline, the success metric and what is out of scope.
  • Say no to the wrong use case, with a reason the customer accepts.
  • Send a weekly stakeholder update: what shipped, what the numbers say, what is blocked.

On the jobThis is the part of the job no tutorial teaches: being accountable for an outcome inside someone else's company.

Check
Capstone: deploy, measure, hand over
  • Deploy a system that automates a real stakeholder's process from your Week 0 discovery.
  • Measure it against the baseline you took in Week 0.
  • Hand over with a runbook: how it works, how to tell it is broken, and what to do then.
Everything so far