DEV Community: Craftly

I Set Up Email Marketing for My Next.js Business in 30 Minutes (Loops.so)

Craftly — Wed, 22 Apr 2026 13:37:47 +0000

Every indie hacker who skipped email marketing eventually regrets it. Your X followers, GitHub stars, or Gumroad audience can disappear overnight if the platform changes. Email is the one channel you actually own.

Last week I wired email capture into my Next.js template business. From zero subscribers to a working welcome sequence in under an hour. Here's exactly how.

The Stack

Loops.so — email service built for developers, $0 for up to 1,000 contacts
Next.js 16.2 — App Router with Route Handlers
Vercel — hosting with env var management

Alternatives considered: Kit (ConvertKit), Resend, Mailchimp. Kit is too creator-focused, Resend is transactional-only, Mailchimp is ancient. Loops is the sweet spot for modern indie products.

Step 1: Sign Up and Get the API Key

loops.so → Sign up
Settings → API → Create API Key
Copy

Loops requires a sending domain for delivery. You can build the integration before domain is verified.

Step 2: Store the Key

\`bash

.env.local

LOOPS_API_KEY=
`\

For Vercel: Settings → Environment Variables. Production + Preview + Development.

Step 3: Create the Subscribe Route Handler

\`ts
// src/app/api/subscribe/route.ts
import { NextRequest, NextResponse } from "next/server";

export const runtime = "edge";

const CREATE = "https://app.loops.so/api/v1/contacts/create";
const UPDATE = "https://app.loops.so/api/v1/contacts/update";

export async function POST(req: NextRequest) {
try {
const { email, source = "newsletter" } = await req.json();

if (!email || typeof email !== "string") {
  return NextResponse.json({ error: "Email required" }, { status: 400 });
}

const emailRegex = /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/;
if (!emailRegex.test(email)) {
  return NextResponse.json({ error: "Invalid email" }, { status: 400 });
}

const apiKey = process.env.LOOPS_API_KEY;
if (!apiKey) {
  return NextResponse.json({ error: "Not configured" }, { status: 500 });
}

const res = await fetch(CREATE, {
  method: "POST",
  headers: {
    Authorization: \`Bearer \${apiKey}\`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    email, source, subscribed: true, userGroup: "newsletter",
  }),
});

if (!res.ok) {
  const data = await res.json().catch(() => ({}));

  // Duplicate? Update instead (idempotent)
  if (res.status === 409 || data?.message?.includes("already")) {
    const updateRes = await fetch(UPDATE, {
      method: "PUT",
      headers: {
        Authorization: \`Bearer \${apiKey}\`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email, subscribed: true, source }),
    });

    if (updateRes.ok) {
      return NextResponse.json({ success: true, existing: true });
    }
  }

  return NextResponse.json({ error: "Failed to subscribe" }, { status: 500 });
}

return NextResponse.json({ success: true });

} catch (err) {
console.error("Subscribe error:", err);
return NextResponse.json({ error: "Internal error" }, { status: 500 });
}
}
`\

Key design choices:

runtime = "edge"\ for fast global response
Idempotent: duplicate signups become updates
Email regex validation
source\ param to track origin

Step 4: Build the Subscribe Form

\`tsx
"use client";
import { useState } from "react";

export function NewsletterForm() {
const [email, setEmail] = useState("");
const [status, setStatus] = useState<"idle" | "loading" | "success" | "error">("idle");
const [message, setMessage] = useState("");

async function handleSubmit(e: React.FormEvent) {
e.preventDefault();
if (!email || status === "loading") return;

setStatus("loading");
try {
  const res = await fetch("/api/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email, source: "homepage-footer" }),
  });

  const data = await res.json();

  if (!res.ok) {
    setStatus("error");
    setMessage(data.error || "Something went wrong");
    return;
  }

  setStatus("success");
  setMessage(data.existing ? "You're already on the list!" : "Thanks!");
  setEmail("");
} catch {
  setStatus("error");
  setMessage("Network error");
}

}

if (status === "success") return

✓ {message};

return (

type="email"
value={email}
onChange={(e) => setEmail(e.target.value)}
placeholder="you@example.com"
required
/>

{status === "loading" ? "..." : "Subscribe"}

);
}
`\

Drop this anywhere in your layout.

Step 5: Verify Sending Domain

Loops won't actually send until you verify a domain.

Loops → Settings → Domain → Add your domain
Loops generates DNS records:
- 3x CNAME (DKIM)
- 1x MX (bounce handling)
- 1x TXT (SPF)
- 1x TXT (DMARC)
Add all to your DNS provider
Wait 1-6 hours for propagation
Click Verify

Step 6: Build the Welcome Sequence

In Loops UI:

Create Loop
Trigger: "Contact Added"
Email 1 (immediate): Welcome + gift + CTA
Email 2 (Day 2): Value + subtle discount
Email 3 (Day 5): Story + blog link

Activate. Every new subscriber gets a 3-part welcome automatically.

Step 7: Track Sources

Use the source\ param religiously. After 30 days you'll learn:

"homepage-footer" converts 3x better than "blog-modal"
One specific blog post drives your best-quality signups
Certain channels bring higher LTV subscribers

Gold for optimization.

What I Learned

#1. Email validation is worth it. Users make typos. Loops charges per contact, bad emails compound.

#2. The 409 case matters. Returning users re-subscribing shouldn't see an error.

#3. Welcome sequences should be written before launch. Zero delay between first signup and first email.

#4. Track sources. Free optimization data.

Numbers After Week 1

Subscribers: 1 (test)
Open rate: N/A (just activated)
Domain verification: Processing

Day 4 of the business. The point isn't traffic yet — it's having the system ready so when traffic shows up, I capture it.

Ship It

If you're building a digital product, set up email before launch. Every day you delay is subscribers you'll never get back.

Every Craftly template includes the /api/subscribe\ endpoint + NewsletterForm wired up. Swap in your LOOPS_API_KEY\, deploy, done. Next.js 16.2 + Tailwind v4 + TypeScript, from $19 to $49 or $99 bundle.

Originally published on Craftly.

Check out our premium templates:

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

How to Build a Developer Portfolio That Gets You Hired in 2026

Craftly — Wed, 22 Apr 2026 00:13:03 +0000

Why a Portfolio Matters More Than a Resume

In 2026, your GitHub profile and portfolio website do more work than your resume ever could. A resume tells hiring managers what you've done. A portfolio shows them how you think, what you build, and whether you can ship something that looks good and works well.

The numbers back this up. Developers with a strong portfolio site get more interview callbacks, negotiate higher salaries, and land freelance contracts faster. Recruiters spend an average of 7 seconds on a resume. They spend significantly more time on a well-built portfolio.

If you're serious about your career — whether you're landing your first job, switching companies, or going freelance — a portfolio isn't optional anymore.

What Hiring Managers Actually Look For

Before you write a single line of code, understand what the person on the other side of the table cares about.

Proof of Execution

Hiring managers don't want potential — they want evidence. They're looking for shipped projects, not half-finished side projects. Show things that are live, deployed, and usable.

Code Quality and Judgment

Your portfolio itself is a code sample. If it's slow, inaccessible, or poorly structured, that's a signal about how you'll write production code. Every technical decision you make is being evaluated.

Communication Ability

