Start with the app, its purpose, and a reproducible baseline
Send the repository or agreed project files, an exact version or commit, setup instructions, and a short account of what users should be able to do. If it only runs on your machine, say that and work out the missing setup with the developer. Separate the live app from local experiments so nobody mistakes a newer folder for the deployed version.
- Who uses the app, and what important task should they finish?
- Which version is live, which version runs locally, and how can each be identified?
- What commands and dependencies are required to run the project?
- What test data or test account can the developer safely use?
- Which behavior and saved information must survive the next change?
Give them a short, usable handoff
Prepare these materials before asking for a fixed estimate. A developer may need a short discovery session to check what is actually present and which repair options are credible.
| Material | What makes it useful |
|---|---|
| Product brief | First user, complete journey, important rules, and the next outcome you want. |
| Runnable baseline | Exact version, installation/start commands, required configuration names, and safe test data. |
| Access inventory | Hosting, database, external services, domain, and account ownership. Arrange scoped access through the relevant service. |
| Working behavior | Steps or a recording of what currently works, with the environment and version noted. |
| Known problems | Steps to reproduce, expected result, actual result, frequency, and evidence. Label unverified concerns separately. |
| Current notes | Relevant architecture and decisions, plus what changed since they were written. Mark stale notes explicitly. |
| Release expectations | Acceptance checks, deployment responsibility, rollback route, and what remains outside the job. |
Copy this handoff brief
Fill in what you know. “Unknown” is a useful answer when it prevents someone from assuming a dependency or migration is already understood. Share credentials through the service’s access controls or an agreed secure channel, not inside this document.
Developer handoff brief
# Handoff: [app name] Purpose and users: [who it helps and what they finish] Next outcome: [one useful change or milestone] Baseline - Repository and exact version: [location + revision] - Live app and deployed version: [URL + version, or unknown] - Run locally: [install, configuration names, start commands] - Safe test data/account: [how to obtain it] - External services and owner: [inventory; no secrets here] Preserve [Working journeys, saved information, permissions, and rules.] Known problems 1. Steps: [sequence] Expected: [result] Actual: [result, environment, frequency, evidence] First appeared: [version or unknown] Current decisions and notes [What is agreed, where it is recorded, and what may be stale.] Questions for discovery [Unknowns that affect the estimate or recommended approach.] Finish and release [Acceptance checks, deployment owner, rollback expectation, and the work deliberately outside this handoff.]
Use the first session to verify the starting point
Ask the developer to run the pinned version, walk through one important journey, and reproduce one reported problem. They should trace enough of the affected code to explain the likely cause and the next investigation. That makes the recommendation about your actual app rather than a general opinion about AI-generated code.
First discovery session
Run the pinned baseline and confirm the setup instructions. Demonstrate [important working journey] and reproduce [bug]. Trace the relevant saved state, permissions, and dependencies. Identify stale notes and missing access. Recommend the smallest complete next milestone. Compare repair, refactor, selective rebuild, or rewrite only where the evidence supports them. Explain what each viable option preserves, what it changes, and what still needs investigation. Return the demonstrated starting state, findings, proposed scope, acceptance checks, and assumptions behind the estimate. Do not change important product rules or migrate data before we have agreed on that work.
Example: describe a disappearing booking precisely
In an illustrative room-booking app, “the calendar is broken” gives the developer little to investigate. A better report is: “On local version X, I sign in as a member, book Room A for Tuesday at 10, and see confirmation. After signing out and reopening, the booking is gone. I expect it to remain. I have not tested the hosted version.” The developer can now check saving, reading, access, and environment differences without treating any one explanation as already proven.
The business rule also belongs in the handoff: only one active booking can occupy a room at a time, and members can cancel their own bookings. Fixing a disappearing row must preserve those rules. This example is not evidence about a Driftbreak customer app.
Agree on a complete milestone before broad cleanup
Use the findings to agree on the next outcome, the behavior to preserve, and the checks needed to accept it. A full rewrite may be justified, but it also needs a plan for data, feature preservation, cutover, and rollback. Do not make “clean up the code” the only finish condition for a job whose real goal is a reliable user journey.
Where Driftbreak fits in the handoff
Driftbreak helps when the product direction needs resolving before implementation can proceed coherently. It works from the story and evidence supplied to your case, then produces connected architecture and implementation material for an agent or developer. It does not replace the developer’s inspection, estimate, deployment work, or verification of the running app. If the rules are clear and the defect is local, you can take that defect straight to the developer.