AI & Automation

In House or Fractional: How to Buy Forward Deployed Engineering

The work is intense and finite, which is exactly the shape a full time hire fits badly. What each model costs, and the handover clause that decides whether fractional works.

Mauricio Esparza By ·Published ·2 min read
mithub.club
Short answer

Forward deployed work is intense and finite: it ends when the system runs and somebody else can operate it. That shape fits a full time hire badly and fractional well. Hire full time when you will have a continuous stream of deployments. Buy fractional when you have one or two, and make the handover a deliverable rather than a hope.

A full time employment relationship does not have that shape. That mismatch is the decision.

When full time is right

You can name the next three deployments. Several locations, several products, a roadmap of integrations that will not run out.

The knowledge has to compound internally. Each deployment teaches something about your business that the next one uses.

You can absorb the between times. There will be gaps between projects. If those gaps are filled with useful work, full time is efficient. If they are filled with looking for work, it is not.

When fractional is right

One or two deployments in view. You have a specific thing that does not work, and you do not know whether there will be a third.

You need to start now. Hiring for this profile in this market commonly takes about three months. A stalled rollout does not wait a quarter.

You are unsure of the shape. A fractional engagement is a cheap way to learn what the role should be before committing to a salary.

The real comparison

Not monthly cost. Cost per deployment completed and handed over.

A full time engineer between projects is expensive in a way that never appears on an invoice. A fractional engineer who never hands over is expensive in a way that appears every month, forever.

The clause that decides whether fractional works

Make the handover a deliverable with a date, not a promise at the end:

  • A runbook that an internal person has followed successfully, not just received
  • Credentials and access that survive the engagement ending
  • A named internal owner from week one, who participates rather than waits
  • Documentation written during the build, not compiled afterwards

If a provider is uncomfortable with that clause, you have learned something early and cheaply.

The hybrid that works in practice

Fractional engineer builds and documents. Internal person owns and operates, shadowing during the build rather than receiving at the end.

Knowledge transfers by participation. A handover meeting transfers a document and very little else.

The question to ask either way

What will exist when this ends, and who runs it?

Anyone whose answer is a support retainer is offering you a dependency. That can be a reasonable purchase, but you should price it as one rather than discover it later.

Frequently asked questions

Is fractional cheaper?

Per month usually, and that is not the point. The real comparison is cost per deployment completed and handed over. A full time hire between projects is expensive in a way that never appears on an invoice.

What is the biggest risk with fractional?

That nothing is handed over and you end up renting access to your own system. Make the handover a deliverable with a date, not a promise at the end.

How do we avoid losing knowledge?

Documentation written during the build rather than at the end, and an internal owner named in week one who shadows rather than receives. Knowledge transfers by participation, not by handover meeting.

When is full time clearly right?

When you can name the next three deployments. If you cannot, you are hiring for a queue that may not exist, and the person will spend their second quarter looking for work inside your company.

Sources

  1. Building effective agents · Anthropic (accessed 2026-09-22)
  2. Handle errors gracefully · n8n Docs (accessed 2026-09-22)
  3. New Lightcast Report: AI Skills Command 28% Salary Premium as Demand Shifts Beyond Tech Industry · Lightcast (accessed 2026-09-22)
AI & AutomationHiringProcurement
Mauricio Esparza
Mauricio EsparzaGTM Systems Lead · Revenue Engineer · Founder of MitHub. Designs and runs revenue systems for multi-location businesses: AI voice campaigns, enrichment, CRM automation and attribution. Founded MitHub to teach the method in the open.

Part of AI & Automation on MitHub.

Keep going

AI & Automation

When to Hire a Forward Deployed Engineer

The buyer's view of the forward deployed engineer: the problems that need someone embedded in your systems, how the engagement is scoped, and how to tell a real one from a consultant with slides.

Read · 3 min →mithub.club
AI & Automation

Forward Deployed Engineer vs Consultant vs Professional Services

Three ways to buy implementation help, told apart by what each is accountable for, what you own at the end, and which one fits a rollout that has already stalled once.

Read · 2 min →mithub.club
GTM Engineering

GTM Agency vs In House vs Dedicated Talent: The Real Comparison

Three ways to buy go to market execution, what each actually costs once you include the parts nobody quotes, and the third option most comparisons leave out.

Read · 2 min →mithub.club
Revenue Engineering

Who Owns an Automation After It Goes Live?

The question nobody answers when the build finishes: who monitors it, who fixes it when an API changes, who approves changes, and what happens when the person who built it leaves.

Read · 2 min →mithub.club
AI & Automation

Our Vendor's Implementation Stalled. Who Finishes It?

The software is paid for and the rollout stopped. Why it happens, what is usually left undone, and the four ways out with what each one costs.

Read · 2 min →mithub.club
Remote Work

What GTM and Forward Deployed Talent Costs in Latin America

Cost for the specific roles, not for developers in general: what moves the number for GTM engineers and forward deployed engineers, what the quote leaves out, and the comparison that decides it.

Read · 3 min →mithub.club