DEV Community: Impeccify.com

The Tailwind CSS Setup I Use on Every Project

Impeccify.com — Mon, 30 Mar 2026 12:29:27 +0000

I have been using Tailwind CSS for about 2 years now on every project. After a lot of trial and error, I settled on a setup that works well for building client websites and web tools.

Here is exactly what I use and why.

The base config

My tailwind.config.js is pretty minimal. I extend the default theme instead of overriding it.


js
module.exports = {
  content: ["./src/**/*.{js,jsx}"],
  theme: {
    extend: {
      colors: {
        brand: "#e3eb01",
      },
      fontFamily: {
        sans: ["Inter", "system-ui", "sans-serif"],
      },
    },
  },
  plugins: [],
};

I add one or two brand colors and a custom font. Everything else stays default. Tailwind defaults are well designed and I rarely need to change them.

Utility patterns I reuse

Card component

<div class="bg-white dark:bg-neutral-900 border border-neutral-200 
  dark:border-neutral-800 rounded-xl p-6 hover:border-neutral-300 
  dark:hover:border-neutral-700 transition-colors">
  Content here
</div>
Section container
<section class="py-16 md:py-24 px-4">
  <div class="max-w-6xl mx-auto">
    Content here
  </div>
</section>
Responsive text
<h2 class="text-2xl md:text-3xl lg:text-4xl font-bold">
  Heading
</h2>

These three patterns cover probably 80% of what I build.

What I do not use
@apply in CSS files
Tailwind has an @apply directive that lets you extract utility classes into CSS classes. I used it heavily at first but stopped. It defeats the purpose of utility-first CSS. If I need a reusable style, I make a React component instead.

Tailwind plugins
I have tried several Tailwind plugins and always ended up removing them. The default utilities cover everything I need. If I need custom styles, I write them in plain CSS.

Arbitrary values
Things like w-[327px] are a sign that something is wrong with the design. I try to stick to the default spacing and sizing scale. If the design has weird sizes, I round them to the nearest Tailwind value.

Dark mode setup
I use the class strategy for dark mode. This lets me toggle dark mode with JavaScript instead of relying on the OS setting.

// tailwind.config.js
module.exports = {
  darkMode: "class",
  // ...
};

Then I just add the dark class to the html element and all the dark: variants kick in.

Production checklist
Before shipping any project, I check:

All text is readable on both light and dark backgrounds
No horizontal scroll on mobile
All hover states work and look intentional
The brand color is not overused (just CTAs and accents)
Loading states do not flash unstyled content
Tailwind with Next.js
Tailwind and Next.js work really well together. Install it during project setup and it just works. The purge step removes unused classes at build time so the final CSS is tiny.

Our production CSS files are usually 15-30KB. Compare that to a typical WordPress site with 200-500KB of CSS and you can see why our sites load faster.

This is the setup I use for everything at Impeccify. If you are starting with Tailwind, keep it simple. Learn the default utilities first before adding custom config. You will be surprised how far the defaults get you.

Building Free Online Tools Taught Me More About SEO Than Any Course

Impeccify.com — Mon, 30 Mar 2026 12:26:08 +0000

About a year ago I started building free online tools. Calculators, converters, estimators. Things people search for on Google every day.

I built them partly to practice Next.js and partly to see if I could rank on Google. What I learned about SEO in the process was worth more than any course or ebook I had read before.

Real SEO is not what the courses teach

Most SEO courses talk about keyword research, backlinks, and technical audits. Those things matter but they skip the most important thing: building something people actually want to use.

When I launched my first few tools, I focused on keywords with low competition. Things like specific calculator types that bigger sites had not built yet. Within weeks, some of these pages started ranking on page 1.

No link building. No outreach. Just useful tools with good SEO fundamentals.

What actually moved the needle

1. Long form content under the tool

Every tool page on our site has the calculator at the top and a long article below it. The article covers how to use the tool, the formulas behind it, real examples, and frequently asked questions.

This does two things. It gives Google more content to understand what the page is about. And it keeps users on the page longer, which signals to Google that the page is useful.

2. Structured data everywhere

We add FAQ schema, WebApplication schema, and BreadcrumbList schema to every tool page. This helps Google display rich results like FAQ dropdowns in search.

You do not need a plugin for this. Just add JSON-LD script tags with the right data. It is maybe 20 lines of code per page.

3. Page speed

