What to expect from a forward-deployed engineering team

On June 30, 2026, Amazon Web Services said it would put $1 billion into a forward-deployed engineering unit. Teams of five or six engineers work inside a client company for about 45 days, and the client is supposed to be able to run the result on its own afterward. If you are considering one of these teams, from AWS or anyone else, three things are worth knowing in advance: what the engineers will build, what you will own at the end, and what you will be able to do once they have left.

What the engineers will build

Forward-deployed engineers work inside your business, so most of what they build is specific to it. On an ERP project covering finance, procurement, inventory and order management, they will configure workflows, write integrations, fix inconsistent data and code up rules that only your company uses.

The vendor gets something out of this too. A problem that shows up at one client tends to show up at the next, and a vendor that pays attention turns those problems into product: business rules you can configure, integrations it can reuse, data checks that run automatically. That takes cooperation inside the vendor. The engineers report what keeps recurring. Product managers decide which of those problems are common and which belong to a single client. Engineers build the common ones as features with automated tests, and the vendor tracks whether customers use them and whether later projects need less custom work. Anything particular to your company stays particular to you unless there is a reason to share it.

For you, the benefit is that the vendor's tenth project goes faster than its first. A vendor with this loop can add clients without adding engineers at the same rate. One without it has to hire engineers for each new client.

What you should own

The hard part of these projects is turning a business process into software that works and that someone else can maintain. AI tools write code faster than people do, but the project still needs people who understand the process, the architecture and security, and who answer for the system once it is live.

When nobody is clearly responsible, companies find they cannot change their own systems without calling the vendor back, even for small fixes. Gartner predicts that by 2030, half of enterprises will face delayed AI upgrades or higher maintenance costs because of unmanaged generative AI technical debt.

Split the duties in writing. The vendor designs the architecture from your requirements, builds the integrations, checks the business logic, sets up automated tests, writes the documentation and trains your staff. You own the requirements, the process decisions, the definition of acceptable work, your data and who can access it. You also own the resulting software, including the right to run and extend it with your own people or another provider. Put this in the contract, and make sure the architecture and the access permissions match what the contract says.

The code and what you hold at handover

Code written by AI needs review, testing and security checks, the same as code written by people. Veracode tested more than 100 models in 2026 and found that their code passed security tests about 56% of the time on average when no guardrails or human review were in place. Ask the vendor how it checks AI-generated code before that code reaches production.

At handover you should hold your business rules, integrations, deployment pipelines, documentation and test suites. Ask which parts of the system depend on the vendor's proprietary tools, and what it would take to leave. The system should also fit your processes, controls and regulatory obligations. You should not have to change how your company works to suit the vendor's method.

What to agree before work starts

Settle the measures first, track them during the project and check them again after handover: implementation time against a documented baseline, cost per delivered capability, defect rates and reliability in production, the share of components that can be reused, and how long later enhancements take. Standard benchmarks rarely fit, so set targets from the project's complexity, its risk and where you are starting.

Then find out whether you can manage without the vendor. After handover, your staff should be able to make routine changes, release updates, diagnose failures and keep the system running. A good check is to have a team that did not build it do those things. Financial results show up in realized business benefits, total cost of ownership and time to return on investment. Estimated productivity gains do not count as evidence of any of these.

All blogs