Can the developer write the text if we are still deciding it?

Only if writing is part of the paid scope, and you still approve the final wording. Otherwise the developer will invent placeholder copy, and that placeholder will become the thing you argue about in review. If the text is not ready, the honest status is waiting on text.

Can we accept the work on the live site if we are careful?

No. Review on the live site makes every mistake public. It also turns every fix into a night change on production. Use a separate copy, run the acceptance clicks there, and treat that copy as part of the job.

What if two people on our side disagree about the feature?

Name one person who decides the same day. If nobody has that role, the developer will eventually guess. The calendar does not stop just because your side is still debating. That guess is what later appears as a mistake.

We are handing over an existing application, not a new page. Does this checklist still apply?

Yes, but start with what is already live, who owns access, and where changes can be tested safely. The same handoff rules still matter. They just sit on top of an existing system instead of a blank page.

Handoff checklist: what to give a developer so the build does not get redone

Q: We already have a long chat. Is that enough for a handoff?

No. A chat history is not a handoff pack. The next person should be able to open one place and see the outcome, the boundary, and the acceptance checks. If the key decision lives only in messages, the project will pay for that gap later.

Most rebuilds start with a decision nobody wrote down, not with a weak developer. Hand over the result, the boundary, and the acceptance checks before anyone starts the work.

You are about to pay for a site build, a landing page, or a change that sounds small. The files sit in a chat. The deadline is vague. Two people on your side want different things, and both expect the developer to notice. The first version arrives. You say it is wrong. The second version fixes the sentence you mentioned and still misses the rule you never wrote down. That second version is the rebuild. It looks like a quality issue. Usually it is a handoff issue.

A developer can build what you specify. They will also fill the gaps, because an empty gap still has to become a button, a state, or a saved field. That fill-in becomes part of the product. If you did not choose it, you will pay to replace it. This checklist is the small pack that keeps those guesses small. It is not a fifty-page specification. It is the set of decisions that cost real money to reverse.

1. One sentence for the outcome, and a fence around it

Write one sentence that says what a person will be able to do after this work is finished that they cannot do today. Use the words the buyer would accept. “A guest can order tonight’s menu for delivery inside these districts, and the kitchen receives the order.” “A manager can change the price without a developer.” If you need three sentences, you may be buying three projects. Split them or choose one for this invoice.

Then write what this work will not do. The page will not take payment yet. The second language is not part of this phase. The old blog stays where it is. People skip the “will not” list because it feels negative. It is the part that stops a rebuild. Without it, every review adds a feature that was “obviously included.”

Name the one person who decides when stakeholders disagree. Not a group. One name, and how fast that person answers. A developer who waits three days for approval will guess on day two, because your date is still on the calendar. That guess is what you will later call a mistake.

2. Materials that are actually current

Send the text you want published, not “something like the old site, but better.” If the text is not ready, say the build is waiting on text, and do not pretend the layout can already be approved. Placeholder copy written by a developer becomes copy you then debate in review. Real sentences are faster to review than a mood.

Send logo files and images you have the right to use. A cropped screenshot of a logo is not a logo file. A photo from search results becomes a legal problem later, and then a rebuild when you finally get proper images. If you do not have photos, say so. A plain page with true text can go live. A page built on borrowed polish will be replaced.

Send the addresses that matter: the live site, the page this work replaces, and any page that must keep its address because ads or search already point there. Say who owns the domain and hosting, and how the developer gets access without a password sitting in a group chat. A named invite or a password manager is enough. A password in a thread is how the next freelancer still has access after the project ends.

If a marketer is preparing this for a campaign, the pack has a different shape: outcome, platform, and what “accepted” means. That list is in what to attach to a brief. Use it. Do not replace it with a longer chat. If you are handing over an existing application rather than a new page, the first week is about what is already running. Start with how to hand over an existing build instead of this checklist alone.

3. The rules the developer must not invent

Write down the business rules that are already true, even if they feel obvious inside your company. Which cities you serve. Which items are never discounted. Who may see another branch’s rows. What happens on a holiday. A developer who does not know the holiday rule will ship a normal Tuesday. You will call that a bug. It was a missing sentence.

Write where a request or order must appear, in the tool your team already opens. A mailbox, a card, a printer, a sheet. If the only thing you tested was thank you on the site, the rule is not finished. Walk through one example. The failure pattern is explained in why a lead never arrives. Put the destination into the handoff so nobody discovers it during launch week.

Point to the states you already know you need: an empty list, a wrong password, a waiting step, a value longer than the sample, a person who should not see the page. If a designer is part of the process, those states belong in the layout before build. That note is what to give a developer with the layout. If there is no designer, write the states as plain sentences. “If the cart is empty, show the menu, not an error from the payment provider.” That sentence can save a rebuild.

4. How you will accept the work, and where

Acceptance is a list of clicks, not a feeling. Name five to ten checks that a person who was not in the chat can run. Order one item. Change a price as the staff user. Open the second language if you bought one. Confirm the request landed in the named place. Try the case you said was out of scope, and confirm it stays out. If a check needs a private account, include how to get one.

Run those clicks on a copy of the site, not on the live one. A review that happens only in production makes every mistake public, and every fix becomes a night change on the live site. If you do not have that copy yet, creating it is part of the job, not a delay. The reason is in why you should not patch the live site quietly. Put “separate place to try the work” into the handoff as a requirement, even when the task sounds small.

Agree what “done” does not require. A perfect score from a tool you have not installed. A new logo. Copy written by the developer. If those items slip into acceptance, the date you announced was never real, and the rebuild is how the extra work gets billed.

One sentence for the outcome, and a short list of what this invoice will not include.
One person who can decide a disagreement in the same day.
Final text, legal images, and the addresses that must keep working.
Access without a password in the group chat.
The place a request must appear, checked with one example.
The clicks you will use to accept, on a copy that is not the live site.

5. Language, dates, and the note that prevents a second build

If the site must work in more than one language, say which language is the source, and who supplies the other one. “We will translate later” means the first release ships with empty blocks or machine text you will not want to advertise. Either provide the sentences, or remove the second language from this invoice. A half-translated menu becomes a rebuild the week the ads start.

Tie the date to a decision you control. “As soon as possible” makes the developer choose a scope you never reviewed. A date is fair when the text is ready, the decider is named, and the place to test exists. If one of those is missing, the honest status is waiting, not late. Tell your client or your boss what the waiting item is. A status update that hides the gap creates the Friday surprise, and the Friday surprise creates the rebuild.

Keep this pack in one place the next person can open. A chat history is not that place. When the freelancer changes, or your marketer is away, the next person should be able to see the outcome, the boundary, and the acceptance clicks without interviewing you. Projects get rebuilt when that note lived in one head. Write it once. Attach it every time the scope changes, in a few lines, not as a new novel.

When to ask for help

You can fill this checklist yourself if you know the weekly work. Ask for help when nobody can name where the request goes, when the materials contradict each other and the team wants the developer to “just choose,” or when the thing you are handing over is an existing system and you do not know what is live. The job is to make the first build match a decision you already made. It is not to discover the business during review.

Services include reviewing a handoff like this and pointing out what is still missing before the build, so the missing part does not return as a second invoice. Selected work shows results next to the operation, not as a gallery of moods. If you write, send the one-sentence outcome, what you believe is out of scope, and where a test request should appear. Leave passwords and customer data out of the message.