How I Build Fast, Modern Websites in 2026

Most websites don’t fail because someone picked the wrong font. They fail because nobody decided what the site was supposed to do. I’ve built enough of them at this point that my process has less to do with tools and more to do with forcing the right decisions early, when they’re cheap to make. Here’s how I actually work on a project, start to finish.

Start with the business goal, not the sitemap

The first conversation is never about pages. It’s about what has to happen for the project to be worth the money. A restaurant wants reservations or online orders. A law firm wants qualified consultation requests, not traffic. A B2B company wants demo bookings from people who fit their customer profile. If we can’t name that outcome in one sentence, we’re not ready to talk about layout.

From there I push for the one action that matters. Not five. One. It’s fine to have secondary actions (call, email, newsletter), but they get designed as secondary. The moment you give three buttons equal weight, you’ve given the visitor a decision they didn’t come to make. I’ve watched this play out dozens of times: a homepage with “Contact Us,” “Learn More,” “Download Our Guide,” and “Follow Us on Instagram” all competing in the hero. Nobody clicks any of them.

I also ask about the constraint that kills most redesigns: who has to update this thing after I’m gone? If the answer is “nobody, it’s static,” that changes the stack. If the answer is “our office manager updates it weekly and she hates computers,” that changes it a lot more. Getting this wrong is how you end up with a beautiful site that’s stale in six months.

Plan the structure and content before design

I write the page list and the purpose of each page before I open a design tool. Every page needs a job. If two pages do the same job, one of them is a problem, usually because it’s competing with the other in search results. This is also where I map out what the visitor needs to believe before they’ll take the action. For a contractor, that’s proof you’ve done this exact work before, in this area, without drama. For a SaaS product, it’s clarity on what the thing does and what it costs.

Content comes next, and I mean real content, not lorem ipsum. I ask clients to send me whatever they have: old brochures, service descriptions, the emails they send customers, photos from jobs. Then I shape it. Writing the actual headlines and body copy in the wireframe stage does two things. It exposes pages that don’t have enough substance to justify existing, and it stops us from designing around fake text and then cramming real text into a layout that can’t hold it.

This part is unglamorous and clients sometimes want to skip it. Skipping it is the single most reliable way to add two weeks and a round of revisions to a project. The design decisions get easier once the words exist.

Pick the leanest stack that fits

Two paths, and I choose based on the client’s reality, not my preference.

Custom code when the site needs to do something specific, load fast, and stay fast. Typically that’s a hand-built front end, often with a static site generator or a lightweight framework, deployed to a CDN. No plugin sprawl, no database to maintain unless it’s actually needed, and page weight measured in tens of kilobytes instead of megabytes. This is the right call for marketing sites that need to be quick, for anything with unusual interactions, and for clients who care about the details. It’s what I mean when I talk about custom web development.

Clean WordPress when the client genuinely needs to publish content themselves and doesn’t want to call me every time. WordPress is fine. It powers a huge chunk of the web and it’s not going anywhere. The problem was never WordPress. The problem is what people bolt onto it: three page builders stacked on each other, a theme that loads 40 scripts, an SEO plugin doing what the theme already does.

So I use WordPress with a lightweight custom theme or a minimal starter, the block editor for content, and a short list of plugins that each do one thing. No Elementor, no Divi, no WPBakery. Page builders are convenient for the person building and expensive for the person visiting. They generate deeply nested markup, inline styles, and CSS you can’t reason about. I’ve inherited sites where the homepage HTML was 4,000 lines before any content. That’s not a design problem, it’s a debt problem, and the visitor pays the interest in load time.

The rule I use: if a plugin can be replaced by 15 lines of code, it gets replaced by 15 lines of code. Fewer moving parts means fewer things to break, fewer security holes, and a site that a future developer can actually read.

Design mobile-first, and mean it

Mobile-first isn’t a slogan, it’s an ordering decision. I design the narrow view first because that’s where the constraints are real and where most of the traffic is. When the phone layout works, the desktop layout is mostly a matter of using the extra space well. Do it the other way around and you end up with a desktop design that gets chopped into a pile of stacked boxes on a phone.

Practically, that means: readable type without zooming, tap targets that are actually tappable (44px minimum, per the WCAG guidance), forms that don’t fight the on-screen keyboard, and no hover-dependent interactions. I check the design against a 360px-wide viewport before anything else. If the primary action isn’t reachable with a thumb, it’s not done.

I also stop treating mobile as a lesser experience. Same content, same functionality, just arranged for the screen. Hiding the phone number on mobile because “it looks cleaner” is a good way to lose the call.

Build with performance and accessibility from the start

Performance is a build-time decision, not a cleanup task. If you wait until launch to run Lighthouse, you’re choosing between shipping slow and rebuilding. I’d rather not have that conversation.

What that looks like in practice:

• Semantic HTML. Real <header>, <nav>, <main>, <button>, and heading levels that descend in order. This is the foundation for both screen readers and search engines, and it costs nothing.
• Images sized correctly, served in modern formats (AVIF or WebP with fallbacks), with explicit width and height so nothing jumps as the page loads. That single attribute prevents most layout shift.
• Fonts self-hosted, subset, and loaded with font-display: swap. No render-blocking requests to a third party just to show text.
• JavaScript that earns its place. If a feature works without JS, it works without JS.
• Color contrast checked against WCAG AA, focus states that are visible (not outline: none with no replacement), and every form field with a real label.

