What your agency needs before hiring a new developer

If your WordPress developer has left a half-built site, start by finding out what your agency can access, what actually works, and what still needs to happen before launch. Those answers make it possible to hire the right replacement and agree on a realistic scope.

The temptation is to send someone the staging URL and ask how quickly they can finish. A staging site can look nearly complete while forms, content editing, integrations, or deployment are still unresolved. Before you promise another launch date, put together a handover that lets a new developer assess the work properly.

Find out what you can actually access

Make a short list of the accounts and materials involved. For each one, record who controls it, whether your agency or client can sign in, and what is missing.

  • WordPress administration and the hosting account, including backups and staging.
  • Domain registration and DNS, the settings that direct traffic to the site.
  • The code repository, custom theme or plugin files, and deployment instructions.
  • Paid plugin and theme licenses, plus accounts for forms, email, CRM, payments, or other connected services.
  • Approved designs, content, specifications, and the current issue list.

Being able to edit pages does not establish that you can move the website or maintain its custom code. Mark uncertain access as unknown. If the previous developer is still available, request the missing materials and a walkthrough. If they are unavailable, tell the replacement developer exactly where access stops.

Use individual account invitations where available. Keep passwords and recovery codes out of ordinary inquiry forms.

Preserve the current site before changing it

Ask the technical person handling the takeover to preserve a full backup and verify that it can be restored somewhere separate from the live site. WordPress needs both its files and its database for a complete restoration, as the WordPress backup documentation explains.

Keep a record of the current behavior too. A screenshot, page URL, and steps to reproduce a problem give the next developer something specific to investigate. Avoid a round of plugin deletions or bulk updates just to see what happens before there is a recovery path.

Testing needs its own safeguards. For a WooCommerce site, check payment test modes and connected services before placing test orders. WooCommerce warns that test orders can still trigger emails and other integrations. A copied site needs its settings checked before anyone treats it as a safe testing environment.

Turn the remaining work into a launch checklist

Gather the original scope, approved designs, client feedback, and development tickets into one list. Then separate four kinds of work:

  • Broken behavior: something that has been built but does not work as agreed.
  • Unfinished scope: something required for launch that has not been implemented.
  • Missing decisions or materials: content, approvals, account access, or answers that someone still needs to provide.
  • Later improvements: useful additions that the agency and client agree can wait.

For each launch requirement, write down how you will know it is complete. A contact form should reach the right recipient and show the expected confirmation. An editor should be able to update a representative page without breaking the layout. A launch plan should name the person who will deploy the site and the checks they will run afterward.

Put an owner beside missing content and decisions. A replacement developer can estimate technical work more usefully when those dependencies are visible.

Get an assessment before committing to the takeover

Ask the new developer to review the implementation, hosting, deployment process, and remaining work before quoting the full rescue. The assessment should explain what can be retained, what needs repair, and which unknowns still affect the estimate.

A useful recommendation leaves room for several outcomes. Targeted repairs may be enough. A smaller launch scope may meet the immediate need. Some parts may need rebuilding. There may also be work that should stop until an underlying decision is resolved.

Ask for reasons you can discuss with your client. A preference for a different page builder is not enough information to approve a rebuild. You need to understand the limitations of the existing implementation and the work required by each option.

Agree on ownership through launch

Before implementation starts, confirm who approves scope changes, who communicates with the client, and who is responsible for deployment. Decide whether the incoming developer will work behind the scenes or join client conversations.

The estimate should say what is included, what depends on your team, and what happens when new issues emerge. It should also make clear what support is included after launch. That gives your agency something concrete to manage when the project starts moving again.

Need a second look at an unfinished build

I work with design agencies on inherited and stalled WordPress projects. Pilotmade’s rescue assessment is $2,500, with a recovery plan delivered within five business days after access is complete. Implementation is scoped separately.

Send me the situation: the site URL, deadline, current blocker, and what access you have. I’ll review the materials and tell you the right next step.