From Three Roles to One Forward-Deployed Engineer

A few months ago, we changed how we deliver on a few projects. We dropped the complex team structure, gave our best people AI, and put them right next to the business.

For one client, two projects three years apart show the difference. The video above is the full story. This is the written version, with the same diagrams.

Same Client, Three Years Apart

In 2023, we added one big component to the platform and updated part of the backend. It took about six months and 1,300 hours.

This year, for the same client, we rebuilt the whole platform: the whole ecosystem, new features, over 90% test coverage, documentation and automations. It took about the same time, under seven months, and under 2,000 hours.

By our estimate, that’s at least five times the scope for about 1.5 times the hours. The difference wasn’t a bigger team.

Why We Built Around One Person

Our closest long-term client relationships had something in common. Usually, one person led the project. They wore many hats, took responsibility and kept their focus on what the business needed. Clients loved working with them, especially the ones who couldn’t afford a big dev team.

These people:

• solved problems instead of waiting for tasks;
• asked for context instead of building blind;
• learned to work across product, infrastructure and business.

The only thing holding them back was time: time to learn, to build more and to ship faster.

What AI Changed

Learning a new tool used to eat that time. Now it doesn’t. You don’t need to master Figma to build a working prototype. You don’t have to cut corners on test automation, or trade quality for features: you can have both, with far less overhead.

That let our best people speed up a lot and ship more, at a quality most of our clients couldn’t get before. So we made it how we deliver.

What We Mean by a Forward-Deployed Engineer

Palantir started sending engineers to work right next to their customers, and called them forward-deployed engineers. For us, an FDE is a senior engineer who talks to the business, takes the problem, builds the solution and stays on the team. The earlier video covers the role in full.

At Brival, an FDE is:

• Full stack: hands-on experience across backend, frontend, mobile and infrastructure.
• Fluent with AI across the whole delivery process: gets much more done with it, without losing quality.
• Trained in product: understands the business, prototypes and shapes the product.
• Never on their own: our wider team has specialists in specific domains, so the tough calls always get a second opinion.

How a Project Worked Before

Every step had its own role:

• The product manager met with the product owner, who ran discovery.
• The designer worked on layouts, and the three of them iterated.
• The architect laid out the architecture and handed it to the dev team: backend, frontend and mobile.
• The dev team wrote the software.
• Quality assurance built the tests, automations and documentation, and the work shipped.

Before: a role for every step, and a hand-off between each.

And it worked. Many people did different things, and with the right coordination, it clicked. But every idea had to pass through several people before anyone could see it working.

How It Works Now

In this engagement, the FDE is an engineer with over 15 years of experience. He works on the project part-time, leads three full-time developers and is the product manager’s direct contact.

A typical loop:

1. The product manager meets with the engineer.
2. The engineer builds a prototype, sometimes in the existing codebase, on a side branch.
3. The next day, they walk through it together and change the prototype live.
4. The engineer brings in other specialists, but only if needed. He also talks to the testers and answers the team’s product questions, because he’s the closest to the business.
5. A few days later, it’s delivered, and quality assurance does a final check. Most of the testing happened during development: unit tests, end-to-end tests and documentation.
6. It ships, and the loop is closed.

Now: the product manager works with one engineer, and specialists join only when needed.

Three Roles in One

In practice, the engineer covers three roles, and part of a fourth:

• Product owner on the dev team’s side.
• Designer, helping the product manager turn ideas into the product.
• Architect and full-stack developer, advising on the approach and delivering at high quality.
• Part of the dev team’s work, too.

That changed the team around him. We dropped the dedicated technical product owner role. Prototypes now come from product or from developers, not from designers. And with fewer people to keep in sync, the project management needed to keep all those open loops in check shrank on its own.

We’ve tried this on a few projects now, of different sizes and with different teams.

What It Solved

Four problems, each with a before and a now:

1. Rare people meant bigger teams. People like this are hard to find, and the ones you had were busy in one area, so you needed a bigger team, which cost a lot. Now, one engineer covers several roles, and AI gives them the time to do it.
2. Ideas took days to become demos. Every idea went through product, design and engineering. Now, the whole spec, with prototypes, wireframes and a doc, is done in a week.
3. Developers built the wrong thing. They only got tasks, so they didn’t ask enough questions. Now, the person building it asks why and helps shape the idea. They have the most context, so they’re the right person to build it.
4. Answers came back slow. PMs often just passed messages between product and the developers, and answers came back slow and half-explained. Now, you talk directly to the person who builds it.

Two Ways to Do It Right

Building software properly takes product, design, architecture, development, data and quality assurance. There are two ways to cover all of it:

• a wide team, with a person for each, or
• a small team of exceptional people who still cover it all.

The small team goes a little less deep on each subject. But consistency across every stage, and no communication gaps, pay off anyway, especially in smaller organizations.

The Catch

It only works with someone who has years behind them, and there aren’t many people like that. That’s why we only run a few pilots at a time.

AI also moves fast, so this may look different in a few months. For now, this is how we work.

Try It on One Problem

We start with a 3-day pilot: one engineer, one problem you pick, for $3,000. You only pay if you keep the work. The details are on the forward-deployed engineer page.