For a long time the default way to ship software went like this: build a general product, then try to bend it to fit each customer. The product team works from a roadmap, someone else handles the customer, and the gap between "works on our machine" and "works in their network" gets closed slowly, if it gets closed at all.
Forward Deployed Engineering (FDE) flips that order. A forward deployed engineer works close to the customer, turns a real problem into working software in the customer's own environment, and then pulls out what is reusable for the product.
None of the individual activities are new. What's different is that one person owns the whole loop, and writing code is only one part of it. As AI makes the coding faster, more of the value sits in the parts around it: discovery, deployment, and generalization.
This is an introduction to the role, not a claim that every FDE works the same way. The engagement below is a fictional but realistic scenario.
What a forward deployed engineer does
An FDE works closely with customers to turn real-world problems into working software. The work runs through three loops:
- Understand: discover the actual workflow and its constraints.
- Build: integrate, adapt, prototype, and test.
- Deliver: deploy, validate, and iterate.
Why the role exists
Products are designed for repeatable needs. Real customer environments are full of unique constraints: legacy systems, network rules, security requirements, odd firmware versions. FDEs bridge that gap by connecting product engineering to real deployments, fast feedback, and measurable customer outcomes.
FDE vs. product engineer
| Product engineer | Forward deployed engineer | |
|---|---|---|
| Primary focus | Shared product capabilities | A customer outcome |
| Works from | Often a roadmap | Direct contact with users and their constraints |
| Success | Scalable, maintainable features | A deployed, usable solution |
The two roles overlap. Product engineers talk to customers too, and FDEs care about maintainability. FDE is a difference in emphasis, not a hard boundary.
A typical engagement
The process is iterative. New constraints often appear during deployment, and that's expected.
Case study: a nine-day security integration
The customer's request sounds simple:
"Connect traffic logs from our 15 FortiGate firewalls to your monitoring platform."
What they actually want is searchable logs and alerts, not an API client. Three constraints shape everything that follows:
- No inbound internet access to the firewalls.
- Mixed firmware and a fixed set of approved authentication methods.
- Reliable collection with limited log history on the devices.
Days 1–2: discover and investigate
Coding doesn't start on day one. Day one is spent asking questions:
- Which FortiOS versions are in use?
- How many events per second?
- What latency is acceptable?
- Can a collector run on-prem?
- Who owns credentials and access?
Day two checks those answers against reality: test a permitted API or log source, confirm authentication and network reachability, inspect sample event schemas, and measure API history, volume, and pagination limits. Some sources, such as in-memory traffic logs, may not be suitable for durable production ingestion. If so, this is when to look at FortiAnalyzer or supported log forwarding.
Deliverable: agreed success criteria and a validated collection approach.
Day 3: design the integration
Because the firewalls can't be reached from outside, the FDE proposes a collector inside the customer network. It reads events over internal access and ships them over secure outbound TLS, with a durable checkpoint and least-privilege credentials. The exact log transport depends on what each FortiOS version supports and on the customer's requirements.
Days 4–6: implement and harden
A naive fetch-and-send loop isn't enough. The connector needs:
- approved authentication and proper secret storage,
- field normalization across log versions,
- retries, backoff, and rate limiting,
- checkpointing and deduplication.
The engineering decisions are where the real work happens. What happens after a restart? What if the API returns partial data? What if events arrive late? Should the auth configuration be reusable? Use idempotent event IDs where you can, and never advance a checkpoint before records are durably accepted downstream.
Deliverable: a tested integration, not just a successful HTTP request.
Day 7: deploy in the real environment
The local build works. Then it meets the customer's network: an internal CA, proxy rules, restricted outbound ports, and limited container resources.
This is where working close to the customer pays off. The FDE works with the customer's infrastructure and security teams (without trying to fix everything alone) to configure certificates and approved egress, package the service and its secrets safely, and add health checks and operational logging.
Deliverable: software running in the customer's environment.
Day 8: validate with real tests
| Test | Expected result |
|---|---|
| Traffic generated | Events appear in monitoring |
| Collector restarted | Resumes from the durable checkpoint |
| Network outage | Retries and recovers |
| Invalid credentials | Clear error and alert |
| Duplicate events | No duplicate downstream records |
These tests check customer value, not just whether the process is running: log freshness, counts, security, and recovery.
Deliverable: acceptance criteria demonstrated together with the customer.
Day 9: hand over and improve the product
The engagement ends with two outputs.
Customer handover: document deployment and troubleshooting, explain operational ownership, train the customer's team, and agree on escalation and support. The customer's team will run this after you leave, often without in-house developers, so the handover isn't optional.
Product feedback: identify repeated authentication needs, propose configurable connector settings, and separate customer-specific logic from reusable product capabilities. Productization is a decision made with the core team. Not every customer exception should become a permanent feature.
The nine-day schedule is illustrative. Real engagements vary a lot.
What makes the solution successful
- It works here: correct events, secure access, usable dashboards, reliable deployment.
- It can be supported: health checks, documentation, recovery behavior, clear ownership.
- It improves the product: reusable connectors, better configuration, lessons for future customers.
Success = outcome + operability + reusable learning.
Trade-offs and risks
| Upside | Risks |
|---|---|
| Fast feedback | One-off customization |
| Deep customer understanding | Scope creep |
| Early proof of value | Security and maintenance debt |
One-off customization. If every customer gets their own branch, you've built a consulting shop, not a product. Something built for one environment may not work in the next.
Scope creep. Halfway through, the customer realizes they also want logs from somewhere else. With tight cycles, a ten-day job can quietly turn into two months. Define scope at the start, and make it clear to the customer that a change in scope means a new cycle.
Debt from speed. Fast prototyping produces hard-coded values that should be in config, and shortcuts that are hard to maintain. That debt is manageable, but only if you track it on purpose.
There's also a softer risk that came up in our discussion. When a customer sees a working prototype, they see a finished product. Either you build it properly the first time, or you'll have to explain later why "the thing that already works" needs a rewrite before the next phase. Setting expectations early, including how much of what they see is a prototype, is part of the job. With AI systems this is even harder, because behavior isn't fully deterministic and output quality needs its own acceptance criteria.
The question to keep asking: what should stay customer-specific, and what belongs in the product?
Three things to remember
- FDE is a way of working close to the customer. You don't always need to be on-site, but you need to be close to the problem.
- Success means a working outcome, not just shipped code.
- What you learn in the field should become reusable product value.
In some ways this is a return to how things worked after the dot-com bust, when one engineer configured the network, wrote the code, installed it, and set up the database. The difference now is that AI handles much of the typing, which leaves the engineer free to own the parts AI can't: understanding the problem and making the solution work in the real world.
If you have an integration that has to work inside your network rather than in a demo, let's talk.
Dugo je podrazumijevani način isporuke softvera izgledao ovako: napravi se opšti proizvod, pa se pokušava prilagoditi svakom klijentu. Produktni tim radi po roadmapi, neko drugi se bavi klijentom, a jaz između „radi kod nas“ i „radi u njihovoj mreži“ zatvara se sporo, ako se uopšte zatvori.
Forward Deployed Engineering (FDE) obrće taj redoslijed. Forward deployed inženjer radi blizu klijenta, pretvara stvaran problem u softver koji radi u klijentovom okruženju, i tek onda izvlači ono što je upotrebljivo i za proizvod.
Nijedna od tih aktivnosti pojedinačno nije nova. Novo je to što jedna osoba vodi cijeli ciklus, a pisanje koda je samo jedan njegov dio. Kako AI ubrzava kodiranje, sve više vrijednosti je u onome oko koda: otkrivanju problema, deploymentu i generalizaciji.
Ovo je uvod u ulogu, a ne tvrdnja da svaki FDE radi na isti način. Angažman koji slijedi je izmišljen, ali realan scenario.
Šta radi forward deployed inženjer
FDE radi blizu klijenata i pretvara probleme iz stvarnog svijeta u softver koji radi. Posao se odvija kroz tri petlje:
- Razumjeti: otkriti kako stvarni proces izgleda i koja su mu ograničenja.
- Izgraditi: integrisati, prilagoditi, napraviti prototip i testirati.
- Isporučiti: deployovati, validirati i iterirati.
Zašto ta uloga postoji
Proizvodi su dizajnirani za potrebe koje se ponavljaju. Stvarna klijentska okruženja su puna specifičnih ograničenja: naslijeđenih sistema, mrežnih pravila, sigurnosnih zahtjeva, neobičnih verzija firmvera. FDE premošćuje taj jaz tako što povezuje produktni inženjering sa stvarnim deploymentima, brzim feedbackom i mjerljivim rezultatima za klijenta.
FDE naspram produktnog inženjera
| Produktni inženjer | Forward deployed inženjer | |
|---|---|---|
| Primarni fokus | Zajedničke mogućnosti proizvoda | Rezultat za klijenta |
| Radi na osnovu | Često roadmape | Direktnog kontakta sa korisnicima i njihovim ograničenjima |
| Uspjeh | Skalabilne funkcionalnosti koje se lako održavaju | Isporučeno rješenje koje se zaista koristi |
Ove uloge se preklapaju. I produktni inženjeri razgovaraju sa klijentima, a i FDE-u je stalo do održivosti. FDE je stvar naglaska, a ne čvrsta granica.
Kako izgleda tipičan angažman
Proces je iterativan. Nova ograničenja se često pojave tek tokom deploymenta, i to je očekivano.
Studija slučaja: sigurnosna integracija za devet dana
Zahtjev klijenta zvuči jednostavno:
„Povežite traffic logove sa naših 15 FortiGate firewalla sa vašom platformom za monitoring.“
Ono što stvarno žele su logovi koji se mogu pretraživati i alarmi, a ne API klijent. Tri ograničenja oblikuju sve što slijedi:
- Nema dolaznog pristupa sa interneta do firewalla.
- Različite verzije firmvera i ograničen skup odobrenih metoda autentifikacije.
- Pouzdano prikupljanje uz ograničenu istoriju logova na uređajima.
Dani 1–2: otkrivanje i istraživanje
Kodiranje ne počinje prvog dana. Prvi dan je za pitanja:
- Koje verzije FortiOS-a su u upotrebi?
- Koliko događaja u sekundi?
- Koje kašnjenje je prihvatljivo?
- Može li kolektor da radi on-prem?
- Ko je vlasnik kredencijala i pristupa?
Drugi dan se ti odgovori provjeravaju u praksi: testira se dozvoljeni API ili izvor logova, potvrđuju se autentifikacija i mrežna dostupnost, pregledaju se primjeri šema događaja i provjeravaju istorija, obim i ograničenja paginacije API-ja. Neki izvori, poput traffic logova koji se drže u memoriji, možda nisu pogodni za trajno prikupljanje u produkciji. Ako je tako, sada je trenutak da se razmotre FortiAnalyzer ili podržano prosljeđivanje logova.
Isporuka: dogovoreni kriterijumi uspjeha i provjeren pristup prikupljanju.
Dan 3: dizajn integracije
Pošto firewalli nisu dostupni spolja, FDE predlaže kolektor unutar klijentove mreže. On čita događaje preko internog pristupa i šalje ih preko sigurnog odlaznog TLS-a, uz trajni checkpoint i kredencijale sa minimalnim privilegijama. Tačan način prenosa logova zavisi od toga šta svaka verzija FortiOS-a podržava i od zahtjeva klijenta.
Dani 4–6: implementacija i ojačavanje
Naivna petlja „povuci pa pošalji“ nije dovoljna. Konektoru treba:
- odobrena autentifikacija i ispravno čuvanje tajni,
- normalizacija polja kroz različite verzije logova,
- ponovni pokušaji, backoff i ograničenje brzine,
- checkpointing i deduplikacija.
Inženjerske odluke su mjesto gdje se radi pravi posao. Šta se dešava nakon restarta? Šta ako API vrati djelimične podatke? Šta ako događaji stignu sa zakašnjenjem? Da li konfiguracija autentifikacije treba da bude višekratno upotrebljiva? Gdje god možete, koristite idempotentne ID-jeve događaja i nikada ne pomjerajte checkpoint prije nego što su zapisi trajno prihvaćeni na odredištu.
Isporuka: istestirana integracija, a ne samo uspješan HTTP zahtjev.
Dan 7: deployment u stvarnom okruženju
Lokalni build radi. Onda se susretne sa klijentovom mrežom: interni CA, proxy pravila, ograničeni odlazni portovi i ograničeni resursi za kontejnere.
Ovdje se rad blizu klijenta isplati. FDE radi sa klijentovim infrastrukturnim i sigurnosnim timom (bez pokušaja da sve riješi sam) na konfigurisanju sertifikata i odobrenog odlaznog saobraćaja, sigurnom pakovanju servisa i tajni, i dodavanju health checkova i operativnog logovanja.
Isporuka: softver koji radi u klijentovom okruženju.
Dan 8: validacija stvarnim testovima
| Test | Očekivani rezultat |
|---|---|
| Generisan saobraćaj | Događaji se pojavljuju u monitoringu |
| Restart kolektora | Nastavlja od trajnog checkpointa |
| Prekid mreže | Ponovni pokušaji i oporavak |
| Neispravni kredencijali | Jasna greška i alarm |
| Duplirani događaji | Nema dupliranih zapisa na odredištu |
Ovi testovi provjeravaju vrijednost za klijenta, a ne samo da li proces radi: svježinu logova, brojeve, sigurnost i oporavak.
Isporuka: kriterijumi prihvatanja demonstrirani zajedno sa klijentom.
Dan 9: primopredaja i unapređenje proizvoda
Angažman se završava sa dva rezultata.
Primopredaja klijentu: dokumentovati deployment i rješavanje problema, objasniti operativno vlasništvo, obučiti klijentov tim i dogovoriti eskalaciju i podršku. Klijentov tim će ovo voditi kada vi odete, često bez sopstvenih developera, pa primopredaja nije opciona.
Feedback za proizvod: prepoznati potrebe za autentifikacijom koje se ponavljaju, predložiti konfigurabilna podešavanja konektora i odvojiti logiku specifičnu za klijenta od mogućnosti koje mogu ući u proizvod. Odluka o tome šta ulazi u proizvod donosi se zajedno sa core timom. Ne treba svaki klijentski izuzetak da postane trajna funkcionalnost.
Raspored od devet dana je ilustrativan. Stvarni angažmani se znatno razlikuju.
Šta rješenje čini uspješnim
- Radi ovdje: ispravni događaji, siguran pristup, upotrebljivi dashboardi, pouzdan deployment.
- Može da se podržava: health checkovi, dokumentacija, ponašanje pri oporavku, jasno vlasništvo.
- Unapređuje proizvod: višekratno upotrebljivi konektori, bolja konfiguracija, lekcije za buduće klijente.
Uspjeh = rezultat + operativnost + znanje koje se može ponovo iskoristiti.
Kompromisi i rizici
| Prednosti | Rizici |
|---|---|
| Brz feedback | Jednokratna prilagođavanja |
| Duboko razumijevanje klijenta | Širenje obima posla |
| Rani dokaz vrijednosti | Sigurnosni dug i dug održavanja |
Jednokratna prilagođavanja. Ako svaki klijent dobije svoju granu koda, napravili ste konsultantsku radnju, a ne proizvod. Nešto napravljeno za jedno okruženje ne mora da radi u sljedećem.
Širenje obima. Na pola posla klijent shvati da želi i logove iz još nekog izvora. Sa kratkim ciklusima, posao od deset dana lako se pretvori u dva mjeseca. Obim definišite na početku i klijentu jasno stavite do znanja da promjena obima znači novi ciklus.
Dug zbog brzine. Brzo prototipiranje proizvodi vrijednosti zakucane u kod umjesto u konfiguraciju i prečice koje se teško održavaju. Taj dug je savladiv, ali samo ako ga svjesno pratite.
Postoji i jedan „mekši“ rizik koji se pojavio u našoj diskusiji. Kada klijent vidi prototip koji radi, on vidi gotov proizvod. Ili ćete ga odmah napraviti kako treba, ili ćete kasnije morati da objašnjavate zašto „ono što već radi“ mora da se prepravi prije sljedeće faze. Postavljanje očekivanja na vrijeme, uključujući koliko je od onoga što vide prototip, dio je posla. Kod AI sistema je to još teže, jer ponašanje nije potpuno determinističko i kvalitet izlaza traži sopstvene kriterijume prihvatanja.
Pitanje koje stalno treba postavljati: šta treba da ostane specifično za klijenta, a šta pripada proizvodu?
Tri stvari koje treba zapamtiti
- FDE je način rada blizu klijenta. Ne morate uvijek fizički biti na lokaciji, ali morate biti blizu problema.
- Uspjeh znači rezultat koji radi, a ne samo isporučen kod.
- Ono što naučite na terenu treba da postane vrijednost koju proizvod može ponovo da koristi.
Na neki način ovo je povratak na period nakon dotcom balona, kada je jedan inženjer podesio mrežu, napisao kod, instalirao ga i postavio bazu. Razlika je u tome što danas AI odrađuje dobar dio kucanja, pa inženjeru ostaje da preuzme ono što AI ne može: da razumije problem i učini da rješenje radi u stvarnom svijetu.
Ako imate integraciju koja mora da radi u vašoj mreži, a ne samo na demou, razgovarajmo.