How to hand off a website to a developer with real, working code

When a handoff makes sense

Many sites never need a developer: they publish on Anticode, take enquiries through its forms, and change through the builder. The time to hand off a website to a developer is when you need something Anticode doesn't do on published sites: real customer accounts, a database the site reads and writes, an integration with your own systems, or hosting on infrastructure you already run. Name that reason in the handoff; it tells the developer where to spend their first week.

What the export contains

Anticode exports either a single self-contained HTML file or a standard Next.js project using the App Router. The second is what most developers want. It's written in TypeScript, uses Postgres through Prisma with Zod for validation, and includes server routes for bookings, contact, newsletter and email sign-in, plus an admin area with two-factor sign-in and roles. App builds export too, with customer and staff roles, an audit log and Postgres row-level security. Email goes through Resend, and the README covers Neon, Supabase, Docker and Vercel. There's no Anticode runtime in it; the developer owns every line.

The handoff sequence

1. Freeze the design. Finish content and layout changes in Anticode first. Every change after the export has to be made twice or not at all.
2. Export or push. Download the Next.js project, or push it to a GitHub repository you pick. The GitHub push asks for its own repo permission, separate from signing in, so grant it consciously and to the right organisation.
3. Give the repository to the developer, in an organisation the business owns. The developer gets access; the business keeps ownership.
4. Send the brief. Include the original request and the plan the Architect agreed (name, kind, sections, look, features). It explains intent better than code comments.
5. List what's simulated. If any part was an app build, anything that would need a server was simulated with sample data and labelled "Demo data" in Anticode. Mark each one so the developer knows it needs a real backend.
6. Hand over environment duties. The developer will need a Postgres database, a Resend account for email and a host. These are accounts in the business's name, not the developer's personal ones.
7. Agree the source of truth. From this point the repository is the site. Edits happen there, through pull requests, not in Anticode.

The note to send with it

• Why you're handing off, and the first feature you need.
• The live address today, and whether the domain will move to the new host.
• Where form submissions go now, and where they should go after the switch.
• Which parts are simulated or sample content.
• Who approves changes on the business side, and how quickly.

Decisions and trade-offs

The main trade-off is ease against control. While a site is on Anticode, publishing runs design and security checks, forms are stored and forwarded, and version history is kept for you. After the export those become the developer's job: tests, monitoring, backups and security reviews. That's fine when you need what custom code offers, and an unnecessary cost when you don't. If the only goal is to let a coding agent help, Anticode's open anticode.json format, its CLI and /AGENTS.md let a coding agent edit the project without leaving the platform.

What goes wrong

• Edits on both sides. Someone keeps changing the Anticode project after the export, and the two drift apart. Pick one home and say so in writing.
• Personal accounts. The database or repository sits in the developer's own account and leaves with them.
• Demo data mistaken for features. A tracker or dashboard that looked working in the preview was saving to the visitor's browser only. Flag it before the developer quotes.

How you know it worked

The developer runs the project locally on day one, deploys a copy to a staging address within the week, and asks questions about features rather than about what the code is for. For the mechanics of each step see the Next.js export, pushing to GitHub, and the designer and developer collaboration workflow.

Limits

Anticode produces the code and pushes it; it doesn't host the exported project, run its database or review the developer's later changes. App builds export too, but anything that was simulated in the sandbox still needs someone to build the real backend.

Questions people ask

Is the exported code tied to Anticode?

No. The export has no Anticode runtime. It's a standard Next.js App Router project in TypeScript that any Next.js developer can run and deploy.

Can I keep editing in Anticode after the handoff?

You can, but the changes won't appear in the developer's repository on their own. Decide on one place for edits, or re-export and let the developer merge deliberately.

What does the developer need to set up?

A Postgres database, a Resend account for email and a host. The project's README covers Neon, Supabase, Docker and Vercel.