In mid-September we exhibited at Infobip Shift 2026 in Zadar, a conference held from September 13 to 15 with around 3,000 attendees and more than 115 speakers from the tech industry. One term kept coming up on stage and at the stands: forward deployed engineer, or FDE, the newest buzzword in AI.
The clearest example at Shift was OpenAI's first talk in Croatia, given by Luis Velasco, a forward deployed engineer at OpenAI, and we followed it from the audience. A forward deployed engineer is a software engineer who works inside a customer's company, on its systems and data, until a product or an AI system runs in daily use.
This post explains what an FDE does, why AI companies built their delivery around the role, and what the model means for a Croatian company with 20 to 200 employees, where AI adoption trails the EU average and the gap grew in 2025.
Why AI stalls in Croatian companies
Croatian companies use AI less than the EU average, and the distance grew last year. According to Eurostat data for 2025, 15% of Croatian companies with 10 or more employees used AI, against 20% across the EU, up from 12% and 13.5% a year earlier. Small companies moved slowest: among Croatian firms with 10 to 49 employees the share rose from 10.5% to 12.8%, while the EU average for the same size reached 17%.
Most of this use stops at off-the-shelf tools. According to a 2025 survey by the Croatian Employers' Association (HUP), close to half of Croatian companies use AI in some form, while only about 3 in 100 have a formal AI strategy, 1 in 10 has a person or a team responsible for AI, and close to a third name the lack of skills among their own staff as a barrier. The gap sits between using a tool and running a system inside the business.
Context lives with people, not in the database
Velasco named the core problem on the Shift stage: business processes are hard to automate because their context is scattered across Slack, older applications and knowledge nobody wrote down. An AI agent needs the same context a new employee needs, and in most companies this context exists only in people's heads.
The rule for when a customer gets a discount sits with the sales manager, and the reason a machine gets serviced every 6 weeks instead of 8 sits with the technician who has looked after it for years. Neither shows up in a database export, and neither makes it into a requirements document written in a meeting room.
An engineer who spends 2 weeks next to the people doing the job finds these rules, an engineer working from a specification never sees them, and this is the whole argument for the "forward deployed" part of the title.
Fiscalization 2.0 showed where the work sits
Croatian companies already went through a version of this. Since January 1, 2026, VAT-registered businesses issue and receive eRačun e-invoices for domestic B2B transactions and report fiscalization data to the Tax Administration, and for most of them the regulation was the smaller part of the job. The bigger part was connecting an existing ERP, an accounting system and years of invoicing habits to a new flow. AI adoption runs into the same integration work, without a legal deadline to force anyone to finish.
Where the FDE role comes from
A forward deployed engineer is an engineer assigned to one customer instead of one product feature. Palantir created the role in the early 2010s and called it Delta internally, and the distinction it used was simple: a regular engineer works on one capability for many customers, a Delta on many capabilities for one customer. Until about 2016, Palantir employed more FDEs than regular software engineers.
OpenAI built its own FDE team in 2025, and its FDEs write code directly on the customer's infrastructure, which separates them from solutions architects who advise and hand over. At Shift, Velasco showed an insurance claim handled by agents in 22 seconds instead of 20 to 30 minutes, and his advice to companies was plain: without a clear answer to what will improve, an AI project stays an experiment.
How the FDE model works in a company with 20 to 200 employees
A Croatian company of this size won't hire a full-time FDE, and it doesn't need one. It needs the same way of working from a small external team, people who sit with the operations team, build on the systems already in place, and leave once the company runs the result on its own. One process takes about 12 weeks.
Weeks 1 and 2 involve almost no code. The team watches the work, maps where data gets created and where people retype it, and agrees with the company on one measurable outcome, for example a technician closing a work order in under 3 minutes. Weeks 3 to 8 build on real data, with a rough working version in front of real users by week 3 or 4, integrations with the ERP and the accounting system, and the AI layer once the data underneath it is trustworthy. Weeks 9 to 12 bring training, fixes from daily use, documentation, and the handover of code, access and maintenance to the company.
FDE, consultant or body leasing?
Croatian buyers know body leasing well, and some providers will relabel an hourly engineer as an FDE. The difference shows in where the people work and how the engagement ends.
| FDE-style partner | Consultant | Body leasing | |
|---|---|---|---|
| Where they work | Inside your operations, with the people doing the job | Meeting rooms and interviews | Inside your dev team, under your tech lead |
| Who defines the problem | The partner and your process owner, together, on site | The consultant | You |
| What they deliver | Working software in daily use, measured by one outcome | A report and recommendations | Hours |
| How it ends | Handover to your team, with a plan to become unnecessary | When the report lands | When the budget runs out |
A partner without a plan to leave is selling hours.
Why a small team fits the FDE model
The FDE model rewards something small companies have by default: the person who sells you the work is the person who does it. With a small team you work with the senior engineer you met in the first conversation, from the first workshop to the handover. In larger tech companies and agencies, the senior who wins the project often hands it over to a delivery team, and the day-to-day code lands with junior developers who never met your process owner.
We're a small team in Split, and this is how we work on Serwizz, the CMMS we build for maintenance and service teams who still run work orders on paper, in WhatsApp and in spreadsheets. Every new customer starts the same way: we go to their site, look at how their technicians work and what goes wrong today, set Serwizz up around their process, and change the product where their process needs something we haven't built yet. Whatever we build for one maintenance team stays in the product for the next one, which is the same loop Palantir ran between its field engineers and its platform.
Start with one process and the person who owns it
The FDE model comes down to where the engineer sits. For a Croatian company the first step is small: pick the process where people retype the most data, name the person who owns it, and write down the outcome worth paying for. The integrations and the AI layer follow from there.
