AI decisions Sourcing: build, buy or partner
Forward deployed engineers or a project-based consultancy: how should you bring in outside AI help?
Bring in forward deployed engineers when the value depends on wiring AI into your own systems, data and processes and the hard part is getting it to work in daily operation; choose a project-based consultancy when the scope is clear, the integration is light and you mainly need a defined deliverable. Many failed pilots come from using the project model for work that needed embedded engineering. Either way, the engagement should end with your team able to run what was built.
The options
Forward deployed engineers
External engineers work inside your teams, on your systems and data, building and adapting the solution until it runs in production, then hand it over.
Project-based consultancy
An external firm takes a scoped project, designs and builds it largely with its own team and processes, and delivers it at the end of the project.
Side by side
| Criterion | Forward deployed engineers | Project-based consultancy |
|---|---|---|
| Where the work happens | Inside your teams, systems and tools | Mostly in the firm's own team, with checkpoints with yours |
| Best for | Integration-heavy cases with messy, real data and processes | Well-defined scopes with stable requirements |
| Path to production | Built in the target environment from day one | Often a separate step after delivery, sometimes by another team |
| Knowledge transfer | Continuous, because your people work alongside | Concentrated at the end, through documentation and handover sessions |
| Demand on your organisation | High: access, decisions and people available every week | Lower day to day, higher at milestones and acceptance |
| Commercial model | Usually time-based, with outcome milestones | Usually fixed scope and price, with change requests |
| Main risk | Endless engagement if the exit is not planned | A deliverable that works in a demo but not in operation |
Choose Forward deployed engineers when…
- Several pilots worked in a demo but none reached daily use.
- The value depends on connecting AI to your ERP, CRM, documents, permissions and identity.
- Requirements will only become clear once real users try the system.
- You want your own team to learn by building, not by reading a handover document.
Choose Project-based consultancy when…
- The scope, data and interfaces are well understood and unlikely to change.
- The deliverable is mostly self-contained: an assessment, a strategy, a model or a standalone tool.
- You cannot give an external team regular access to people and systems.
- You need a fixed price and scope for budget or procurement reasons.
When to combine them
A common pattern is to scope with a short, project-style phase (use case, data readiness, risks and success metrics) and then build with embedded engineers until the solution runs in production. What matters is that the second phase lives in your environment, with your people, and that the exit is written in from the start.
Common mistakes
- Running a fixed-scope project for a case whose real requirements only appear in production.
- Embedding external engineers without a client-side owner who will take the system over.
- Measuring the engagement by deliverables instead of by use in daily operation.
- Leaving code, evaluations and documentation outside your repositories.
- Not planning the exit, so the embedded team becomes permanent by default.
How Thinkia approaches it
We are a consultancy, so read this with that in mind. Our view is that most enterprise AI value sits in integration and adoption, which is why we work as one team with yours, inside your systems, until the solution runs in daily operation.
We design the exit from the start: code and documentation in your repositories, evaluation sets you own, runbooks and a dated handover. When a scope is clear and self-contained, we say so and propose a defined project instead.
Our products help when they fit, not as a condition: Pulse to keep AI-assisted software development governed and traceable, and Synapse when you want to own a governed AI layer without building it from scratch. We are vendor-agnostic on models and clouds.
Thinkia products involved
- SynapseGoverned agentic platform: agents, models, costs and data in one place.
- PulseGoverned AI-SDLC: signable specs, AI-BOM traceability, auditable delivery.
- The MeshThinkia's five service layers: Innovation, Data, Experience, Platform, Autonomy.
Related AI solutions
Frequently asked questions
What is a forward deployed engineer?
A software engineer who works inside the client's organisation, on its systems and data, until a solution runs in production. The model was popularised by Palantir and is now common among AI companies, because connecting AI to real systems is where most projects stall.
Is a forward deployed engineer more expensive than a consultancy project?
Per week it can look similar or higher, because the work is senior and hands-on. The comparison that matters is cost to a system in daily use: a cheaper project whose output never reaches production is the more expensive option.
How long should an embedded engagement last?
As long as it takes to get a first use case into daily operation and your team able to run it, with a dated handover. If there is no planned end, treat it as a warning sign.
Who owns the code and the know-how?
You should. Ask for code, prompts, evaluation sets and documentation in your repositories from day one, and for your people to build alongside the external engineers.
Can we start with a project and switch to embedded engineers?
Yes, and it is often the right sequence: a short scoping phase to choose the case and check data readiness, then embedded engineering to build it in your environment.
Keep exploring
Related decisions
- In-house team, AI consultancy or platform: who should build your AI?
- AI pilot vs production: what actually changes when you scale?
- Build vs buy AI agents: which agents should you own, and which should you rent?