One website problem? Write a repair brief before buying a rebuild

A frustrating page does not automatically justify replacing a whole website. If customers cannot find a phone number, start with that path. If one form fails, investigate the form and its delivery. A new visual design can leave the original fault untouched when nobody has described it precisely.

For a Houston service business or a business serving customers nationwide, the useful first purchase may be a bounded diagnosis and repair. The aim is not to prove the site is bad. It is to establish what happens, who is affected and how you will know the work is complete.

Replace the complaint with an observable task

“The website is old” is an opinion. “On this phone, the service page has a horizontal scrollbar and its inquiry button is outside the visible area” is a reproducible problem. Record the page address, device, browser, approximate time and the steps taken. A screenshot can help, but do not include customer messages, passwords or other private information.

Use a short problem statement: “A visitor trying to request a repair cannot identify the next step after reading the services.” Then separate observation from assumption. You may observe that the button is missing; you cannot infer from that alone how many customers left or what revenue was lost.

Make a one-page repair brief

• Task: what the visitor is trying to do, in ordinary language.
• Evidence: the exact page, reproduction steps and safely redacted image or error text.
• Boundary: the pages and functions the provider may change.
• Completion check: the action that must work afterward on agreed devices.
• Dependencies: who controls the website, form provider, domain and inbox.
• Approval: who can accept the change and authorize additional work.

Illustrative example: a fictional home-repair business has a form that shows a success message but no inquiry appears in its system. The brief should require checking the actual server acceptance and storage, not merely making the success message look nicer. If the email provider then fails, the application needs honest handling of that separate delivery state. No customer outcome is assumed by this example.

Use a small decision test

A targeted repair fits when the affected area is identifiable, the existing platform remains maintainable and the owner still has usable access. A broader review becomes reasonable when several important journeys fail, content is fundamentally disorganized, or the current system cannot support agreed requirements without extensive rework.

Neither missing search metadata nor an isolated lab-speed result is enough by itself to choose a rebuild. Website Opportunity Review can supply observations from a public page and limited supporting pages. It does not test private systems or submit the site's forms. Google’s Web Vitals guidance also distinguishes lab observations from measurements of real visitors; compare like with like before drawing a conclusion.

Ask for a repair option and a rebuild option separately

Request a description of the repair, what will not change, what access is needed and the acceptance check. If a provider also recommends a rebuild, ask which remaining problem the rebuild solves that the repair cannot. A useful answer identifies structure, platform constraints or required functions rather than relying on “modern” or “premium.”

Keep domain ownership, existing email and important URLs in either discussion. A small CSS repair should not silently become a platform migration. A new contact form should not silently become a custom CRM integration. Where the root cause is still unknown, agree the investigation before committing to a fixed implementation scope.

Verify the actual task after the change

Walk the same path on the agreed desktop and phone screens. Check keyboard access, readable labels, the visible result and, with permission, the destination system. A contact-path check should use an agreed safe test rather than sending unsolicited messages. Record any limitations, including browsers or external delivery that were not checked.

Keep the before-and-after evidence with the accepted brief. That gives the next provider a useful record without pretending a repair guarantees rankings or inquiries. If the evidence instead supports broader work, our website process and written-scope guidance explains that discussion, and pricing separates the standard approved-brief website offer from more involved work.

A useful next step

Write the single visitor task you most want to improve, then collect one example of it failing. Bring that brief to a website inquiry. We can discuss whether a focused fix, further investigation or a separately scoped rebuild fits; an inquiry is not a purchase.