Start with the business problem
Describe what a visitor cannot do and what your business needs restored. A missing image and a failed payment deserve different priorities. Separate urgent failures from improvements you would like while someone is working on the site. Give each issue its own entry so the developer can investigate and estimate it separately.
Report observations without deciding the cause. For example: the contact form shows a success message, but the sales inbox receives nothing. That gives the developer something to reproduce. Saying the form plugin is broken narrows the investigation before anyone has checked it.
If a critical journey is failing, pause unrelated edits and record what changed most recently. Tell the developer whether you need an immediate temporary measure, a permanent repair, or both. Ask them to explain the limits of any temporary measure and how the full repair will follow. Avoid making several speculative changes while someone is investigating.
Prepare a brief someone can investigate
A useful brief does not require technical vocabulary. Walk through the failure as a customer would, from the starting page to the point where the result differs from what you expected. Include the exact error wording and whether the problem happens every time or only sometimes.
Supply a screen recording if the steps are difficult to describe. Remove customer details, account information, and anything entered into payment fields. Mention unsuccessful fixes too; they are part of the investigation history.
Example problem brief: “The contact form shows success, but the sales inbox receives nothing. Expected: one message with all entered fields and a confirmation to the visitor. Observed: no inbox message after a test submission. Please investigate delivery before proposing a replacement. We can supply a staging account and a recent backup; our site owner approves publication.” Add the affected URL, browser, time of the test and a recording if useful. Use approved test data, and share credentials by the agreed access method.
- Affected task: what the visitor or editor is trying to do.
- Reproduction steps: where to start, what to click, and what to enter using test information.
- Expected and actual result: describe both in plain language.
- Environment: device, browser, and whether the visitor is signed in.
- Pattern: when you first noticed it, how often it happens, and any recent edits or updates.
- Impact and priority: which business activity is blocked and whether a workaround exists.
- Constraints: important campaigns, people who must approve changes, and areas outside the repair scope.
Map access before promising a start
List the services involved and identify who can invite a developer into each one. Include the website editor, hosting, domain account, source code, deployment service, form delivery, and relevant integrations. Mark anything unknown. You can send this inventory without sending credentials.
Keep business accounts under your control and invite the developer through a separate account where available. Ask which permissions the investigation needs and why. WordPress uses roles and capabilities to control permitted actions; the right access depends on the work. Do not assume an editor login is sufficient for every repair.
For an agency sub-project, name the person who approves access and the person who approves release. Decide whether communication goes through the agency or directly to the business. If the original developer is available, request setup notes and a technical handover. Missing documentation is useful information, not a reason to pretend the setup is understood.
Hire for the existing system
Tell candidates which platform the site uses, if you know. Ask how they would investigate this particular issue within that setup. For a custom website, ask how they will obtain the code, run it, and understand how changes reach the live site. For a site managed through a hosted editor, ask what access they need to inspect its configuration and custom additions.
Ask for a walkthrough of relevant technical work they can discuss. Focus on the reasoning: what failed, how they isolated the cause, and how they tested the result. Attractive screenshots tell you little about diagnosing a broken integration.
A useful candidate can explain what remains unknown. Be cautious about a firm repair promise made without seeing the system, or a rebuild recommendation supported only by dislike of the original tools. Ask what evidence would change their proposed approach.
- What will you inspect before changing anything?
- What access or information could block the investigation?
- How will you protect the live site and its current data?
- What will I receive if the diagnosis shows the repair is outside the agreed scope?
Separate diagnosis from the repair commitment
When the cause is unclear, commission a bounded investigation. Agree on what the developer will inspect, how much work is authorised, and when they must stop and report back. The deliverable should identify the observed failure, supporting evidence, likely cause, remaining uncertainty, and recommended next action.
Ask whether the investigation may include a small fix, and what approval is needed before a larger change. This avoids an open-ended instruction to keep going until everything looks better. A diagnosis may also identify a dependency on hosting support or another service provider; ask who will handle that conversation.
Use a fixed scope when the repair and acceptance checks are clear. For uncertain troubleshooting, agree on a limit and a review point for hourly work. Compare proposals on included investigation, implementation, testing, release, and handover. A short proposal that omits those tasks is difficult to compare with one that includes them.
Make the scope testable
Write the acceptance checks before implementation. Replace broad requests such as fix the forms with observable outcomes. Name the affected forms, intended recipients, success messages, and failure cases. Include what must continue working nearby, such as another form using the same component.
Use the following examples as a starting point, then adapt them to your actual site. They are proposed checks, not evidence that a particular repair has passed.
| Repair | Acceptance check | Evidence to request |
|---|---|---|
| Contact form | A valid test submission reaches the intended inbox; missing required fields produce a useful message. | Recorded steps and confirmation of receipt using test data. |
| Mobile menu | Visitors can open, use, and close the menu on the agreed devices, including with a keyboard where applicable. | A demonstration covering the agreed navigation checks. |
| Checkout failure | The affected purchase journey completes in the agreed test setup, and a failed payment shows a useful next step. | Test order details and results for both success and failure. |
| Broken layout | The affected content remains readable and usable at the agreed screen sizes. | Before-and-after captures with the tested sizes identified. |
Agree on backups, testing space, and rollback
Before edits begin, ask what will be backed up, where it will be stored, and how restoration will be checked. WordPress documentation distinguishes site files from the database; a typical full restoration needs both. Ask for the equivalent recovery plan for your site's actual setup.
Request a separate test copy where practical. Agree how customer data will be excluded or reduced, and how test activity will avoid sending customer messages, taking real payments, or reaching fulfilment systems. Have the developer document any important differences between that copy and the live site.
Define who can approve release, what failure would trigger rollback, and who will carry it out. For sites receiving orders or submissions, ask how new records will be preserved during recovery. Do not approve restoring an older database without understanding what happens to activity recorded since that backup. If work must happen live, agree on a narrower change and immediate checks.
Ask for evidence before accepting a rebuild
An inherited website may need a targeted repair, replacement of one component, or broader rebuilding. Ask the developer to distinguish the immediate fault from longer-term maintenance concerns. A broken form alone does not explain why every page should be redesigned.
For each proposed option, request the affected areas, dependencies, testing work, and unresolved risks. Ask what can be retained and whether the urgent problem can be addressed independently. If replacement is recommended, request a concrete explanation of what prevents a maintainable repair.
Treat a rebuild as a separate scope with its own content, integration, migration, and acceptance decisions. Decide what happens to existing pages, editing workflows, accounts, and historical records. The question is whether the proposed work meets the business need with an understandable ongoing maintenance burden. A preference for a different framework is not enough evidence on its own.
Review the result as a working website
Run the agreed acceptance checks yourself or nominate someone who understands the workflow. Start from the same conditions that produced the original failure. Ask the developer to show both the successful journey and the relevant error state, using test information.
Check adjacent behaviour affected by shared components. If the navigation changed, inspect it across the relevant page templates. If form delivery changed, check the intended destination rather than stopping at a success message. For an intermittent issue, agree on an observation period and a way to record recurrence instead of treating one successful attempt as conclusive.
After release, repeat the critical checks on the live site under agreed conditions. Record anything that remains unverified because access, a provider, or a particular device was unavailable. Decide explicitly whether that limitation blocks acceptance or becomes a follow-up task.
Close the handover while the work is fresh
Request a concise record of the cause, changes, checks, and remaining issues. Ask where the current code and configuration notes live, how future changes should be released, and how to recover from a failed change. Another developer should be able to understand the repair without reconstructing it from chat messages.
Confirm what follow-up is included if the reported fault returns, how to report it, and what counts as new work. Assign responsibility for maintenance rather than assuming the repair created an ongoing arrangement. Remove temporary access that is no longer needed and record any access retained for agreed support.
- The original issue and acceptance results are recorded.
- Changes and any new service dependencies are documented.
- Business account access and recovery contacts are confirmed.
- Remaining issues have an owner and an agreed next step.
- Temporary access and test materials have been reviewed.
How hehe.software can help
hehe.software is a small, independent web and app studio based in Vancouver, British Columbia, Canada, working remotely with businesses across Canada and the United States. We take fix-it jobs on websites and apps we did not build, including agency sub-projects that can be white-label or credited. Work can start with paid discovery, an hourly assignment, or a fixed-price project; monthly retainers are available for ongoing maintenance. Pricing is quote-only: we scope the work and provide a fixed quote or an hourly estimate. Email mwe@hehe.software or use the contact form with the failure, its business impact, and the access you have.