Paying for a website rebuild before the real problem is clear

I keep getting the same enquiry. The site feels slow, checkout is flaky, or every plugin update turns into an afternoon of repairs. Someone has already quoted a full rebuild. Before anyone pays for that, I want to know which problems a rebuild would actually solve.

A focused technical review is usually the cheaper first move. It turns a vague worry into evidence, priorities, and a next step you can explain to a business partner who has never opened the code.

Agree the decision you need

Audit my website is too vague. Are we asking whether checkout can be made reliable without ripping the store out? Whether an inherited Laravel app can take another year of work? Or why a routine WordPress update keeps breaking the same area?

I pin that question first. Then the review has a purpose, and you have a way to judge whether the answer was useful.

A review of one problem is not a full security audit, accessibility pass, SEO crawl and code rewrite in one go. Those are different jobs. The scope should say what is in, what is out, and where a further look might be needed.

What I put in the written review

The checks change with the question. The deliverable should still cover five things.

• A plain description of the problem, who it hits, and when it shows up.
• Evidence. What was checked, what was seen, and what supports the diagnosis.
• Priorities based on business impact, not a wall of warnings.
• Options. Repair, improve in stages, or replace.
• A next step, how it will be tested, and what is still uncertain.

A PageSpeed screenshot is not a decision. I want each serious finding tied to something customers or staff actually feel.

Evidence has to match the pain

If staff say saving a product takes forever, I look at that task. If customers drop at checkout, I want the failing journey, not a clean homepage test.

Useful evidence is a repeatable sequence, a relevant error, a working vs failing comparison, or a clear note of where the process stops. Specific enough for a developer to act on. Not a dump of raw logs for you to decode.

I also separate a confirmed cause from a strong suspicion. Those imply different confidence and different spends of your money.

Repair, staged fix, or rebuild

I look at all three. Existing systems often hold business rules that are easy to miss when someone is selling a clean slate. Keeping a mess forever is expensive too, if every change is a workaround.

A focused repair fits when the broken area is understood, the rest still works, and the fix can be verified.

Staged improvement fits when the system is still useful but a few areas need attention. Smaller decisions. Something working after each stage.

A rebuild is worth considering when the required changes are broad enough that replacement is the clearer route. The proposal still has to cover data, integrations, staff workflows, and the move. Those do not vanish because the design is new.

For each option I ask the same thing. What is different for the business when this is done?

Agree what done looks like

A useful review makes the follow-on work easier to scope. Acceptance checks should sit around the original problem.

• Broken form. The submission reaches the right place with the expected confirmation.
• Flaky integration. Representative records arrive, and failures are visible to the right person.
• Awkward admin task. Staff can finish it without the old workaround.

Use the circumstances that caused the pain, not the easiest demo path. Spell out exclusions. Then you can decide if the finish line is enough before you approve the spend.

What helps before we start

You do not need a technical brief. A short note on what is going wrong and how it hits the business is enough to talk.

• One or two examples, with rough dates.
• What you expected instead.
• How often it happens and who feels it.
• Any recent changes you know about.
• Any deadline or business event that shapes the decision.

Access comes after scope is clear. Do not send passwords, payment details, or customer records in the first message. A description, or a screenshot with private bits removed, is usually better.

How I run reviews at DawsonyWeb

Technical reviews start from £295 for an agreed area of investigation. You get a written diagnosis, prioritised recommendations, and a quote for the next step. The review fee is credited against development booked within 30 days. I confirm scope before work starts.

You work with me directly on WordPress, WooCommerce, and Laravel systems. Some enquiries are clear enough to scope as a smaller fix without a paid review. If an investigation is needed first, I will say what it is meant to answer.

I also look after ongoing WordPress and WooCommerce care when the issue is less rebuild and more steady breakage. Details sit on the service pricing and WordPress and WooCommerce support pages.

Technical reviews from £295

If the site is hurting and the rebuild quote arrived before anyone checked the real fault, start with the review. Cheers.