Before You Pay to Rescue a Stalled Build, Gather These Seven

A useful rescue review starts with access and evidence. Gather these seven items so a reviewer can assess what exists, what is missing and what is worth keeping.

A stalled build leaves a business owner with two problems: unfinished software and an unclear picture of what they actually have. A demo may work, but nobody knows where the code lives. The website may be online, but the previous developer controls the hosting account.

Before paying someone to finish the project, gather the materials they need to inspect it. Otherwise, a review can become a search for logins, missing files and decisions buried in email.

The goal is not to organize everything perfectly. It is to make the project accessible enough that a reviewer can distinguish working software from unfinished work, and reusable parts from parts that need repair.

Gather access to the actual build

Start with the systems that hold and run your software. Screenshots and demonstrations help explain the product, but they cannot replace access to the underlying build.

1. The source code repository

Ask for access to the repository, the place where the project's source code and change history are stored. Confirm that it includes the latest work, not just an early version.

Request:

• The repository location and access for a business-controlled account
• Confirmation of which version is currently live
• Any unfinished work stored elsewhere
• Instructions for running the project and its tests

Ask whether separate repositories exist for the website, back office or mobile app. If you receive a downloaded folder instead, ask the developer to confirm whether it includes the change history and all the code needed to run the project.

TEFY's existing project completion service begins with a review of the codebase and related materials. It is not the right route if no source code can be provided.

2. Hosting and deployment accounts

Hosting is where the software runs. Deployment is the process that puts a version of the code online. Your reviewer needs to understand both.

Collect the account names, account owners and access details for the live environment and any test environment. Include databases, file storage, deployment settings and available backups.

Ask which services are still being billed and whether anything is scheduled for cancellation. Do not shut down an unfamiliar service just because it appears unused. It may hold customer uploads or run a background task.

3. Domain and DNS access

Your domain account controls the renewal and ownership details for your web address. DNS settings direct that address to your website, email and other services.

These may be managed separately from hosting. Ask for the domain registrar, the DNS provider, the renewal date and the account owner for each.

Confirm that your business controls the recovery email and multi-factor authentication arrangements. A working website does not prove that you can move it or renew its domain.

Collect the services and decisions behind it

The code rarely tells the whole story. External services, design files and written requirements explain how the product was meant to work.

4. Third-party service accounts

List every external service the product relies on, such as payments, transactional email, customer records, analytics or AI model access.

For each service, identify:

• What it does
• Who owns and pays for the account
• Whether it uses test or live credentials
• How an authorized reviewer can receive access

For an AI feature, also request prompts, evaluation cases and any records describing what data is sent to the model. A chat window alone does not show whether the feature has been tested on the business task it is supposed to handle.

5. Editable design files

Ask for editable design files, prototypes, brand assets and any notes explaining the intended user journey.

Images of screens are useful references, but editable files make it easier to inspect states and interactions. For example, a checkout design should explain more than the successful payment screen. Failed payments and incomplete submissions matter too.

If the implemented product differs from the designs, record which version reflects the current agreement.

6. The original brief and later specifications

Gather the original brief, requirements, technical notes and any later changes approved by email or in project tools.

Include setup documentation, known defects, test results and handover notes where they exist. Missing documents should be marked as missing, not quietly reconstructed as if they were original agreements.

TEFY's general approach begins with understanding the workflow, users, data and constraints. For existing projects, the review covers code, architecture, dependencies, defects, tests, documentation, access and outstanding work. These documents help establish context without relying entirely on memory.

7. A list of what was promised and what works

Create a plain-language list of the agreed features. Beside each one, record whether it works, partly works, fails or has not been checked.

Keep expectations separate from observations. For example: “Customers should receive an order confirmation” is a requirement. “The test order appeared in the dashboard, but no email arrived” is an observation.

Include agreed exclusions and later additions. This helps a reviewer distinguish defects from new scope.

Send one clear handover request

You can send the following checklist to the previous developer this week:

“Please help us assemble the project handover materials:

• Source repositories, latest work and confirmation of the live version
• Hosting, deployment, database, storage and backup access
• Domain registrar and DNS access, including renewal details
• Third-party service inventory, account ownership and access
• Editable designs, prototypes and brand assets
• Original brief, specifications, approved changes, documentation and tests
• Agreed feature list, outstanding work and known defects

For anything unavailable, please state what is missing and who may hold it. Please use account invitations or an agreed secure transfer method rather than sending passwords by email.”

Give the request a clear response date. Keep a record of what arrives and what remains outstanding.

Share access safely, then choose the next step

Do not paste passwords, secret keys or customer records into a shared checklist. Use named account invitations with only the permissions needed for the review. Agree how sensitive material will be handled before sharing it.

Once the materials are assembled, clarify the review scope and price. TEFY's review is scoped and priced before work begins. After the review, TEFY agrees a completion plan with a fixed quote.

If key access is still missing, prioritize recovering it. If the materials are ready but the route is unclear, a free fit call can help determine the next step.