You are probably here because someone told you to hire a forward deployed engineer, and you want to know what that means for your business before you say yes. The role page explains the job. The how it runs page is the week-by-week mechanics, written for people who will work alongside one. This page is for the person who signs. It is short on engineering and long on what you will be asked for, what you will get, and when you will know whether it is working.
The short answer
I come inside your company, build the system with your real data, ship something you can open every week, and hand it over to your people when it runs.
- You give
- The decisions that are yours, written down once. Access to the systems the work touches. One person who knows the business well enough to say "that is wrong."
- You get
- A running system inside the tools you already use. A written handover that names what shipped, what was left out and why, and who does what next. A team that owns it.
- You keep
- Your accounts, your keys, your vendors, your data, and the right to say no to anything, including me.
Before day one: the decisions that are yours
The first document in every engagement I run is not a plan or a design. It is a list of your decisions, written so they are never reopened. On one engagement that list had a heading that said, in so many words, do not relitigate. Under it: which data source was in and which was out, that nobody would ever be phoned or texted, which customers came first and which came later, which advertising channels were allowed and at what budget. None of those were engineering questions. All of them would have been argued about in month three if they had not been written down in week one.
Next to it goes a list of your rules for touching anything live. From the same records: no change to the domain, the zone or the running site without the owner's OK. Keep the analytics and search console exactly as they are. Plain English in anything the owner reads. Ask before any spend over a stated amount. A schedule that costs money stays off until the owner switches it on. Rules like these are how an engineer inside your company stays a guest and not a risk.
Then the split of authority, as a table anyone can read. You own what gets built: the spec is the product decision and it is yours entirely. You set the order by one click on one label, from a browser or a phone. You decide when a finished piece goes to production, at your own pace, daily or weekly or whenever. Everything between your label and a finished piece is mine. That table is written before any code, and it holds for the whole engagement.
The first month
| When | What happens | What you see |
|---|---|---|
| Week one | The decisions file and the rules for live systems. Access set up. The first screen built end to end through the whole machine, deliberately a small one, so the pipeline is proven before anything ambitious runs through it. | A page you can open and sign in to. A written spec for it. Three tracked issues that show how a piece of work moves from your label to production. |
| Weeks two to four | The rule is that every week ends with something usable through a real channel: a page, an email that actually sends, a report you can read, a number on a dashboard that agrees with your point-of-sale. Progress nobody can touch does not count. | One thing a week to look at in a browser. Your reactions get written down in your own words so the next week applies them without asking again. |
| By the end of month one | The system runs and tests end to end with none of your credentials in it yet, because every outside service sits behind a seam with a mock. Your keys go in when you are ready, and they are never the thing holding the work up. | A working system on your data, in your accounts, that your reviewer has already found at least one real mistake in. |
That last line is the one owners underestimate. On a video engagement, the system labeled a run of footage with the wrong district. Every engineer on earth would have shipped it. The owner's local reviewer caught it on the first pass, because they knew the streets. The reviewer you assign will do that for your business, and it is the most valuable hour anyone spends in the first month. Choose someone who knows how the work actually gets done, not someone who is free.
What you will be asked to decide
- What problem, in one sentence. Not a strategy. One thing that is broken or slow and what it looks like when it is fixed.
- What is off limits. The vendor that stays, the data that never leaves the building, the customers who are never contacted a certain way.
- Who reviews. The one person whose "that is wrong" ends an argument.
- What money gets spent. Every metered tool or paid schedule waits for your approval, with the cost stated. On one engagement the daily advertising budget was derived by the system and the partner approved a ceiling above it; both numbers went in the file.
- When to switch. Any step that cannot be undone, such as pointing your domain at the new system, waits for your go-ahead on the day. One migration was built and cut over the same day, with the owner's yes recorded at the moment it happened.
- What to remove. Sometimes the right decision is to take something down. A newsletter sign-up that promised a weekly email with nothing behind it was removed on the owner's call, and the reason was written next to it.
Your indifference counts as a decision too. When an owner said "either is fine" about two options, that went in the file so nobody asked again. The point of all of this is to make your decisions once, in the open, and then get out of your way.
What you will not be asked to do
- Read technical documents. Anything for you is in plain English. That is a rule, not a courtesy.
- Attend daily meetings. Your review is one look a week at something real, and one label when you want the next thing built.
- Decide anything twice. If it is in the decisions file, it is settled unless you reopen it.
- Buy tools before they have proved themselves. A metered capability starts as admin-only, used on your own business first, and opens to customers only after it has earned it.
- Paste a password or a key into a chat, ever. Values are copied across directly. Any key that ever touched a chat is re-issued as the last step of the handover.
What you own at the end
The handover is a document, and it is written as a contract between two named sides. It has the same sections every time.
- What shipped, with the exact change identifiers, so there is no argument later about which version is which.
- What was deliberately not built, and why. On one handover this included a warning not to switch on a feature whose receiving end did not exist yet. Leaving things out on purpose is part of the delivery.
- The activation order, numbered, with the actor named at the start of every line: you do this, then I do that, then you trigger a real one and I confirm it landed. Your own steps are the ones only you can do, such as adding a record to your domain or setting a key in your hosting account.
- An acceptance list you can check without me. Every address on the site answers the same as before. Every old redirect still lands. Speed on mobile at or above a stated score. No change to your analytics property or your search console.
- A copy list: the six files your team takes with them, and nothing else.
- What is next, in order, with your name on the steps that need your account, and the cost stated on the ones that cost money.
- The security step, last. Any credential that was ever pasted anywhere gets re-minted and handed to you fresh.
After that, your team owns it. That means the accounts, the keys, the domain, the list of who is allowed into the admin screens, and the documentation, which on my engagements keeps itself current: a named agent updates the existing documents when a feature changes and is not allowed to create new ones. On one shipped system your team can add a second brand by publishing to a folder, with no engineering at all. That is what owning it looks like: the next change does not need me.
How you will know it is working
Not by a feeling. Every plan I write carries measurement dates and a decision point with the options named in advance. Read the real conversion rate at week four on the first two hundred sign-ups. At week twelve, decide: double down, change direction, or stop honestly. Between those dates, the weekly rule is the early warning. If a week ends with nothing you can open in a browser, that week failed, and you will hear it from me before you notice it yourself.
When you should not hire one
If you have not decided what problem you want solved, hire nobody yet; write the sentence first. If nobody inside will own the system afterwards, the handover has no one to hand to. If the data the system needs is not accessible in practice, no matter what the vendor said, the engagement becomes a discovery of that fact. If what you actually want is a document to take to the board, that is a different service and a shorter one. And if your point-of-sale or accounting system is being replaced this year, wait: every seam built now will be rebuilt then. The role page has the longer version, and the retail page shows what the work looks like in one industry from the inside.
Common questions
How much of my time does it take?
About an hour in the first week to write the decisions file, then a few minutes a week: look at what shipped and say yes, no, or change this. Priority is one click on one label. Releases happen at your pace. Your indifference gets written down too, so you are never asked twice.
What access do you need?
Repositories, the accounts the system has to talk to, and one reviewer who knows the business. Credentials never block the work, because every outside service is built behind a seam with a mock, so the system runs and tests before any key exists. Keys are copied across, never pasted into chat, and any that ever touched a chat is re-issued at handover.
Do you work with our existing vendors and IT?
Yes. Which vendor stays is your decision and goes in the file on day one. The work is built around what you already run, in the tool you already use where there is one, and nothing live is touched without your go-ahead.
What if we already have developers?
Then the engagement is the architecture, the integrations and the seams, and your team builds on it. On a retail platform I led for nineteen months, a team of seven built on the foundation and released on a version cadence. The handover is written for your developers, with pointers into the code rather than a conversation.
What happens if it is not working?
You find out on a date, not a feeling. Measurement dates and a decision point are written into the plan, with the options named in advance. Before that, a week that ends with nothing you can open is a failed week, and you hear it from me first.
How do we start?
The form below: three questions about what is broken or slow and when it needs to be running. I reply within two working days. If it is a fit, the first thing we produce together is the decisions file. If it is not, I say so and why.
Agentic AI architect. Twenty years in enterprise architecture, seven companies built and sold, more than 8,000 commits in the last twelve months across a retail platform, an ad-acquisition platform, a transactional email service, a video product, robotics and CPU inference research. Every number on this site was measured on real hardware or taken from a real engagement's records.
Working with me
I take on one or two engagements at a time, inside the company, and I hand over when it runs. If you have a problem that sits between products, inside your own process, and you need it running rather than recommended, that is the kind of work I do.
The role
What is a forward deployed engineer? The job, from inside itWhere the name came from, a normal week, the handover, and when you should not hire one.
One industry, from the inside
AI in retail: what actually gets built inside a retail chainThe reconciliation before any model, the forecast by hand, the model ladder, open-to-buy, and where AI is the wrong call.