Day one onsite, and the client's IT manager, a guy named Rob who has watched vendors come and go since the dial-up era, asks what you plan to build on. You tell him: Python, Postgres, and a server that costs less per month than his coffee budget. He blinks. Somewhere in his head, a slide deck with fourteen hexagons and the word microservices quietly catches fire.
His disappointment is the point. The forward deployed engineer tech stack is boring on purpose, and boring is a design goal rather than a failure of imagination.
Here is the entire loadout: one backend language (Python or TypeScript), Postgres for nearly all data, one LLM API tucked behind a wrapper you can swap, and one deploy target the client can see, understand, and pay for. Everything else earns its slot case by case, and most things never do. The stack is optimized for the day you leave, not the day you arrive.
The Forward Deployed Engineer Tech Stack: Boring Is the Whole Point
Embedded work inverts the normal status game. At a product company, exotic infrastructure signals ambition. At a client site, it signals a future invoice, because every unusual technology you install is maintenance debt you are leaving behind for people who did not choose it.
The scar tissue looks like this: an FDE inherits a previous vendor's masterpiece at a 40-person wholesaler. Event-driven, naturally. A message bus, three services, a language nobody in the building can read, and a deployment process documented only in the head of a contractor who ghosted in March. The system did roughly what a cron job and two tables could do. The client had been paying a small fortune to keep it alive, and every change request started with archaeology.
Your stack choices get judged by one audience: the person who inherits the system. That person is not scrolling Hacker News. They are a competent generalist with six other responsibilities, and they will decide whether your work was a gift or a crime scene.
The Core Four
One backend language. Python or TypeScript, and ideally you are fluent in both but dogmatic about neither. Python wins when the work is data-shaped, which at most client sites it is. TypeScript wins when the deliverable is mostly a web app. What you never do is introduce both into one engagement because you felt like it.
Postgres. More below. It is the load-bearing wall of the whole stack.
One LLM API, behind a wrapper. Every AI feature calls a thin internal function instead of the vendor SDK directly, so swapping models later is a config change rather than a rewrite. Choosing the LLM API itself is a task-shape decision, not a benchmark beauty contest, and it deserves its own thirty minutes of thought.
One deploy target. Cloudflare Workers, Render, or a plain VPS. Pick one per engagement and write down how it works.
Postgres for everything (yes, including vectors)
Relational tables for the business data, JSONB for the weird vendor payloads you do not understand yet, pgvector when semantic search shows up, and a cron-friendly jobs table for scheduled work. That covers roughly 95% of what a mid-size client needs, and the entire operational history of a 60-person company usually fits in a few gigabytes. You do not have a scale problem. You have a "the spreadsheet is the database" problem, and Postgres for everything is the fix.
The deploy target rule: if the client can't see the bill, don't use it
Every deploy target gets one test: can the client log in, see the monthly cost, and understand it without you in the room. A $20 VPS passes. Cloudflare Workers passes beautifully, since the free tier covers most internal tools and the dashboard is legible to a non-engineer. A hand-rolled Kubernetes cluster spread across three cloud accounts fails so hard it loops back around to comedy. When you leave, the infrastructure should feel like a utility bill, not a riddle.
The Situation Room Tools
Past the core four sits a grab-bag you reach for weekly. None of it is glamorous. All of it has saved a Thursday.
- Scheduled jobs and a queue. Cron plus a jobs table beats a fancy broker until the day it genuinely does not, which is rarer than the internet claims.
- A dashboard framework. Something that turns a query into a screen in an afternoon, because the fastest way to build trust onsite is a number people check every morning.
- Browser automation. Half your client's vendors have no API, a login page, and an export button. Playwright is how you politely take your own data back.
- The spreadsheet escape hatch. A sync that writes results back to the Excel file the team refuses to abandon. You will not win the spreadsheet war in week two. Sign the treaty, sync the data, win the peace.
Most of this grab-bag is glue code, and glue code is why Python automation stays the FDE's Swiss Army knife: scheduled pulls, data munging, and the scrappy scripts behind nearly every quick win you will ship.
What's Deliberately NOT in the Stack
Kubernetes. Microservices. Kafka. The trendy vector database du jour. A service mesh, obviously. Not because these tools are bad, but because none of them solve a problem a 40-person company has, and all of them create problems a 40-person company cannot staff.
The rule is simple: you may add a technology when a client is actively paying for the problem it solves. Kafka enters the chat when there are genuinely millions of events a day and a team to babysit the cluster. Until then, a Postgres table named events and an index will break your heart with how well they work.
The Handoff Test
Every tool choice gets one question, and you should ask it out loud before installing anything: can a competent generalist inherit this in a week?
Concretely, that means a README that gets from clone to running in one command, a monthly bill under a hundred dollars with no surprises, credentials in a password manager the client owns, and zero knowledge that lives only in your head. If any layer fails the test, simplify the layer. The engagement does not end when you ship; it ends when somebody else can keep the system alive without calling you.
Build for that stranger. They will speak well of you at exactly the moment you are not in the room.