Can you explain what a project does and why it matters in two sentences? Developers who can communicate clearly are 10x more valuable than those who can't. Your project descriptions are a writing test in disguise.

Personality and Taste

A generic template with placeholder text tells hiring managers nothing. Show your aesthetic preferences, your interests, your writing voice. People hire people they can imagine working with.

Essential Sections for a Developer Portfolio

1. Hero Section

Your hero is prime real estate. Include your name, a one-line description of what you do (not your job title — your value), and a clear call-to-action. "I build fast, accessible web apps" is better than "Full Stack Developer."

Add a professional photo if you're comfortable with it. Profiles with photos get significantly more engagement.

2. Projects (The Core)

This is the most important section. For each project, include:

Project name and live link — always link to something deployed
Problem it solves — one sentence on the "why"
Tech stack — let the reader know what you used
Your role — especially important for team projects
Screenshot or video — visuals dramatically increase engagement

Aim for 3-5 strong projects rather than 10 mediocre ones. Quality over quantity every time.

3. Skills

List technologies you can actually use in a production environment. Group them logically — languages, frameworks, tools, cloud. Avoid skill meters (percentages are meaningless) and don't list things you used once in a tutorial.

4. Experience

Keep it concise. Company, role, dates, and 2-3 bullet points on impact. Use numbers where possible: "Reduced API response time by 40%" beats "Improved performance."

If you're early in your career, highlight open source contributions, freelance work, or notable side projects instead.

5. Blog (Optional but Powerful)

A technical blog is a force multiplier for your portfolio. Every article demonstrates depth of knowledge, communication skill, and continuous learning. It also drives organic search traffic to your site.

You don't need to post often. Two or three well-written articles on topics you know deeply are worth more than twenty shallow posts.

6. Contact

Make it easy to reach you. A simple contact form or a prominent email link is enough. Add your GitHub and LinkedIn icons in the footer. Don't make people hunt for a way to get in touch.

Technical Tips That Separate Good Portfolios from Great Ones

Performance

Your portfolio needs to load fast. Aim for a Lighthouse performance score above 95. Use next/image\ for optimized images, next/font\ for zero layout shift fonts, and static generation for every page.

A slow portfolio is a red flag. If you can't optimize your own site, why would a company trust you to optimize theirs?

SEO

Add proper metadata to every page. Use the Next.js Metadata API to set unique title tags and descriptions:

\\

Originally published on Craftly.

Check out our premium templates:

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

Why I'm Giving Away 8 Next.js Templates for Free (And What I Want in Return)

Craftly — Tue, 21 Apr 2026 15:31:30 +0000

Most indie product launches start with a price tag and hope. Mine started with a price tag, a catalog of 8 production-ready Next.js templates, and exactly zero sales.

So I changed the plan. For 4 weeks — through May 19, 2026 — every Craftly template is free.

Not discounted. Free. Pay-what-you-want on Gumroad with a $0 minimum.

Here's why, what's inside, and what I actually want in exchange.

The problem a discount doesn't solve

When I looked at Craftly honestly, the bottleneck wasn't pricing. The Bundle at $99 is the cheapest full Next.js + Tailwind v4 template catalog I know of. Individual templates at $19-49 beat most competitors on quality.

The bottleneck was social proof. Zero testimonials. Zero "I shipped this with Craftly" tweets. Zero stories.

A 20% discount doesn't fix that. It tells people buy now for less. It doesn't tell them this is worth buying.

Free does something a discount can't: it removes the "is it worth the money?" question entirely and replaces it with "can I use this?"

That's the question I actually want answered.

What's in the bundle

Every Craftly template, free through May 19:

SaaSify — SaaS landing page, 8 sections, conversion-ready
Admin Dashboard — charts, tables, sidebar, dark mode
Developer Portfolio — 7 sections, single data file to customize
Blog — tag filtering, newsletter signup, SEO metadata
Pricing Page — toggle, comparison table, testimonials, FAQ
Waitlist — countdown, email capture, social proof
Free 404 — space-themed, always free
All-Access Bundle — all of the above in one listing

Same stack across everything: Next.js 16 App Router, Tailwind v4 with @theme inline (no config file), TypeScript strict, Framer Motion, Lucide icons. Consistent design system. Dark mode everywhere.

MIT-friendly license — ship with what you build.

What I'm trading for

The only thing I'm asking for in return is feedback.

Seven days after you download anything from Craftly, Loops sends you a short email. Three questions:

What did you build (or try to build) with it?
What almost stopped you? Something confusing, broken, missing?
Would you tell another dev about it? Why or why not?

Reply with one-line answers. Brutal honesty welcome. I'd rather fix what's broken than read compliments.

That's the whole mechanism. No hidden upsell, no bait-and-switch. The templates are yours to keep forever regardless of whether you reply.

Why the math actually works

Free isn't just a marketing tactic here — it's the highest-leverage thing I can do with Craftly's current state.

Before free launch: 0 paying customers, 0 testimonials, ~20 Dev.to views per article, near-zero X reach.
Predicted after free launch: 100-500 downloads, 10-30 testimonials, meaningful external coverage (HN, Reddit, Dev.to), email list in the hundreds.

The templates took weeks to build. Giving them away for 4 weeks costs me exactly $0 in marginal revenue (because marginal revenue was already $0).

What I gain:

A library of real-world feedback I can use to make the next version better
Early users who might become paying customers when prices restore
Quotable testimonials that break the zero-to-one social proof trap
Real conversations with developers building real things

The cost-benefit is absurdly lopsided.

What happens on May 19

Prices return. Bundle goes to $99. Individual templates go to $19-49.

Anything you downloaded during the free window stays yours — commercial use, personal projects, client work. No clawback, no license change.

After May 19, I plan to release Lite versions of SaaSify, Portfolio, Blog, and Dashboard — smaller free tier — while keeping Pro versions paid. That keeps a permanent free funnel open after the 4-week window closes.

If you want to participate

Free launch goes live today. Grab anything at getcraftly.dev.

No signup required to download — just pay $0 on Gumroad and the zip is yours. Email is only captured if you subscribe to the newsletter, which is optional.

If you want to help more directly, one public reply to this post or an honest review once you've tried a template would mean a lot.

This is the whole experiment. Four weeks. Free templates. Honest feedback. We'll see what actually happens.

Craftly ships production Next.js + Tailwind v4 templates. All 8 are free through May 19, 2026 at getcraftly.dev.

Tailwind v4 Container Queries: A Practical Guide with Real Examples

Craftly — Mon, 20 Apr 2026 08:42:04 +0000

Tailwind v4 Container Queries: A Practical Guide with Real Examples

Container queries landed as first-class citizens in Tailwind CSS v4. The short version: you can now style an element based on the size of its parent container, not just the viewport. That unlocks truly reusable components that adapt to wherever you drop them.

This guide shows the exact syntax, real-world patterns we use in every Craftly template, and the three gotchas that aren't in the docs.

What problem container queries solve

Before container queries, responsive design was anchored to viewport width. A card component on a full-width mobile layout and a card component tucked into a 300px sidebar on desktop would both get the same media-query breakpoints. The sidebar card looked broken.

Container queries fix this by letting the card respond to its own available width instead. Move it from full-width to sidebar and it adapts, same component.

The basic pattern in Tailwind v4

Three steps:

Step 1: Mark the container

Put the @container class on whatever parent should be the query target:

<div className="@container">
  <Card />
