How I Build Websites: A Working Web Developer’s Approach in 2026

People ask me what “my approach” actually means, which is fair, since the phrase shows up in a lot of agency copy and means almost nothing. So here’s the real version. It’s less a philosophy and more a set of habits I’ve settled into after enough projects where the shortcuts came back to bite me.

Start with the boring questions

Before I open an editor, I want to know three things: who’s going to update this site after I hand it over, what happens when it breaks at 11pm, and what the site actually needs to do to be worth the money. That third one kills a lot of feature requests, which is a good thing. A restaurant doesn’t need a customer portal. A contractor doesn’t need a blog with 400 SEO posts nobody reads.

Most of the sites I build are for small businesses around Commack and the rest of Long Island, plus a handful of remote clients. The scale is usually modest. That’s exactly why I care about the boring stuff. There’s no team of ten to absorb a bad decision.

Hand-written code beats plugin soup

I build custom themes and static sites instead of stacking page builders. Not because page builders are evil, but because every plugin is a future maintenance problem, a security surface, and a performance tax. When I write the markup myself, I know exactly what’s on the page. When something renders wrong two years later, I can read the code and fix it in ten minutes instead of reverse-engineering a drag-and-drop layout.

This is the core of what custom web development means to me: the site fits the business, not the other way around.

A real example: the mobile nav

Here’s a nav toggle I’ve used on a dozen sites. It’s accessible, it’s tiny, and it doesn’t need a library.

<button class="nav-toggle" aria-expanded="false" aria-controls="site-nav">
 Menu
</button>
<nav id="site-nav" hidden>
 <a href="/services/">Services</a>
 <a href="/work/">Work</a>
 <a href="/contact/">Contact</a>
</nav>

<script>
const btn = document.querySelector('.nav-toggle');
const nav = document.getElementById('site-nav');
btn.addEventListener('click', () => {
 const open = btn.getAttribute('aria-expanded') === 'true';
 btn.setAttribute('aria-expanded', String(!open));
 nav.hidden = open;
});
</script>

Note the aria-expanded and the fact that the nav is hidden with the hidden attribute rather than display:none in a stylesheet. Screen readers and keyboard users get the right behavior without extra work.

Performance is a budget, not an afterthought

I set a target before I start: under 200KB of JavaScript on the initial load, LCP under 2.5 seconds on a mid-range phone over 4G. That’s the Core Web Vitals “good” threshold and it’s been stable for years. If a feature pushes me past the budget, the feature gets cut or rewritten.

In practice that means:

• No client-side framework for a marketing site. Server-rendered HTML is faster and simpler.
• Images served as AVIF or WebP with explicit width and height to stop layout shift.
• Fonts self-hosted, subset, and loaded with font-display: swap.
• Third-party scripts (analytics, chat widgets, pixels) audited every six months. They creep in and never leave on their own.

Accessibility isn’t a separate project

I check contrast, keyboard navigation, and form labels as I build, not at the end. Retrofitting accessibility is expensive and usually half-hearted. Doing it inline costs almost nothing. Semantic HTML does most of the work for you if you stop reaching for <div> when you mean <button>.

What I hand over

Every project ends with a short Loom video, a written doc covering how to update the common things, and credentials to every account in the client’s own name. I’ve seen too many businesses locked out of their own domain because a previous developer registered it under his personal email. That’s not a technical problem, it’s a trust problem, and it’s easy to avoid.

I also stay reachable. Most clients send me a text when something looks off, and I fix it. That ongoing relationship is a bigger part of the job than the initial build.

FAQ

Do you use WordPress or build from scratch?

Depends on the client. If they need to publish content weekly, WordPress with a custom theme is the right call. If it’s a five-page brochure site, static HTML is faster, cheaper to host, and has almost no attack surface. I pick based on who’s maintaining it, not on what I feel like writing that week.

How long does a typical site take?

A small business site with 5 to 10 pages usually runs 3 to 5 weeks from kickoff to launch. Content is almost always the bottleneck, not code. If you have your text and images ready, it moves fast.

What happens if I want to leave?

You take everything. Domain, hosting, code, database, analytics. No hostage situations, no “transfer fee.” I’d rather have a client who stays because the work is good.