Can you take over a website if our developer has left?

Yes, after reviewing the setup and the access you can provide. The first step is understanding how the site is hosted, how it is built, and what needs attention. Support can then cover agreed fixes, maintenance, and improvements. A rebuild is only recommended when the current system cannot support the work.

Do I need to rebuild the website before you can support it?

No. Many engagements start with maintenance or a targeted improvement. A redesign is for journeys that no longer help visitors or the team. A migration or rebuild is for when the platform itself blocks the work. Those are separate choices, not a required sequence.

Do you only support WordPress?

No. WordPress is one platform I work with. I also work with custom websites, web applications, and integrations. What can be supported depends on the platform, the codebase, and the access available, so I review those before committing.

Can you connect our website enquiries to the CRM we already use?

Often, yes. I start with the form, where enquiries go today, and the CRM you already use. A useful workflow creates or updates a record, assigns an owner, and keeps a copy if the connection fails. A custom CRM is considered only when suitable existing tools cannot meet a clear requirement.

Can you work with our agency on a client project?

Yes. I work with agencies on scoped delivery and ongoing engineering for existing websites, integrations, and applications. We agree communication, client ownership, and handover before starting. That does not imply a referral fee, exclusivity, or white-label terms unless those have been agreed.

Send an enquiry at https://www.asadiqbal.me/work-with-me describing the website, application, or workflow and what you want to improve. I review that and suggest whether a conversation or a scoped assessment is the right next step. You do not need to choose the technical solution first.

When to improve, redesign, or replace an existing website | Asad Iqbal

Most website conversations start in the wrong place. Someone says the site looks dated, a plugin is failing, or a competitor has a newer stack, and the suggested answer is a rebuild.

A rebuild is sometimes the right project. It is a poor default. The useful question is narrower: what is the site failing to do for the people who use it, and for the team that has to run it?

I use three paths. Improve what is already there. Redesign the journey where it is getting in the way. Migrate only when the current platform blocks the work the business needs to do. They are separate decisions. You do not have to buy a rebuild before you can fix the thing that is broken this month.

Start with the work, not the technology#

The GOV.UK Service Standard puts user needs before a solution. That advice travels well outside government. A business website has two groups of users: the visitor trying to understand an offer and take a next step, and the team trying to publish, answer enquiries, and keep the site available.

Before I recommend a platform change I want answers to a few plain questions:

What are people supposed to do on the important pages?
Where do those attempts fail: the form, the content, the speed, the mobile layout, or the handover into email or a CRM?
Who can change the site today, and what takes too long?
What would a successful month look like after the work, in terms the team already understands?

“Move it to the newest framework” is not one of those answers. A newer codebase can be easier to maintain. It can also throw away working content, URLs, and integrations for a visual refresh that does not change how enquiries are handled.

Jakob Nielsen’s long-standing observation still holds: people scan web pages, they do not read them like a brochure. Jakob’s Law adds the other half. Visitors spend most of their time on other sites, so they expect yours to behave in familiar ways. A redesign that hides the offer, the proof, or the next step behind a novel layout often performs worse than a quieter improvement to the pages that already get the traffic.

Improve what is already there#

This is the right starting point when the platform can still support the business, but small problems keep returning.

Typical work in this band:

Forms that fail quietly, ask for too much, or send enquiries into an inbox nobody owns.
Pages that are slow or jump around while they load.
Content that no longer matches how the business sells.
A handover after a previous developer has left: hosting, accounts, dependencies, and a short list of known issues.

Google’s Core Web Vitals are a useful check here, not a growth promise. Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift describe whether a page loads, responds, and stays visually stable. They are worth measuring because slow or unstable pages frustrate people. They are not a guarantee of more leads. Lead results also depend on the offer, the traffic, and what happens after someone enquires.

WordPress is one platform I work with. It is not the only one. A custom site, a web application, or a mix of both can be the system you already have. The review comes before any commitment about what can be supported.

Redesign when the journey is the problem#

A redesign earns its place when people cannot tell what you do, who it is for, or what to do next, and tidying the existing templates will not fix that.

The scope should name the journeys, not “the whole website” as a mood. For many established businesses that means the homepage, the service pages, and the enquiry path. It may leave a large content archive, a booking tool, or a logged-in area alone until there is a reason to touch them.

A redesign can improve how clearly the offer is explained and how reliably an enquiry is captured. It cannot, by itself, promise a fixed increase in leads. Agree the measures that matter before the work: completed enquiries, fewer abandoned forms, less time spent correcting bad submissions, or fewer support requests about “how do I change this page”.

Replace the platform only when it blocks the work#

A migration is justified when the current system cannot do something the business actually needs, or when keeping it running costs more attention than the value it returns. Examples I look for:

The team cannot safely change the site because the setup is undocumented and every edit risks the live version.
An integration the business depends on cannot be added, or fails in ways nobody can see.
Security updates are no longer available for a part of the stack you rely on.
The same information has to be copied by hand between the website and the systems that follow up.

Even then, a single cut-over is rarely the safest plan. Martin Fowler’s strangler fig describes a calmer pattern: keep the old system serving what still works, and replace one route or one workflow at a time until the old part can be retired. The name comes from a vine that grows around a tree. The practical point is smaller. You do not have to switch the entire site off to improve the part that is failing.

A migration plan should name, before anyone builds the new version:

which content moves, and which is archived
which URLs must keep working
which forms, payments, or integrations are in scope
how the team will check the important journeys
who owns the site after launch

If those items are vague, the project is not ready to be a migration. It may still be ready as a focused improvement.

A sequence that stays optional#

These are ways to start, not stages a client has to buy in order.

Describe the system, what is going wrong, and what the team needs to do.
Review enough of the setup to recommend a scoped next step.
Agree the work, the responsibilities, and how you will know it is done.
Continue with ongoing support or a further phase only when there is a clear need.

A first conversation establishes whether the work is a fit. A deeper technical assessment is a separate piece of work when the system needs it. I do not offer a free complete audit, and I do not promise a same-day diagnosis of a site I have not seen.

If the website is only half the problem, and enquiries still die in an inbox after they arrive, the next article is the one to read: how a website enquiry becomes an owned follow-up, without assuming you need a new CRM first.

If you want a view on a site you already run, tell me what it needs to do better. Ongoing support for a site that mostly works is a separate conversation.