How I Actually Approach a Website Build (Not the Marketing Version)

Most "how I build websites" content is written to sound impressive. Mine isn't going to do that. I want to walk you through the actual five steps I use — the reasoning behind each one, and what happens when a step gets skipped, because I've watched it happen. I recently ran this exact process on my own website, fabianhendricks.com, so instead of talking in hypotheticals, I'm going to show you the real audit findings and what I did about them.

If you're an entrepreneur or creator sizing up whether to trust someone with your site, you don't need a sales pitch. You need to see how someone actually thinks. So here's how I think.

I've spent 24 years in UX and conversion work, across corporate and independent projects, and the pattern is the same regardless of budget: sites that struggle almost never fail because of one dramatic mistake. They fail because five ordinary decisions got made out of order, or made without anyone asking why. This process is my answer to that — not a formula for making things "look nice," but a sequence for making sure the right questions get asked before the wrong ones do.

Why this process exists at all

A website build has a hundred small decisions hiding inside it — font size, button colour, whether the testimonial goes above or below the pricing table. If you make those decisions one at a time, in the order they occur to you, you end up with a site that feels like a hundred small decisions. Disjointed. A bit precious in places, thin in others.

The five steps below exist to force decisions to happen in the right order, so that by the time you're picking button colours, the things that actually matter — clarity, trust, speed — are already locked in.

Step 1: Audit before anything

Before I touch a single design element, I audit what exists. Not a vague "does this look good" scan — a specific list of what's broken, what's stale, and what's quietly costing trust.

When I ran this on my own site, the audit turned up five concrete issues:

• A broken newsletter icon in the footer — small, but it's the kind of thing a visitor notices in half a second and quietly downgrades their opinion of you.

• A call-to-action that hadn't been updated to match where the business actually is now.

• Testimonial photos that weren't rendering correctly.

• A hero image that was generic enough to belong to any consultant, in any industry.

• A blog that was thin — a handful of posts, no real cadence, nothing that signalled ongoing authority.

None of these are dramatic. That's the point. A site rarely fails because of one big mistake. It fails because of five small ones that each say, quietly, "this wasn't finished." The audit's job is to find those five things before a visitor does.

An audit worth doing looks at a site the way a stranger would, not the way its owner does. Owners stop seeing their own site after a while — the broken icon has been broken for three months and you've trained your eye to skip past it. A visitor hasn't. They see it in the first second, and first seconds are expensive. So the audit process is deliberately mechanical: go section by section, page by page, and write down only what's factually true. Is this link working. Is this image loading correctly. Does this heading describe what's actually below it. Is this the most recent version of this offer, or a leftover from six months ago.

What an audit is not: it's not a redesign brainstorm. At this stage I'm not thinking about solutions, and I'm actively resisting the urge to. The moment you start solving problem one, you stop looking for problems two through five with a clear eye — you've already shifted into "fix it" mode, and fix-it mode makes you rush the rest of the list. So I build the whole list first. Solutions come later, once I know everything I'm actually solving for, not just the first thing I noticed.

Skip this step and what usually happens is a redesign that fixes the one problem the owner already knew about — the CTA everyone complained about in a meeting — while leaving the four they'd stopped noticing untouched. The site looks "refreshed" and still quietly leaks trust in the same four places it always did.

Step 2: Structure before style

This is the step most people skip, and it's the one that causes the most expensive rework later.

Structure means: what does this page need to say, in what order, before anyone thinks about what it should look like. This is the wireframe stage — boxes and labels, no colour, no imagery, no font choices. Just: hero, then what, then what, then what.

The reason this comes before the mockup isn't aesthetic preference. It's cost. If you design the look first, every structural change afterward means redoing finished visual work. If you lock the structure first — and get agreement on it — the mockup stage becomes fast, because you're only deciding how something looks, not what it is or where it goes.

On my own revamp, this step is where the stale CTA problem actually got fixed. Swapping in better wording is a five-minute job. Realising the CTA was answering a question visitors weren't asking anymore — that only shows up when you strip the page back to structure and ask, "what is this section's job?"

There's a second reason structure comes first, beyond cost: it's the only stage where you can have an honest conversation about content with a client before either of you gets emotionally attached to how something looks. It's much easier for someone to say "actually, I don't think we need a team section" when it's a labelled grey box than when it's a beautifully shot photo they've already fallen in love with. Wireframes are disposable by design. That's a feature, not a limitation — it keeps the conversation about what the page needs to do, not about whose favourite colour won.

I'll also say plainly: this is the step that separates a site built to look like a professional built it from a site built by someone who actually understands why pages convert or don't. Anyone can pick a nice template. Structuring a page so each section earns the next scroll is a different skill, and it's invisible in a portfolio screenshot — you only feel it when you're the visitor moving through the actual page.

Step 3: Decide what earns the top of the page

Above-the-fold — everything a visitor sees before scrolling — is the most contested real estate on your site, and also the most commonly mishandled. The instinct is to put your best-looking asset there. That's usually wrong. The correct question isn't "what looks good here," it's "what does a stranger need to believe in the next four seconds to keep reading."

For most Christian entrepreneurs and creators building a personal brand, that's some combination of: who you are, what you help with, and one piece of evidence you're not making it up. Rarely is it a stock photo of a laptop on a desk.

