You’ve spent evenings choosing colours, moving sections around and trying to make your website work. It looked straightforward when you started. Now the mobile layout is a mess, the contact form isn’t reliable or there’s one feature you simply can’t get working. You’ve already put time and money into it, so starting again feels like admitting defeat.
You don’t necessarily need to start again. A developer may be able to finish, repair or simplify what you’ve built, whether you used WordPress, Wix, Squarespace or an AI website builder. The sensible next step is to establish what’s actually stopping the site from working and whether the existing build is worth keeping. Here’s how I’d approach that decision.
1. Work out exactly where you’ve got stuck
“My website doesn’t work” covers too much ground. Are visitors unable to submit a form? Does the layout break on a phone? Can you edit pages without accidentally changing others? Or does everything function but the site still doesn’t bring in enquiries?
Write down the problems in plain English, starting with the ones affecting customers. Include the page address, what you expected to happen and what actually happened. A short list of specific faults is much easier to assess than a general request to “finish the website”.
2. Decide whether this is a technical problem or a business problem
If a booking button fails, that’s a functional fault. If visitors can book but don’t understand what they’re booking, that’s a content and conversion problem.
I’ve seen how easy it is to spend days tweaking design details while leaving the important customer questions unanswered. Before commissioning another round of development, ask whether your website explains what you do, who it’s for, why someone should trust you and what they should do next. My guide to websites that get traffic but no enquiries covers that second problem in more detail.
3. What parts of your DIY website are worth keeping?
A self-built website isn’t automatically bad. Replacing all of that would waste the effort you’ve made.
I’d separate the work into three groups:
- Keep: accurate content, usable layouts and features that work reliably.
- Repair: broken forms, mobile problems, inconsistent styling and fixable configuration issues.
- Replace: elements that can’t be maintained safely or don’t support what the business needs.
This isn’t something to decide by looking at a homepage screenshot.
4. Why one apparently small change can become complicated
You may only want a new field on a form, but that field could affect notifications, customer records and a third-party service. On an AI-built application, a small change can unexpectedly alter another part of the workflow. On a heavily customised WordPress site, a page builder or plugin may control more than it appears to.
That’s why a responsible developer shouldn’t quote a complex repair on confidence alone. They need to understand the relevant setup first. If somebody promises everything can be fixed immediately without knowing what they’re taking over, be cautious.
5. Can another developer take over an AI-built website?
Sometimes, yes. It depends on whether the code, hosting, database and essential services are accessible and whether the project can be maintained outside the original tool. A working demonstration isn’t necessarily a maintainable production website.
Ask where the actual website runs, who controls the accounts and whether the source code can be exported. If an AI builder only provides limited access or relies on proprietary features, you may be restricted to what that service supports.
6. What should you prepare before asking for help?
You’ll get a more useful answer, and usually a more realistic estimate, if you can provide a concise handover.
- Your website address and the platform used to build it.
- A list of faults, with the most urgent first.
- What customers should be able to do when it’s finished.
- Any deadline or dependency, such as a product launch.
- Whether you control the domain, hosting and relevant accounts.
Don’t email passwords around. Access should be shared securely, and only when there’s an agreed reason to inspect the project.
7. Should you pay for a diagnostic before paying for repairs?
For a straightforward, clearly visible change, a developer may be able to price the work directly. For an unreliable form, an AI application with several integrations or a website behaving differently across devices, a paid diagnostic is often a better starting point.
That investigation should identify the fault, likely causes, whether it’s repairable and what the next work involves. Repair is a separate decision. You’re buying clarity before committing to a larger bill. Be wary of both extremes: somebody charging for an elaborate audit of a trivial task, or somebody offering a firm repair price without understanding a complicated failure.
8. When is a rebuild better than repairing the site?
A rebuild makes sense when fixing the existing setup costs nearly as much as replacing it, when the platform cannot support an essential requirement or when each change creates another problem. It can also be worthwhile if the business itself has changed so much that the current structure no longer fits.
It isn’t justified simply because a developer prefers another platform. Ask for a clear comparison: what can be kept, what must be replaced, the likely cost of each route and the risks involved. If you’re weighing that decision, read the signs your website may need replacing.
9. Agree what “finished” means before anyone starts
It’s surprisingly easy for an open-ended rescue job to grow. You ask for a working website, then the conversation moves into new pages, animations, integrations and SEO campaigns. Some may be useful, but they’re not automatically part of the original job.
List the outcomes that matter: the form submits and delivers messages, mobile navigation works, key pages are editable and checkout or booking functions are tested. Then agree what’s excluded, how variations are quoted and who signs off the result. That protects your budget and gives the developer a sensible brief.
10. How do you stop getting stuck again?
Once the site works, make sure you understand who updates it, where the accounts are and how changes should be tested. Keep a record of important licences, integrations and any custom functionality. If you use WordPress, ongoing website maintenance can help manage updates and backups without turning every small change into a new emergency.
You should also be able to make ordinary content edits without depending on a developer for every sentence. A sensible handover gives you that control while making the limits of safe DIY changes clear.
Get the site working without wasting what you’ve built
You’ve already invested time in this website. Don’t throw it away out of frustration, but don’t keep patching it just because you’ve spent money on it either. Identify the customer-facing problems, establish whether the platform can support the solution and get a clear scope before authorising work.
If you’re stuck with a DIY or AI-built website and want to know whether it can be finished properly, book a call. Tell me what you’ve built and where it’s failing, and I’ll explain the sensible next step. Any investigation beyond an initial conversation can then be scoped as paid work.