</div>

Step 2: Use container variants on children

Inside Card, use @sm:, @md:, @lg: etc. as variant prefixes — they key off the container, not the viewport:

<div className="p-4 @sm:p-6 @lg:p-8">
  <h3 className="text-base @md:text-lg @lg:text-xl">Card title</h3>
</div>

Now that card responds to its own parent's width. Drop it in a full-width grid cell, it renders at the @lg size. Drop it in a narrow sidebar, it stays at the base size.

Step 3: Container sizes default

The default breakpoints are:

Variant	Container width
`@xs`	20rem (320px)
`@sm`	24rem (384px)
`@md`	28rem (448px)
`@lg`	32rem (512px)
`@xl`	36rem (576px)
`@2xl`	42rem (672px)

You can customize these in your @theme inline block if the defaults don't match your layout.

A real example: a reusable product card

Here's the pattern we use in SaaSify and the Portfolio template. Same component, three contexts:

function ProductCard({ product }) {
  return (
    <div className="@container">
      <article className="rounded-2xl border bg-card p-4 @sm:p-6 @lg:flex @lg:items-center @lg:gap-8">
        <img
          src={product.image}
          className="aspect-square w-full rounded-lg object-cover
                     @sm:aspect-[4/3]
                     @lg:aspect-square @lg:w-48 @lg:flex-shrink-0"
        />
        <div className="mt-4 @lg:mt-0">
          <h3 className="text-lg font-semibold @md:text-xl @lg:text-2xl">
            {product.name}
          </h3>
          <p className="mt-2 text-sm text-muted-foreground @md:text-base">
            {product.description}
          </p>
          <div className="mt-4 @lg:mt-6">
            <span className="text-2xl font-bold">${product.price}</span>
          </div>
        </div>
      </article>
    </div>
  );
}

Drop this into any grid and it adapts:

// Full-width stacking mobile
<div className="space-y-4">
  <ProductCard product={p} />
</div>

// 3-column grid on desktop — each cell renders at @md
<div className="grid grid-cols-3 gap-6">
  <ProductCard product={p} />
</div>

// Narrow sidebar — stays at base size
<aside className="w-64">
  <ProductCard product={p} />
</aside>

No media-query fiddling. No prop threading a size variant. Just the card, looking right everywhere.

Gotcha 1: The `@container` parent needs explicit sizing

This trips everyone. For container queries to work, the @container parent needs to have a width that the browser can measure. If the parent is inside a flex column with no explicit width, or inside a grid cell with min-content, container queries won't fire until a parent establishes sizing.

Usually this "just works" because most layouts have some grid or flex sizing. But when the parent has no size, add w-full or put it in a container with known width:

// Won't work inside a flex parent without sized children
<div className="flex">
  <div className="@container">
    <Card />  {/* @sm: never fires */}
  </div>
</div>

// Works — explicit width
<div className="flex">
  <div className="@container w-full">
    <Card />
  </div>
</div>

Gotcha 2: Container vs viewport variants are distinct

The @md: variant (container) and the md: variant (viewport) are different. Don't mix them thinking one falls back to the other.

// These are different
<div className="text-base md:text-lg @md:text-xl">
  {/* md:text-lg fires at viewport 768px+ */}
  {/* @md:text-xl fires at container 28rem+ */}
</div>

Pick one per component, and usually @ (container) wins for reusability.

Gotcha 3: Named containers for multi-level queries

If a component nests inside another @container, you might want children to query the outer container, not the nearest one. Tailwind v4 supports named containers for this:

<div className="@container/outer">
  <div className="@container/inner">
    <p className="@lg/outer:text-xl">
      {/* Queries the outer, ignoring the inner */}
    </p>
  </div>
</div>

Most projects never need this — if you do, name your containers after the semantic role (@container/card, @container/sidebar) rather than position.

Performance notes

Container queries are implemented in the browser with container-type: inline-size (or size for two-axis queries). The reflow cost is real but small — Chrome's implementation handles thousands of container-query elements without frame drops.

Tailwind v4 only emits the container-type on elements you explicitly mark with @container, so you don't pay the cost globally.

Browser support

As of 2026:

Chrome/Edge 105+ ✅
Safari 16+ ✅
Firefox 110+ ✅

Which is to say: everyone who updated Chrome in the last two years has them. The @container feature is firmly in the "can use without guilt" category.

When not to use container queries

For layout decisions that depend on user viewport (hamburger menu vs full nav), you still want viewport breakpoints. Container queries are for component-level responsiveness, not app-level layout.

Rule of thumb: if the component is reusable across multiple layout slots, use @container. If the decision is global (site header, main content column), use md:/lg: viewport breakpoints.

Migrating existing components

If you already have responsive components using viewport breakpoints, you don't have to migrate everything. A sensible refactor:

Identify the 3-5 components you reuse in multiple layout contexts
Wrap each in @container
Replace sm: → @sm:, md: → @md: inside those components
Test by dropping them into different layout slots

The rest of your app can stay viewport-based.

Wrapping up

Container queries in Tailwind v4 let one component serve full-width, grid-cell, and sidebar contexts without duplication or prop-drilled size variants. The three gotchas — sized parents, container vs viewport distinction, and named containers — account for 90% of "why isn't this working" moments. Once you internalize them, you'll wonder how you shipped responsive components before.

Every Craftly template uses @container for its primary card components. If you want to see real-world patterns, browse the catalog at getcraftly.dev.

How to Use Next.js Templates with Cursor and Claude Code (2026 Workflow)

Craftly — Mon, 20 Apr 2026 00:26:49 +0000

If you bought a Next.js template in 2023, you spent a weekend customizing it. If you buy one in 2026, you spend an afternoon — if you use AI coding tools right.

Cursor and Claude Code both changed the cost of template customization. This guide shows the workflow I use to go from "cloned template" to "shipped product" in 3-4 hours.

Why This Matters

Templates aren't finished products. They're starting points. The real work is:

Replacing all the copy with your product's voice
Swapping out demo data with your actual data
Rebranding colors, fonts, tone
Adding the one or two sections unique to your product
Wiring up your actual backend / auth / payments

Historically this was a week of semi-mindless work. AI cuts it to hours. Here's how.

Step 1: Clone and Get It Running

Standard setup. Nothing AI-specific yet.

\bash unzip saasify-template.zip cd saasify-template npm install npm run dev \\

Verify the template works before you touch anything. 30 seconds.

Step 2: Point Your AI Tool at the Repo

This is where 2026 differs from 2023.

With Cursor

Open the folder in Cursor
The entire repo is now indexed
Cmd+K for inline edits, Cmd+L for chat with file context

With Claude Code

cd into the folder in your terminal
Run claude\ to start a session
Claude has full read/write access to every file

Either works. Cursor feels more like an IDE. Claude Code feels more like pair-programming.

Step 3: Ask It to Rebrand

The magic trick: you don't manually hunt through files. You describe what you want.

Example prompt:

\`
Rebrand this template from "SaaSify" to "Nimbus". My brand:

Primary color: #10B981 (emerald)
Accent: #F59E0B (amber)
Font: Inter (keep)
Tone: playful, for small team founders

Find every mention of "SaaSify" and update to "Nimbus" consistently.
Update CSS variables in globals.css.
Update any brand-colored accents throughout components.
`\

The AI will:

