Web Design Tools I Actually Use in 2026 (and What I Dropped)

In 2026 I build with VS Code, Cursor for AI-assisted edits, zsh, Vite, and Tailwind, all tools that ship fast sites without locking clients into monthly fees. I dropped heavier page builders and subscription plugins because they slowed builds and added costs small businesses shouldn't pay.
Part of the complete web design guide.
On this page
Every year the tool list churns. Some things stick because they solve a real problem, and some things get dropped the moment they slow me down or lock me into someone else’s pricing. Here’s what’s actually on my machine in 2026, why it’s still there, and a few tools I walked away from.
I build sites for small businesses and agencies, mostly around Long Island web design work, so the bar is simple: does this tool help me ship a fast, maintainable site without adding a monthly bill I can’t justify to a client?
Editor and Terminal
VS Code is still the default, but I’ve moved most of my actual editing into Cursor or a similar AI-assisted fork. Not because the autocomplete writes the site for me (it doesn’t), but because it’s genuinely good at the boring parts: renaming a prop across twelve files, writing the boilerplate for a form handler, or explaining a stack trace I haven’t seen before.
The terminal is still where the real work happens. I use zsh with a light prompt, and I keep a small set of aliases in ~/.zshrc that save me hours a month:
alias gs="git status -sb"
alias gp="git push origin HEAD"
alias ll="ls -lah"
alias serve="npx serve ."
alias ports="lsof -iTCP -sTCP:LISTEN -P -n"
That last one has saved me more times than I can count. When something won’t start because port 3000 is already taken, you want to know what’s holding it.
Build Tooling: Vite, Still
Vite is the default for anything that isn’t a plain static site. Cold starts are fast, HMR is instant, and the config stays small. For a marketing site or a small app, this is the whole setup:
npm create vite@latest my-site -- --template vanilla
cd my-site
npm install
npm run dev
I don’t reach for a framework on every project. If a site is five pages and a contact form, hand-written HTML and a bit of CSS will outperform almost anything you bolt on top of it. Frameworks are a cost you pay in complexity, and you should only pay it when the project actually needs reactivity or routing.
CSS in 2026
I write plain CSS again. Container queries, :has(), nesting, and custom properties have closed most of the gap that made Sass and preprocessors necessary. A layout that used to need a library is now a few lines:
.card-grid {
display: grid;
gap: 1.5rem;
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
}
.card:has(img) {
padding-block-start: 0;
}
@container (min-width: 40rem) {
.card {
display: flex;
gap: 1rem;
}
}
Tailwind still has a place on larger team projects where consistency matters more than raw CSS literacy, but I’ve stopped reaching for it on small sites. The build step and the class soup aren’t worth it when the CSS is this capable.
Version Control and Deploys
Git and GitHub, unchanged. What changed is where things deploy. For static sites and small apps I use Cloudflare Pages or Netlify. Push to main, it builds, it’s live, and the preview URLs make client review painless. For anything with a real backend and a database, I’ve been happy with managed Postgres plus a small Node or Go service.
One habit worth building: keep a .nvmrc or set the Node version explicitly in your build settings. Half the “works on my machine” deploy failures I see are a version mismatch between local and CI.
What I Dropped
- Heavy page builders. The output is bloated, the markup is unmaintainable, and clients get stuck when they want to change something.
- Preprocessors for small projects. Native CSS caught up. Adding a compile step for nesting alone is a bad trade now.
- Analytics that ship a giant script. A small, privacy-respecting script or server-side logging tells me what I need without tanking Core Web Vitals.
- jQuery on new builds. It did its job for fifteen years. Modern DOM APIs do the same work without the dependency.
How I Pick a Tool
Three questions, every time:
- Does it make the site faster or slower for the person loading it?
- Can the next developer (or me in six months) understand it without a manual?
- What’s the real cost, including the monthly bill and the exit path if I want to leave?
If a tool can’t clear all three, it doesn’t go in the stack. That’s the whole filter. The tools change every year, but the questions don’t.
FAQ
Do I need to use the same tools as my developer?
No. What matters is that the finished site is fast, accessible, and something you can maintain or hand off. The tool is a means, not the deliverable.
Is AI-assisted coding worth it for small business sites?
It helps most on repetitive work and debugging, and helps least on architecture and design decisions. It’s a speed boost, not a replacement for knowing what you’re building.
What’s the single biggest performance win in 2026?
Shipping less JavaScript. Most small business sites don’t need a framework at all, and cutting one is a bigger win than any optimization you’ll do afterward.


