Everyday storyThe kitchen fitter from the modular kitchen company
A company in Pune sells modular kitchens. Its showroom is beautiful. Every cabinet in the catalogue is a neat 60 cm wide, every corner is a perfect right angle, and the demo kitchen looks finished in an afternoon.
Then the kitchen arrives at a real flat in Kothrud. The wall leans by two centimetres. The gas pipe comes out exactly where the drawer should go. The window is lower than the drawing said. The family wants space for a big pressure cooker and a steel dabba shelf that no catalogue imagined.
So the company does not send only a delivery van. It sends a fitter. The fitter measures the real walls, talks to the person who will cook there, trims a panel, moves a shelf, and gets a working kitchen in place by the weekend. Before leaving, the fitter phones the factory: "Third flat this month where the wall leans. Can we make the side panels adjustable?" A few months later, every kitchen ships with adjustable panels, and every fitter's job gets easier.
That fitter is a forward deployed engineer. The catalogue is the product. The real flat, with its leaning wall and its gas pipe, is the customer's company. The fitter's job has two halves: make it work here, and tell the factory what every kitchen needs.
In a real productSetu AI and its customers
Setu AI is a Bengaluru company that sells an AI platform to Indian enterprises: assistants that answer questions, agents that carry out tasks, and tools that read documents. Its demos are impressive. A prospective customer types a question and gets a clear answer in seconds.
The trouble starts after the contract is signed. Take Sanjeevani Hospitals, a chain of 14 hospitals across Pune and Mumbai. Its was installed in 2011. Patient notes mix English and Marathi. Nurses share a few computers at each ward station. Lab reports live in a separate system that only the lab team understands. Patient data is sensitive, and the hospital's IT head will not allow any data out of the building without a long review.
None of that was in the demo. If Setu AI hands over a login and leaves, nothing happens. The licence fee is spent, the nurses keep working the old way, and next year the hospital does not renew.
So Setu sends a (FDE). Setu's FDEs include Ananya, a senior FDE who used to be a backend engineer; Rohit, a fresher who joined from campus; Imran, who switched from a support engineering role; and Meera, who leads the FDE team.
What is at stake in their work:
- For the customer: whether an expensive purchase changes anything in daily work, for example whether patients stop waiting 20 minutes on hold to ask if their blood report is ready.
- For Setu AI: whether the customer renews and expands. A hospital chain paying ₹1.2 crore a year is worth far more over five years than one sale.
- For the product: whether Setu learns what real hospitals need, so the next hospital takes four weeks instead of four months.
The ideaHow it works
The one-line definition
A forward deployed engineer is a software engineer who works directly with a customer, often in the customer's office, to get a product working inside that customer's real systems and real daily work, and who brings back what they learn so the product improves for everyone.
Each part of that sentence matters:
- A software engineer. FDEs write real code that runs in production: integrations with the customer's systems, data pipelines, prompts and agents, evaluation scripts, small apps. This is not a sales role with a technical title.
- Works directly with a customer. The FDE talks to the people who will use the system, not only to their managers. They sit with a nurse, a loan officer or a truck dispatcher and watch how the work is really done.
- Often in the customer's office. "Forward deployed" is borrowed from military language: placed out where the action is, not at headquarters. Many postings in 2026 asked for 25 to 50 percent travel. Some weeks are fully on site; others are remote.
- Real systems and real work. The job is not to show the product working. It is to make it work with the customer's old database, their security rules, their messy data and their staff's habits.
- Brings back what they learn. An FDE is part of the product company. When they notice that three hospitals need the same lab-system connector, they tell the product team, and the connector becomes a feature.
The FDE stands in the middle. On one side is their own company's product and product team. On the other side are the customer's people and systems. Most of the job is moving understanding across that middle, in both directions.
Why the gap exists at all
Software companies try to build one product that many customers can use. That is how they grow. But every large customer is unusual in its own way:
- Old systems. Banks run core systems from the 1990s. Hospitals run systems their original vendor no longer supports. Many logistics firms run on spreadsheets that one person understands.
- Rules. A bank cannot send customer data outside India without checks. A hospital must protect patient records under India's . Every big company has a security team that must approve new vendors.
- Habits. Staff have done the work a certain way for years. A tool that adds two clicks to a nurse's busy shift will be quietly ignored.
- Data. Real data has typos, blanks, two date formats, duplicate customers and fields that mean something different from their names.
A general product cannot know all of this in advance. Someone has to go and find out, then close the gap. With AI products the gap is even wider, because a general AI model knows nothing about one hospital's lab codes or one bank's loan policy until someone connects it to them carefully and checks it works.
What an FDE actually produces
People sometimes imagine FDEs spend all day in meetings. In practice, an FDE's week produces concrete things you can point to:
- Questions and notes. A list of discovery questions, notes from watching people work, and a of what the customer runs.
- A scoping document. One or two pages saying what will be built, for whom, by when, and how success is measured. (See writing a scoping document.)
- Integration code. Code that reads from and writes to the customer's systems through an , a nightly file, or a database view.
- The AI part. Prompts, retrieval over the customer's documents, agents and tools, configured for this customer.
- An evaluation set. A set of real questions or cases with agreed good answers, so you can prove quality before . (See evals.)
- A rollout plan and a runbook. How the system is switched on safely, and what to do when something breaks.
- Updates. A short weekly written update to the customer and to your own team.
- . Notes for the product team: what was missing, what was confusing, what you had to build by hand.
The engagement arc
One block of work with one customer is called an . Most engagements follow a similar shape, though real ones loop back often:
- Discovery. Find out what problem is worth solving. Talk to users, watch the work, look at the data.
- Scoping. Agree on a small first project and how its success will be measured.
- Access and integration. Get accounts, network paths and data access. Connect to the customer's systems.
- Build. Make a thin working version, then improve it with real users.
- Evaluate. Test it against real cases until it meets the agreed bar.
- Roll out. Switch it on for a small group first, watch closely, then widen.
- Hand over and feed back. Train the customer's team, document it, and send lessons to your product team.
- 1
Customer teamSetu FDE
We want AI to handle patient calls
- 2
Setu FDECustomer team
Discovery: who calls, about what, from which data?
- 3
Customer teamSetu FDE
Call logs, lab system access, nurse interviews
- 4
Setu FDECustomer team
Small working slice in their systems
- 5
Customer teamSetu FDE
Feedback from real users
- 6
Setu FDESetu product team
Field notes: what the product lacked
- 7
Setu product teamSetu FDE
Improved feature for every customer
Notice the last step of the flow. The FDE's work does not end at the customer's door. If the improved feature never reaches the product, the next customer pays the same price again.
The three tensions you live with
The role is interesting because it pulls you in different directions at once.
- The customer versus the product. The customer wants exactly what they asked for. Your product team wants changes that help all customers. A good FDE builds what this customer needs in a way that can be reused, and says so when a request should become a product feature instead of custom code.
- Speed versus safety. The customer wants results this month. But a hospital system that gives a wrong answer about a medicine is dangerous. FDEs move fast on the safe parts and slow down on the risky ones, with tests and human review.
- Building versus saying no. Customers ask for many things. Some are good ideas, some are outside the agreement, some are harmful. An FDE has to refuse some requests politely and explain why. (See saying no and pushing back.)
Is this job for you?
You will probably enjoy FDE work if:
- You like seeing your code used by real people the same week you write it.
- You are curious about how other businesses run: hospitals, banks, trucks, factories.
- You can stay calm when things are unclear and nobody has a full answer.
- You don't mind explaining the same thing three times to three different people.
- You like variety more than deep focus on one system for years.
You may find it hard if:
- You want long, quiet stretches of focused coding on one codebase.
- You dislike travel or being away from home for a week at a time.
- You find it stressful to be the person in the room who has to say "I don't know yet, I'll find out by Thursday."
Neither list is a verdict. Many good FDEs started out uncomfortable with the second list and learned. The rest of this section teaches those skills one by one, starting with where the role came from.
For experienced engineers
Why do companies pay for this? An FDE is expensive: a skilled engineer spending weeks on one customer. It makes sense when contracts are large, when the product is new and the company needs to learn what customers really need, or when a few successful deployments can be turned into repeatable patterns. The danger is that the company slowly becomes a services firm, doing custom projects with thin margins. Healthy FDE teams watch how much of their work turns into product, and they push back when they are being used as free developers. The origins lesson and turning field work into product go deeper.
Step by stepSanjeevani Hospitals wants AI for patient calls
Sanjeevani's call centre in Pune handles calls for all 14 hospitals. The head of operations, Ms. Kavita Kulkarni, tells Setu AI: "We want AI to answer patient calls. Our hold times are terrible." Ananya leads the engagement, with Rohit joining for his first project.
Week 1: discovery, not building. Ananya does not start by configuring a voice bot. She asks for three things: a week of call logs, time with call-centre agents, and a list of the systems agents look at during a call.
The call logs show about 1,400 calls a day. Rohit sorts a sample of 500 calls by reason, using the notes agents type after each call:
Sample of 500 calls, by reason
Is my lab report ready? 205 (41%)
Book or change an appointment 110 (22%)
Billing and insurance questions 85 (17%)
Doctor availability 45 (9%)
Medical questions, complaints,
emergencies and everything else 55 (11%)
Rohit also sits beside two agents for a morning. He notices that for a report question, the agent opens the lab system, searches by phone number, finds the report and reads its status. Average handling time: about 3 minutes, most of it waiting for the old lab system to load.
Week 1, Friday: the real problem. Ananya writes in her notes: "They asked for AI to answer calls. The biggest single reason for calls is report status, which needs no intelligence, only a fast lookup in the lab system. Medical questions must never be answered by the bot." That is a very different project from "AI answers calls."
Week 2: scoping. Ananya proposes a first project with a clear measure:
First project: report status by phone and WhatsApp
For: patients calling about lab reports at the 4 Pune hospitals
Success: 50% of report-status calls answered without an agent,
with zero wrong statuses in a 2-week pilot
Not included: medical questions, billing, appointments
Risk: lab system has no API; read access needs IT approval
Ms. Kulkarni signs off. The hospital's IT head, Mr Prakash Joshi, agrees to give read-only access to a reporting copy of the lab database, after Setu completes the hospital's .
Weeks 3 to 5: building. Rohit writes the code that looks up a report by patient phone number and booking ID, returns only the status (ready, pending, or collected), and never the results themselves. The assistant on Setu's platform calls that lookup as a tool. Anything that is not a report-status question goes straight to a human agent.
They hit a problem: the lab system stores phone numbers in three formats, such as 9822012345, +91 98220 12345 and 098220-12345. Lookups failed for about 18% of test calls until Rohit normalised the numbers.
Weeks 6 and 7: evaluation and pilot. Before go-live, they test 300 real past calls whose correct status is known. The first run gives 291 correct, 9 wrong. All 9 wrong ones are reports split across two samples. They fix the logic and rerun: 300 out of 300. The pilot starts at one hospital, then all four Pune hospitals.
Results after two weeks of pilot: 58% of report-status calls were answered without an agent, and no wrong statuses were reported. Average hold time across all calls fell from about 9 minutes to under 4, because agents had more time for harder calls.
The part people forget. Ananya writes a one-page field note for Setu's product team: "Lab systems at hospitals store phone numbers in mixed formats; report status needs a read-only connector; our platform has no built-in way to say 'never answer medical questions'. Two other hospital customers are likely to need the same." Two months later, Setu ships a ready-made lab-status connector and a "never answer" topic rule. The next hospital customer goes live in three weeks.
ScenariosYou're the engineer
Real situations you could face. Think about what you'd do before reading on.
Day one, and you have no access
You arrive at Kaveri Bank's office in Mumbai. Your laptop is not allowed on their network, your account request is "in process", and nobody knows when it will be done.
What you'd do: Use the day for work that needs no access. Meet the people who will use the system, ask them to show you their screens, and draw a first systems map on paper. Find out who approves access and ask what exactly they need from you. Write it all up by evening.
Why: Access delays are normal at banks and hospitals. An FDE who waits idle loses a week. One who learns the people and the process in that week saves a month later.
The customer asks for something the product cannot do
At Raftaar Logistics, the operations manager wants the Setu assistant to send drivers voice notes in Haryanvi. Setu's platform supports text and a few languages, not that.
What you'd do: Thank them, ask what problem the voice notes would solve (drivers who don't read text messages while driving?), and check whether something the product already does could solve it. Note the request for your product team with how many drivers it affects. Don't promise a date for a feature your team has not agreed to build.
Why: The request might point to a real product gap, or to a simpler fix. Either way, a promise you cannot keep hurts trust more than an honest "not yet."
A relative asks what you actually do
Your uncle in Lucknow asks whether an FDE is a "proper engineering job" or "some kind of sales."
What you'd do: Use a picture he knows: "My company makes software that answers questions. Big hospitals and banks buy it, but it doesn't work for them straight out of the box. I go to them, connect it to their old systems, test it until it's reliable, and teach their staff to use it. Then I tell my company what to improve."
Why: If you can explain your job to someone outside tech, you can explain it to a customer's CEO. This is the first Field Lab exercise for this module.
You are the most junior person in the room
Rohit, three months into the job, is asked by Ms. Kulkarni in a meeting whether the system could also read X-ray reports. Ananya is on another call.
What you'd do: Don't guess and don't freeze. Say: "Good question. I don't want to give you a half answer. Let me check with Ananya and our product team, and I'll reply by tomorrow evening." Then do it.
Why: A clear follow-up with a time builds more trust than a confident wrong answer. Customers notice who does what they said they would.
What happens when…Situations
Real situations this idea runs into, and how well-built systems handle each one.
The demo that died on real data
A Setu FDE built an impressive document assistant for Suraksha Insurance using 50 clean sample claim forms. When it was connected to real scanned claims, it misread amounts on about one in five documents. The customer's claims head lost confidence in a single afternoon.
The team went back to the real data first. They pulled 400 real scanned claims, sorted them by type and quality, and built an evaluation set from them. They found that faded thermal-paper bills caused most errors and routed those to human review instead of the assistant. The lesson they wrote down: never show a customer a demo on data that is cleaner than theirs. Ask for real samples in week one.
The FDE who became the customer's free developer
At Dukaan Distributors, an FDE was so helpful that the sales head started asking for unrelated things: a new report in their CRM, a fix to their website, a script for their accountants. Six weeks in, the actual project, an assistant for the sales team, was two weeks late.
Meera, the FDE lead, joined a call with the sales head. Together they listed every open request and sorted them into three groups: inside the agreed project, a possible new paid project, and out of scope. The FDE started writing a short for any new ask. The relationship stayed warm, and the main project shipped three weeks later.
The fix that never reached the product
Three different Setu FDEs, at three customers, each wrote their own code to read the same popular HR system's export. Each took about a week. Nobody told the product team, so each thought their problem was unique.
Meera started a simple rule: every engagement ends with a one-page field note listing anything built by hand that another customer might need. In the next monthly review, the HR export showed up three times. The product team built one supported connector in two weeks, and later customers needed none of that custom work.
Watch outCommon mistakes
Thinking the job is mainly sales
Some candidates expect an FDE role to be talking and demos, with a little scripting. They are surprised when they must debug a failing data pipeline at 11 pm.
Expect to write and own production code. Talking to customers is how you find out what to build; building it is the job.
Promising before seeing the data
In the first meeting, a new FDE tells the customer, "Yes, we can automate all of that in a month." Then they see the data: three systems, no API, half the records missing a field.
Say what you'll do to find out instead: "Let me look at a sample of your data and the systems this week. By Friday I'll tell you what's possible in a month."
Working alone at the customer
An FDE spends eight weeks on site without involving their own company's product or engineering team, and builds everything from scratch.
Stay connected to your team. Ask whether someone has solved this before, share early, and send field notes back. You are the product company's eyes at the customer.
Treating the customer's users as the problem
When nurses don't use the new tool, an FDE complains that they "resist change."
Go and watch them work. If the tool adds steps to a rushed shift, the tool is the problem. Make it fit their work, and they will use it.
Trade-offsWhat it costs, and when not to use it
What the FDE model gives a company: products that actually get used at big customers, faster renewals, and a direct stream of learning from the field into the product. For the engineer, it gives fast feedback, variety, exposure to many industries, and responsibility early in your career.
What it costs: FDEs are expensive. A company spends weeks of a skilled engineer's time on one customer. Engineers face travel, context switching and pressure from two sides. If the company is not careful, the team drifts into custom projects that never become product, and margins shrink.
When it is not the right model:
- Small, self-serve products where customers sign up with a card and use it as is. A help page works better than an engineer on site.
- Customers too small to justify weeks of engineering time.
- Products that are already mature and well documented for a market, where a before the sale and a support team after it are enough.
Interview angleIn an interview
Almost every FDE interview loop includes some version of "Why do you want to be an FDE?" It often comes in the recruiter call and again with the hiring manager. A weak answer is about the company's brand or salary. A strong answer shows you understand both halves of the job.
A strong answer sounds like:
"I like building things people use the same week. In my final-year project I built a small attendance tool for my college office, and I learned more from watching the staff use it for one day than from the whole semester of coding. The FDE role is that, at scale: understanding how a hospital or bank actually works, making the product fit inside their systems, and bringing back what the product needs. I'm comfortable with ambiguity and I'm happy to travel."
Interviewers also listen for:
- Do you know it's engineering? Mention code, integrations, debugging and testing, not only "customer interaction".
- Do you know the feedback half? Mention telling the product team what you learn.
- Have you done anything like it? A college project with a real user, an internship where you sat with operations staff, a support role. Any real story beats a general claim.
Later lessons cover the interview loop and the behavioural round in detail.
Quick checkCheck your understanding
Words in this lessonThe jargon, in plain English
Every technical word used above. In the lesson, tap any word with an ⓘ to see its meaning right there.
- API
- An Application Programming Interface: an agreed set of requests one program can send another, and the responses it will get.
- Change request
- A written ask to change what an agreed project will deliver, with its effect on time and effort, so both sides decide on it openly.
- DPDP Act
- India's Digital Personal Data Protection Act, which sets rules for collecting and using personal data, including consent, use only for the stated purpose, and erasure on request.
- Engagement
- One block of work with one customer, from kick-off to handover, with agreed goals and people. FDEs usually talk about their time at a customer as an engagement.
- Field feedback
- What engineers learn while working at customers, such as missing features, confusing behaviour or repeated custom work, written up so the product team can act on it.
- Forward deployed engineer (FDE)
- A software engineer who works directly with a customer, often at their office, to get a product working inside the customer's real systems and daily work.
- Go-live
- The moment a new system starts handling real work for real users, after testing and trials are done.
- Hospital information system (HIS)
- The main software a hospital runs on: patient registration, appointments, admissions, billing and often medical records.
- Security review
- The checks a company's security team runs before letting a new vendor or system touch its data: questionnaires, documents, network rules and sometimes tests.
- Solutions engineer
- A technical person on the sales side who shows customers how a product fits their needs, runs demos and answers technical questions before a deal is signed. Also called a sales engineer.
- Systems map
- A short shared document listing a customer's systems, what each one holds, who owns it and how data moves between them. It is the first thing an FDE builds at a new customer.
Practise it
Do the work this lesson teaches: code checked in your browser, or writing graded against what a strong FDE would do.
Enjoyed this? Keep going for free
This lesson is a free preview. Sign up free to save your progress and earn XP, and to unlock all 449 lessons, the simulator challenges and mock interviews.
Sign up free