Edit src/data/site.ts (or equivalent)
Update globals.css color tokens
Find stray brand mentions in components
Update metadata, OG image config, README

Review the diff. Accept or iterate.

Step 4: Replace Demo Data

Prompt:

\`
Replace the demo feature cards in src/data/site.ts with our 6 actual features:

Invoice automation — "Stop chasing payments. Auto-send reminders."
Client portal — "Self-serve dashboards your clients actually use."
Recurring billing — "Subscriptions without the enterprise price tag." ...

Match the existing data structure. Keep the icon style consistent.
`\

AI writes it in the exact shape the components expect. No manual formatting.

Step 5: Add Custom Sections

Templates cover the common case. You always need one weird section.

Prompt:

\`
I need a new section between Features and Pricing called "How it works":

3 numbered steps with icons from lucide-react
Each step has a title and 1-line description
Match the existing design language (dark mode support, Framer Motion stagger)
Create src/components/how-it-works.tsx and compose it into src/app/page.tsx `\

AI generates the component following your template's patterns. 30 seconds of work.

Step 6: Wire Up the Real Stuff

Forms, payments, auth — the parts that differ per project.

Prompt for email capture:

\`
Wire up the newsletter form in src/components/footer.tsx to Loops.so.

Create src/app/api/subscribe/route.ts that POSTs to Loops API
Use LOOPS_API_KEY from .env.local
Handle loading, success, and error states
Validate email format client-side `\

AI writes the endpoint and component update together. You add the env var and test.

Step 7: Review, Don't Accept Everything

This is the part nobody emphasizes enough.

AI is very good at matching patterns. AI is not always right about:

Security edges — check API validation carefully
Accessibility — alt text, focus rings, ARIA labels
Performance — sometimes picks the "works but slow" option
Brand tone — AI defaults to "generic SaaS copy"

Read every diff before accepting. You're the editor, AI is the writer.

A Realistic Timeline

Template: SaaSify ($49 Craftly)
Goal: Launch "Nimbus" — an invoicing tool

Step	Time
Clone + run	5 min
Point AI at repo	2 min
Rebrand prompt + review	20 min
Replace demo data	25 min
Custom section	20 min
Wire email capture (Loops)	30 min
Final review + polish	45 min
Total	~2.5 hours

Week-long project → afternoon. That's 2026.

The Combo That Works Best

From my experience:

Claude Code for planning and multi-file refactors (rebranding, structural changes)
Cursor for rapid inline edits while reviewing the visual result in dev server
Use both on the same project — they complement each other

The Templates I Ship With This Workflow

Every Craftly template is structured for this AI workflow:

Single data file (src/data/*.ts) controls all content — AI knows where to edit
CSS variables in globals.css for instant rebranding
TypeScript types everywhere — AI generates valid code
Clean component boundaries — AI can add sections without breaking existing ones

Next.js 16.2 + Tailwind v4 + TypeScript. See current pricing at getcraftly.gumroad.com.

Closing

If you're still customizing templates by hand, you're leaving hours on the table. The 2026 workflow is: buy a good template, point AI at it, iterate until it's yours.

The skill isn't writing code anymore. It's knowing what to ask for, and being able to tell when AI got it right.

Originally published on Craftly.

Production-ready Next.js templates — browse the current catalog at https://getcraftly.gumroad.com or save with the All-Access Bundle.

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

Tailwind CSS v4 Complete Migration Guide

Craftly — Mon, 20 Apr 2026 00:25:42 +0000

Tailwind CSS v4 rewrote almost everything that made v3 great. The config file is gone. The plugin system changed. Colors moved to OKLCH. If you are migrating a real project, expect surprises.

Here is the exact process I use to migrate production apps — including all the traps I fell into so you do not have to.

Why Upgrade at All?

Three reasons:

Speed. The Oxide engine (Rust-based) is roughly 10x faster at scanning classes. HMR updates feel instant.
Less config. Design tokens live in your CSS. The tailwind.config.js\ file is gone.
Modern CSS. Container queries, @starting-style\, OKLCH colors — all built in.

If you are on a fresh project, skip v3 entirely. If you have a mature v3 codebase, read on.

Step 1: Update Dependencies

Remove the old packages and install v4:

\bash npm uninstall tailwindcss postcss autoprefixer npm install tailwindcss@next @tailwindcss/postcss \\

The new @tailwindcss/postcss\ package replaces the old tailwindcss\ PostCSS plugin. It also includes autoprefixing, so you can remove autoprefixer\.

Step 2: Update PostCSS Config

\\

Originally published on Craftly.

Production-ready Next.js templates — browse the current catalog at https://getcraftly.gumroad.com or save with the All-Access Bundle.

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

Custom Domains for Next.js: The Cloudflare + Vercel Setup That Works in 2026

Craftly — Sun, 19 Apr 2026 11:18:58 +0000

You shipped a Next.js app to Vercel. It's live at your-project-xxx.vercel.app\. Everything works, but the URL looks like a throwaway demo.

Getting a real domain is a 30-minute task, but it's easy to make mistakes that cost you SSL certificates, SEO, or deliverability.

Here's the exact flow I used to move my template business from a vercel.app URL to my own domain. Production-tested, 2026-current.

The Stack

Registrar: Cloudflare Registrar (at-cost pricing)
DNS: Cloudflare DNS (free, fastest propagation)
Hosting: Vercel
Email Routing: Cloudflare Email Routing (free receiving)
Email Sending: Loops.so

Zero monthly cost except the domain itself (~$12/year for .dev).

Step 1: Buy the Domain on Cloudflare

Use Cloudflare Registrar, not Namecheap or GoDaddy. Prices are wholesale, WHOIS privacy is free, and DNS is managed in the same dashboard.

dash.cloudflare.com → Domain Registration → Register Domain
Search your domain
2 years with auto-renew ON
Pay. Domain is yours in ~60 seconds

Step 2: Add the Domain to Vercel

Open your Vercel project → Settings → Domains
Click Add Domain
Enter your domain
Uncheck "Redirect to www" — apex as canonical is cleaner in 2026
Save

Vercel shows Invalid Configuration. Expected.

Step 3: Get DNS Records

Click Edit in Vercel → Manual setup. Vercel shows:

\Type: CNAME Name: @ Value: <project-hash>.vercel-dns-xxx.com \\

Vercel is migrating from the old A record (76.76.21.21) to CNAME-based records.

Step 4: Add to Cloudflare DNS

Cloudflare → your domain → DNS → Records → Add record:

\Type: CNAME Name: @ Target: <Vercel-provided value> Proxy: DNS only (gray cloud) ← CRITICAL TTL: Auto \\

Why DNS only matters: Cloudflare proxy ON intercepts HTTPS, so Vercel can't issue SSL. Keep it gray.

Step 5: Wait for Verification

Vercel auto-detects propagation in 2-10 minutes. Green check = done.

The Apex CNAME Gotcha

DNS spec (RFC 1912) doesn't allow CNAMEs on apex. Cloudflare solves this with CNAME Flattening — internally resolves to IP, returns A record. You don't do anything special.

AWS Route 53 calls this "ALIAS". Google Cloud DNS has similar. If your DNS provider doesn't support this, use A record with Vercel's IP instead.

301 Redirects from Old URL

\\

Originally published on Craftly.

Production-ready Next.js templates — browse the current catalog at https://getcraftly.gumroad.com or save with the All-Access Bundle.

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

How to Build an Admin Dashboard with Next.js in 2026

Craftly — Sun, 19 Apr 2026 11:11:26 +0000

Why Dashboards Matter for SaaS

Every SaaS product eventually needs an admin dashboard. Whether it's monitoring revenue, tracking active users, or managing customer accounts, dashboards are where data becomes actionable. A well-built dashboard is often the difference between a product that feels professional and one that feels like a prototype.

Yet dashboards are notoriously time-consuming to build from scratch. You need charts that work, tables that sort and filter, a sidebar that collapses on mobile, stat cards that update in real time, and a layout that stays coherent at every screen size. Get any one of these wrong and the whole thing falls apart.

In 2026, Next.js 16 with Tailwind CSS v4 is the strongest foundation for building admin dashboards. Here's how to approach it.

Key Components of a Modern Dashboard

Stat Cards

Stat cards are the first thing users see — a row of KPI tiles showing the numbers that matter most: total revenue, active users, conversion rate, churn. A good stat card includes the current value, a comparison to the previous period, and a trend indicator (up/down arrow with color coding).

\`tsx
interface StatCardProps {
label: string;
value: string;
change: number;
changeLabel: string;
}

export function StatCard({ label, value, change, changeLabel }: StatCardProps) {
const isPositive = change >= 0;
return (

{label}

{value}

{isPositive ? "+" : ""}{change}% {changeLabel}

);
}
`\

Keep stat cards in a 2x2 or 4-column grid on desktop, stacking to a single column on mobile.

Charts

Charts are where most dashboard projects get complicated. You need to choose a library, understand its API, and make it work with your data format.

Choosing a Charting Library: Recharts vs Chart.js vs Tremor

Recharts is the most popular choice for React dashboards. It's built on SVG, composable, and integrates naturally with React's component model. The API is declarative and easy to read.

\`tsx
import { LineChart, Line, XAxis, YAxis, Tooltip, ResponsiveContainer } from "recharts";

export function RevenueChart({ data }: { data: { date: string; revenue: number }[] }) {
return (

);
}
`\

Chart.js (via react-chartjs-2) is battle-tested and has more chart types, but the API is more imperative and less idiomatic in React. Good for teams coming from a non-React background.

Tremor provides pre-built dashboard components including charts, stat cards, and tables. It's the fastest path to a working dashboard, but less flexible for custom designs.

For most SaaS dashboards, Recharts is the right choice. It's flexible, actively maintained, and the community is large.

Data Tables

Tables are the most common dashboard component and the easiest to get wrong. A production-grade data table needs:

Sortable columns (click header to sort, click again to reverse)
Pagination (server-side for large datasets, client-side for small ones)
Search and filter
Row selection for bulk actions
Responsive behavior (horizontal scroll or card view on mobile)

Build your table as a generic component that accepts column definitions and row data. This makes it reusable across different sections of the dashboard.

Sidebar

The sidebar is the backbone of your dashboard navigation. In 2026, the standard pattern is:

Desktop: Fixed sidebar, 240px wide, with icons and labels
Tablet: Collapsible sidebar, icons-only mode
Mobile: Off-canvas drawer, triggered by a hamburger menu

\`tsx
"use client";

import { useState } from "react";

export function Sidebar() {
const [collapsed, setCollapsed] = useState(false);

return (

setCollapsed(!collapsed)}>
{collapsed ? "Expand" : "Collapse"}

{/* nav items */}

);
}
`\

Store the collapsed state in localStorage\ so it persists across page loads.

Data Architecture: The Single Data File Pattern

The cleanest approach for dashboard data is a single data file that exports everything the dashboard needs. This keeps your mock data organized and makes it easy to swap in a real API later.

\`ts
// data/dashboard.ts
export const stats = [
{ label: "Total Revenue", value: "$48,295", change: 12.5, changeLabel: "vs last month" },
{ label: "Active Users", value: "2,847", change: 8.2, changeLabel: "vs last month" },
{ label: "Conversion Rate", value: "3.4%", change: -0.6, changeLabel: "vs last month" },
{ label: "Churn Rate", value: "1.2%", change: -0.3, changeLabel: "vs last month" },
];

export const revenueData = [
{ date: "Jan", revenue: 32000 },
{ date: "Feb", revenue: 38000 },
// ...
];

export const recentOrders = [
{ id: "ORD-001", customer: "Alice Johnson", amount: "$299", status: "Paid" },
// ...
];
`\

