Working With Clients on a Source Recovery Project

When a client asks you to recover the source of a PHP application they own, you are stepping into a position of trust. Handled well, source recovery restores their control over software they depend on and strengthens your relationship. The professional foundation of that work is confirming the client's rights, agreeing on scope, communicating honestly, and handing off cleanly. This article walks through each of those in turn, so a client recovery project reflects well on you from the first conversation to the final delivery.

Confirm the Client's Rights First

Before any technical work, establish that the client actually owns the software or is authorized to recover it. This is not a sign of distrust; it is standard professional diligence that protects both of you. Ask for the proof:

• An invoice or receipt for the software
• The relevant license or contract
• A development agreement, if the software was commissioned
• Written confirmation that the client owns the code and authorizes the work

It is entirely reasonable, and expected, to require this before you begin. A client who genuinely owns their software will have no difficulty providing it. If a client cannot demonstrate ownership, that is the moment to pause the engagement, not to press ahead on trust alone. Declining to proceed without proof is the responsible position, and a legitimate client will respect it.

Get Authorization in Writing

Verbal approval from a client is not enough for work of this nature. Put the authorization in writing, naming the software, the files in scope, and the fact that the client owns the code and approves the recovery. Have someone with real authority over the software sign it, not merely a point of contact. This written authorization is the backbone of the engagement. It protects the client, protects you, and gives both parties a clear record of what was agreed if any question arises later.

Agree on Scope and Expectations

Recovery projects go smoothly when everyone shares the same picture of the work. Before starting, nail down:

• Exactly which files and modules are in scope
• What the deliverable is, such as readable source for maintenance
• What testing and validation you will perform
• The timeline and the cost, with reference to our pricing
• How the recovered source may be used
• What happens to working copies once the project ends

Write this down in a short statement of work. A clear scope prevents the drift and misunderstanding that turn good projects sour, and it gives you a reference point if the client later asks for more than was agreed. When scope needs to grow, update the document rather than quietly expanding the work.

Communicate Honestly Throughout

Recovered source is a starting point for maintenance, not a guaranteed pixel-perfect reproduction of the original development. Set that expectation early and plainly. Explain that you will validate behavior against the running application and test carefully before anything is relied upon, and that the value you deliver lies in careful, professional handling as much as in the recovery itself. Clients appreciate candor far more than promises that cannot be kept. Avoid any language that sounds like a guarantee of a perfect result; describe instead the diligence you will apply. Honest framing builds the trust that leads to repeat work and referrals.

Handle the Client's Data With Care

A client's application may contain their customers' personal data, their credentials, and their business secrets. During the project, protect that information as carefully as the client would themselves. Keep recovered source and any data in secure locations, limit access to those who need it, and plan to rotate any credentials that appeared in the files once the work is done. Treat the client's data as a responsibility you have taken on, not merely as material to work through. How you handle their data is part of how you demonstrate that their trust was well placed.

Deliver a Clean Handoff

When the project ends, deliver the recovered source in an organized form rather than as a loose pile of files. A professional handoff includes:

• The recovered source, ideally placed under version control
• Notes on what was recovered and how it was validated
• The records that establish the basis for the work
• A clear statement of any follow-up the client should handle, such as rotating credentials

Give the client everything they need to take full control, and remove working copies you no longer need to retain. A clean handoff leaves the client in command of their own software and leaves you with a reputation for doing the job properly.

Set the Stage for Ongoing Work

Recovery is frequently the beginning of a longer maintenance relationship. If the client wants ongoing support, use the handoff as a natural transition. The version-controlled source, the validation notes, and the records you produced all become the foundation for future work. Offering a sensible maintenance plan, without overpromising, positions you as a trusted partner rather than a one-time contractor. Our ionCube decoder and SourceGuardian decoder help you deliver readable source for the code your client owns, and the professional relationship you build around that is where the lasting value lies.

FAQ

What if a client pressures me to skip authorization? Do not. Written authorization protects you both, and a client's reluctance to provide it is a reason to pause the engagement rather than to rush past it.

Should I keep a copy of the source after delivery? Only what you are engaged to retain for ongoing support, stored securely. Otherwise hand it over and clean up your working copies.

How do I set expectations without underselling the work? Be honest about what recovery produces and emphasize the diligence you bring: careful validation, testing, secure handling, and organized delivery. That is real value, and clients recognize it.

What if a client cannot prove they own the software? Pause the work until ownership is established. Recovering software whose ownership cannot be shown is not a risk worth taking, however well-intentioned the client seems.

Who at the client should sign the authorization? Someone with genuine authority over the software, such as an owner, director, or responsible manager, not simply whoever happens to be your day-to-day contact.

Can I offer a guarantee to win the work? Avoid guarantees about the result. Commit instead to the care and process you will apply. Overpromising damages trust when reality falls short, while honest diligence earns it.

Clear rights, clear scope, and honest communication make client recovery projects a credit to your practice. Review our FAQ and pricing, then create an account to get started.