How I Actually Approach Web Design Projects (and What Most Agencies Get Wrong)

Most web design “process” pages read like a sales brochure: discovery, wireframes, launch, done. The real work is messier and more interesting than that. Here’s how I actually run projects, what I push back on, and the technical decisions that end up mattering a year after launch.

Start with constraints, not mood boards

Before anyone opens Figma, I want to know three things: who has to update this site after launch, what the site has to do to make money, and what we absolutely cannot break. That last one matters more than people expect. If a restaurant site goes down on a Friday night, that’s real money. If a law firm’s contact form silently stops emailing, they might not notice for a month.

A mood board tells me nothing about whether the site will still be fast with 400 blog posts and a third-party chat widget bolted on. Constraints tell me everything.

The performance budget is not negotiable

I set a budget before writing a line of code. For most brochure and small business sites, that looks like this:

• Total page weight under 1MB on first load
• Largest Contentful Paint under 2.5 seconds on a mid-tier phone over 4G
• No layout shift, meaning every image and embed has reserved space
• JavaScript under 150KB compressed unless there’s a real reason

That last one is where most builds fall apart. A typical WordPress site with a page builder, a slider plugin, and three marketing scripts ships 600KB to 1MB of JavaScript to render text and images. That’s the whole problem in one sentence.

What that looks like in practice

Reserving space for images is one line, and it kills most of your cumulative layout shift:

<img
 src="/images/storefront-800.avif"
 srcset="/images/storefront-400.avif 400w,
 /images/storefront-800.avif 800w,
 /images/storefront-1600.avif 1600w"
 sizes="(max-width: 700px) 100vw, 800px"
 width="800"
 height="533"
 loading="lazy"
 decoding="async"
 alt="Front counter at the Commack shop on a Tuesday morning">

The width and height attributes are doing the heavy lifting. The browser knows the aspect ratio before the file downloads, so nothing jumps. AVIF is well supported now and typically beats WebP by 20 to 30 percent on photos.

Accessibility is a build requirement, not a cleanup task

Retrofitting accessibility costs three times what building it in costs. I check four things on every component before it ships:

• Keyboard reachability. Tab through the whole page. If you get stuck, it’s broken.
• Visible focus states. Never outline: none without a replacement.
• Color contrast at 4.5:1 for body text, 3:1 for large text.
• Form labels tied to inputs, not placeholder text pretending to be a label.

Placeholder-as-label is the single most common accessibility bug I find on small business sites. It disappears the moment someone starts typing, and screen readers treat it inconsistently. Just use a real label:

<label for="email">Email address</label>
<input
 type="email"
 id="email"
 name="email"
 autocomplete="email"
 required
 aria-describedby="email-hint">
<p id="email-hint">We reply within one business day.</p>

Pick boring technology on purpose

I’ve watched businesses get locked into a headless CMS, a static site generator, and a deployment pipeline that nobody on staff can maintain. Six months later they can’t change a phone number without calling a developer.

My default for a small business site is a well-configured CMS the client can actually use, a fast host with a CDN, and as little custom JavaScript as possible. For sites that are mostly static content, I’ll go further and pre-render everything, then hydrate only the parts that need interactivity. That’s not a trend. It’s just what makes pages fast.

If you’re weighing this out, I wrote more about the tradeoffs of Long Island web design work and what local clients typically need versus a national brand.

Handoff is where projects actually succeed or fail

Launch day is not the finish line. The finish line is three months later, when the client has updated the site a dozen times without calling me. If they can’t, I built the wrong thing.

So the handoff includes a short screen recording walking through the parts they’ll touch, a one-page doc of what not to do (don’t paste from Word, don’t upload 6MB phone photos, don’t install plugins without asking), and a real conversation about what happens when something breaks.

What I say no to

I turn down work when the brief is “make it look like this other site but different,” when there’s no one on the client side who owns the content, or when the budget only covers design and not the build. Those projects don’t fail loudly. They just quietly rot.

Saying no early is cheaper for everyone than saying yes and delivering something nobody can maintain.

FAQ

How long does a typical small business site take?
Four to eight weeks for a focused brochure or service site, assuming content is ready. Most delays come from missing copy and photos, not code.

Do you use WordPress or custom code?
It depends on who’s updating the site and how often. WordPress is often right. Sometimes a pre-rendered static site is faster and cheaper to host. I’ll tell you which fits your situation instead of defaulting to one.

What do you need from me to start?
A rough goal, examples of sites you like and hate, your existing content if you have it, and one person who can make decisions. That’s enough to scope the work and give you a real number.