This pattern works for templates, prototypes, and early-stage products. When you're ready to connect a real API, replace the imports with fetch\ calls — the components don't need to change.

Dark Mode Implementation

Dashboard users are almost universally power users who prefer dark mode. Implement it with CSS variables so the switch is instant and doesn't cause a flash of wrong theme.

\`css
/* globals.css */
@import "tailwindcss";

@theme inline {
--color-background: #ffffff;
--color-foreground: #0f172a;
--color-card: #f8fafc;
--color-border: #e2e8f0;
}

.dark {
--color-background: #0f172a;
--color-foreground: #f8fafc;
--color-card: #1e293b;
--color-border: #334155;
}
`\

Store the preference in localStorage\ and apply the .dark\ class to <html>\ before the first paint to avoid flicker:

\tsx // app/layout.tsx — inline script runs before React hydrates const themeScript = \
const theme = localStorage.getItem("theme") ?? "dark";
document.documentElement.classList.toggle("dark", theme === "dark");
`;

export default function RootLayout({ children }: { children: React.ReactNode }) {
return (

{children}

);
}
`\

Responsive Sidebar Patterns

The sidebar needs fundamentally different behavior at different breakpoints:

Large screens (lg+): Persistent sidebar. The main content shifts right when the sidebar is open. Use CSS Grid or Flexbox with a fixed-width sidebar column.

Medium screens (md): Icon-only sidebar. Keep navigation accessible without consuming too much horizontal space.

Small screens (sm and below): Off-canvas drawer. The sidebar slides in from the left over the content. A backdrop overlay closes it when tapped.

\`tsx
// Use Tailwind's responsive prefixes to handle this declaratively

{children}

`\

Getting Started Fast

Building a production-quality admin dashboard from scratch takes weeks. You need to get every component right, handle responsive behavior at every breakpoint, wire up dark mode, and make sure charts look good in both themes.

Craftly's Dashboard template ($39) ships with all of this pre-built: stat cards, Recharts integration, a sortable data table, responsive sidebar with collapse state, and full dark mode. The single data file pattern means you can customize the content without touching the component code.

In the meantime, the patterns above give you everything you need to build your own. Start with the layout and sidebar — get those right and the rest of the components slot in cleanly.

A great admin dashboard isn't about the number of charts or the complexity of the data. It's about making the right numbers immediately visible and actionable. Focus on that, and the technical decisions become clearer.

Browse Craftly's template collection for production-ready Next.js templates built with these patterns from the ground up.

Originally published on Craftly.

Production-ready Next.js templates — browse the current catalog at https://getcraftly.gumroad.com or save with the All-Access Bundle.

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

Next.js 16 App Router: The Complete Guide for 2026

Craftly — Sun, 19 Apr 2026 07:19:55 +0000

What Is the App Router?

The App Router, introduced in Next.js 13 and now the default in Next.js 16, is a file-system based router built on top of React Server Components. It lives in the app/\ directory and replaces the older pages/\ router as the recommended approach for all new projects.

