How I Approach Web Design in 2026 (and Why It Works)

Most web design advice online is written to sell you something. This is the opposite. This is how I actually approach building a site in 2026, from the first conversation to the day it goes live.

Start with the job, not the look

The first question I ask a client isn’t “what colors do you like.” It’s “what does this site need to do for your business.” A restaurant needs hours, a menu, and a tap-to-call button that works on a phone. A contractor needs proof of work, a service area, and a form that actually lands in an inbox someone reads. A SaaS company needs a clear value prop and a fast signup path.

Design decisions fall out of that. If the job is “get more phone calls,” the phone number goes everywhere and the hero section is short. If the job is “explain a complicated service,” you need room to breathe and real content, not a stock photo of people shaking hands. I’ve watched too many projects start with a mood board and end with a site nobody can use.

Performance is a design constraint, not an afterthought

In 2026, a slow site is a broken site. Google’s Core Web Vitals still reward real-world speed, and users bounce fast. I set a budget before I write a line of code and I hold to it. For most small business sites that means:

• Largest Contentful Paint under 2.5 seconds on a mid-tier phone over 4G.
• Total JavaScript under 150KB gzipped for a content site. Yes, that’s achievable.
• Images served as WebP or AVIF, properly sized, lazy-loaded below the fold.

That last point matters more than people think. The most common performance killer I see is a 4MB hero image that someone uploaded straight from a camera. Here’s the fix at the markup level:

<img
 src="/images/hero-1200.avif"
 srcset="/images/hero-800.avif 800w,
 /images/hero-1200.avif 1200w,
 /images/hero-2000.avif 2000w"
 sizes="(max-width: 700px) 100vw, 1200px"
 width="1200" height="675"
 alt="Finished kitchen remodel in a Commack home"
 loading="eager"
 fetchpriority="high">

That one block, done right, does more for perceived speed than any plugin you can buy.

Accessibility is not optional and it’s not hard

Accessible sites are better sites. They’re easier to navigate, they rank better, and they don’t get you sued. The basics cover 90% of real problems:

• Every image has meaningful alt text, or empty alt if it’s decorative.
• Color contrast hits at least 4.5:1 for body text.
• Everything works with a keyboard. Tab through your own site. If you get lost, so does everyone else.
• Form fields have real labels, not just placeholder text that disappears when you type.

None of this is exotic. It’s just attention. I check it before launch, not after a complaint.

Build on boring, reliable tools

I’ve used every framework and CMS you can name. For most clients I reach for boring tools that will still be maintained in five years. WordPress with a lean custom theme for content-heavy sites. A static build with something like Astro or Eleventy when the site is mostly marketing pages and speed is the priority. Plain HTML and CSS when the project is small enough that a framework would be overhead.

The framework matters less than the handoff. Can you edit your own hours without calling me? Can you add a blog post without breaking the layout? If the answer is no, I built the wrong thing.

A quick word on AI tools

I use them. They’re good for scaffolding, refactoring, and catching dumb mistakes. They are not good at knowing what your customers need or why a section feels off. The judgment is still the job. Auto-generated copy and auto-generated design both read exactly like what they are, and people can tell.

What a real project looks like

I work out of Commack and most of my clients are on Long Island or in the New York area, though remote work is normal now. A typical small business site runs four to six weeks:

• Week 1: goals, content inventory, sitemap.
• Weeks 2-3: design and build in parallel. I don’t hand off a static mockup and disappear.
• Week 4: content, accessibility pass, performance pass, cross-browser testing.
• Week 5+: launch, then a check-in at 30 days to fix what real traffic reveals.

If you want the longer version of how I run projects, it’s on my Long Island web design page. The short version is that I tell you what I’d do, I tell you what it costs, and I don’t pad the scope.

Honest pricing beats cheap pricing

I quote a flat number per project, not an hourly rate that punishes you for asking questions. Small business sites usually land in a range, and I’ll give you that range on the first call so nobody wastes time. What I won’t do is quote low and nickel-and-dime you later. That’s how you end up with a site that limped across the finish line and a client who never calls again.

FAQ

How long does a website take to build?

Four to six weeks for most small business sites, assuming content is ready. Content is almost always the bottleneck, not code.

Do I own the site when it’s done?

Yes. You own the domain, the hosting account, and the code. I’ll set it up in your name from day one so there’s never a question.

Can you fix a site someone else built?

Often, yes. Send me the URL and I’ll tell you honestly whether it’s worth fixing or cheaper to rebuild. Sometimes the honest answer is rebuild, and I’ll say so.