Our tool pages load in under a second. Google PageSpeed scores are 95+ on all of them. This is not because we did anything special. It is because Next.js generates static pages that are fast by default.

4. Solve one problem well

Each tool page does one thing. A px to rem converter just converts px to rem. A nutrition calculator just calculates nutrition. No feature bloat, no confusion.

Google wants to rank the best result for a search query. If someone searches "px to rem converter" and your page is a clean, fast, focused converter, Google will eventually figure that out.

The numbers

After about 6 months of building tools:

40+ indexed pages
5000+ daily impressions
Growing organic traffic month over month

Not life changing numbers but for a new domain with zero budget, it proves the concept works.

What I would do differently

I would pick keyword targets more carefully. Some of my early tools targeted keywords that were too competitive for a new site. I should have focused entirely on keywords with difficulty under 10 for the first 6 months.

I also would have started building backlinks earlier. Good content gets you far but at some point you need other sites linking to you to keep climbing.

Try it yourself

If you want to learn SEO, build something. Pick a calculator or converter that people search for, build it, optimize the page, and wait. You will learn more in 3 months of watching your own pages rank than in any course.

You can check out the tools we have built at impeccify.com/tools to see what I mean. Each one started as a learning experiment and turned into real traffic.

Why I Stopped Using WordPress and Switched Everything to Next.js

Impeccify.com — Mon, 30 Mar 2026 12:24:10 +0000

I used WordPress for years. Built probably 30+ sites with it. Starter themes, page builders, custom themes, the whole thing. Then about two years ago I switched everything to Next.js and I have not looked back.

This is not a "WordPress is bad" post. WordPress is fine for a lot of use cases. But for what I do now at Impeccify, Next.js is just better. Here is why.

Speed difference is not small, it is massive

My WordPress sites loaded in 2-4 seconds on a good day. With caching plugins, CDN, image optimization, and all the usual tricks, maybe 1.5 seconds.

Our Next.js sites load in under 1 second. Some of our static pages load in 300-400 milliseconds. No plugins needed. No caching configuration. It just works because the pages are pre-built at compile time.

This matters because Google uses page speed as a ranking factor. And users leave slow sites.

No more plugin problems

WordPress plugins are both the best and worst thing about the platform. Need a feature? There is a plugin. But every plugin is a potential security risk, a potential performance hit, and a potential compatibility problem.

I spent more time updating plugins and fixing conflicts than building actual features. With Next.js, if I need a feature, I write it. It takes more time upfront but I never wake up to a broken site because some plugin updated overnight.

Hosting costs dropped

My WordPress sites needed decent hosting. Shared hosting was too slow. Managed WordPress hosting was $20-50 per month per site.

Now I deploy on Vercel. The free tier handles most of our sites. When a site needs more, the pro plan is $20 per month. That is less than what I was paying for a single managed WordPress site.

SEO control is better

WordPress SEO plugins like Yoast are great but they are still plugins working within WordPress limitations. With Next.js, I have full control over:

Metadata for every page
Structured data (JSON-LD schemas)
Canonical URLs
Sitemap generation
Robots directives
Open Graph tags

I write the SEO exactly how I want it, not how a plugin interprets what I want.

The learning curve is real

I am not going to pretend this switch was easy. Going from PHP templates to React components is a big jump. It took me maybe 3 months to feel comfortable and 6 months to be as fast as I was with WordPress.

But once you get past the learning curve, you are faster. Building a new page in Next.js takes me less time than it did in WordPress because I am not fighting with a visual editor or trying to override theme styles.

When I still recommend WordPress

I still tell clients to use WordPress when:

They need to edit content themselves frequently
They have a blog with multiple writers
Their budget is under $500 and they just need something basic
They are not technical and need to manage the site alone

For everything else, especially for businesses that want speed, custom design, and good SEO, I go with Next.js.

If you are thinking about switching

Start small. Build one project with Next.js. Maybe a personal site or a simple tool. Get comfortable with the basics before you migrate client work.

We built all our free tools with Next.js and it was a great way to learn the framework while building something useful. Start with something simple and work your way up.

How We Structure Our Next.js Projects (Simple and Boring)

Impeccify.com — Mon, 30 Mar 2026 12:22:59 +0000

Every time I see a "project structure" article it is always some over-engineered setup with 15 folders and custom abstractions. That works for big teams but for a small studio like ours, we keep it simple.

