A day in the life of a forward deployed engineer splits roughly in half: code on a customer’s systems, and calls, demos and status notes with that customer. This is a real day from my year as an FDE at Brolly Software Solutions in Hyderabad, deploying the RAG Chatbot and Brolly VoxFlow products, with client details replaced by placeholders.
Key takeaways
- Across 1,000 FDE postings, 55% list customer work before coding; my own weeks ran about 50% code, 30% customer calls and demos, 20% evals, documentation and security.
- The day is built around the customer’s calendar, not yours: morning standup, a mid-morning client call, deep work after lunch, a status note before you log off.
- Tools I touched almost daily: Python, FastAPI, Postgres with pgvector, the Claude and OpenAI APIs, Langfuse, promptfoo, Docker, GitHub Actions, AWS and the customer’s own ticketing and identity systems.
- A bad day is a silent regression discovered by the customer. A good day is a demo where the sponsor asks for the next use case before you finish.
- What surprised me most: the hardest problems were data access, permissions and expectations, not the model.
How is a forward deployed engineer’s day actually split?
A forward deployed engineer (FDE) is an engineer who builds and deploys software, mostly AI systems today, inside a customer’s environment and owns whether it gets used. If you want the full definition and history before the narrative, read what a forward deployed engineer is.
The job data confirms the split. Bloomberry’s analysis of 1,000 FDE postings found 55% list customer-facing work before any technology, and 68% mention travel to customer sites. Python shows up in 66% of postings, TypeScript in 35%, AWS in 32%, AI agents in 35%.
| Activity | Share of a typical week (my experience) | What it looked like |
|---|---|---|
| Coding and debugging | About 50% | Connectors, retrieval tuning, prompt and context changes, fixing what broke in the customer’s environment |
| Customer calls, demos, on-site visits | About 30% | Weekly status call, UAT sessions, discovery for the next use case, two or three site visits a month in Hyderabad |
| Evals, documentation, security | About 20% | Golden-set updates, Langfuse review, evidence pack items, handover docs |
Those shares moved by phase: 70% meetings in the first two weeks, 70% code and evals in the two weeks before go-live. That matches the scoping, validation and delivery structure the Pragmatic Engineer describes for OpenAI’s FDE engagements.
What does an FDE’s day look like hour by hour?
This is a composite Wednesday from the middle of a RAG Chatbot deployment for [PLACEHOLDER: client sector] in Hyderabad, with a Brolly VoxFlow pilot running for a second client in parallel. Our office is near JNTU Metro at Nizampet X Roads; the client site was [PLACEHOLDER: client location].
08:30. Triage before anyone calls
First 30 minutes: Langfuse traces from the previous evening, the customer’s shared Slack or Teams channel, and the nightly eval run in GitHub Actions. On this day, two traces showed the chatbot answering a policy question from an outdated version of a document. That became the top item for the 11:00 call.
09:00. Internal standup
Fifteen minutes with the Brolly team: one backend engineer, one front-end engineer and me. I own the customer, they own the product roadmap. Most of the standup is me translating customer feedback into tickets and defending why the document-store connector ships before the UI polish.
09:30. Deep work: the ingestion bug
Ninety minutes of code. The outdated-document problem traced back to ingestion: the client’s document store [PLACEHOLDER: client system name] kept both versions with the same title, and our deduplication keyed on title. Fix: key on document ID plus modified timestamp, re-embed the affected 340 chunks in pgvector, and add two golden-set cases so it cannot regress silently.
11:00. Weekly customer status call
Forty-five minutes with the client’s operations head, their IT manager and two end users. I lead with the number they care about: answer accuracy on their 60-question test set went from 71% to 86% in two weeks. Then the bug, framed as “we found this before your users did, here is the fix, here is the test that prevents it”, and the ask: read access to one more document library.
The IT manager asks where the embeddings are stored. I show the architecture diagram: everything inside their AWS account, Postgres in a private subnet, no data leaving the VPC except the logged model API call. This question comes up in every engagement; have the diagram ready.
12:00. Notes, tickets, a Telugu follow-up
Thirty minutes turning the call into three tickets and a short note. One of the end users messages me in Telugu asking how to phrase questions to get better answers; I reply with three examples in Telugu. Demos and support in English and Telugu or Hindi are normal for Hyderabad clients, which is why we practise both at FDE Masters.
13:30. Second client: Brolly VoxFlow pilot
Brolly VoxFlow takes a spreadsheet of contacts and runs outbound voice calls grounded in a RAG knowledge base. The pilot client, [PLACEHOLDER: client sector], sent a new spreadsheet format that morning with merged header rows. Two hours: a parser for their format, a schema check that rejects bad files with a readable error, and a 20-script eval in promptfoo against the updated knowledge base.
15:30. Security checklist with the deploy
Before the VoxFlow change goes to the pilot environment, I run our pre-deploy checklist: prompt-injection tests on knowledge base inputs, a check that call recordings follow the agreed retention, and a PII scan on the logs. The DPDP Act 2023 makes clients ask about this, so having the evidence ready saves a week. The deploy goes through GitHub Actions with the eval gate and passes.
Want to become a Forward Deployed Engineer in Hyderabad?
Every week of the FDE Career Program and Advanced Program has a Friday Customer Engagement Lab where you run the 11:00 call yourself, with Deccan Finance as the client and a security review before every deploy. Classroom near JNTU Metro or live online.
16:30. Discovery call for the next use case
The RAG Chatbot client wants the assistant to draft replies to customer emails. Forty minutes of questions: who sends the reply, what happens when the draft is wrong, which systems hold the customer record, who approves. By the end we have a one-paragraph scope and an agreement that a human approves every draft before it leaves.
17:30. Status note and tomorrow’s list
Twenty minutes for one email to the client sponsor: what shipped, what the numbers are, what I need from them, what is next, answer first and under 150 words. Then my own list for Thursday, which starts with the document-library access I asked for at 11:00.
18:00. Logging off, mostly
On a normal day I stopped here. Two or three times a month an on-site UAT session ran to 20:00 or a go-live started at 06:00; the 68% travel figure is real even when the travel is across Hyderabad.
Which tools does a forward deployed engineer use in a day?
| Purpose | What I used | How often |
|---|---|---|
| Application code | Python, FastAPI, TypeScript and Next.js for the chat UI | Daily |
| Data and retrieval | PostgreSQL with pgvector, hybrid search, a reranker | Daily |
| Models | Claude API and OpenAI API, structured outputs, prompt caching for cost | Daily |
| Observability and evals | Langfuse traces, promptfoo and RAGAS on golden sets | Daily review, weekly full run |
| Delivery | Docker, GitHub Actions with an eval gate, AWS (IAM, S3, RDS, VPC), Terraform for environment changes | Several times a week |
| Customer systems | Their document store, ticketing tool, SSO provider; developer sandboxes to prototype connectors | Weekly or on demand |
| Communication | Shared chat channel, one architecture diagram, one status-note template, Claude Code for drafting docs and tests | Daily |
The full stack and the order to learn it are in our forward deployed engineer skills guide. The artefacts those tools produce, from permission-aware RAG to evidence packs, are explained in what forward deployed engineers build.
What does a bad day look like, and a good one?
A bad day
The customer finds the bug first. A new document type arrived on Friday, the ingestion job skipped it without an error, and on Monday an end user got “I do not have information on that” for a question the sponsor had demoed the week before. [PLACEHOLDER: client sector.]
The fix took an hour; rebuilding confidence took a month and delayed the next use case by a quarter. The lesson was not technical: we had no alert on documents expected versus documents ingested, and no eval case for that document type. Every project since has both before go-live.
A good day
A UAT session with eight end users where the accuracy number holds on questions we had never seen, and the operations head interrupts to ask whether the assistant could handle vendor contracts too. That is the signal: the customer starts scoping the next phase for you. The same afternoon the VoxFlow pilot completed [PLACEHOLDER: number] calls with zero parser failures.
What surprised me about the role?
- The model was rarely the problem. Data access, document versioning, permissions and expectations caused most delays. Retrieval quality mattered far more than which model we called.
- Identity took longer than AI. Getting SSO working with the client’s provider and mapping their groups to what each user could retrieve took longer than building the RAG pipeline.
- Evals were a sales tool. A golden set the client helped write turned “does it work?” into a number both sides trusted.
- Language mattered. Being able to switch to Telugu with end users in Hyderabad changed adoption. The sponsor spoke English; the people using the tool often preferred not to.
What would I tell someone starting as an FDE?
- Build the golden set in week one, with the customer. Everything else in the engagement gets easier once a shared test exists.
- Have the architecture diagram and the data-flow answer ready before the first IT question. It will come in the first or second call.
- Alert on absence, not just errors. The silent skip is the failure that costs trust.
- Write the status note even when nothing shipped. Silence reads as trouble.
- Decide if you like this split. Some engineers want 90% code. Our FDE vs software engineer comparison is honest about who should and should not take the role.
I built the FDE Advanced Program around this day. Weeks 1 to 8 cover the RAG, evals, agents, integration, deployment and security work above; the Friday Customer Engagement Lab is the 11:00 call and the 17:30 note, practised weekly against the Deccan Finance case; weeks 9 and 10 are a real 2-week forward deployment. It runs on three weekday evenings plus Saturdays for ₹30,000 online or ₹35,000 classroom, for engineers with 2 to 7 years; beginners take the 18-week Career Program version of the same spine.
Frequently asked questions
How many hours a day does a forward deployed engineer code?
In my experience about half the working day, roughly 3 to 4 hours, split into two deep-work blocks. The rest goes to customer calls, demos, evals, documentation and security checks. Early in an engagement coding drops to 2 hours a day because discovery dominates; in the two weeks before go-live it rises to 6 or more.
Do forward deployed engineers travel a lot?
68% of FDE postings mention travel. For a Hyderabad-based FDE serving local clients, that meant two or three on-site visits a month, mostly UAT sessions and go-lives, rather than flights. FDEs at global firms or serving clients in other cities travel more, sometimes a week per month. Ask about the expected on-site share before accepting a role.
Is a forward deployed engineer’s job stressful?
It is more exposed than a product engineering job because the customer sees your work directly and a silent failure costs trust quickly. The stress is manageable if you build alerts on missing data, keep a shared golden set with the client and send a status note every week. The role suits engineers who like ownership and dislike waiting for someone else to talk to users.
What tools does a forward deployed engineer use daily?
Python and FastAPI for services, PostgreSQL with pgvector for retrieval, the Claude and OpenAI APIs, Langfuse for tracing, promptfoo or RAGAS for evals, Docker and GitHub Actions for delivery, AWS and Terraform for infrastructure, and the customer’s own document store, ticketing tool and SSO provider. A short status-note template and one architecture diagram are used as often as any of them.
How is an FDE’s day different from a software engineer’s day?
A software engineer’s day is organised around the team’s sprint; an FDE’s day is organised around the customer’s calendar and environment. FDEs spend 30 to 50% of their time in customer conversations, work on infrastructure they do not control, and are judged on adoption rather than features shipped. The coding is similar; the context and the accountability are not.
Want to become a Forward Deployed Engineer in Hyderabad?
Come to a free demo class and I will walk through one of these engagements end to end, from the discovery call to the evidence pack. Classroom in Kukatpally near JNTU Metro, or live online.
