Forward-deployed at SAIL: from shop floor to a ₹1.27 Cr RFP win

Most of my career has been building systems: APIs, pipelines, infrastructure. This autumn at Liquidmind I did something different. I was the forward-deployed engineer on an engagement with Steel Authority of India Limited (SAIL) across three integrated plants: Durgapur Steel Plant, IISCO Steel Plant, Burnpur and Rourkela Steel Plant.

It ended with a ₹1.27 Cr contract. The case study with the timeline is here. This post is about what the job actually is, because "forward-deployed engineer" is a title many people use and few explain.

What an FDE is (and isn't)

A forward-deployed engineer is an engineer who sits with the customer long enough to understand their problem better than they can describe it, then builds the first version of the solution in front of them.

• It is not sales. I didn't hand off to an engineer after the meeting. I was the engineer in the meeting.
• It is not consulting. The output is working software on their data, not a slide that says "AI can help".
• It is not custom development. The point is to map the customer's problem onto the product platform you already have, and to bring back what the product is missing.

In practice it was five stages.

1. Discovery: three plants, three customers

The first mistake would have been treating SAIL as one customer. DSP, ISP and RSP are each a city-sized operation, with their own departments, legacy systems and priorities. I ran discovery separately at each plant and asked the same four questions every time:

1. Who feels this pain, and who signs off on fixing it?
2. What does it cost today, in hours, delays or risk, in your words?
3. Where does the data live: paper, scans, ERP exports, email, CCTV?
4. What would "solved" look like to you?

Question 4 matters most. Engineers jump to how. Customers buy what changes.

The answers fell into three tracks: documents checked by hand, knowledge locked in manuals and circulars nobody can search, and vision, meaning shop-floor monitoring that depends on someone watching a screen. Each track mapped onto something real on our platform: TradeGuard-style extraction and cross-checks, Patram-style retrieval with citations, and vision models on Bedrock. That mapping is what made a fast PoC possible. I wrote about the platform underneath separately.

2. PoCs: their data or it didn't happen

A demo on our sample invoices proves we can build demos. A plant engineer is convinced when their own document comes back as structured fields with a confidence score next to each one, or when their own manual answers a question their team actually asks, with the page number.

Rules I followed for every PoC:

• One sitting. If it needs a second meeting to understand, it's too big.
• Show the failure modes. Low-confidence fields were highlighted, not hidden. Trust grows when the system says "I'm not sure" in the right places.
• Cite everything. In a PSU, an answer without a source is an opinion, and opinions don't get approved.

I pitched each PoC twice: once to the people who would use it, and once to the people who would approve the spend. They want different things. Users want to know it works on the messy cases. Approvers want to know it's safe, governable and phased.

3. Go to the site

The PoCs earned the invitation to the plants. Walking the actual workflow changed the proposal more than every meeting before it combined:

• The real constraints: network reach on the floor, who is allowed to install what, and how data may leave the premises.
• The real workflow: the "simple check" that turns out to involve three people, a register and a signature.
• The real priority: which problem to solve first so that phase two gets approved.

You cannot get this from a requirements document, because nobody writes down what they stopped noticing years ago.

4. Write for the evaluator

PSU procurement runs on formal RFPs. Your champion is not the person scoring your response. The evaluator has a checklist, limited time, and no context from your meetings. So I wrote the proposal and the RFP response for them:

• A compliance matrix: every clause, our answer, and where in the document the evidence is. Never make an evaluator hunt.
• Problem statements in the plant's own language, each tied to an outcome a department had named in discovery.
• Architecture that answers the governance questions before they are asked: managed models on Amazon Bedrock with an in-region option, data kept in India, role-based access, audit trails.
• Phasing: start where the PoC already proved value, expand plant by plant, with acceptance criteria per phase. Phasing lowers risk for the buyer and makes the commercials easier to approve.

5. Close, then hand over cleanly

The award came through: ₹1.27 Cr. The part that matters for delivery is that the scope is made of problems the plants named, PoCs they had already seen work, and a rollout they helped shape. That is a project the delivery team can win, instead of one they inherit and apologise for.

What I took away

• Engineering credibility closes deals. Answering the edge-case questions on the spot, in the room, moved conversations further than any deck.
• Discovery is a technical skill. Turning "this takes forever" into a field list, a data source and a success metric is design work.
• Bring a baseline. If I did it again I would measure the current state on the first site visit, in minutes per document and searches per answer, so every later conversation is a before-and-after.
• FDE work makes the product better. Every PoC exposed something the platform should do by default. That feedback loop is worth as much as the contract.

If you're an engineer wondering whether to take a customer-facing role: do it once. You'll write better software for having watched someone use it.