Start with what the site stops you from doing.
“We need a new website” often begins with a frustrating experience: a slow page, an awkward form or a service no one can find. Those problems are real, but they do not all require rebuilding the whole site.
Write down the customer’s task and where it breaks. Can a visitor understand the offer, find the right service, compare the details and send an inquiry? Can your team update those details without asking a developer to change every sentence?
Check the cause before buying the solution. A broken integration needs repair. An unclear offer needs better content. A platform that cannot support essential pages or functions may justify a rebuild. Treating all three as a design problem wastes budget.
When to improve, when to rebuild.
The final choice depends on access to the current code, platform constraints and the agreed scope. Ask a developer to show the limitation rather than simply call the old site outdated.
| What you find | Try improvement first | Consider a rebuild |
|---|---|---|
| Customers cannot understand the offer | Rewrite and restructure the important pages. | The template prevents a usable service-page structure. |
| The site is slow | Inspect images, scripts, hosting and page rendering. | The platform imposes limits that a focused fix cannot remove. |
| Forms or integrations fail | Repair the confirmed failure and test delivery. | Required workflows cannot be implemented reliably. |
| You need another language | Add complete versions if the system supports them. | The system cannot manage separate pages and localized navigation. |
| The business has changed | Update a manageable number of pages. | Most pages, journeys and functionality need replacing. |
A focused fix can be the better investment.
Illustrative situation: a detailing business has a working website, but all services share one vague page and the inquiry form has no reliable confirmation. A new animation will not solve either problem.
The first scope could be clear pages for the actual services, better mobile navigation and a tested form. If the platform supports those changes, keep it. Check that inquiries reach the intended destination, then connect measurement to that accepted submission.
At BeeCited, website optimization starts at $100. Technical maintenance also starts at $100 for a defined task. These are starting prices, not a promise to repair every issue for the minimum fee. A useful quote names the problems and the checks that prove they were fixed.
A rebuild makes sense when the foundation gets in the way.
Consider a business expanding into several languages with an old site that cannot support separate service pages, usable editing or a required integration. Repeated patches can become more expensive and fragile than a planned replacement.
A new site should have an agreed page inventory, a clear content plan and the functions the business needs. Decide whether the work includes frontend only or a backend, content management and integrations. “A website” is too broad to price without that distinction.
BeeCited website development starts at $300. Payment is 50% at the project start and 50% after handover. At the starting price, that is $150 at each stage. Larger scopes receive their own quote before work begins.
48 hours or a few weeks? The scope decides.
We can build a simple site in as little as 48 hours when the brief, content and materials are ready and the scope is agreed. This suits a focused website with a clear purpose, rather than an undefined project that changes halfway through.
Larger projects typically need one to three weeks, depending on the page count, languages, backend and integrations. Content preparation, approvals or external dependencies can affect the schedule. We confirm the delivery plan before starting.
To make the work move faster, supply the actual services, prices where relevant, brand assets and a person who can approve the content. Decide early who owns the domain, accounts and code. Speed comes from clear decisions as well as development.
Keep useful URLs when replacing a site.
A rebuild should start with an inventory of existing pages. Mark which receive useful visits, inquiries or links. Decide what stays, what improves and what is genuinely removed before the new design goes live.
When addresses change, map each old URL to the appropriate replacement and test the redirect. Google warns against sending many unrelated old pages to the homepage; a relevant destination matters.
Our handover checklist also covers internal links, canonical addresses, language versions, indexing settings and form delivery. Check them on the built site, not only in a design preview. A visual upgrade should not leave a visitor arriving at a dead end.
Will a new site make AI recommend the business?
A clear, accessible website gives customers and systems better information to work with. It does not purchase a recommendation. Google’s AI-feature guidance continues to point to normal SEO foundations.
If AI visibility is the goal, inspect the offer, public brand information and sources around the business as well as the site itself. Otherwise you may replace the frontend and leave the reason for weak visibility unchanged.
Agree on what the website project can deliver: useful pages, readable content, clean URLs, appropriate structured data and working customer journeys. Treat wider brand visibility as a separate programme when it requires work beyond the site.
A short brief that helps you avoid buying twice.
Send us that information with your website link. We can discuss a focused improvement or a new build against the same business task, so the decision follows the problem rather than the appearance of a mockup.
- Share the current website and the exact problem customers or your team encounter.
- List the services, languages and functions you need.
- Say what already works and should be preserved.
- Identify required integrations and who controls the relevant accounts.
- Agree on deliverables, a total price, payment stages and acceptance checks.
Sources & further reading
Practical guidance, grounded in the sources below. Examples are illustrative; recommendations are our working approach.
