The forward deployed engineer's toolkit

The first tool is not software

When an embedded engineer walks into your offices, the first week produces very little code. It produces understanding. A notebook, a stopwatch, a whiteboard and a lot of questions are worth more, at that point, than any development environment. The reason: inside an organisation, nobody can fully describe their own work. Written procedures cover the standard case. Real work is made of exceptions, workarounds, unofficial files and habits learned on the job.

That is why the toolkit starts with observation instruments and ends with handover instruments. In between there is code, but code is only the visible part. We open the box family by family: what each one is for, how you choose inside it, what it asks of your IT team, and what remains at the end.

Observing and measuring the real work

This family answers one question: what actually happens between a request coming in and leaving, handled. The instruments are deliberately crude.

• The gesture log. You sit beside a person and write down every action, in order, with the tool used. A round trip to a spreadsheet counts as an action.
• The annotated screenshot. You capture the screen at the moment the person hesitates, and write in the margin why. It travels best to an executive committee.
• Timing. You measure a simple case and a complicated one, across several people. Never to judge anyone's pace: to find out where the time goes.
• The short interview. Twenty minutes, three questions. What wastes your time. What do you redo twice. What do you never dare delegate.

How to choose: the instrument that disturbs the observed work the least. A measurement tool to install on every workstation costs more in time and suspicion than half a day sitting beside someone. At this stage your IT team is not involved: nothing installed, nothing connected.

Reaching the existing data

Once observation has picked a target, you need the data. No useful tool is built on information typed in twice. Four paths, from the lightest to the most committing.

• The manual export. You ask for a file in the usual format. Enough to understand the structure, not enough to run a tool day after day.
• The existing connector. Many off the shelf products already know how to send their data elsewhere, without a line of code. When an existing connector covers the need, we take it. Code you do not write is code nobody has to maintain.
• The programming interface. Most business software exposes a documented door. It is the cleanest path: scoped reads, named permissions, traceable calls.
• Direct read only database access. Reserved for cases where nothing else exists. You ask for an account that can only read, in writing.

A fifth path covers documents: contracts, purchase orders, scanned invoices. The tool becomes a reading chain that turns a document into usable text, then into checkable fields. This is often where projects that start from a spreadsheet begin: see turning an Excel file into a tool.

How to choose: the source closest to the truth and least intrusive. Ask for named read permissions and document who reaches what from day one. For your IT team, this is when the real requests arrive: a technical account, an address to allow, a firewall rule. Better to handle them in one batch at the start.

Prototyping fast

A prototype settles a question, it does not deliver a service. Its useful life is counted in days. The tools here are chosen for speed: a small web app built in a few hours, a throwaway spreadsheet replaying the disputed calculation, a clickable mockup with no engine behind it, a script running on a sample.

The rule attached is strict: a prototype is not a production system. It has no permissions, no backups, no audit trail, no error recovery. Nobody should use it on a real client file. The danger is social. As soon as a prototype helps, one person uses it, then a whole department, and going to production is no longer decided: it is endured. So we set an end date for the prototype before writing it, and we list what would be missing to make it usable. That step has specific prerequisites, worth knowing before getting excited about a working demo.

How to choose: the most disposable tool that answers the question. If a spreadsheet proves the calculation, we do not build an app. A prototype should cost your IT team nothing: it runs on a workstation or in an isolated space, never inside a live system.

Building the application

Once the decision is made, the building tools come out. More boring, on purpose. Four blocks come back almost every time.

• The database. It fixes the vocabulary: what a case is, a client, a step, a status. Half the usage disagreements are settled here, before the first screen.
• The screens. One screen per moment of work, not one per database table. You draw the user's typical day first, the forms come after.
• Permissions. Who sees what, who edits what, who approves. A tool with unclear permissions ends up used half heartedly: nobody wants to own a mistake everyone can see.
• The audit trail. Every important action leaves a dated, named trace. That is what answers who changed a figure without opening an investigation.

On top of those come automated tests, data migrations and version control. Nothing spectacular, but it is the difference between a tool that ages well and a tool that collapses the first time the team changes. These blocks form the base of our full application method.

How to choose: the most ordinary technologies that hold the need. A widespread, documented framework others know how to pick up beats an elegant choice known to three people in the country.

The AI part

AI is a component sitting among the others, not a separate family. It steps in where a rule would be impossible to write: understanding free text, reading a badly framed document, matching two labels spelled differently. Five tools make up this family.

• The language model, called from the application server, never from the user's browser.
• Document extraction. A PDF or a scan becomes checkable fields, keeping the source passage for human review.
• Search over a corpus. Your documents are indexed so the model answers from them and says where the answer came from. Without a cited source, an answer cannot be verified, so it cannot be used.
• The evaluation set. A list of real cases with the expected answer, replayed after every change. The most neglected and most decisive tool: without it, nobody knows whether a change improved or degraded the result.
• Server side guardrails. This is our house rule: anything that commits the company, a price, an availability, a reference, an address, is computed by code and checked before display. The model phrases, it does not decide.

How to choose: the smallest model that passes the evaluation set, and no model at all when a rule is enough. Two non technical constraints come with it: where the processing runs, and what regulation requires in your sector. On the first point, see hosting an AI project in France.

