Case Study: Deploying an LLM Feature at an Enterprise Customer in 5 Days
The Deployment Challenge: 5 Days to Value
A Fortune 500 logistics customer had a painful bottleneck: their legal team spent 15 hours a week manually reviewing vendor contracts for non-standard liability clauses. The ask was an AI feature that could flag risky clauses. The constraint: the solution had to run entirely inside their VPC, touching no external APIs. The timeline: 5 days.
This isn't a hypothetical. It’s a representative case study of what Forward Deployed Engineers (FDEs) actually ship. The goal isn't a perfect production system on day one—it's a working, secure, high-signal prototype that earns the right to be productionized.
Day 1: Scoping the Real Problem
The initial request was "build a contract analyzer." That’s a trap. An FDE’s first job is to decompose vague enterprise needs into a concrete, shippable slice. We spent the first 4 hours in a conference room with two paralegals and their VP.
We discovered:
- The core task: Identify indemnification clauses that deviate from the company’s standard template.
- The volume: 30–50 contracts per week, mostly PDF and DOCX, heavily scanned.
- The security boundary: No data leaves the AWS VPC. Period.
- The success metric: Reduce initial review time by 50%, with zero missed high-risk clauses.
We defined the v0 scope: a single endpoint that accepts a contract and returns a JSON risk assessment for the top-3 most dangerous clause types. No UI. No multi-tenancy. Just a Python script behind a FastAPI server.
Day 2: Data Engineering in the Dark
Enterprise data is messy. The contracts lived in a SharePoint library with inconsistent OCR layers. Many were image-heavy PDFs generated by ancient scanners. We couldn’t use a cloud Vision API, so we needed an on-prem OCR pipeline.
We stood up:
- Tesseract OCR inside a Docker container, tuned with the customer’s specific font profiles (they used a custom corporate typeface from the 90s).
- PyMuPDF for native text extraction where possible, falling back to Tesseract.
- A chunking strategy that split documents by section headings (Article I, Section 2.1, etc.) using regex patterns the paralegals identified.
This is where FDE work diverges from pure ML engineering. The "AI" part was useless if we couldn't get clean text. We spent 40% of the total project time on data ingestion and cleaning. The output was a structured JSON array of clause objects, each with metadata about its position in the document.
Day 3: Model Selection & The On-Prem Constraint
No OpenAI. No Anthropic. No hosted models. The customer’s security team was immovable. We needed a capable LLM that could run on their existing GPU cluster (two NVIDIA A100s).
We evaluated three options:
| Model | Size | Inference Speed | Contract Clause Accuracy (Qualitative) |
|---|---|---|---|
| Llama 3 70B (4-bit quantized) | ~40GB VRAM | ~25 tokens/sec | Good, but struggled with legalese |
| Mixtral 8x7B | ~25GB VRAM | ~45 tokens/sec | Better, but hallucinated clause numbers |
| Fine-tuned Mistral 7B (legal dataset) | ~14GB VRAM | ~60 tokens/sec | Best for targeted extraction |
We chose the fine-tuned Mistral 7B, served via vLLM for continuous batching. It fit comfortably on one A100, leaving the second for embedding generation. For retrieval, we used ChromaDB with all-MiniLM-L6-v2 embeddings, indexing the customer’s 500 golden-standard contract clauses.
This is a critical FDE judgment call: we sacrificed general intelligence for speed and precision on a narrow task. The model didn’t need to write sonnets; it needed to spot when a liability cap was missing.
Day 4: Prompting, Guardrails & The Human-in-the-Loop
Prompt engineering for enterprise legal use is unforgiving. A hallucinated clause number in a report to the General Counsel is a career-limiting move.
We built a two-pass system:
- Retrieval Augmented Generation (RAG): For each extracted clause, retrieve the 3 most similar clauses from the golden-standard database.
- Comparative Analysis Prompt: The LLM receives the target clause, the reference clauses, and strict instructions to output ONLY valid JSON with a risk score (1-5) and a 1-sentence justification. No markdown. No commentary.
SYSTEM_PROMPT = """
You are a legal clause comparator. You receive a TARGET_CLAUSE and 3 REFERENCE_CLAUSES.
Output ONLY a JSON object with keys: risk_score (integer 1-5), justification (string).
A risk_score of 5 means the clause is missing critical protections present in the references.
Do not output any other text. Do not use markdown.
"""
We added a guardrails layer using a combination of regex validators and a secondary LLM call that checked if the output was valid JSON and if the justification was grounded in the provided text (a lightweight form of hallucination detection).
Critically, we designed a human-in-the-loop review queue. The system didn't auto-reject contracts; it surfaced a prioritized list of flagged clauses with direct links back to the source PDF. The paralegals could accept or override each flag in a simple Streamlit interface we threw together in 2 hours. This built trust and created a feedback loop for future fine-tuning.
Day 5: Shipping & The Silent Launch
Day 5 was about hardening and handoff. We:
- Containerized the entire pipeline (OCR, chunker, vLLM, ChromaDB, FastAPI, Streamlit UI) into a single
docker-composefile. - Wrote a 3-page runbook for the customer’s DevOps team.
- Ran the system on 10 historical contracts the paralegals had already reviewed, achieving 92% agreement on high-risk flagging.
- Scheduled a 30-minute silent launch: the paralegals used the tool for their morning batch while we watched over their shoulders, fixing a PDF parsing edge case in real-time.
By 4 PM, the VP signed off. The feature reduced initial review time by 60% in week one. The feedback loop we built meant the model improved with every override.
Architecture: The Final Flow
Here is the system architecture we landed on. Notice the clean separation between the on-prem data plane and the minimal UI layer.
Why This Worked: The FDE Skill Stack
This 5-day deployment wasn't magic. It was the direct application of the highest-leverage FDE skills. For a deeper dive into these competencies, see The Highest-Leverage Skills for an FDE in the AI Era: Prompting, Data, and Modeling.
1. Ruthless Scope Negotiation We didn't build a contract analyzer. We built a clause comparator for three specific clause types. Saying "no" to feature creep is an engineering skill. Understanding the operational workflow well enough to know what matters is the FDE multiplier. This pattern is core to the Palantir-style embed model, which we break down in How Palantir-Style FDEs Embed with Customers to Unlock Operational Value.
2. Pragmatic Data Engineering The model was the easy part. The OCR, chunking, and regex were the hard parts. FDEs live in the data. If you can't get clean text out of a 1998 scanner, your vector database is useless.
3. Security-First Architecture Knowing how to serve open-weight models with vLLM inside a VPC, using no external dependencies, is table stakes for enterprise FDE work. This unlocks opportunities that SaaS products can't touch.
4. Guardrails & Human-in-the-Loop Design We didn't try to automate the human out of the loop. We built a system that made the human faster and more accurate. The Streamlit review queue was the feature that sold the VP, not the LLM.
5. Shipping Velocity The difference between a research prototype and an enterprise feature is the last 10%: the runbook, the edge-case handling, the silent launch with real users. This is the daily rhythm of an FDE, which we detail in What an FDE Actually Does in a Week: Daily Rhythm of Customer Shipping.
FAQ: Enterprise LLM Deployments
Q: Why not use a commercial LLM API with a BAA? Many enterprises, especially in regulated industries, have strict policies against external data transit for certain workloads. The legal team’s contracts contained commercially sensitive terms. An on-prem model was non-negotiable.
Q: What if the customer didn't have GPUs? We would have explored CPU-only inference with a quantized model like Llama.cpp, but performance would have suffered. In that scenario, we’d push for a smaller, specialized model and potentially a longer inference time SLA.
Q: How do you handle model updates and maintenance?
The docker-compose setup included a model registry path. The customer’s ML team could swap the Mistral 7B model file for a fine-tuned version. The feedback loop from the review queue provides training data for future fine-tuning runs.
Q: Is 5 days realistic for most enterprise deployments? It depends entirely on the scope and the customer’s readiness. This customer had GPUs provisioned, a clear problem, and a motivated champion. The FDE skill is in finding the smallest possible slice that delivers measurable value, then expanding from there. Comp for FDEs who can execute at this pace typically ranges from $180K–$280K+ at top-tier firms, reflecting the blend of engineering, customer empathy, and speed.
Want to build like a Forward Deployed Engineer?
FDE Coach is a cohort-based program in frontend, backend, AWS, and AI. Build real products and get referred to 200+ hiring partners.
Explore the program