Core Web Vitals are the scoreboard here: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. They’re not abstract. LCP is roughly “how long until the visitor sees the main thing.” INP is “how long until the page responds when they tap.” CLS is “did the page move while they were reading.” Every one of those maps directly to whether someone stays or leaves. I test against the numbers Google publishes in its web.dev documentation, and I check them on a throttled connection, not my office fiber.

Accessibility gets the same treatment, and not as a legal checkbox. Accessible sites are usually just well-built sites. Keyboard navigation, proper labels, sufficient contrast, and sensible heading structure help everyone, including the person on a phone in bright sunlight with one hand.

Set the SEO foundation while you build

SEO isn’t a phase after launch. It’s baked into structure, and retrofitting it is painful. The pieces I handle during the build:

• URL structure that reflects how people search, with one clear topic per page and no orphan pages.
• Title tags and meta descriptions written for humans, not stuffed with keywords. The description doesn’t directly affect ranking, but it affects whether someone clicks.
• One H1 per page and a heading hierarchy that mirrors the content outline.
• Structured data where it’s genuinely applicable: LocalBusiness for a local company with an address and hours, Service for what they offer, FAQPage for a real FAQ, Article for posts. I don’t add schema that doesn’t describe something actually on the page, because that’s how you get manual actions.
• Internal linking that connects related pages with descriptive anchor text, so both visitors and crawlers understand what’s related to what.
• A sitemap and clean robots.txt, plus canonical tags to prevent duplicate URLs.

Here’s a minimal example of the kind of local business schema I’ll add to a homepage:

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "LocalBusiness",
 "name": "Example Plumbing",
 "url": "https://example.com/",
 "telephone": "+1-631-555-0123",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "100 Main St",
 "addressLocality": "Commack",
 "addressRegion": "NY",
 "postalCode": "11725",
 "addressCountry": "US"
 },
 "areaServed": "Long Island, NY",
 "openingHoursSpecification": [{
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
 "opens": "08:00",
 "closes": "17:00"
 }]
}
</script>

That’s it. Accurate, verifiable, and it describes what’s on the page. I go deeper on all of this when I handle the SEO foundation for a client, but the point is that it’s part of the build, not an add-on.

Test on real devices, not just a resized browser

DevTools device emulation is useful and it is not the same as holding a phone. I test on an actual iPhone, an actual Android device, and at least one older or slower phone, because that’s what a chunk of the audience is using. I also test on a real laptop, a tablet, and with the browser at 200% zoom, which catches layouts that break when text scales.

Then the boring checks that catch real bugs: forms submitted end to end (including the confirmation email landing in the inbox, not spam), every link clicked, the 404 page, keyboard-only navigation through the whole primary flow, and a screen reader pass on the main pages. I run Lighthouse and PageSpeed Insights, but I treat them as a starting point. The number matters less than whether the site feels fast when you use it.

If something’s slow, I fix the cause. Usually it’s an unoptimized hero image or a third-party script someone added without asking. Occasionally it’s my own code, and I’d rather find that before the client does.

Launch with measurement already in place

Launch day is not the finish line. Before the site goes live I make sure analytics is installed and configured, conversion tracking is firing on the actual action (form submit, call click, booking), and Search Console is verified with the sitemap submitted. If a client can’t tell me how many inquiries came in last month, the site is a guess, and I don’t like shipping guesses.

I also set up a simple baseline report: what’s getting traffic, what’s converting, and what’s being ignored. That’s what makes the first post-launch review useful instead of a vibe check. Usually within 60 to 90 days there’s a clear signal about which page is doing the work and which one needs to change.

One more thing I do at this stage: write down how to update the site. A short doc, sometimes a screen recording, covering the handful of tasks the client will actually do. It saves a phone call and it means the site stays current.

The short version

Good web design in 2026 isn’t about picking the trendiest framework. It’s about deciding what the site is for, writing the content before designing around it, choosing the smallest stack that does the job, and building performance and accessibility in from the first line of markup instead of bolting them on later. Most of the value is in the decisions you make before you write any code. The code is just where those decisions become visible.

FAQ

How long does a website project actually take?

For a focused marketing site with five to ten pages, usually four to eight weeks from kickoff to launch. The variable isn’t the build, it’s the content and the feedback loop. If copy and images are ready and decisions get made promptly, it moves fast. If we’re waiting on text or collecting feedback from six people, it stretches. I’d rather tell you that upfront than pad a timeline.

Do I need WordPress, or should this be custom code?

If you’ll be publishing content regularly and want to do it yourself, WordPress with a clean custom theme is the right answer. If the site is mostly fixed marketing pages that need to load fast and stay stable, custom code is usually better and cheaper to maintain. The honest test is: who’s updating it, and how often? Answer that and the choice is obvious.

Why not just use a page builder? It’s faster to build.

It’s faster to build and slower to live with. Page builders generate bloated markup and CSS that’s hard to optimize, which shows up directly in Core Web Vitals and load time. They also lock you in, so a future redesign means starting over. A lean theme or custom build takes a bit longer upfront and saves you from a site that fights you for years. I’ve rebuilt enough builder sites to know which one clients regret.