Web design
Most small business websites fail in one of two ways. Either nobody can find them, or people find them and leave before the page finishes loading. Both are fixable, and both are decided long before anyone argues about colors.
A site should do three things: come up when someone searches for what you do, load quickly enough that they stay, and make the next step obvious. Everything else — the animation, the layout, the photography — is in service of those three or it is decoration.
Before any design, the site needs a list of the things a customer types when they need you — and those are rarely the words a business uses about itself. A roofer's customers search 'roof leak repair', not 'exterior envelope solutions'. That list becomes the page structure, because a page can only rank for one thing well.
A single page trying to cover four services ranks for none of them. Splitting them means each page can answer one question completely, which is what both a reader and a search engine are looking for. It also means you can see which service is actually bringing in work.
Design that comes first produces boxes that copy then has to be squeezed into, which is how sites end up padded with filler. Writing first means the layout is shaped around what there is to say, and it surfaces the pages that turn out to have nothing behind them — better to find that now than after they're built.
The page content is written into the file at build time rather than assembled in the browser. Google can render JavaScript, but it does so on a slower second pass, and most AI assistants don't run it at all — so a client-rendered site can be visible to Google and invisible to ChatGPT and Perplexity. Static HTML is also simply faster.
Every page gets checked before it ships: title present and unique and the right length, description present, canonical absolute and self-referencing, one h1, images with alt text and dimensions, valid structured data, sitemap matching the pages that actually exist, and no internal link pointing at a 404. If anything fails, the build fails.
You get the repository, the domain configuration, and a documented deploy. Nothing is locked to a proprietary builder or a monthly platform fee, and nobody has to ask permission to change a phone number.
Usually this is a findability problem rather than a design problem. If the site is one page, or every page shares the same title, or the content only appears after JavaScript runs, then there is very little for a search engine to match a query against. The fix is structural, not cosmetic.
Most local searches happen on a phone, often on mobile data. A hero image that is fine on office wifi can take several seconds on a phone, and the visitor is gone before it appears. Image weight is the single most common cause, and it is one of the easiest things to fix.
Sometimes it is competitive difficulty and there is no quick answer. Often it is something concrete and unglamorous: no unique title tags, a canonical pointing at the homepage, the site not in the sitemap, or content thin enough that Google has clustered it with a competitor's. Those are diagnosable in an afternoon.
A common and genuinely difficult position, especially when the domain, hosting and site are spread across accounts nobody has the logins for. Recovering control of the domain is the first priority, because everything else can be rebuilt and that cannot.
Often it can be fixed, and it's worth checking before spending on a rebuild. If the structure is sound and the problem is missing metadata, slow images or thin content, that's repair work. If the site is a single page, or built on a platform that won't let you control titles and URLs, a rebuild is usually cheaper than fighting it.
It depends almost entirely on how quickly the content comes together, not on the build. The technical work is predictable; waiting on photos, service descriptions and decisions is what stretches timelines. Sites where the owner has their material ready move dramatically faster.
Yes, and you'll own it. Text and images live in plain data files rather than being buried in code, and you get the repository. There's no platform subscription you have to keep paying to keep the site online.
A list of what you sell, anything you already know about what customers ask you, photos of real work if you have them, and access to your domain. Real project photos matter more than most people expect — they're the part a competitor can't copy.
Search Google for site:yourdomain.com. If it returns one result, or none, search engines cannot see most of your website — and no amount of design work will fix that.
Ask who owns the domain, who owns the site if you stop paying, and what happens if the designer disappears. Those three answers tell you more than any portfolio.
In most cases it's images — full-size photos sent to phone screens. It's also usually the cheapest thing on the site to fix, and it's the most common reason a page fails Google's speed thresholds on mobile.
If you want to know where your current site actually stands before spending anything, ask and I'll go through it and tell you what I find — including when the honest answer is that it doesn't need replacing.
Send over your domain and you'll get back a specific list of what's working and what isn't — including when the honest answer is that nothing needs replacing.