Here is how we organize our Next.js projects at Impeccify. Nothing fancy, just practical.

The folder structure

src/ app/ - Pages and routes components/ - Reusable UI components constants/ - Static data and configuration lib/ - Utility functions hooks/ - Custom React hooks styles/ - Global CSS (minimal with Tailwind) public/ - Static files

That is it. No domain folders, no feature folders, no barrel files. Just the basics.

Why this works for us

The app folder is flat

Every page gets its own folder inside app. We do not nest routes unless the URL structure actually requires it.
src/app/ page.jsx - Homepage tools/page.jsx - Tools hub blog/page.jsx - Blog hub px-to-rem-converter/ page.jsx layout.js chipotle-nutrition-calculator/ page.jsx layout.js

Each tool or page has its own folder with a page.jsx and layout.js. The layout.js handles SEO metadata and structured data. The page.jsx has the actual content.

Components are flat too

src/components/ Navbar.jsx Footer.jsx ChipotleCalculator.jsx PxToRemConverter.jsx FAQAccordion.jsx

No nesting. No index files. Every component is one file with a clear name. When you need to find something, you just search by name.

Constants hold all the data

This is probably the most unusual part of our setup. We put all static data in the constants folder.
src/constants/ chipotleNutritionData.js starbucksNutritionData.js dotsCalculatorData.js

Each data file has the formulas, presets, default values, and reference data for its calculator. This keeps the component files clean. The component handles UI and interaction. The constants file handles data and logic.

Lib is for shared utilities

src/lib/ utils.js paddle.js

Utility functions, API helpers, and third party integrations. We keep this small. If a function is only used in one component, it stays in that component.

What we skip

TypeScript (for now, on small projects it adds time without much benefit for us)
Testing framework (we test manually and in the browser)
Storybook (we do not have enough components to justify it)
Monorepo tools (we deploy one site at a time)
State management libraries (React state and context is enough)

The point

You do not need a complex setup to build real products. We have shipped dozens of tools and service pages with this simple structure. It works because everyone (which is just me most of the time) knows exactly where everything goes.

Pick a structure that matches your team size. For solo developers and small teams, flat and simple beats nested and organized every time.

5 Things I Learned Building 100+ Web Pages with Next.js App Router

Impeccify.com — Mon, 30 Mar 2026 12:20:06 +0000

I have been building websites with Next.js for a while now. Our studio Impeccify has shipped over 100 pages using the App Router and I wanted to share some stuff I learned along the way.

These are not things you read in the docs. These are things you figure out after building real projects for real clients.

1. Metadata setup matters more than you think

Most tutorials show you the basic metadata export and move on. But if you want your pages to actually rank on Google, you need to go deeper.

Here is what we put on every page:

Title with the main keyword near the front
Description under 160 characters with a clear value prop
Open Graph tags for social sharing
Canonical URL to avoid duplicate content
Structured data (FAQ schema, breadcrumbs, etc)

The structured data part is what most people skip. But it is what gets you those rich results in Google search. We add FAQ schema to every tool page and it makes a noticeable difference in click through rates.

2. Do not put everything in a layout file

When I first started with App Router, I tried to put as much as possible in layout files. Navigation, footer, providers, metadata. It made sense at the time.

The problem is layout files do not re-render when you navigate between pages. That is actually the whole point of layouts. But it means if you have any state that needs to reset between pages, it will not work in a layout.

Now I keep layouts minimal. Just the basic wrapper, maybe shared navigation, and that is it. Everything else goes in the page component.

3. Static generation is still the default for a reason

With all the talk about server components and streaming, it is easy to forget that most pages should just be statically generated. If your page does not need real time data, let Next.js build it at compile time.

All our calculator and tool pages are static. They load instantly because there is no server round trip. The JavaScript hydrates on the client for interactivity, but the initial HTML is already there.

For a marketing site or a tool site, static generation gives you the best performance scores. And performance scores affect your Google rankings.

4. Image handling needs a plan

Next.js has the Image component and it is great. But you need a plan for how you handle images across the whole site, not just per page.

Things to decide upfront:

Where do images live? Public folder or external CDN?
What sizes do you need? Define your breakpoints early
Do you need blur placeholders? They look nice but add build time
Are you using SVGs for icons? Do not put SVGs through the Image component

We use Lucide for icons (SVG components), keep most images in the public folder for small sites, and use external CDN for anything with lots of images.

5. Error and loading states are not optional