If you're still building with pages/\, the App Router isn't just a new feature — it's a fundamentally different mental model. Understanding it properly will make you a significantly more effective Next.js developer.

Server Components vs. Client Components

This is the most important concept in the App Router. Every component in the app/\ directory is a React Server Component (RSC) by default.

Server Components

Server components render on the server and send HTML to the browser. They can:

Fetch data directly using async/await\
Access server-only resources (databases, environment variables)
Import server-only packages without sending them to the client

\tsx // app/blog/page.tsx — runs entirely on the server export default async function BlogPage() { const posts = await db.query("SELECT * FROM posts"); return <PostList posts={posts} />; } \\

Because server components never ship JavaScript to the browser, they reduce your bundle size dramatically. No useEffect\, no hydration overhead.

Client Components

Client components are the ones you're used to from React. They run in the browser and can use hooks, event listeners, and browser APIs. To opt into client rendering, add "use client"\ at the top of the file:

\`tsx
"use client";

import { useState } from "react";

export function Counter() {
const [count, setCount] = useState(0);
return setCount(c => c + 1)}>{count};
}
`\

When to Use "use client"

A common mistake is marking too many components as client components. Use "use client"\ only when the component needs:

React state (useState\, useReducer\)
Effects (useEffect\, useLayoutEffect\)
Browser APIs (window\, document\, localStorage\)
Event listeners
Third-party libraries that require a browser environment

Pass server-fetched data down to client components as props. Keep the boundary as close to the leaf as possible.

The params Promise API (Breaking Change in Next.js 15+)

This is the biggest breaking change you'll encounter when upgrading. In Next.js 15 and 16, params\ and searchParams\ in page components are now Promises, not plain objects.

Before (Next.js 14)

\tsx // Old — params is a plain object export default function PostPage({ params }: { params: { slug: string } }) { return <h1>{params.slug}</h1>; } \\

After (Next.js 15+)

\tsx // New — params is a Promise export default async function PostPage({ params, }: { params: Promise<{ slug: string }>; }) { const { slug } = await params; return <h1>{slug}</h1>; } \\

This change enables better streaming and parallel data fetching. It affects every dynamic route in your app, so update all page components when migrating.

generateStaticParams

For dynamic routes, generateStaticParams\ tells Next.js which paths to pre-render at build time. This is the App Router equivalent of getStaticPaths\:

\tsx // app/blog/[slug]/page.tsx export async function generateStaticParams() { const posts = await fetchAllPosts(); return posts.map((post) => ({ slug: post.slug })); } \\

Any path not returned by generateStaticParams\ will be rendered on-demand (or return 404, depending on your dynamicParams\ setting). For blogs and docs, always use generateStaticParams\ — pre-rendered pages are faster and reduce server load.

generateMetadata

Dynamic metadata for SEO is handled by generateMetadata\, an async function that runs on the server:

\`tsx
export async function generateMetadata({
params,
}: {
params: Promise<{ slug: string }>;
}) {
const { slug } = await params;
const post = await fetchPost(slug);

return {
title: post.title,
description: post.description,
openGraph: {
title: post.title,
images: [post.ogImage],
},
};
}
`\

This gives every page unique, accurate metadata without client-side workarounds. Combined with static generation, it produces near-perfect SEO scores.

File Conventions: layout, loading, error

The App Router introduces special file names that automatically wrap your pages:

layout.tsx

Layouts wrap pages and persist across navigations. The root layout is required and must include <html>\ and <body>\ tags:

\tsx // app/layout.tsx export default function RootLayout({ children }: { children: React.ReactNode }) { return ( <html lang="en"> <body>{children}</body> </html> ); } \\

Nested layouts let you share UI across groups of pages without re-rendering on navigation.

loading.tsx

Create a loading.tsx\ file to show a loading UI while a page or layout is fetching data. Next.js wraps the page in a <Suspense>\ boundary automatically:

\tsx // app/blog/loading.tsx export default function Loading() { return <div className="animate-pulse">Loading posts...</div>; } \\

error.tsx

An error.tsx\ file catches runtime errors in that segment and displays a fallback UI. It must be a client component:

\`tsx
"use client";

export default function Error({ reset }: { reset: () => void }) {
return (

Something went wrong.

Try again

);
}
`\

Performance Tips

1. Fetch data at the component level. Server components can fetch their own data in parallel. No more prop-drilling data through component trees.

2. Use React.cache\ to deduplicate requests. If multiple components fetch the same resource, wrap the fetch in cache()\ to avoid redundant database calls.

3. Prefer static over dynamic rendering. Static pages are faster, cheaper, and cached by default. Only use dynamic = "force-dynamic"\ when the page genuinely needs fresh data on every request.

4. Stream with Suspense. Wrap slower data-fetching components in <Suspense>\ so fast parts of the page render immediately while slower parts load in the background.

5. Optimize images with next/image\. It handles lazy loading, resizing, and format conversion automatically. Never use plain <img>\ tags in production.

Putting It All Together

The App Router might feel like a lot to take in, but the mental model is consistent: server components by default, client components only when you need interactivity, and file conventions to handle loading, error, and layout states.

All Craftly Next.js templates are built with these patterns baked in — proper layout nesting, generateStaticParams\ for dynamic routes, generateMetadata\ for SEO, and "use client"\ used sparingly at the leaf level. It's the best way to see these patterns in production-quality code.

If you want to accelerate your Next.js development, check out Craftly's template collection — every template is built with Next.js 16, TypeScript, and App Router best practices from the start.

Originally published on Craftly.

Production-ready Next.js templates — browse the current catalog at https://getcraftly.gumroad.com or save with the All-Access Bundle.

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

I Used Claude Design on Day 2. Here's What Web Designers Should Know.

Craftly — Sun, 19 Apr 2026 03:05:08 +0000

Anthropic launched Claude Design two days ago. I spent day two putting it through a real test — an hour-long session where I asked it to generate design artifacts for a working business with a real codebase and an existing brand.

This is an honest field report. Not a hype piece, not a doom piece. What worked, what didn't, and what I think it means for web designers going forward.

What is Claude Design

Claude Design is a new product from Anthropic Labs, powered by Opus 4.7. You describe what you want, it generates visual output — prototypes, slide decks, one-pagers, design system artifacts. It reads your codebase and existing design files to maintain consistency.

Available to paid Claude subscribers at claude.ai/design.

The Test

I'm an indie product builder. I wanted to see how far Claude Design could go when handed inputs typical of a real engagement:

A repo with existing code
A brand logo (a gradient geometric mark)
A paragraph of brand voice (dark-first palette, OKLCH colors, tight typography)

Then I asked it to produce production-grade marketing artifacts.

What It Generated

In one conversational session, it produced:

A complete design system CSS file — brand colors (hex + OKLCH), dark/light semantic tokens, gradients, shadows, radii, spacing scale, and typography preset classes.
17 preview HTML cards covering every token and component category (colors, type scales, components, utilities).
A React UI kit recreating a marketing site — 10+ .jsx\ files with components, inline Lucide icons, and an interactive demo.
A set of 1280x720 cover-image HTML files, each with a distinct accent gradient but sharing a unified layout system.