Automating the flows

An application is not enough if the work still has to be started by hand. This family connects the blocks. Four notions explain what will be installed at your place.

• The trigger. An event that starts a process: an email arriving, a file dropped, a status changing, a time of day.
• The queue. Tasks stack up and are handled one by one. That stops a load spike from taking everything down on closing day.
• The nightly run. Heavy calculations and bulk synchronisations happen while nobody works.
• Error recovery. A failing task is retried, then set aside with its error message and enough to replay it. A flow that fails silently is worse than no flow at all: you believe the work was done.

Here again, an off the shelf automation product often does the job, and you need to know when it is enough and when it breaks down. The switch to custom work happens on three points: volume, how finely errors must be handled, and the need for a trace that survives an audit.

How to choose: the number of moving parts. Every automation added can break on a Sunday night. We only automate flows whose failure can be detected and caught up, and leave by hand whatever requires judgement.

Hosting and running it

The tool then lives on its own, for years. This family separates a delivered project from an abandoned one. It comes down to four items.

• Environments. A test space separate from the live one. You never fix things directly in the tool the teams use, not even a comma.
• Backups. Automatic, dated, and above all tested. A backup never restored is an assumption, not a safety net.
• Monitoring. Does the service answer, did the nightly runs complete, is the queue draining. Three indicators beat thirty dashboards nobody reads.
• Alerts. Who is notified, through which channel, above which threshold. An alert sent to everyone reaches no one: you name a recipient.

How to choose: whatever your teams already know how to run. If your IT team already administers a given kind of server, we fall in line. Installing a stack nobody in the house knows creates a dependency on the supplier, and that is not the deal. This is the family that needs the most discussion, as early as possible: hosting, access, backups, on call duty.

Handing over

Last family, the most neglected, the one that decides whether the tool survives the engineer's departure. Four deliverables.

• Short documentation. A few pages, not a binder. What the tool does, how it is wired, where the data lives, what to do in a given case. Long documentation is never read, therefore never updated, therefore wrong within a year.
• Training on the real tool. With real files, in the real application, not on slides. Users learn by handling their own cases. That is the format of our training method.
• Access to the code and the accounts. The code is yours, in a repository you own. Service accounts are in your name, with your suppliers. If you have to ask us for a password to take back control, the handover failed.
• An internal owner. One named person in the house, trained during the engagement, who knows who to call and where to look. Not necessarily from IT: often whoever knows the business process best.

How to choose: everything installed must be recoverable without us. We ask it backwards: if the team vanished tomorrow, what would become unusable. The answer dictates which documentation to write and which technical choices to refuse.

The simplest thing that holds

One rule runs through every family: we pick the simplest tool that holds the real need, not the need imagined three years out. Unnecessary machinery carries a cost that never shows up on the quote. It is paid at hiring time, when you need someone who knows that stack, and when something breaks and nobody knows where to start.

In practice: an existing connector instead of a hand written integration, an explicit rule instead of a model call. Every time a part is added, we should be able to say who maintains it and how we notice when it fails.

The opposite trap exists: refusing a necessary block in the name of staying light. An application handling sensitive data needs permissions and an audit trail, even for ten users. Simplicity applies to the number of technologies, not to the seriousness of what is built.

What stays with you

At the end of an engagement, take inventory. You should hold: the source code and the hosting accounts in your name, data in a format you can export, short and current documentation, an evaluation set if AI is involved, and one person inside who can keep it running. If any is missing, it is not a finished engagement, it is an installed dependency.

That is the point of the embedded model: the engineer works at your place, on your data, next to your teams, and leaves a tool they can keep alive. To start the series from the beginning, see what a forward deployed engineer is. And if you have a process in mind and want to know which tool families it actually calls for, the diagnostic is built for that: we look at the real work, name what can be automated, and tell you what stays manual.

Frequently asked questions

Will the engineer install software on our workstations?

During the observation phase, no: gesture logs and interviews require no install at all. After that, the tool we build is usually a web application reached from a browser, so nothing is deployed machine by machine. Any installation concerns servers, and goes through your IT team.

Who decides the technical stack, you or our IT department?

Your IT department has the final word on hosting, access and internal standards. We propose, we explain the cost of each option, and we fall in line with what your teams can operate. Installing a technology nobody in the house knows creates a dependency, which is exactly what the embedded model is meant to avoid.

How many access requests should we expect at the start?

As few as possible, and grouped. We draw up the full list after the observation phase, read only wherever that is enough, with one named account per use. This avoids drip fed requests that stall the project a week at a time and make it impossible to track who reaches what.

Can we keep the prototype running while we wait for the final version?

That is the request we most often turn down. A prototype has no permissions, no backups, no audit trail: a case handled inside it is a case nobody will be able to trace. If the need is urgent enough to want to keep the prototype, that is the signal to discuss the scope of a usable version, not to extend the prototype.

How do we know the tool still works once you have left?

Through three things left in place: monitoring, which tells you whether the service answers and whether nightly runs completed, named alerts, which reach an identified person, and the evaluation set, replayed before every change when AI is involved. Your internal owner knows how to read them, that is part of the handover.