Get closer to
the real work.

The brief says “build a tool.”
The work says something else.

A team asks for a dashboard. Spend a morning with them and you may find that the numbers disagree because three people enter the same information in three places. A nicer chart will faithfully display the confusion.

That is the kind of gap a forward deployed engineer should notice. Forward Deployed Engineering, or FDE, means putting engineering close to the customer’s actual work: understanding the problem, building the solution, and staying involved as it reaches production and gets used. FDE also names the person doing it. The precise role varies by employer.

In OpenAI’s description of the role, that responsibility runs from discovery and system design to production rollout, with field feedback informing the product. The important part is that the person learning what is wrong can help change the software.

There is overlap with consulting, product engineering and solutions architecture. Titles do not settle the difference. Ask whether the team owns implementation, learns from real use and leaves behind something that works. “Forward deployed” should describe that responsibility, not simply where someone’s desk sits.

Companies are putting people
and money behind it.

This is no longer a role associated with one company. As of this article’s review, OpenAI is recruiting FDEs to carry work from discovery through production rollout. Anthropic is recruiting them to build applications inside customer systems with Claude. Both descriptions combine engineering with customer-facing judgment.

On June 30, 2026, AWS announced a dedicated FDE organization backed by a $1 billion investment, with plans to embed thousands of engineers and extend the approach through partners. That is an announced commitment, not a count of completed hires.

These are concrete hiring and investment signals. They do not prove an industry-wide growth rate, a universal talent shortage or a guaranteed career path. They do tell us that major technology companies are investing in the distance between a capable model and a useful operation.

Fewer handoffs.
Better questions.

The potential value of FDE is a shorter path between discovering a problem and testing a response. An operator can show the exception that breaks the happy path. An engineer can change it. Both can see whether the change helped.

The result should be measured in the work itself: time to finish an intake, errors that require rework, questions resolved, adoption after the launch meeting, or the effort needed to correct a mistake. Pick a baseline and a useful test before celebrating the new system. Those are measures to agree, not savings we can promise from a job title.

There are failure modes, too. An embedded engineer can become a permanent workaround for a brittle product. A rushed deployment can leave nobody else able to operate it. A dedicated team can be an expensive answer to a problem a standard tool already solves. FDE earns its place when uncertainty, integration and the consequences of getting the workflow wrong justify that proximity.

Technical depth.
A wide field of view.

The current OpenAI and Anthropic roles ask for production engineering, experience with language models, clear communication and sound decisions under ambiguity. Our own filter puts that combination into practical terms:

• Build beyond the demo. Work across interfaces, APIs, data and deployment. Read unfamiliar code. Test it, monitor it, and make recovery possible.
• Learn the operation. Ask the person doing the work to show you. Notice the spreadsheet, the missing connection, the approval nobody mentioned and the exception that happens every Friday.
• Exercise product and design judgment. Separate the request from the need. Make the next action understandable. Know when buying, simplifying or removing something beats building it.
• Use AI with discipline. Understand model limits, retrieval, evaluation and the cost of a wrong answer. Decide what needs a person’s approval and what should remain deterministic code.
• Work across people and disciplines. Explain a trade-off to an engineer, a director and a field worker without changing the truth. Respect language, context and the expertise already in the room.
• Leave the work legible. Document decisions, define ownership and teach someone else to run what you built. Being indispensable forever is a poor handover plan.

No single person needs to be the strongest specialist in every discipline. They do need enough depth to deliver and enough humility to know who else belongs on the team.

Keep the proximity.
Widen the responsibility.

We like what FDE insists on. We also think Mutiny can take that way of working further for the organizations we serve.

A vendor’s FDE team usually starts with a platform it knows deeply. That depth can be exactly what a customer needs. Mutiny’s starting point is the organization’s decision: what should exist, what should change, and which combination of tools and people can make it useful? Sometimes the answer uses AI. Sometimes it is an operational application, a better public experience, a connection between existing systems, or a decision not to add software.