Because I asked for code, each of these landed as text files — HTML, CSS, JSX, Markdown — that I could read and edit. (If I'd asked for images or PNGs, it would have produced those instead.)

The Good Part: It Really Did Get Easier

Let me be specific about what "easier" means here, because it's the real story.

The workflow is conversational, not point-and-click

The biggest shift from Figma or Canva. I didn't drag rectangles or manipulate layers. I wrote:

"Create a cover image with a browser mockup of a landing page on the right and title + price on the left."

And it generated that. When I wanted changes, I described them in English:

"The logo in the output is wrong — here's the correct one."

Fixed. No layer inspector, no components panel, no constraint editor. Just description.

When you ask for code, you get code

Ask for HTML, CSS, or JSX and Claude Design outputs exactly that — version-controllable text, not a proprietary design file. You can git add\ a session's output directly. (PNG export is also there when you ask for it — but the default for code-oriented prompts is working code.)

A beginner can ship something decent with this alone

This is the part I want to be loud about. If you have an idea and zero design background, you can now produce a coherent-looking landing page, a usable color system, and marketing covers in one afternoon. "I'm not a designer" is no longer an acceptable excuse for shipping ugly things.

For a hobby project, a side hustle MVP, or a quick pitch deck, Claude Design alone is enough. Really.

The Honest Part: "Decent" and "Great" Are Different Tiers

Here's the thing people won't tell you in the launch-week hype.

Claude Design hands you a solid baseline in minutes. But the gap between "solid baseline" and "actually good" still costs knowledge, taste, and iteration — and AI can't skip that for you.

Where the baseline falls short

First-pass outputs drift. Three or four iterations were normal — wrong asset pulled from the repo, proportions slightly off, spacing rhythm inconsistent between screens. If you don't see the drift, you ship it.
Fine control is harder than big direction. "Apply a subtle mesh gradient with grain overlay" works instantly. Dialing in exact grain intensity so it reads as texture instead of noise? I dropped into the CSS myself.
It has no taste about your taste. It matches a plausible style guide given your inputs. Whether that's the right style for your audience, your positioning, your category — it can't tell you. Only you can.
Systems thinking is still yours. AI happily generates ten cover variations. Deciding which three ship, what the naming convention is, how this scales to the next twenty covers — that's a systems problem, not a generation problem.

The knowledge that still pays off

If you actually want output that looks considered rather than just competent, you still need to know things like:

Why this spacing scale and not a different one
When a gradient reads as premium vs. when it reads as dated
How type contrast actually works (not just "bigger + bolder")
What a design system's job is beyond "list of colors"
How to read a layout and diagnose why it feels off

Nothing about Claude Design changes that. It just makes the generation step cheap, so the knowledge-shaped bottleneck shows up earlier and more visibly.

What This Means for Different People

If you're a beginner or non-designer

Great news. The floor just rose dramatically. You can ship things that don't look embarrassing, without six months of design study first. Use it.

Just don't confuse "no longer embarrassing" with "great." If your goal is something that resonates beyond "acceptable," you'll still hit a ceiling that only design knowledge removes.

If you're a working designer

Your execution speed is no longer the thing that makes you valuable. Anyone with a prompt can generate variations now. What compounds is:

Judgment — which of the ten outputs ships
Direction — what should be made in the first place
Craft at the edges — the 20% of polish AI won't reach by default
Systems — turning one-off artifacts into reusable, consistent work

These are all things AI accelerates your process around, not things it replaces.

If you're a design system maintainer

Probably the biggest shift. Claude Design reads your codebase and generates artifacts that match your existing tokens. Grunt work — refreshing preview pages, recreating examples, documenting new components — becomes near-free. The human role concentrates on defining principles and reviewing output for consistency.

What To Actually Do

Don't panic, don't dismiss. "AI will kill design" and "AI is just a toy" are both wrong for the same reason — they skip the part where how you use it decides the outcome.

Learn prompt craft, but don't stop there. Describing visual work precisely is a real skill. But a great prompt without design knowledge still produces mediocre design faster. Prompt craft is a multiplier; knowledge is the base number.

Keep studying the fundamentals. Type, hierarchy, rhythm, color, systems. The floor went up — so the relative value of being above the floor went up too.

Integrate it, don't fight it. Use AI for first drafts, exploration, system documentation, mundane asset generation. Reserve your focus for decisions and polish that actually need you.

The Honest Bottom Line

Claude Design makes "decent output" trivially easy. That's a big deal — a beginner can ship something they'd have been embarrassed to ship a year ago.

But "decent" and "great" are still different tiers, and the gap between them is still paid in knowledge and judgment. AI shrinks the distance from "idea" to "baseline." It doesn't shrink the distance from "baseline" to "considered, intentional, well-crafted work."

Which, honestly, is the best possible outcome. The boring part got cheap. The interesting part — knowing what's worth making, and making it well — is still where humans live.

Looking for hand-crafted, production-ready Next.js templates with careful attention to detail? Take a look at Craftly — Tailwind v4 native, Next.js 16.2, TypeScript strict. Real code, carefully built.

Originally published on Craftly.

Production-ready Next.js templates — browse the current catalog at https://getcraftly.gumroad.com or save with the All-Access Bundle.

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

Next.js 16.2 Turbopack: 400% Faster next dev — What It Actually Feels Like

Craftly — Sat, 18 Apr 2026 12:16:58 +0000

Next.js 16.2 shipped last month with one headline claim: next dev\ is now 400% faster. The official release notes promise 10x HMR on large projects. Turbopack replaces Webpack as the default bundler.

I've been running it on five production-grade template repos for two weeks. Here's what that actually feels like in practice.

The Boring Answer: Yes, It's Fast

Here are the numbers I saw across the Craftly template repos (Next.js 16.2.2, MacBook Air M2):

Repo	15.x `next dev\` cold	16.2 `next dev\` cold	Speedup
SaaSify (8 sections, ~40 components)	6.8s	1.4s	4.9x
Dashboard (sidebar, charts, tables)	9.2s	1.9s	4.8x
Blog (tag filter, 6 posts, typography)	5.1s	1.3s	3.9x

The 400% claim isn't marketing. If anything, it undersells the subjective experience.

Where You Feel It Most

1. Cold start on large projects

Before: you npm run dev\, go make coffee, come back.
Now: it's ready before your terminal prompt settles.

On a fresh clone of a monorepo, the difference is the gap between "I'll grab a drink" and "oh, it's already running."

2. HMR on deeply nested components

Editing a prop in a component 6 folders deep used to produce a visible lag — 200-500ms before the browser reflected the change. On 16.2, it's effectively instant. You stop noticing HMR as a step.

3. Type-checking doesn't block you

Turbopack runs type-checking async. If your types are wrong, you still get the error, but your page doesn't hang waiting for the compiler.

The Catches (there are always catches)

Webpack plugins may not work

If you had a custom webpack config — analyzers, special loaders, module federation — check whether the Turbopack equivalent exists. Most common ones (bundle-analyzer, mdx) are covered. Exotic setups may need migration.

`next.config.ts\` assumptions

Config that worked on Webpack may need tweaking. The clearest symptom: missing files in production build that were fine in dev. Always do a full next build\ before deploying.

HMR for Server Components got better, but not perfect

16.2 adds "Server Fast Refresh" — hot reload for server components. It works for most edits. Complex changes (moving between RSC and Client, changing layouts) still sometimes require a full page reload.

Should You Upgrade?

If you're on 15.x → yes, today. The upgrade is incremental, and the DX improvement alone justifies it. Budget 30 minutes for a small app, an afternoon for a larger one.

If you're on 14.x or earlier → upgrade staged. Go 14 → 15.0 → 15.x latest → 16.2. Don't jump directly.

If you're on 13.x with pages/\ → different question. You're migrating App Router and Turbopack at once. Budget more than a weekend.

What This Means for Templates

I ship Next.js templates for a living, and the jump from 15.x to 16.2 changes the baseline.

A template that ships with 15.x gets outdated the moment a buyer runs npm install\ in three months. A template that ships 16.2 with Turbopack default gives buyers the speed boost without them knowing they wanted it.

This is also why most templates on Gumroad still show pages/\ in their structure. They were built for 13/14, never updated. Buyers get code that technically works but feels slow the moment they start editing.

All Craftly templates ship 16.2 with Turbopack default out of the box. No config migration needed — it's already done.

The Part Nobody Talks About

400% faster dev server means you're willing to try more things.

You don't batch edits because HMR is slow. You don't console.log\ 10 things to avoid a full reload. You just... edit, look, edit, look. The feedback loop tightens, and the quality of your code improves because you iterate more.

The actual unlock isn't the benchmark number. It's the change in how you work.

If you're shipping something this weekend, upgrade to 16.2 first. You'll save more than you spend.

And if you want a Next.js 16.2 + Tailwind v4 + TypeScript template to start from, browse the full catalog at getcraftly.gumroad.com.

Originally published on Craftly.

Production-ready Next.js templates — browse the current catalog at https://getcraftly.gumroad.com or save with the All-Access Bundle.

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

SaaS Pricing Page Best Practices: Design That Converts

Craftly — Sat, 18 Apr 2026 11:27:56 +0000

Your Pricing Page Is Your Most Important Page

For most SaaS products, the pricing page is the highest-intent page on your site. Visitors who reach it are seriously considering buying. A well-designed pricing page can double your conversion rate.

The Three-Tier Rule

Three tiers work best for most SaaS products. Fewer feels limiting, more feels overwhelming.

Starter / Free Tier

Your free tier serves two purposes: it lowers the barrier to entry, and it creates an upgrade path. Keep it useful but limited enough that growing users will naturally outgrow it.

Pro / Growth Tier

This is your money-maker. Design everything on the page to guide users toward this plan. Use visual emphasis, a "Most Popular" badge, and position it in the center.

Enterprise Tier

The enterprise tier serves a dual purpose: it captures large customers, and it makes your Pro tier look affordable by comparison. This is called price anchoring.

Annual Billing Toggle

Always offer annual billing with a visible discount. The industry standard is 15-20% savings. Show the monthly equivalent price so users can easily compare.

Display the annual savings prominently — "Save $60/year" is more compelling than "Save 17%."

Feature Comparison Table

A comparison table removes guesswork. Users can see exactly what they get at each tier without reading paragraphs of text.

Best practices for comparison tables:

List features in order of importance
Use checkmarks and X marks for clarity
Bold the differentiating features
Keep it under 15 rows to avoid overwhelming users

Social Proof

Place testimonials near your pricing cards. Quotes from customers who specifically mention value or ROI are most effective.

Star ratings, customer count badges, and logo clouds all increase trust at the decision point.

FAQ Section

Address the top objections that prevent conversion:

"Can I cancel anytime?" — reduces commitment anxiety
"Is there a free trial?" — lowers perceived risk
"What happens when I exceed limits?" — removes uncertainty
"Do you offer refunds?" — builds trust

Money-Back Guarantee

A 30-day guarantee removes the last barrier to purchase. The small number of refund requests is far outweighed by the increased conversion rate.

Mobile Optimization

Over 40% of SaaS pricing page visits happen on mobile. Your pricing cards must stack cleanly, and the comparison table needs horizontal scrolling or an accordion layout.

Common Mistakes

Too many tiers — stick to three
No visual hierarchy — make the recommended plan obvious
Hidden pricing — "Contact us for pricing" kills conversions for SMB products
No annual option — you're leaving revenue on the table
Missing FAQ — unaddressed objections kill deals

Test Everything

A/B test your pricing page regularly. Small changes to price points, tier names, feature ordering, and CTA copy can have outsized effects on conversion.

Build your pricing page with Craftly's pricing template — conversion-optimized, responsive, and ready to deploy.

Originally published on Craftly.

Production-ready Next.js templates — browse the current catalog at https://getcraftly.gumroad.com or save with the All-Access Bundle.

Built with Next.js 16, TypeScript, and Tailwind CSS v4.

DEV Community: Craftly

I Set Up Email Marketing for My Next.js Business in 30 Minutes (Loops.so)

The Stack

Step 1: Sign Up and Get the API Key

Step 2: Store the Key

.env.local

Step 3: Create the Subscribe Route Handler

Step 4: Build the Subscribe Form

Step 5: Verify Sending Domain

Step 6: Build the Welcome Sequence

Step 7: Track Sources

What I Learned

Numbers After Week 1

Ship It

How to Build a Developer Portfolio That Gets You Hired in 2026

Why a Portfolio Matters More Than a Resume

What Hiring Managers Actually Look For

Proof of Execution

Code Quality and Judgment

Communication Ability

Personality and Taste

Essential Sections for a Developer Portfolio

1. Hero Section

2. Projects (The Core)

3. Skills

4. Experience

5. Blog (Optional but Powerful)

6. Contact

Technical Tips That Separate Good Portfolios from Great Ones

Performance

SEO

Why I'm Giving Away 8 Next.js Templates for Free (And What I Want in Return)

The problem a discount doesn't solve

What's in the bundle

What I'm trading for

Why the math actually works

What happens on May 19

If you want to participate

Tailwind v4 Container Queries: A Practical Guide with Real Examples

Tailwind v4 Container Queries: A Practical Guide with Real Examples

What problem container queries solve

The basic pattern in Tailwind v4

Step 1: Mark the container

Step 2: Use container variants on children

Step 3: Container sizes default

A real example: a reusable product card

Gotcha 1: The @container parent needs explicit sizing

Gotcha 2: Container vs viewport variants are distinct

Gotcha 3: Named containers for multi-level queries

Performance notes

Browser support

When not to use container queries

Migrating existing components

Wrapping up

How to Use Next.js Templates with Cursor and Claude Code (2026 Workflow)

Why This Matters

Step 1: Clone and Get It Running

Step 2: Point Your AI Tool at the Repo

With Cursor

With Claude Code

Step 3: Ask It to Rebrand

Step 4: Replace Demo Data

Step 5: Add Custom Sections

Step 6: Wire Up the Real Stuff

Step 7: Review, Don't Accept Everything

A Realistic Timeline

The Combo That Works Best

The Templates I Ship With This Workflow

Closing

Tailwind CSS v4 Complete Migration Guide

Why Upgrade at All?

Step 1: Update Dependencies

Step 2: Update PostCSS Config

Custom Domains for Next.js: The Cloudflare + Vercel Setup That Works in 2026

The Stack

Step 1: Buy the Domain on Cloudflare

Step 2: Add the Domain to Vercel

Step 3: Get DNS Records

Step 4: Add to Cloudflare DNS

Step 5: Wait for Verification

Gotcha 1: The `@container` parent needs explicit sizing

`next.config.ts\` assumptions