Recently at an FDE salon in Shenzhen, our team broke down the end-to-end delivery roadmap of a million-yuan (seven-figure RMB) Forward Deployed Engineering engagement. This article turns those field insights into a structured retrospective: What did the enterprise client actually purchase, what did we physically build and deploy, and why did this project command a seven-figure commercial budget?
Before diving into the numbers, two non-negotiable principles must be clarified upfront. This project succeeded entirely because of two foundational practices:
- FDE projects must be executed through phased, staged milestones;
- Before any phase commences, explicit delivery boundaries must be agreed upon in checklist-level detail.
At its core, a Forward Deployed Engineer (FDE) is a builder who embeds directly into the customer’s operational trenches to turn a concrete business bottleneck into a production-grade, verifiable tool that internal teams can reliably maintain. That tool might take the shape of an enterprise-wide intelligent collaboration suite, or it might just be a twenty-line Python script.
How large the solution should be depends strictly on the business problem and the contractual boundaries—not on how futuristic the word “AI” sounds in marketing slides.
On this project, before writing a single line of application code, we firmly established: which exact problem this phase solves, what criteria define completion, and what edge cases are explicitly out of scope. Otherwise, before pilot metrics are even verified, feature requests multiply uncontrollably; when acceptance testing rolls around, the client’s definition of “done” and the engineering team’s definition will be miles apart.
1. Phased Rollout: Every Step Must Leave Verifiable Artifacts
Enterprise FDE engagements should be partitioned into four progressive stages:
Stage 1: Problem Diagnosis & Scope Fencing
Sit alongside employees performing the actual daily routine: who owns the task, where do bottlenecks emerge, and how do operators currently decide whether an output is correct?
- If internal documents cannot be found, is it because materials do not exist, version sprawl has corrupted sources, or access portals are too fragmented?
- Identify root causes, document the operational boundary, and compile realistic input-output samples. Only then can you objectively decide whether the task demands an LLM or if a deterministic script suffices.
Stage 2: Small-Scale Pilot & Feasibility Validation
Confine the pilot to a single task category, a curated dataset, or a tight cohort of frontline users to generate verifiable outputs using authentic business materials.
- Test normal inputs, but aggressively test pathological edge cases: missing source documents, ambiguous prompts, and contradictory records.
- The pilot must conclude with quantifiable answers: which exact friction point was eliminated, under what circumstances does the tool fail, and does the business impact justify expanded capital investment?
Stage 3: Industrialization & Operational Integration
Once algorithmic and UX efficacy are proven, transition to infrastructure: enterprise SSO authentication, private document ingestion pipelines, on-prem VPC deployments, department Token quotas, and automated fault recovery.
- The objective is ensuring the system runs reliably and unattended under agreed service-level agreements.
- Running successfully once on an engineer’s local MacBook does not satisfy this milestone.
Stage 4: Acceptance, Handover, and Ownership Transfer
Submit production workloads through real corporate endpoints, inspect the final exported deliverables alongside frontline staff, and systematically hand over installation manifests, update runbooks, debugging protocols, and maintenance responsibilities.
- Only when internal teams know how to operate the system daily and whom to contact when errors arise does the project attain operational sustainability.
[!IMPORTANT] Progression Rule: Advancing to the next phase requires explicit “gating criteria.” If a pilot fails to prove concrete business utility, do not rush to expand department rollouts; if enterprise service accounts are not provisioned, integration cannot be marked complete in status reports. Advance milestones based on verified artifacts, not calendar schedules.
A phased approach accommodates backward iteration. If entering the client’s intranet reveals transparent file encryption that breaks parsers, retreat immediately to Stage 1 to resolve data governance and decryption rights. If frontline users report that business logic feels counterproductive, pause, refine rules, and re-test. Staging exists to surface problems early, not to lock project scope in an inflexible straightjacket.
2. Setting Delivery Boundaries That Can Be Audited
A vague requirement like “build us an intelligent enterprise office assistant” is toxic to engineering timelines. It specifies neither the operational tasks covered, nor the required quality threshold, nor who holds ultimate sign-off authority.
A robust delivery boundary must answer the following core questions:
- Actionable Scope Boundaries: For example, when building a “meeting summary assistant,” if the contract states “generates a structured draft from uploaded transcripts,” engineers must not casually promise to “automatically assign action item owners, trigger approval workflows in OA, or email announcements to departments.” Delivering the UI portal does not mean every department is onboarded.
- Read vs. Write Boundaries: Permission to query a database does not imply authorization to mutate records; permission for an LLM to draft official memos does not imply authorization to publish them under the corporate banner. Chaining APIs together in code is trivial; delineating legal and operational liability is not.
- Prerequisite Boundaries: Boundaries must detail what will be built, what is explicitly excluded, and what external conditions must be fulfilled prior to execution. If internal knowledge repositories are unindexed or API credentials delayed, engineering must document in writing which dependencies are missing and how schedules are affected.
During the Stage 2 pilot, a meeting summarizer might deliver human-reviewed sample drafts. Once in production, documentation must dictate what happens when audio quality degrades, where failure logs reside, and who maintains prompt extraction templates. Recording these terms in delivery specifications ensures both parties agree on what is being accepted today and what remains for future iterations.
[!NOTE] Change Requests Require Re-scoping: Adding a third-party chat webhook, shifting from cloud to air-gapped on-premise servers, or requesting complete repository source code requires re-evaluating engineering workload, acceptance criteria, delivery timelines, and commercial terms. Transparency is the bedrock of enterprise trust.
3. Inside the Million-Yuan Deal: What the Enterprise Needed
The corporate office deployment we delivered targeted several recurring, high-volume operational tasks:
- Searching internal policy compendiums and operational guidelines;
- Audio transcription and executive meeting minute synthesis;
- Drafting corporate memorandums, notices, and presentation decks;
- Automated scheduling reminders and action item tracking.
Take meeting minute synthesis: employees upload meeting recordings or raw transcripts, the system extracts structured drafts, and human operators review decisions, pending tasks, and open questions.
- The business guardrails were uncompromising: “we might consider” must never be hallucinated into “it was decided”;
- Unassigned task owners must never be arbitrarily fabricated;
- Presentation decks and memos blend corporate slide templates with historical collateral, saving staff from starting from a blank screen.
When we initially demonstrated our cloud prototype on-site with live enterprise data, the product capabilities were immediately apparent. However, transitioning from a departmental trial to group-wide enterprise procurement shifted executive scrutiny toward infrastructure governance:
- Where does corporate data travel, does it cross national borders, and how is it encrypted at rest?
- How are multi-tenant subsidiary token budgets, rate limits, and billing tracked centrally?
- When model completions misfire, how are audit trails established for accountability?
- Once external engineers depart, how will internal IT teams maintain and upgrade the stack?
The commercial structure shifted accordingly:
- Initial Proposal: Departmental pilot, cloud-hosted SaaS subscription, priced in the hundreds of thousands of RMB for year one;
- Final Agreement: Group-wide enterprise licensing for thousands of concurrent employees, native integrations with WeChat Work and Feishu, air-gapped on-premise VPC deployment, and delivery of complete source code and deployment blueprints. The software engineering budget reached seven figures, with long-term maintenance SLAs and model inference tokens billed separately.
What expanded here was delivery scope and enterprise ownership. Designing architecture for 1,000-seat capacity does not mean 1,000 employees connect simultaneously on day one. Purchasing source code grants the enterprise architectural blueprints; translating those blueprints into operational sovereignty still demands version-controlled CI/CD environments, deployment runbooks, and incident triage manuals.
Calling a cloud chatbot an “enterprise management platform” does not eliminate the hard engineering required for intranet integration, on-prem deployment, load testing, and technical handover.
4. Expanding Scope: What to Add vs. What to Keep Simple
Scaling from an experimental prototype to enterprise-grade infrastructure requires disciplined architectural additions and subtractions.
Architectural Additions: Unified Model Gateway & Security Guardrails
- Model Gateway: We designed and deployed a centralized AI model gateway to mediate all upstream business requests:
- Sensitive PII masking and regulatory compliance filtering;
- Departmental quota enforcement and dynamic concurrency throttling;
- Task-based model routing (directing general reasoning, long-context parsing, and code generation to appropriate model families);
- Comprehensive observability: logging prompt tokens, completion tokens, latency distributions, and trace IDs.
- Multi-Layer Defense-in-Depth: A gateway manages model access, but message payload encryption, IP whitelisting, and audit log masking require strict isolation within application and database tiers.
- Enterprise IM Integration Cycles: Integrating with WeChat Work and Feishu relies on corporate admins provisioning enterprise application IDs and whitelisting callback domains. Writing integration code is fast; clearing enterprise security reviews takes weeks. Those timelines must be buffered into the schedule.
Architectural Subtractions: Restraint Over Unnecessary Complexity
In our technical choices, we exercised deliberate simplicity:
- Prioritizing BM25 Over Heavyweight Vector Stores: For internal policy document retrieval, given document collection scale, we chose a battle-tested BM25 keyword index over a dedicated vector database. The system retrieves candidate paragraphs by exact terms before passing context to the LLM for synthesis.
- Retrieval quality is validated via sampling with authentic enterprise queries;
- When queries fail, we inspect whether text was unindexed, phrasing mismatched, or chunking defective, rather than blaming “imperfect vector embeddings.”
- Excel Bill-of-Materials (BOM) Ingestion: Verified spreadsheet records originally required manual re-entry into the ERP system.
- The LLM parses unstructured remarks and normalizes messy column headers into canonical formats;
- SKU validation, quantity arithmetic, and tax calculations are enforced via deterministic Python rules.
- A real-world production hurdle: operators could open spreadsheets on local desktops, but background backend workers ingested corrupted ciphertext. Investigation revealed transparent enterprise DLP (Data Loss Prevention) file encryption, requiring dedicated decryption microservices and service account credentials. Concurrency locks and idempotency keys were added to prevent duplicate ERP submissions during network retries.
[!TIP] Core Engineering Philosophy: AI accelerates tool construction, but running that tool in production does not always require invoking AI. If a deterministic script or a regular expression reliably solves the problem, deliver that scoped solution with confidence.
5. Tracing Acceptance Boundaries to the Final Deliverable
During enterprise acceptance testing, engineering teams often fall into a trap: mistaking “API call succeeded” or “fast time-to-first-token” for “business solution accepted.”
Prior to final procurement bidding, we conducted stress testing under production concurrency: 30 parallel streaming sessions completed without error, with a P95 Time-to-First-Token (TTFT) of approximately 7 seconds. Roughly 95% of requests began streaming completions within 7 seconds.
This metric demonstrated only one thing: under defined test constraints, gateway connectivity held and generation began. It did not prove support for 1,000 active concurrent employees, nor did “token streaming began” mean “a complete 30-page memorandum was generated.” Connections can drop midway through streaming, or completions can trigger content filter blocks near the end.
Our fault-tolerance design implemented explicit recovery paths:
- If a primary model times out before emitting tokens, the gateway falls back immediately to a secondary provider;
- If generation crashes mid-stream, the partial completion is saved as a recoverable draft while prompting the user for manual review.
- It does not mean a half-completed generation can swap underlying models mid-sentence without losing conversational state.
Therefore, acceptance testing must track identical business materials through the entire pipeline:
- Did the retrieval engine access the correct source paragraphs?
- Are generated conclusions grounded in authoritative corporate documents?
- When opening the final exported Word, PDF, or PowerPoint document, are layout hierarchies, table figures, and indentation levels correct?
[!WARNING] Production Lesson: On an automated engineering drawing project, internal vector calculations were accurate, but the rendered dimension callouts shifted on the exported CAD drawing. Automated unit tests verified in-memory coordinates and passed with green flags, but the delivered drawings were unreadable by factory technicians. The Takeaway: Acceptance must inspect the final file opened on the user’s screen. API success, file generation success, and business utility are three independent milestones that must be verified separately.
6. The Two Ledgers of a Million-Yuan Deal
When enterprise executives approve a seven-figure FDE engagement, they evaluate two distinct financial ledgers:
Ledger 1: The Delivery Ledger (Cost to Deliver)
A limited cloud prototype differs fundamentally from an on-premise, source-code-delivered group deployment.
The commercial quotation must transparently itemize application development, intranet network bridging, enterprise IM integration, on-site deployment, and final handover training. Long-term maintenance SLAs and operational token consumption are calculated over a multi-year horizon.
SaaS seat subscriptions and source code buyouts represent contrasting commercial models; one cannot simply be billed as a marked-up version of the other.
Ledger 2: The Business Ledger (ROI & Value Creation)
A heavy engineering workload explains how vendor costs are calculated. Whether the enterprise purchases depends on how much redundant labor is eliminated from daily operations.
Consider this labor cost model:
- Assume 200 knowledge workers across the enterprise use the system regularly;
- Factoring in mandatory human review, each worker saves a net 15 minutes per day;
- Across 200 workers, that yields 50 hours saved per day;
- Over 220 standard working days, the system saves 11,000 labor hours annually;
- Assuming an average enterprise labor cost of 100 RMB/hour (incorporating benefits, facilities, and overhead), this nominally recoups 1.1 million RMB annually in recovered productivity.
[!NOTE] This represents an operational projection rather than immediate cash returned to the balance sheet. Whether employees adopt the system consistently, whether saved hours translate into higher-density output, and whether vendor outsourcing and overtime are reduced must be tracked in quarterly operational reviews.
Project Handover and Operational Wrap-up
In the final phase of an FDE engagement, engineers must deliver a comprehensive operational package to the client:
- Deployed application binaries and tagged Git source code repositories;
- Comprehensive deployment configurations and container manifests;
- Production benchmark suites covering realistic business scenarios;
- Backup, failover, version rollback, and incident recovery runbooks;
- Operational guides for internal IT staff on template maintenance and model routing updates.
Only when internal teams can update document templates, inspect logs during outages, and manage the system after external consultants depart does the enterprise realize compounding value from their investment.
From a simple script to an enterprise system: phased rollouts prove value before committing capital; strict delivery boundaries ensure both teams agree on what is delivered today. When requirements expand, adjust timelines calmly; when a focused tool solves the operational bottleneck, deliver it with stability and precision.
The genuine value of an FDE lies not only in lines of code shipped, but in architectural restraint, explicit boundaries, and steady engineering accountability.
I am Miles, focusing on AI algorithm engineering, corporate AI enablement, and hands-on FDE enterprise delivery. Connect with me on X: @miles_mazy for ongoing discussions on practical enterprise AI implementation.