Our work brings innovation strategy, experience design, software engineering, applied AI, interactive storytelling and ongoing operations into the same conversation. A cultural archive needs editorial judgment as well as search. A service platform needs a clear experience for the public and a workable process for the team behind it. Neither fits neatly inside a single vendor’s feature list.

Established FDE teams also care about outcomes, collaboration and customer independence. We are not claiming to have invented those standards. Our bet is that a senior-led, cross-disciplinary studio can combine them with the freedom to choose the right approach across platforms, and carry that coherence from strategy into daily use. Better has to be demonstrated in the work. It cannot be awarded by the headline.

Decide it. Build it.
Keep it working.

That is already how our services are organized. An organization can enter where it needs us; it does not have to buy all three.

Fractional CIORetainer or hourly

Chief Innovation Officer leadership. A senior partner joins the leadership table to pressure-test priorities, align people and make the difficult decisions, with accountability through delivery.

ProjectsFee-for-service

A defined innovation outcome turned into a working capability. We scope, design, build, ship and measure the work, then transfer it to the people who will use it.

Product stewardshipMonthly retainer

Adoption, maintenance and improvement after launch. Onboarding and playbooks, monitoring and updates, restore checks and a shared backlog, delivered on an agreed cadence and within defined capacity.

I lead the engagement personally, with specialists assembled around the work: engineering, creative direction, product design or 3D when the experience calls for it. The team changes with the problem. The senior responsibility does not disappear into an account-management layer.

The method has five moves.

Our published process is deliberately plain. Each stage should make the next decision better informed.

1. Sense

   Pressure-test the brief. Find the real problem, with the people who live with it. Understand the constraints before choosing a solution.

2. Frame

   Shape three sharp bets. Consider build, buy and partner. Decide what is worth testing and what evidence would change the decision.

3. Prototype

   Put working code in users’ hands. Our published process targets that by week three; the Projects service describes roughly six-week sprints. Scope and access requirements belong in the agreed plan.

4. Pilot

   Use it with real customers. Measure what happens. Make a decision to continue, change course or stop; a pilot is useful even when it disproves the first idea.

5. Hand off

   Document and transfer a capability the team can run. Agree who owns it, how people learn it and what support follows. Continuing improvement has a home in stewardship.

The boundaries matter: product stewardship is not a help desk, managed IT or round-the-clock emergency coverage. Inherited platforms are considered after a paid technical review. “Stay involved” needs a scope, not an unlimited promise.

The constraints are
where the design starts.

These projects were not built to illustrate a job title. They show the kind of work we mean.

Rimas: what happens when the connection disappears?

For Fundación Rimas, we built enrollment, consent and survey workflows that can capture work offline and synchronize when signal returns. Personal information is separated from pseudonymized analytics, with distinct access roles. The field conditions shaped the architecture. Read the Rimas case →

PSI: what happens after someone presses Send?

For Platform for Social Impact, the public website connects to an operations layer where submissions become tracked, assignable work, with status, ownership, notes and an audit trail. The experience includes the team responsible for answering, not only the person filling out the form. Read the PSI case →

La Voz del Centro: who can correct the machine?

The archive has a recurring pipeline for transcription, annotation and search, with answers linked back to the recording. Its host can describe a correction in Spanish, inspect the proposed change, apply it and undo it. The domain expert has a usable way to challenge the system. Read the archive case →

These delivery choices make our standard inspectable: the tool should fit its setting, respect its users and remain correctable.

The next brief might not
have a name yet.

Some of the work ahead will not arrive as a neat software category. A new capability will meet an old constraint, and somebody close to the problem will see a possibility the rest of us missed.

We want partners willing to explore that with us: leaders who will question the brief, let us work with the people doing the job, test something real and change course when the evidence asks for it. Agencies, institutions, founders and other specialist teams can bring something we cannot supply alone. The point is to raise the bar together.

The unknown is a reason to experiment carefully. Give the experiment a boundary, define what we need to learn, and decide what may reach real users. We can challenge an industry’s habits without making the people who depend on it carry an unexamined risk.