The title Forward Deployed Engineer (FDE) came out of Palantir Technologies around 2011. The job was simple to describe and almost impossible to copy: an engineer flies to the customer (an intelligence agency, a bank, a manufacturer), sits inside their operation, watches the work happen, and ships running systems on their side of the wall. No deliverable is a deck. No deliverable is a recommendation. The deliverable is a system in production that the customer team owns the day the engineer leaves. OpenAI and Anthropic picked up the title for the same reason: enterprise AI does not deploy itself, and the buyers wanted somebody to own the outcome instead of the integration meeting. Databricks hires FDEs. So does Ramp. So does every infrastructure company that decided customer success teams cannot write the integration code.
The role works exactly the same way at SMB scale. The size of the company changes. The kind of code changes. The kind of operations change. The job does not change.
I am embedded in five businesses right now. Two B2B distributors (paint and dimensional stone). One photo-mosaic e-commerce brand on Amazon and Etsy. One retail-adjacent education business. One AI consulting practice (this one). All five run on the same operating model: I live in one or two tools per business, watch what is actually happening, and ship code daily. The total stack costs less than what a single mid-level engineer would charge for one month of contract work in New York City, and it covers five operations.
This post is the playbook. What an embedded FDE actually does inside an SMB. How to spot a business that is ready for one. What gets built and what gets killed in the first 30 days. The three-tier offer (Audit $2,500, Sprint $5K+, Install $20K+). The failure modes you will see if you try this. The anti-cases where you should not try this. What to charge. How to scope. One concrete case study from an operation I am embedded in right now.
If you are an operator at a $5M to $50M business and you are reading this to figure out whether to hire one, the answer is probably yes if you nod at sections 2 and 3, and probably no if you nod at section 7. Read both before booking anything.
The job has three modes. Almost everything I do at every business is one of these three.
Mode 1: Live in 1-2 tools per business. The default move on day one of any engagement is to ask for read access to the two tools where the work actually happens. That is usually not the CRM. The CRM is where the work gets logged. The work happens in the inbox, in the shared Slack channel, in WhatsApp, in the cash register, in the dispatcher's spreadsheet, in the customer service queue. I get added to those tools as a real user, not as an auditor. I see the same notifications the operator sees. I read the same threads. By day three I usually know two or three things the founder does not know about their own operation, because the founder has stopped seeing them. The leak the founder is paying me to fix is rarely the leak with the highest dollar value. That is fine. That is what the first week is for.
Mode 2: Watch operations for three to five days. No code in week one. The temptation is to ship something fast to prove value. Resist it. Real operations have invisible rules that are not documented anywhere. The vendor account number that has to be in field 3 of one specific form. The customer who must always be quoted in metric units because they once got a wrong size in imperial. The Friday afternoon rush that is the actual revenue driver of the business even though the Monday morning meeting treats it like an edge case. Code shipped before you see this stuff will break operations before it fixes anything. Three to five days of watching is the smallest cost you can pay to avoid that.
Mode 3: Ship code daily from week 2. Once the operational map is real, the work flips to daily shipping. Small commits. Visible to the team. Reversible. The goal in week 2 is to get one thing live in production that the team uses, not to ship the cathedral. By week 4 the cathedral can start, but only because the small things in week 2 and week 3 surfaced what the cathedral actually needs to do. The pattern is anti-waterfall by design. The customer side of an SMB cannot absorb a four-month build with a single launch event. They can absorb daily incremental shipping if the engineer is in the room.
The output of those three modes is a system that runs in production on the customer side. Not a strategy. Not a roadmap. Not a 40-page deliverable. A thing that runs, that the team uses, that breaks sometimes, that the engineer fixes, and that eventually the team owns without the engineer. That is the unit.
Three signals. If two or three of these are true, the business is ready. If zero or one are true, the business is not ready, and the right move is to delay the engagement by 90 days while one of the signals matures.
Signal one: there is at least one operational leak the owner can describe in a single sentence. Not "we need AI." Not "we want to transform digitally." Something like: "Inbound leads from our website take 4 hours to get a reply and we lose half of them." Or: "Every quote takes two people 45 minutes and we ship 30 a week." Or: "Our bookkeeper closes the month on day 18 and we cannot make decisions before that." A one-sentence leak is a sign the founder has been watching. If the founder cannot name a one-sentence leak, the audit is the right first step, because the audit is partly a forced exercise in naming the leak.
Signal two: there is one person on the operations side who will be in the room with the engineer. Not the founder. The founder is too senior and too distracted. The person who answers customer questions, runs the quote desk, manages the dispatcher, or closes the books. The operations lead. If there is no operations lead and the founder is the operator, the FDE engagement will either turn the founder into a part-time PM (which kills it) or proceed without an internal owner (which means the system has nobody to inherit it). The single best predictor of a successful 30-day Sprint is the existence of one named internal owner who attends the daily 15-minute standup.
Signal three: revenue is between $5M and $50M, and at least one workflow has 20+ events per week. Volume matters because the ROI math on custom automation requires throughput. A 4-hour build that saves 30 minutes per event pays back in 8 events. A 4-hour build that saves 30 minutes per event when there are only 2 events per month takes a year to pay back. The $5M to $50M band is where most workflows hit 20+ events per week. Below $5M, off-the-shelf tools win on math. Above $50M, you have already hired the engineer full time and you do not need an embedded FDE on a fractional contract.
I have walked away from engagements that nailed two of the three signals but missed one badly. The most common miss is signal two: a founder who promises to be the internal owner and then misses standups by week 3. That is a 30-day Sprint that ships nothing the team can run. Better to delay 90 days, hire the operations lead, then start.
The shape of every engagement is the same. The names of the tools change. The leak changes. The internal owner changes. The shape does not.
60-minute kickoff with the founder and the operations lead. Three outputs: a one-sentence problem statement that both parties sign off on, a list of the two tools I get added to as a real user, and the time slot for the daily standup. Access bootstrap means tool invites get sent during the call, not after. Standing up access takes a day of latency you do not get back. The default standup is 15 minutes, same time daily, on the operations lead's calendar, not the founder's.
I sit inside the two tools and read. I follow the path of one inbound lead from first touch to close. I follow the path of one order from quote to fulfillment. I read the Slack channel where the team coordinates. I count where data gets re-entered, where decisions wait on one person, where the same question gets asked three times in a week. The deliverable at the end of day 4 is a one-page operational map: the actual workflow, not the official workflow. The founder usually sees something in that map they had not noticed. That is the first proof point.
Three leak candidates ranked by ROI per hour of build time, not by what sounds impressive. Each candidate has a dollar estimate (labor cost or revenue cost), a build complexity rating (one to three days, four to ten days, more than ten days), and a kill criterion (what stops the build mid-flight if the assumption turns out to be wrong). The operations lead picks the top candidate. The founder signs the scope. Scope locks before any code gets written. If we discover something during the build that invalidates the scope, we re-scope to the next-ranked candidate before continuing.
Build starts in a sandbox that points at test data. I commit daily. The operations lead can see what shipped. By day 9 the sandbox should be able to run end-to-end on 20 test cases without an undocumented error. If it cannot, the scope was wrong and we re-scope. The reason for daily visible commits is not transparency theater. The reason is that the operations lead catches operational mistakes (a vendor field used differently than the documentation says, a customer segment the build forgot) when they see the work in flight, not when they review a finished system at handoff.
The system points at real production data for the first time. Expect three breakages in the first 48 hours. Vendor APIs that have rate limits the documentation did not mention. Auth tokens that expire on a schedule the docs got wrong. Production data that has nulls, mixed formats, and edge cases the sandbox did not cover. The build budget always assumes 30 percent of the work happens after the system first touches real data. If you do not budget for it, you ship something that runs in sandbox and breaks the moment the team relies on it. The internal owner watches the breakage with me. That is part of how they learn to run the system.
Three alert types get wired in. Hard failure: the system stopped, the operations lead gets a message within 2 minutes. Silent failure: the system ran but produced a wrong result, flagged by a confidence score threshold and surfaced in the daily standup. Drift: the system runs slower or with worse outputs than baseline, surfaced in a weekly digest. Handoff documentation gets written while the build is fresh, in a Notion or Google Doc the operations lead owns, not in my private notes. The doc is for the person on the team who will actually run the system. If they cannot follow it, I rewrite it.
The system runs in production for 48 hours with the operations lead watching, not intervening. Every "wait, what does this do?" question gets logged. The questions are the diagnostic for what the documentation missed. After the pause test, I record a 10 to 15 minute walkthrough video covering the three or four things the team needs to know: how to check health, how to read the logs, how to handle the two most common issues, who to call when something the doc does not cover happens (usually a vendor, not me). Video stored in the customer's Google Drive or Notion, not in my account.
The system goes fully live with no active engineering presence. I am available on Slack for questions but I am not monitoring the system myself. The day 30 deliverable is a one-page comparison: pre-engagement baseline versus first 72 hours live. Inbound lead response time before, after. Manual hours per week before, after. Cost per transaction before, after. If the metric did not move, I say so. The exit plan covers what I am available for in the 30 days post-handoff (two check-in calls and Slack questions), and what triggers a fresh statement of work for follow-up build.
The timeline above is the shape of one Sprint. Most engagements after the first audit run two or three Sprints back to back over 8 to 14 weeks. That is what the Full Install tier covers. The shape of each Sprint inside the Install is the same as the shape above.
The offer structure mirrors how the work actually scopes in the real world. Most operators do not know what they need yet. The audit is for finding out. Most operators who finish the audit need one focused system. The Sprint is for shipping it. A subset of operators who finish a Sprint want a multi-system portfolio across sales, ops, and customer-facing surfaces. The Install is for that.
5-day calendar engagement. 60-minute discovery call, 2 to 3 hours of operations shadow, tools landscape map, and a 20-page PDF deliverable with three prioritized leak findings. Each finding has a dollar estimate (labor or revenue cost) and a build complexity rating. The deliverable is specific enough that an operator can take it to any engineer or agency and get a build quote that is apples to apples.
No fit, no fee applies. If during the 5 days I conclude there is no leak worth automating (the business is too small, the leaks are people problems wearing an AI costume, the operational stack does not support the build), the audit is free. That has happened twice in the last 12 months. Both operators got a one-page memo explaining what they actually needed (one needed a sales hire, one needed a CRM that worked). I do not get paid for those. The structure forces me to call it honestly instead of inventing work.
The audit is the right entry point for most operators. It is cheap enough to fit on a credit card and slow enough to surface what the operator could not see on their own. The audit deliverable also creates the artifact that makes the Sprint scope obvious. Roughly two thirds of audits convert to a Sprint. The other third either take the report and build it themselves (the report is specific enough to do that), or use the report to defer the build by 90 days while they fix a precondition.
4-week calendar engagement. The Day 1 to Day 30 timeline in section 3 is the Sprint. The deliverable is one production system: built, tested against real data, documented, and handed off to a named internal owner. Includes 30 days of post-handoff support (two check-in calls and async Slack access for questions).
$5,000 is the starting price. The starting price covers a system with two to three integrations, one workflow, and a clear ROI metric. Higher complexity bumps the price. A voice agent that handles multilingual inbound calls and books straight to a calendar costs more than $5,000 because it has more integrations and a higher failure cost. A document extraction pipeline that processes 50 invoices a week and routes them to the right ledger costs more than $5,000 because the failure cost is auditable. The audit deliverable usually contains the actual quote because the audit surfaces the actual complexity.
One Sprint, one system. No bundling. That sounds like a marketing decision but it is actually an engineering decision. The reason most multi-system builds fail is that the integration surface between systems gets debugged at the end, by which point three systems are broken and nobody knows which one broke first. One system at a time means the integration surface gets debugged as it is built, by the engineer who built it, while the operations lead is in the room. The Install tier exists for operators who want three to five Sprints in series. The Sprint tier exists for operators who want one and done.
8 to 14 weeks. Three to five systems shipped sequentially, each as its own Sprint, with shared infrastructure and a single reporting dashboard. The Install is the right fit for operators who have done one Sprint, seen the model work, and want a portfolio of systems running across sales, ops, and customer-facing surfaces.
The typical Install covers a sales-side system (inbound lead handler, voice agent, or outbound sequencer), an ops-side system (document processing, scheduling, or reporting), and a customer-side system (post-sale follow-up, support deflection, or retention triggers). The three systems share a small dashboard that surfaces what a 5 to 10 person operations team would surface manually. The operations lead reads the dashboard once a day and makes decisions.
The Install includes 90 days of post-handoff monitoring instead of 30. The reason is that a portfolio of three to five systems exposes failure modes that single systems do not (a vendor change that breaks two systems at once, a data quality drift that propagates across the dashboard). The longer monitoring period exists to catch those before they compound.
I cap the practice at three concurrent Install engagements. That is not a scarcity tactic. It is a math constraint. An Install engagement requires me to be in the room (on Slack, in standups, fixing breakage in production) for the duration. Three Installs plus the audit and Sprint pipeline plus the five operations I run for my own businesses is the load that fits in a week without dropping a ball.
The specific work that gets killed in the first 30 days of a typical Sprint. Names are anonymized, numbers are real.
A 75-minute daily reporting task at a B2B distributor. Every morning the operations lead pulled inventory data from the warehouse system, sales data from the CRM, and outstanding quote data from a shared sheet. She combined them into a one-page report that the founder read with coffee. The report drove the day. Time on task: 75 minutes per day. After the Sprint: 4 minutes per day. The system pulls the three sources, applies the same combination rules, and posts the report to a Slack channel at 7:45 AM. The operations lead reviews the auto-generated report for accuracy in 4 minutes, then approves it for distribution. Annualized labor savings: roughly 280 hours, or about a third of an operations lead's quarter. The system took 18 hours to build.
A 32 percent inbound lead drop at an e-commerce brand. The brand ran ads. Ads drove traffic. Traffic that did not convert immediately filled out a contact form. The form went to a generic inbox. The inbox got checked twice a day. By the time anybody replied, the customer had bought from a competitor. The Sprint built a webhook on the form that fired a contextual reply within 90 seconds (with the right product link, the right tier match, and the right next-step CTA based on the form input). Reply rate on the same-day reply: 41 percent. Drop on stale leads: down from 32 percent to under 8 percent. Revenue impact in the first 60 days: a measurable increase the founder mapped directly to the new flow.
A 3-day quote turnaround at a stone distributor. Custom quotes required a salesperson to look up slab inventory, calculate edge work, add freight, check stock at a partner yard, and assemble a PDF. Average turnaround: 3 days. Lost-quote rate: high. The Sprint built a quote builder that took the customer's specifications (dimensions, edge profile, ship-to ZIP, finish), queried the same systems the salesperson queried, and produced a draft PDF that the salesperson reviewed and approved in 6 to 10 minutes. Quote turnaround dropped from 3 days to 2 to 4 hours during business hours. The system did not replace the salesperson. It replaced the 2 hours of lookups that preceded the salesperson's 10 minutes of judgment.
Three things to notice across all three. None of them are sexy. None of them needed a new AI model. None of them required the customer to change their underlying business. All three killed a leak that was visible the first time I sat in the operations lead's seat and watched the work for a day. The interesting part of an embedded FDE engagement is almost never the AI. The interesting part is the operational map.
Three specific ways an embedded FDE engagement fails. I have seen each one. Two of the three I caused. The third I caught early enough to walk away.
Failure mode 1: the engineer builds the cathedral before sitting in the room. The temptation is real. The operator describes a problem on the kickoff call. The engineer has built similar systems before. The engineer starts building the system on day 2 instead of watching operations until day 5. The cathedral ships on day 25. It is technically correct. It is operationally wrong: it does not match how the team actually works, it does not handle the three edge cases that drive 80 percent of the volume, and it cannot be operated by the internal owner because it was designed for an idealized team that does not exist. The fix is structural. Force the no-code period. Days 2 through 4 are sacred. The Sprint is allowed to ship less code as long as the code that ships is the right code.
Failure mode 2: the internal owner is fictional. The founder names somebody on the kickoff call. That person attends the first standup. By the third standup they are missing. By week 3 they have not seen the build in two weeks. The handoff at day 30 has nobody to receive it. The system runs but nobody on the team knows how. Within 60 days the system has drifted, broken, or been silently abandoned. The fix is to insist on the operations lead's attendance as a hard scope condition. If the operations lead cannot make the daily standup, the engagement does not start. The founder does not count, no matter how engaged the founder is on the kickoff call.
Failure mode 3: the operator wants a strategy deck, not a system. Some operators book the engagement expecting a 40-page deliverable they can take to their board. They want the artifact, not the system. The first sign is a question like "can you also do an executive summary for our advisory board?" or "what would the slide version of this look like?" That is a consultant deliverable. An FDE shipping a slide deck is a consultant in an engineer's job description, and the system never gets built because the time goes into the deck. The fix is to call this out on the kickoff call and offer to refer the work to a consultant. Saying no costs a deal. Saying yes costs a refund and a bad reference. The math is obvious.
Six specific cases where the right answer is not an FDE engagement. If you nod at any of these, do something else first.
Anti-case 1: your core operation runs on a legacy on-premise ERP with no public API. The integration surface alone breaks the 4-week Sprint container. Examples: a 1990s-era manufacturing system, a custom internal application built by a contractor who is no longer around, a SaaS platform on a deprecated version with no upgrade path. These projects are sometimes worth doing. They are not worth doing inside a Sprint. The right container is a 6 to 9 month project with a dedicated integration engineer and a budget that absorbs the unknown.
Anti-case 2: you are pre-product-market-fit. If you do not yet know what your customers want, automating the way you do business today will lock in the wrong thing. The right move is to do less, not more. Spend the $5,000 on customer research, not on automation. Come back when you have a workflow that has worked for 6 months and feels obviously broken because of volume.
Anti-case 3: the leak is a people problem wearing an AI costume. A sales rep who does not follow up does not follow up because of a process, not a tool. A customer service backlog that grows because the product has a recurring defect is not a customer service problem. A founder who cannot make decisions because they do not have data is not a data problem; usually the data is fine and the decision is the bottleneck. AI cannot fix these. An FDE engagement that tries will spend $5,000 to address the symptom while the actual problem continues. The audit is designed to call this out in writing before anybody signs a Sprint contract.
Anti-case 4: you want a side project, not a production system. Some founders are curious about AI and want a small fun build to learn from. That is a great instinct. It is not an FDE engagement. The right path is to spend a weekend with the API console, build something small, and see what you learn. An FDE engagement requires production traffic, an internal owner, and a real metric. If the build does not need any of those, the engagement is theater.
Anti-case 5: nobody on your team can answer questions during the build. If your operations lead is at trade shows for 3 of the 4 weeks of the Sprint, the engagement does not have an internal counterpart and the handoff has nobody to receive it. Postpone until you have somebody who can be in the standup daily.
Anti-case 6: you are looking for the cheapest engineer who can do the work. Embedded engineering is expensive per hour. The hourly rate looks high compared to a junior contractor on Upwork. It is high. The work is structured so that fewer hours produce more shipped systems. If the buying criterion is hourly rate, the offer that wins will be the offer that bills for the longest, and embedded FDE will lose to a 12-week engagement with a junior team that ships less. That is fine. The two offers do not compete for the same buyer. The right move is to buy the cheapest engineer who can do the work, and then read this post again in 6 months when the system that was supposed to ship in October still has not shipped.
The pricing structure I run, with the reasoning. Operators can use this as a benchmark for any provider, including offers from agencies, fractional firms, and individual engineers.
Audit: $2,500 flat, no fit no fee, 5 days. Reasoning: low enough to fit on a credit card without a procurement cycle. High enough to filter out tire kickers and to pay for the 5 days of senior engineering time. The audit price is the same regardless of company size in the $5M to $50M band, because the work is the same. Audits priced over $7,500 for SMB are usually agency markups, not deeper work.
Sprint: from $5,000, 4 weeks, one system. Reasoning: the floor price covers a system with two to three integrations and clear ROI. The ceiling depends on complexity. Most Sprints land between $5,000 and $12,000. A multilingual voice agent with a custom calendar integration and a CRM write-back is closer to the ceiling. A document extraction pipeline that routes 30 to 50 events a week is closer to the floor. Anything quoted above $20,000 for a single system at SMB scale is usually padding or a quote that includes ongoing retainer hours.
Install: from $20,000, 8 to 14 weeks, three to five systems. Reasoning: the Install is three to five Sprints in series with shared infrastructure. The math: three Sprints at $6,000 each plus dashboard build and 90 days of monitoring lands around $20,000 to $35,000. Quoted higher than $50,000 for an SMB Install is usually an agency model that includes a slide deck and a project manager you do not need.
What you should not pay for: Hourly billing on production AI work. Hourly billing rewards the provider for taking longer. The work should be priced per outcome. Monthly retainers without a defined deliverable. Retainers create the wrong incentive: the provider gets paid for showing up rather than for shipping. Discovery decks that cost more than $1,500. A discovery deck is a slide version of a kickoff call. It is not an audit. A full "AI strategy" engagement that takes longer than 5 days and ends with a deck rather than a system. The deck is rarely worth what an audit costs and never worth what a strategy engagement costs.
What you should pay extra for: A provider who lives in your operations tools as a real user, not as an auditor. A provider who runs their own business on the same systems they are selling you. A provider who will tell you in writing that the engagement is the wrong fit, and walk away from the fee. Those are rare and worth the premium.
The math is unambiguous in this revenue band. A senior AI engineer in the New York metro area costs $200,000 to $260,000 in base salary, plus benefits, plus equipment, plus office overhead. All-in the loaded cost is closer to $300,000 to $340,000 per year. For a company in the $5M to $15M revenue band, that is between 2 percent and 7 percent of total revenue going to a single engineering seat. The seat does not pay back unless there are enough shippable systems to keep the engineer busy at the same density as a Sprint.
The honest answer for most operators in this band is that the company does not have 50 weeks of senior engineering work per year. It has 12 to 20 weeks of senior engineering work, concentrated into two or three focused initiatives. The other 30+ weeks of capacity sit idle, or get filled with maintenance work that a less expensive engineer could do, or get filled with strategic work the engineer should not be doing.
A fractional embedded FDE solves the math by sizing the engagement to the actual shape of the work. One Sprint per quarter plus an Install during a peak period equals 16 to 20 weeks of senior engineering across a year. At Sprint and Install pricing, the total annual spend lands between $40,000 and $90,000 depending on how heavy the year is. The same outcome (production AI systems running in the business) at a fraction of the loaded cost.
Above $50M in revenue, the math flips. At that scale you have enough work to fill a full-time seat, the maintenance burden of the existing systems justifies a permanent engineer, and the fractional model starts to leave value on the table. The right move at $50M+ is to hire the FDE full time, often by hiring the fractional FDE who has been embedded in the business for the previous 12 to 18 months.
Between those two ends, fractional wins. It is not a hack. It is the right shape of the labor for the actual size of the work.
The audit is the cheapest way to test whether the FDE model fits your business. Here is the exact structure I run for a new operator. Steal it.
Day 1 (60 minutes): Discovery call with the founder and the operations lead. Seven questions in order. What does a good week look like versus a bad week? Where does the founder personally spend time they wish they did not? What is the one bottleneck that, if removed, would change the trajectory of the quarter? What tools are already in use, and which ones does the team actively hate? What has been tried before that did not work, and what failed about it? Who on the team touches each workflow today? What is off-limits (a vendor relationship, a process the founder is attached to, a compliance constraint)? Output: a one-page write-up of what the team thinks the problem is.
Day 2 (3 hours): Workflow shadow. Screen share or in person if local. Follow one inbound lead from first touch to close, or one order from quote to fulfillment, depending on which workflow surfaced strongest on day 1. Count clicks. Note every place data gets re-entered, every place a decision waits on one person, every place a tool talks to another tool through a human. Operations leads have usually stopped seeing the leaks because they pay the cost daily. Output: a workflow diagram of the actual flow, not the official flow.
Day 3 (4 to 6 hours): Tools landscape map. Twelve to fifteen categories: CRM, email automation, voice, document processing, scheduling, inventory, payment, customer support, reporting, outreach, content, data storage, identity, and analytics. For each: what is in use, what it can actually do (not what the vendor claims), what it costs, and what it cannot connect to. The map surfaces the integration gaps before any code is touched. Output: a tools map with red, yellow, green coding by readiness.
Day 4 (4 to 6 hours): Leak ranking. Three candidates ranked by ROI per hour of build time. Each candidate has a dollar estimate calculated two ways (labor cost: hours per week times loaded hourly rate; revenue cost: leads or deals lost because of slow response or dropped handoffs). The third leak is usually a curveball: an opportunity nobody is looking at because nobody noticed it leaking. The ranking is honest. If candidate one is worth $40,000 a year in lost revenue, that is what gets written. If candidate two is worth $4,000 a year, that is also what gets written. Output: a one-page ranked leak board with build complexity ratings.
Day 5 (60-minute walkthrough): Deliver the 20-page PDF and walk the founder and operations lead through it. Recommend one of three paths: (1) build the top leak inside a Sprint, (2) take the report and have an in-house team build it, or (3) defer the engagement by 90 days because a precondition is not in place yet. The recommendation is specific. If the top leak has a blocker that I caught during the audit, I say so in the walkthrough, not after the operator has paid for a Sprint. Output: a binary decision the operator can make in the room.
The whole structure is built to make the buying decision cheap. The audit is $2,500 with a no fit, no fee guarantee. If the audit produces a path that the operator chooses to walk on their own, that is a successful outcome. If the audit produces a Sprint that the operator hires me to run, that is also a successful outcome. The only bad outcome is an audit that produces a vague deliverable that does not give the operator a clear next step. That outcome is on me.
One concrete case study from a current engagement. Names changed, numbers real. This is the Brooklyn paint distributor where I am embedded as the operating partner and the FDE at the same time, so the engagement is unusually deep, but the shape of the work is the same shape that runs at every Sprint.
Setup: A B2B paint distributor in Brooklyn. Five-figure monthly revenue at the time of engagement, with a clear path to mid-six-figure monthly revenue once outbound sales caught up to inventory and warehouse capacity. Two-person ops team. The founder ran sales. The operations lead ran the back office. The biggest constraint was not warehouse, not inventory, not even sales technique. It was outbound volume. The team could place 30 to 50 calls a week to contractors and property managers, and they needed to be placing 300 to 500.
What I saw in the first 5 days: The CRM had 8,000 leads sitting cold because nobody had time to call them. The salesperson was personally good at the conversation but could not scale. The contractors and property managers who picked up usually spoke English, Spanish, Russian, Polish, or Ukrainian, depending on the neighborhood, and the team only had two language coverage. The Friday afternoon call window was the highest-response window of the week and the salesperson was burned out by then.
What got built in the first Sprint (4 weeks): A voice agent stack. Inbound calls handled 24/7. Outbound calls scheduled by the agent against the cold lead list. Multilingual coverage across the languages the neighborhoods spoke. Calendar integration: qualified leads booked straight to the salesperson's calendar with the right context attached. CRM write-back so the salesperson saw what the agent had captured before the meeting. Failure alerting wired to Slack so the team knew within 2 minutes if the system was down.
What it replaced: The need to hire a multilingual SDR team. The labor cost of that team at NYC payroll rates would have been the entire profit line of the business in year one. The voice agent stack runs at less than one tenth of that cost and handles a higher call volume than a 4-person SDR team would have.
What broke in the first 30 days: Three things. A vendor API rate limit that the documentation said was 1,000 calls per minute and was actually 100. Fixed by adding a queue. An accent-handling edge case in one of the languages that mis-routed about 4 percent of calls. Fixed by switching to a different voice provider for that language. A scheduling conflict where the agent booked two leads into the same calendar slot during a brief window when the calendar API was returning stale data. Fixed by adding a 90-second buffer plus a write confirmation step.
What surprised me: The biggest unlock was not the voice agent. The biggest unlock was that the founder got his time back. With outbound covered, he stopped being the person on the phone all day and started being the person closing the bigger contractors and onboarding the partner yards. Revenue moved because the founder moved up the value chain. The voice agent was the lever. The founder's time was the load.
What I would do differently: I would have started the multilingual coverage with three languages instead of trying for five on day one. The first 30 days of operating in five languages exposed too many edge cases at once. Three languages would have shipped a working system in week 3 and added the other two in weeks 5 and 6. Lesson: scope by edge case count, not by language count.
Two other case studies in similar shapes run at a stone distributor in Ohio (where the constraint was quote turnaround, not call volume) and a photo-mosaic e-commerce brand (where the constraint was customer support deflection and review monitoring on Amazon and Etsy). The shapes of the engagements are different. The shapes of the operating model are identical: embed, watch for a week, ship daily after that, hand off to an internal owner, exit cleanly.
If you are an operator at a $5M to $50M business and the description above sounds like the role you have been trying to hire for, the cheapest next step is a 30-minute call. The call is not a sales call. The call is the diagnostic for whether the audit is the right next step or whether you should be doing something else first.
On the call I will ask the same questions that the audit kicks off with, get a sense of whether the three readiness signals are in place, and either book the audit or tell you what the better next step is. If the better next step is to spend 90 days hiring an operations lead and then come back, I will say so. If the better next step is to spend $5,000 on customer research instead of automation, I will say so. The call is free. The audit is $2,500 with no fit, no fee. Most operators who book the call book the audit. The ones who do not book the audit usually get a clearer next step than they had before the call.
Ready to find out if the embedded FDE model fits your operation?
Book a 30-minute callThree pain hypotheses and three quick fixes tailored to your operation, in under a minute. Tells you whether the full $2,500 audit is worth the spend. Run the free audit.
I shadow your operations for 5 days, rank your top three leaks with dollar estimates, and hand you a 20-page PDF with a specific recommendation. No fit, no fee. Book a 30-min call to start.
One production system built, shadow-tested, documented, and handed off to a named internal owner. Includes 30 days of post-handoff support. Sprint details on the FDE services page.
Multiple production systems across sales, ops, and customer surfaces. One reporting dashboard. 90 days of post-handoff monitoring. Full Install details here.
A Forward Deployed Engineer (FDE) embeds inside one operation, watches the work happen, and ships running systems on the customer side. The title originated at Palantir, then spread to OpenAI and Anthropic. For SMBs in the $5M to $50M revenue band, the same role looks like a senior engineer who lives inside one or two of your tools (CRM, Slack, the inbox), watches three days of real operations, and starts shipping code by the end of week one. The deliverable is a system running in production, not a deck.
A consultant writes a recommendation. An agency hands you a junior team and a project plan. A Forward Deployed Engineer writes the production code, deploys the infrastructure, integrates with the existing stack, fixes what breaks during the first month live, and trains the customer team to run it without him. Same person from week one to handoff. No subcontracting. The unit of work is a running system with a measurable outcome, not a billable hour.
$5M to $50M in annual revenue is the sweet spot. Below $5M, off-the-shelf tools (HubSpot AI, Notion AI, ChatGPT Team) usually cover the obvious leaks, and the math on custom work does not pay back fast enough. Above $50M, you can justify a full-time AI engineering team at $300K+ all-in and you probably should. The middle band has enough operational complexity to benefit from production AI, but cannot absorb a full-time senior engineer plus overhead.
$2,500 flat for a 5-day Audit with no fit, no fee. From $5,000 for a 4-week Sprint shipping one focused system in production. From $20,000 for a Full Install covering three to five systems across sales, ops, and customer-facing surfaces over 8 to 14 weeks. No retainer, no hourly billing. If a second Sprint is needed after handoff, it is a new statement of work. The pricing structure on the Forward Deployed Engineer services page mirrors what is in this post.
Three anti-cases. Your core operation runs on a legacy on-premise ERP with no public API: the integration work alone breaks the 4-week Sprint container. You have one founder making every decision and no operations lead: the FDE has nobody to embed with and the system has no internal owner after handoff. You are looking for a strategy deck or a board-ready slide: that is a consultant deliverable, not an FDE deliverable. In all three cases, the engagement burns money and produces no working system. Section 7 above covers six anti-cases in full.
Fractional is a billing model: you get a senior person part time instead of full time. Embedded is an operating model: that person lives inside one or two of your tools, attends standups, sees real data, and ships code without a long approval cycle. The two stack. An embedded fractional FDE is in the room (or in Slack) every business day, but at one to two days of capacity per week instead of five. That is the right shape for a $5M to $50M operator who needs senior engineering decisions made fast but cannot pay $300K plus benefits.
Whatever is leaking the most cash with the lowest fix cost. In a typical first 30 days the FDE kills: one manual report that takes 45 to 90 minutes per day, one inbound lead handoff that drops 25 to 40 percent of leads on the floor, and one approval workflow that adds 2 to 4 days to every quote. None of these require new AI tooling. They require a senior engineer who can write 200 lines of code, wire two APIs, and ship before the next standup. Section 5 above documents three real anonymized cases.