Sarah runs a growing logistics company. She's heard that a forward deployed engineer can ship fast, embed with her team, and build exactly what she needs without the overhead of a traditional agency. What she can't figure out is how many to hire. One seems risky — what if the project is bigger than one person? Two seems expensive . she's not running a tech company, she runs a trucking company. Three seems absurd. But her ops director is already talking about "a pod."
This confusion is normal. The FDE world doesn't have clear org charts. Palantir famously deployed engineers in pairs, but they were selling to governments with billion-dollar budgets. A regional manufacturer with eighty employees doesn't need Palantir's playbook. It needs a fde team structure that matches its actual problems.
Here's the practical truth: one embedded engineer is enough for most first engagements. You add people when the work forces you to, not because it sounds impressive in a kickoff meeting.
The Solo FDE Sweet Spot
The solo FDE thrives on constraints. One user group to serve. One workflow to optimize. One painful moment to eliminate. Give a good FDE that clarity and they'll ship something valuable in weeks.
A typical solo engagement looks like this: an FDE embeds with a manufacturing client's operations team. They discover that inventory tracking lives in seventeen spreadsheets. They build a single source of truth in Postgres. They add a lightweight dashboard. They train two people to maintain it. The engagement lasts eight weeks. The client pays roughly $20K. The FDE's total output is one working system, documented, handed off, and loved.
Solo FDEs are generalists by necessity. They talk to users, write code, design interfaces, and debug production issues. This generalist advantage is actually a feature at small scale. Communication overhead is zero. Decisions happen in real time. There's no standup meeting because there's no team to stand up.
The solo model works when the scope fits in one brain. That usually means: one primary user group, three or fewer systems to integrate, and a timeline under three months. If your problem fits inside those boundaries, hire one great FDE and get out of their way. For a deeper look at what this role actually does day to day, read what a forward deployed engineer actually does. If you're on the hiring side, our guide on how to hire a forward deployed engineer covers the interview questions that actually predict success.
When One Is Not Enough
Solo FDEs hit a wall when the work goes parallel. Parallel means two departments need attention at the same time. It means the data pipeline and the user interface both need serious work in the same week. It means the FDE is context-switching so often that nothing gets deep focus.
I watched this happen with a retail client. The solo FDE was brilliant — she built a vendor portal in week three that saved the procurement team ten hours a week. But the warehouse team also needed a dispatch scheduler. And the leadership team wanted a unified dashboard. By week six, the FDE was spending two hours a day in status meetings just to keep three stakeholders informed. Her coding time dropped to four hours daily. Velocity collapsed.
The warning signs are predictable. The backlog of validated requests exceeds three weeks of solo capacity. Stakeholders start competing for the FDE's attention. Small bugs linger because there's always a louder priority. The FDE starts saying "next sprint" to everything.
When these symptoms appear, you've outgrown the solo model. The question isn't whether to add people. It's how many, and in what configuration.
The Two-FDE Pod
The most common expansion is from one to two. A two-FDE pod isn't double the cost for double the speed — it's more than double the speed because communication overhead between two people is still minimal, and work can split cleanly.
There are two ways to split the work. The domain split: one FDE owns data pipelines, integrations, and backend systems. The other owns user interfaces, dashboards, and frontend workflows. This works well when the project has clear technical boundaries and both engineers can operate independently.
The phase split is different: one FDE prototypes while the other productionizes. The prototype FDE ships fast, breaks things, learns what users actually need. The production FDE cleans up the code, adds tests, hardens the deployment, and documents the system. This rhythm is common in agencies and consultancies where one person is wired for speed and another for stability.
A two-FDE pod typically costs $30-45K monthly — roughly twice the solo rate, but with faster delivery on parallelizable work. The economics make sense when the engagement has multiple workstreams that don't block each other. Two people working on independent tracks finish faster than one person alternating between them.
The hidden advantage of the pod is resilience. If one FDE gets sick, takes vacation, or rotates to another project, the other can keep momentum. Solo engagements freeze when the soloist is unavailable. Pods keep moving.
The Full Embedded Team
Some projects outgrow even a pair. Multi-quarter builds with complex requirements, multiple user groups, and significant design needs may warrant a full embedded team. This usually means a product manager, two FDEs, and a designer — four people total, embedded at the client site or working as a dedicated remote unit.
The PM handles stakeholder communication, requirements gathering, and timeline management. The FDEs split technical work. The designer ensures the interface doesn't look like it was built by engineers — which, let's be honest, most engineer-built interfaces do. Companies building core operational software, with tools used daily by dozens of employees, typically need this level of support.
A full embedded team runs $60-80K monthly. That's serious money. It only makes sense when the software being built is mission-critical and the alternative is a failed off-the-shelf implementation or a six-figure agency engagement that delivers slides instead of code.
Most companies never need this level. The full team is for organizations that have already proven the value of embedded engineering and are ready to treat it as a strategic investment rather than an experiment.
The Hybrid Model
The smartest pattern I've seen is the hybrid: start solo, expand conditionally. The first FDE arrives for discovery and quick wins. They ship something valuable in month one. They map the full problem space. They validate that the client is ready to work with embedded engineers — which, despite the pitch deck, not every organization is.
If the engagement succeeds and the backlog justifies it, you add a second FDE in month two or three. The first FDE briefs the second. Work splits naturally along lines the first FDE discovered. The client funds the expansion because they've already seen return on the solo investment.
This model minimizes risk for both sides. The client isn't committing to a pod before they know if embedded engineering works for their culture. The FDE isn't managing a team before they understand the problem. And the budget grows incrementally, tied to demonstrated value.
The funding milestone is usually clear: when the backlog of validated, scoped requests exceeds three weeks of solo capacity and the client is asking for things faster than one person can deliver. That's the moment to propose the pod. Not before.
Sizing Decision Framework
If you're deciding between solo and team, ask three questions. Be honest. The answers don't lie.
How many user groups? One group — one set of people with shared needs . is solo territory. Two groups with different needs might fit one FDE if the work is sequential. Three or more groups operating simultaneously usually needs a second engineer.
Systems to integrate? Three or fewer systems to integrate is comfortable for one person. Five or more systems, especially if they include legacy databases or APIs with poor documentation, will swallow a solo FDE's entire capacity in integration work alone.
Speed requirements? If the board needs a demo in four weeks, one FDE can probably deliver. If the board needs three working systems in six weeks, you need parallel work and that means more people. Speed requirements are the hardest constraint because they're non-negotiable.
There's a fourth question that's harder to quantify but equally important: how much organizational complexity exists? A company with three layers of approval for every UI change will slow down any FDE, solo or team. Adding engineers doesn't fix process drag. Sometimes the right answer is one FDE and a mandate to streamline decisions.
If you're curious about the work that doesn't show up in timelines but makes or breaks these engagements, read about the hidden work of embedded engineers. And if you're wondering whether a generalist can really handle the technical breadth, our piece on why generalists thrive as FDEs explains why the solo model works despite, or perhaps because of, the jack-of-all-trades nature of the role. For the first-month playbook that sets solo engagements up for success, see FDE onboarding in the first 30 days.
Sarah ended up hiring one FDE for her logistics company. Eight weeks later, she had a working dispatch dashboard and a warehouse alert system that prevented two stockouts in the first month. Her ops director stopped talking about pods and started talking about what to build next. That's the test. Not the org chart. The outcomes.