How an agency hands over someone else’s Laravel without prod surprises

The client says the site is Laravel and the change is small. You promise a date, because the page looks like a page and the previous developer is no longer on the thread. The new developer opens the project the evening before that date. There is no second environment. The production password is somewhere in an old chat. The change touches the payment step nobody put in the brief. The database holds more than one customer's records, and nobody has said whether that is intentional. The surprise arrives on the call with the client, and you are the person who has to explain it.

You are not expected to read the framework. You are expected to know which facts, if missing, turn a small change into that call. The pack below is the handover of someone else's Laravel. It is not the creative brief for a new campaign. What to attach when the work is a new page or a new flow is the brief a developer can start from. Use both when the project is an existing application and a new request at the same time. Use this one whenever the code already runs somewhere customers can see.

1. Where the production surprise actually comes from

The files you have are usually the files a client can see: the new copy, the layout, the list of pages. The behaviour lives in the previous developer's repository, on a server the client pays for and does not open, and in a job that runs at night. "It's Laravel" tells the developer the shape of the code. It does not tell them which branch is deployed, whether a copy exists, or which click takes money.

The date is the other half. It was promised from the visible part. The developer meets the invisible part on the night before, and the only way to keep your date is to try the change on the live site. That is the quiet patch. It feels like loyalty to the deadline. It puts the client's orders in the experiment. If there is nowhere to try the change except production, say that in the first message, and move the date before anyone edits the live server. The owner's version of that decision is why a missing staging site is not a reason to edit live.

Write the gap before you write the date:

• What you already told the client, and what that sentence assumed. "Small change, live by Friday" assumes a place to try it and a path you can name.
• What you have not seen: the repository, the deployed branch, a second environment, a restore.
• Who on your side owns the client conversation if the assumption breaks. The developer should not discover that they are now the account manager.

2. Ownership, without passwords in the chat

Someone else's Laravel means you do not own the code, the hosting, the domain, the payments or the mail. The client might not own them either, if a previous contractor still holds the accounts. A developer cannot be careful with access they do not have, and they should not receive production secrets in the thread where the layout is discussed.

List the systems by name. Repository, hosting, domain, payments, mail, any queue or scheduled job the client has mentioned. Say who can grant a login: the client, you, or the previous contractor. Grant access through accounts you or the client can revoke. Do not paste a production password, a payment secret, or a copy of the customer database into chat or into the brief. A second environment that contains a full copy of real customer records, sitting on a laptop, is not a safer staging site. It is a second place to leak.

• Each system has an owner who can grant and revoke a login.
• The developer receives an account, not a shared password from a forwarded email.
• Production secrets are not in the document and not in the chat.
• You know which branch is on the live site, and when it was last deployed. "Latest" is not a branch name.
• If the previous developer is the only person who can open the server, that is the first task. It is not a footnote under the new banner.

When the client is changing developers entirely, sit this list next to the handover checklist the incoming developer will walk. Your job is to arrive with the owners already named, so that checklist does not start from an empty inbox.

3. Say whether a second environment exists

This is the fact that most often arrives late. The developer asks where to try the change. The honest answer is the live site, and the date is tomorrow. Say it on day one, in writing. A missing environment is allowed. Pretending it exists until the evening before release is how your date becomes their incident.

If a second environment does exist, say what it is: a URL, whose account opens it, and whether its data is a restored backup or a toy set. A toy set will not show the bug that depends on a real order. A restored backup has to be a backup you have seen restored, at least once. If nobody has restored it, write "not proved" rather than "we have backups".

• Yes or no: there is a place to run this Laravel that is not the live site.
• If yes, the URL and the account path. If no, the date you told the client is conditional on creating one.
• If the data is a backup, someone has restored it, or you have written that they have not.
• The developer is not asked to "just be careful" on production as a substitute for this line.

4. Name the flows that can hurt the client

You can describe these without opening the code. Which click takes money? Which form creates the lead you report to the client? Which night job sends mail, rebuilds a file, or charges again? Which of those did the previous developer say were fragile? If you do not know, the change is not small yet. Small is a property you earn by naming the neighbours of the edit.

If more than one of the client's customers share the application, say so. A fix for the client's own staff screen can still show one customer another customer's rows, or a job can send the wrong file. You do not have to decide how the data is separated. You do have to tell the developer that the separation exists and must be rechecked. What to recheck is where shared customer data usually mixes.

• One sentence each for the payment step, the lead step, and any night job the client would notice if it ran twice.
• A way to check the lead step that does not use a real customer's card, if that is possible.
• Whether several customers share this application, in a sentence.
• What is in scope for this visit, and what the previous developer left unfinished. A rescue and a campaign are two dates.

Inherited systems that were already in trouble were steadied before new features were piled on. If this Laravel arrived half-failed, do not hand the developer a stabilization and a launch campaign with one Friday on them. Tell the client the order. You will look more reliable on the second call than on the first call that pretended they were the same task.

5. Review on the copy, then name the release

Your review is the checks you wrote, done on the second environment, with you watching one of them. The developer shows the payment or the lead step, or the closest safe stand-in. You compare it to the sentence in the pack. Production is a separate, named release after that, with a time and a person who will look again once it is live. It is not the place the first try happens, and it is not a surprise you both meet on the client call.

• The developer can point at the check that passed, on the copy, before anyone talks about production.
• You have seen one critical flow yourself, or you have said which colleague has.
• The client date matches that order. If it does not, you correct the date before the release, not after the incident.
• The note of what changed is something you can forward to the client without translating a commit.

Keep the passwords out of that note. Keep the customer's private records out of the screenshot you drop in the channel. A handover that protects the date and leaks the data has not avoided a production surprise. It has changed which surprise you get.

When to bring the developer in before you promise

Bring them in before the date is promised when the change touches payments, a database shared by customers, or a system you cannot describe, and whenever a second environment is not confirmed. A developer who arrives after the client has been told the work is nearly done inherits the surprise with you. That is a bad introduction, and it is an avoidable one.

I take that technical side of the handover for agencies: what you own, where the change can be tried, which flows can hurt, then the change itself. Services cover a defined project or an ongoing collaboration on Laravel and backend systems that already have customers. Selected work is the kind of inherited product these handovers land on. If you have a client Laravel to pass across, message me on LinkedIn. Send the ownership list, whether a second environment exists, and the date you have or have not promised. Leave the passwords out.