What 50+ websites across different industries taught me

I have built 50+ websites for travel agencies in the UK, US and Gulf. Around them I've built web apps for healthcare, education, real estate, finance and automotive clients. After enough of them, the patterns get hard to miss.

Most of what I've learned is not about code.

The code is the predictable part

Early on, I thought a project's risk sat in the technical choices. Which framework, which database, which host. Those choices matter, but they are rarely why a project runs late.

Projects run late because the homepage text hasn't arrived. Or because the owner wants to see three logo options after the build has started. Or because nobody knows who holds the login for the domain registrar, and the person who set it up left the company two years ago.

I now ask about those things in the first conversation. Who owns the domain? Who writes the content? Who approves changes, and how many people is that? A project with one approver and a clear content owner is easier than one with a faster developer and five opinions.

Content decides whether a site works

A good design with weak content still doesn't work. A plain design with clear content often does.

On travel sites, visitors want the same things: what is included, what it costs, when it leaves, how to ask a question. If those answers are buried, the site loses people regardless of how it looks. I'd rather have a clean page with every answer on it than an animated one that makes people hunt.

The same applies to other industries. A clinic site needs opening hours and how to book where people can find them in two seconds. A school site needs the admissions process written in plain language. A property site needs listings that are accurate and recent.

Most visitors are on a phone

I design for a phone first and let the desktop version follow. Not because it's fashionable. The people using a travel site at night are on their phones, and a site that works well on a small screen almost always works well on a large one. The reverse is not true.

Speed belongs here too. Google publishes targets for its Core Web Vitals: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of real visits. I treat those as a floor, and I check them on a mid-range phone, not on my own laptop.

The usual causes of a slow site are boring. Huge images. Too many third-party scripts. Fonts loaded three ways. Fix those and most sites improve.

Pick the tool the client can live with

I've used WordPress on some sites and code frameworks on others. Neither is better in the abstract.

If the owner will edit pages every week and has no developer, a content management system that they understand beats a clever custom build that only I can change. If the site is closer to an application, with accounts, bookings or dashboards, a framework gives you control that a theme won't.

Choosing the stack your client's team can maintain is part of the job. I'd say it's the most underrated part. A site that looks great and breaks the first time someone edits it is a bad result.

Each industry has its own way to go wrong

The engineering is similar across industries. The risks are not.

• Travel: enquiries are the product. Seasonality, changing prices and people messaging at odd hours all shape the design. A slow reply loses the sale.
• Healthcare: privacy first. What you collect, where it's stored and who can see it matter more than any visual detail.
• Education: many types of user, from students to staff to parents, each needing different things from the same system.
• Real estate: the data is the site. If listings are stale or wrong, nothing else saves it.
• Finance: trust is the product. Wording, clarity and the absence of overpromising matter as much as the layout.
• Automotive: images and inventory. Large photos and frequent updates put pressure on performance.

Knowing which of these applies before you start changes what you build first.

Basic search hygiene still pays off

Google's own starter guide is plain about the basics: a unique, clear title for each page, a short description that summarises it, headings that break content into sections, descriptive link text and images with useful alt text. None of that is exciting. Most of the sites I'm asked to fix are missing at least half of it.

Hand over properly

The part nobody sees is the handover. When I finish a project, the client should know where the site is hosted, who owns the accounts, how to make a change and who to call when something breaks. Writing that down takes an hour and saves a bad week later.

It's also why I keep notes on what I decided and why. Six months on, someone will ask, and the honest answer should not be "I think I had a reason."

What I'd tell someone starting out

1. Ask who owns the domain, the content and the final say before you write any code.
2. Build for phones first and measure on a real device.
3. Use the simplest tool the client can maintain.
4. Learn what each industry is afraid of.
5. Write the handover document while the details are fresh.

After 50+ sites, I still find the first step is the one that gets skipped.