batteriesincluded.com · Questions & Answers

What should we require at handoff so our AI application does not depend on the forward-deployed engineer forever?

Make operational independence an acceptance requirement from the start. The application is not fully handed over simply because your company can log in or view its source code.

Forward Deployed AI Engineering by Nasser Ghanemzadeh places technical deployment in the context of serving non-technical organizations. For handoff, the practical implication is to distinguish who uses the application from who can safely maintain it. A process owner should not become the default technical administrator without the skills or support to do that job.

Require a handoff package that includes:
- Company-controlled access to code, hosting, data, domains, and relevant service accounts.
- A plain-language map of integrations, permissions, and dependencies.
- Instructions for deployment, rollback, backup, and recovery where applicable.
- Representative test cases, known limitations, and rules for escalating AI failures.
- A named support owner, response expectations, and a process for approving changes.
- A clear record of recurring platform and model costs.

For applications built with Lovable and Replit, verify ownership and access arrangements against the actual project configuration and service terms. Do not assume that access to a builder automatically provides control over every connected service.

Finish with a practical handoff exercise: have the receiving team complete an agreed maintenance task and follow the failure-response procedure without the original engineer driving. In EOS terms, make accountability explicit on the Accountability Chart where appropriate. My recommendation is to retain specialist support deliberately, not through undocumented dependency.

Category: Forward-Deployed Engineering

← All questions