This one sounds obvious but I see so many sites that just show a blank screen when something goes wrong. Next.js makes error handling easy with error.js and loading.js files.

Every route group should have:

A loading.js with a decent skeleton or spinner
An error.js that actually tells the user something went wrong
A not-found.js for 404s that helps people find what they need

These are small files that take 5 minutes to create but they make a huge difference in how professional the site feels.

Wrapping up

These are things that come from building real sites for real clients. Not everything in web development is about knowing the newest framework feature. Sometimes it is about the boring fundamentals that make your site actually work well.

If you want to see how we apply this stuff, check out the free tools we built at impeccify.com. Things like CSS converters, nutrition calculators, and math tools. All built with Next.js App Router.

YAML vs JSON: What's the Difference and When to Use Each

Impeccify.com — Tue, 17 Mar 2026 17:23:24 +0000

If you've worked with config files, Docker, Kubernetes, or any CI/CD system, you've encountered YAML. If you've built APIs, you know JSON. But when should you use which?

The Syntax Difference

JSON:

{
  "name": "my-app",
  "version": "1.0.0",
  "features": {
    "auth": true,
    "cache": false
  },
  "ports": [3000, 8080]
}

YAML (same data):

name: my-app
version: 1.0.0
features:
  auth: true
  cache: false
ports:
  - 3000
  - 8080

YAML is less verbose and more readable. But it has strict indentation rules.

YAML Gotchas

1. Indentation matters (use spaces, not tabs)

# Wrong
parent:
    child: value  # Tab indented - BROKEN

# Correct
parent:
  child: value  # 2 spaces - WORKS

2. Strings don't need quotes... but sometimes do

version: "1.0"     # Quotes needed - without quotes, YAML reads 1.0 as a float
enabled: "true"    # Quotes needed - without, YAML reads as boolean
port: 3000         # No quotes needed for integers

3. Multi-line strings

description: |
  This is a multi-line
  string that preserves
  newlines.

summary: >
  This is a multi-line
  string that becomes
  one line.

When to Use Each

Use Case	Format	Why
Config files	YAML	More readable, comments allowed
Docker Compose	YAML	Standard
Kubernetes	YAML	Standard
REST API responses	JSON	Universally supported
Package.json	JSON	Node.js standard
Database storage	JSON	No indentation issues
CI/CD pipelines	YAML	Standard (GitHub Actions, etc.)

Converting Between YAML and JSON

Use the free YAML Converter at Impeccify to convert between YAML and JSON instantly. Paste your YAML, get JSON. Paste your JSON, get YAML.

Useful when:

You need to convert config files
You're debugging an API that returns JSON but your config needs YAML
You're onboarding and need to understand an existing config

Linux File Permissions Explained: A Visual Guide to CHMOD (With Calculator)

Impeccify.com — Tue, 17 Mar 2026 17:22:37 +0000

Linux file permissions are one of those things that looks cryptic until someone explains it clearly. Let me be that person.

What Does `chmod 755` Actually Mean?

Every file on a Linux system has three sets of permissions:

Owner (the user who created it)
Group (users in the same group)
Others (everyone else)

Each set can have three permissions:

r = read (value: 4)
w = write (value: 2)
x = execute (value: 1)

The number 755 breaks down as:

7 = 4+2+1 = read + write + execute (owner gets full access)
5 = 4+0+1 = read + execute (group can read and run)
5 = 4+0+1 = read + execute (others can read and run)

Common Permission Numbers

Number	Meaning	Use Case
755	rwxr-xr-x	Web directories, scripts
644	rw-r--r--	Regular files, HTML
600	rw-------	Private keys, secrets
777	rwxrwxrwx	Avoid! Totally open
400	r--------	Read-only sensitive files
750	rwxr-x---	Group-restricted scripts

Symbolic vs Numeric Mode

You can also use symbolic mode:

chmod u+x script.sh    # Add execute for owner
chmod g-w file.txt     # Remove write for group
chmod o=r file.txt     # Set others to read-only
chmod a+r file.txt     # Add read for all

Recursive Permissions

To change permissions for an entire directory:

chmod -R 755 /var/www/html

The -R flag applies the permission recursively to all files and subdirectories.

Setting Web Server Permissions

For a typical web server (Nginx/Apache):

# Directories
find /var/www/html -type d -exec chmod 755 {} \;

# Files
find /var/www/html -type f -exec chmod 644 {} \;