The generic hero image on my own site failed exactly this test. It wasn't wrong, exactly — it just wasn't doing a job. It was decoration standing where evidence should have stood. Fixing it wasn't about finding a "nicer" image. It was about finding an image, or dropping the image entirely in favour of a stronger headline, that actually earned its position.

A useful discipline here: for every element above the fold, ask what it's arguing for. If the honest answer is "nothing, it just looks nice," it either needs a job or it needs to move down the page.

This is also where faith-based positioning tends to go wrong in one of two directions. Some sites lead so hard with faith language above the fold that a visiting stranger has no idea what the business actually does — the credibility case never gets made because the space got spent on identity instead of evidence. Others go the opposite way and scrub every trace of it, which can feel like hiding something you're not actually ashamed of. Neither serves the visitor. The above-the-fold section has room for one clear argument, maybe two. For most people reading this, that argument should be competence first — who you help and proof you can — with everything else, including how faith shapes your work, earning its place further down the page once trust exists to build on.

I'd also flag the most common above-the-fold mistake I see, beyond the wrong hero image: a headline that describes the business owner's aspiration rather than the visitor's problem. "Helping you build a life of purpose" tells a stranger nothing about what happens if they hire you. "I build websites that convert for faith-based entrepreneurs, without the six-month agency timeline" tells them exactly what they're getting. The first sounds nicer in a pitch meeting. The second is what actually earns the scroll.

Step 4: Design mobile-first, then scale up

More of your traffic is arriving on a phone than you probably think, especially if you're publishing content that gets shared. Designing for desktop first and "making it responsive" afterward tends to produce a site that works on desktop and merely survives on mobile.

Designing mobile-first flips the constraint. You're forced to decide, immediately, what actually matters — because a phone screen won't let you cheat with extra whitespace or a five-column layout to hide the fact that you haven't prioritised anything. Whatever earns its place on a cramped 6-inch screen will look even better once you have the room of a desktop layout. The reverse isn't true.

This also connects directly back to Step 3. The above-the-fold decision is at its hardest, most honest, on mobile — there's simply less "fold" to work with. If your hero section survives a phone screen, it'll survive anywhere.

Mobile-first also changes things that aren't obviously "design" decisions. Form fields get more expensive on mobile, because typing on a phone keyboard is slower and more error-prone than typing on a desktop — so every unnecessary field you ask for costs you more abandoned submissions than the same field would on desktop. Load speed matters more, because mobile visitors are more likely to be on an imperfect connection and less likely to wait. Tap targets need to be sized for a thumb, not a cursor, which sounds trivial until you've watched someone miss a button three times in a row on a site that wasn't tested for it.

None of this means desktop becomes an afterthought once mobile is handled. It means desktop becomes an addition — more breathing room, more visual layering, more real estate to work with — layered onto a foundation that already works under the tightest constraint. Building it the other way around means your mobile experience is whatever survived after the desktop layout got compressed, which is a very different, and usually worse, starting point.

Step 5: Finish machine-readable

This is the newest step in the process, and increasingly the one that determines whether your site gets found at all. AI systems — search assistants, answer engines, the tools your future clients are already using instead of typing a query into Google — read your site before a human ever does. If your structure is a mess of unlabelled divs and your content is vague about who you are and what you actually do, the machine reading it can't summarise you accurately, which means it won't recommend you accurately either.

Practically, this means: clear headings that describe what's actually in the section, content that states plainly what you do and who you do it for (not just brand language), and a blog that gives ongoing, dated evidence that you're active and credible — not a thin, stale one.

That thin blog I found in my own audit wasn't just a content gap. It was a machine-readability gap. A blog publishing twice a week gives search and AI systems a constant, dated signal: this person is real, active, and worth surfacing. A blog with four posts from eighteen months ago gives the opposite signal, regardless of how good those four posts are.

There's a technical layer to this too, and it's worth naming even briefly: clean, semantic HTML structure, sensible page titles, and content that answers a specific question in a specific section — rather than burying the answer in a paragraph of brand voice — all make it easier for an AI system to extract exactly what your page says and represent it accurately elsewhere. This is a genuinely new consideration in web design, not a rebrand of old-fashioned SEO. Traditional SEO optimised for a ranking algorithm a human would then click through from. Machine-readability optimises for a system that might answer the visitor's question directly, using your content as the source, without them ever clicking through at all. Both matter. They're not the same skill.

For a small business owner, the practical takeaway is simple: state things plainly, date things consistently, and publish often enough that the "last updated" signal never goes stale.

Putting it together

Audit, then structure, then above-the-fold, then mobile-first, then machine-readable. Each step exists to make the next one cheaper and more honest. Skip the audit and you redesign around problems you never named. Skip structure and you pay for it in rework. Skip the above-the-fold discipline and your best real estate gets wasted on decoration. Design desktop-first and your mobile visitors get an afterthought. Ignore machine-readability and you become invisible to the tools more of your future clients are starting to use first.

None of this is exotic. It's mostly discipline about sequence — doing things in the order that makes each subsequent decision easier and cheaper, instead of the order that feels most natural to jump into. That's really the whole difference between a site that was designed and a site that just happened.

If you want to see the individual pieces of this in more depth, I've written separate posts on the wireframe-versus-mockup decision, how I decide what earns the above-the-fold, what mobile-first actually changes in practice, and what machine-readable design really means now that AI reads your site first. Start wherever your own site's weakest step is — that's usually the fastest way to know which post to read next.