# PHP files that need write access
chmod 664 /var/www/html/uploads/

Use a Visual Calculator

If you find the math confusing, use the free CHMOD Calculator at Impeccify. Just check the boxes for the permissions you want and it gives you the number automatically.

It also shows you the symbolic representation and explains what each permission allows.

CSS Units Explained: PX vs REM vs EM vs VW (With Free Converter Tools)

Impeccify.com — Tue, 17 Mar 2026 17:21:48 +0000

If you've ever gotten confused about when to use px vs rem vs em in CSS, you're not alone. This is one of the most common sources of confusion for developers at every level.

The Quick Answer

px → Fixed size, doesn't scale. Use for borders, box shadows.
rem → Relative to root font size (16px default). Use for font sizes, spacing.
em → Relative to parent font size. Use with caution, compounds with nesting.
vw/vh → Relative to viewport size. Use for full-screen layouts, fluid typography.

Deep Dive: When Each Unit Makes Sense

PX - Use for Fixed Elements

border: 1px solid #ccc;
box-shadow: 0 2px 4px rgba(0,0,0,0.1);

Never use px for font sizes - it overrides user browser font size preferences, breaking accessibility.

REM - Your Default for Most Things

REM is relative to the <html> element font size. Browser default is 16px.

/* 16px → 1rem */
/* 24px → 1.5rem */
/* 14px → 0.875rem */

font-size: 1rem;    /* 16px */
padding: 1.5rem;    /* 24px */
margin-bottom: 2rem; /* 32px */

Pro tip: Set html { font-size: 62.5%; } to make 1rem = 10px so your math is dead simple: 24px = 2.4rem.

EM - For Component-Level Scaling

Use EM when you want the unit to scale with the element's own font size:

/* Button padding scales with button text size */
.btn {
  font-size: 1rem;
  padding: 0.75em 1.5em; /* scales with font-size */
}

.btn-large {
  font-size: 1.25rem;
  /* padding automatically scales up too */
}

VW/VH - For Fluid, Full-Screen Designs

/* Full-screen hero */
.hero {
  width: 100vw;
  height: 100vh;
}

/* Fluid font that scales with screen width */
h1 {
  font-size: clamp(1.5rem, 4vw, 3rem);
}

Quick Conversion Table

PX	REM	EM (16px)
12px	0.75rem	0.75em
14px	0.875rem	0.875em
16px	1rem	1em
18px	1.125rem	1.125em
20px	1.25rem	1.25em
24px	1.5rem	1.5em
32px	2rem	2em
48px	3rem	3em

For any other conversions, use this free PX to REM converter.

There's also a REM to PX converter, PX to EM converter, and PX to VW converter if you need them.

The Rule I Always Follow

Font sizes → rem
Padding/margin → rem (or em if should scale with element)
Borders, outlines → px
Layout widths → % or fr (in Grid)
Full-screen sections → vw/vh

That's it. You don't need to memorize all the edge cases - just follow this rule 90% of the time.

I Built 20+ Free Web Tools for Developers [Here's the Full List]

Impeccify.com — Wed, 18 Feb 2026 16:24:13 +0000

I've been building free web tools over the past few months.

No login. No paywalls. Just tools that work.

Here's everything I've built so far and why I built each category.

Why I Built These

Every developer knows the pain: you need a quick CSS unit conversion,
you Google it, and you get 10 results full of pop-ups, and 'sign up
to see results'. It's exhausting.

So I built clean versions of the tools I use most hosted at
impeccify.com/tools

All free. All instant. Built with Next.js and TailwindCSS.

CSS Unit Converters

These are the ones I use almost daily:

If you're building accessible, responsive layouts, REM and EM units are
non-negotiable. These converters make the math instant.

Code Converters

The CSS to Tailwind converter is one I use constantly when working on
Next.js projects. Write regular CSS, get the Tailwind equivalent instantly.

Color Converters

Color format conversions come up constantly in design-to-development handoffs.

Developer Tools

The CSV to SQL converter alone has saved me hours of tedious manual work.

Website Calculators

These are for clients and business owners estimating website budgets and ROI.

Unit Converters

What's Next

I'm adding new tools every week. If there's a tool you wish existed,
drop it in the comments and I'll build it.

All tools live at: impeccify.com/tools

And if you ever need a custom website built or ui/ux design, that's what my
agency does: impeccify.com