DEV Community: TheKitBase

How to Cut Your AI/LLM Costs in 2026: Caching, Cheaper Models, and Multi-Agent Routing

TheKitBase — Thu, 23 Jul 2026 06:57:17 +0000

AI features ship fast and then the bill arrives. The good news: most LLM spend is avoidable waste - the same prompt paid for a thousand times, a frontier model doing work a cheap one could handle, tokens generated that nobody reads. Here are six levers that cut real money, ordered by how much they typically save, with numbers and code you can paste today.

Lever 1: Prompt caching (the biggest single win)

Most AI apps resend the same large prefix on every request - a system prompt, tool definitions, a knowledge base, few-shot examples. That prefix is often 80% of your input tokens, and you are paying full price for it every single time. Prompt caching bills the cached prefix at roughly one tenth of the input price on a hit. Writing to the cache costs about 1.25x, so the break-even is two requests - after that it is close to 90% off the cached portion.

The rule is that caching is a prefix match: anything before your cache breakpoint must be byte-identical across requests. Put the stable content first (frozen system prompt, deterministic tool list) and the volatile content (the user's actual question, timestamps, per-request ids) last. A single datetime.now() interpolated into the system prompt invalidates the entire cache on every request - the most common reason a cache hit rate sits at zero.

Fastest audit: log cache_read_input_tokens on every response. If it is zero across repeated requests with the same system prompt, a silent invalidator (a timestamp, a random id, unsorted JSON) is in your prefix. Find it and you just cut input cost by up to 90%.

Lever 2: Right-size the model

The reflex to route everything to the smartest, most expensive model is the second biggest source of waste. Model tiers differ by 5x or more in price, and most requests in a real app - classification, extraction, short answers, routing - do not need the top tier. The trick is matching the model to the job, not to your ambition.

Tier	Rough price / 1M tokens (in / out)	Use it for
Small (Haiku-class)	~$1 / ~$5	Classification, extraction, routing, short replies
Mid (Sonnet-class)	~$3 / ~$15	Most product features, tool-calling agents, coding help
Frontier (Opus-class)	~$5 / ~$25	Hard reasoning, long-horizon agents, the few requests that need it

Prices move, so check current rates - but the ratios hold: the small tier is roughly 5x cheaper than frontier for input and output alike. And do not sleep on open-source models. Llama, Mistral, DeepSeek, and Qwen are available through the same gateway, and for high-volume, well-scoped tasks (summarization, extraction, internal tools) they can undercut hosted frontier models dramatically. Route the boring 80% of your traffic to a cheap or open model and reserve the expensive tier for the requests that actually need it.

Lever 3: Multi-agent routing (the cascade pattern)

Levers 1 and 2 combine into the highest-leverage architecture: a cheap model classifies each incoming request, and only the genuinely hard ones escalate to an expensive model. This is the cascade - a fast, cheap triage step in front of your real work. In most apps the classifier costs a rounding error and diverts the majority of traffic away from the frontier tier.

import { generateText } from 'ai'

async function answer(userMessage: string) {
  // 1. A cheap model triages the request
  const { text: difficulty } = await generateText({
    model: 'anthropic/claude-haiku-4.5',
    prompt: 'Classify as SIMPLE or HARD. Reply with one word only.\n\n' + userMessage,
  })

  // 2. Route to the tier that fits
  const model =
    difficulty.trim().toUpperCase() === 'HARD'
      ? 'anthropic/claude-sonnet-4.6'
      : 'anthropic/claude-haiku-4.5'

  const result = await generateText({ model, prompt: userMessage })
  return result.text
}

The same idea scales up: specialized agents per job (a cheap extractor, a mid-tier writer, a frontier planner) instead of one expensive generalist doing everything. You pay top-tier prices only for the steps that are genuinely top-tier work.

Lever 4: Response and semantic caching

Prompt caching (Lever 1) discounts the shared prefix. Response caching skips the model call entirely when the same request comes in again. For static-knowledge queries - FAQs, policy lookups, translations, extraction from identical documents - cache the whole response at the gateway and serve repeats for free.

import { generateText } from 'ai'

const result = await generateText({
  model: 'openai/gpt-5.4',
  prompt: 'Summarize our refund policy in two sentences.',
  providerOptions: {
    gateway: { cacheControl: 'max-age=3600' }, // serve repeats for 1 hour
  },
})

The cache key is the model plus the prompt plus the generation parameters, so identical requests hit and anything that varies (a real conversation) misses and is billed normally. Do not cache user-specific conversations; do cache the repetitive, deterministic lookups that make up a surprising share of most apps.

Lever 5: Gateway-level cost controls

Routing every call through a single gateway is what makes the levers above governable instead of theoretical. From one place you get spend attribution by feature and user, automatic failover to a cheaper provider or model when the primary is down or rate-limited, per-user rate limits so one abuser cannot run up your bill, and budget alerts before you blow the month.

import { gateway } from 'ai'

const result = await generateText({
  model: gateway('anthropic/claude-sonnet-4.6'),
  prompt,
  providerOptions: {
    gateway: {
      order: ['anthropic', 'bedrock'],       // failover order
      models: ['openai/gpt-5.4'],            // fallback model if the primary fails
      user: userId,                           // per-user tracking and rate limits
      tags: ['feature:support', 'env:prod'],  // cost attribution
    },
  },
})

Because the gateway charges provider list price with zero markup, you get all of this - failover, tracking, per-user limits, budgets - without paying more per token than calling the provider directly. Tags turn a mystery invoice into a per-feature cost breakdown, which is how you find the one endpoint quietly burning half your budget.

Lever 6: Token hygiene

The unglamorous lever that adds up. You pay per token in and per token out, so trim both.

Use structured output (a schema) instead of asking for JSON in prose - shorter, parseable, and no wasted tokens explaining the format.
Cap output with maxOutputTokens. A model with no ceiling will happily write three paragraphs where you needed one sentence.
Trim the context you resend - old tool results and stale history are pure cost. Summarize or drop them.
For anything not real-time (nightly reports, bulk classification, embeddings backfills), use the Batch API - it runs asynchronously at roughly half price.

Putting it together

None of these are exotic. Stacked, they routinely take an AI feature from alarming to boring on the cost side. A representative before-and-after for a support assistant handling a mix of simple and hard questions:

Setup	Relative cost
Everything to the frontier model, full prefix every request	100%
+ prompt caching on the system prompt and tools	~40%
+ cascade routing (cheap triage, escalate only hard ones)	~15%
+ response caching on repeated lookups + output caps	~10%

The exact numbers depend on your traffic mix, but the shape is real: the same product, an order of magnitude cheaper to run, with no drop in quality on the requests that actually matter - because the frontier model still handles those. The waste you cut was never doing useful work.

Keel, our AI SaaS starter kit, is built cost-aware from the start - gateway routing, model fallbacks, and a streaming assistant wired so you can swap tiers with a string. Start from an architecture that already respects your bill.

Tool Calling with the AI SDK in Next.js: Build an Assistant That Actually Does Things

TheKitBase — Thu, 23 Jul 2026 06:55:20 +0000

A chat box that only answers questions is a demo. The moment your AI feature has to look something like a user's orders, book a slot, or update a record, you need tool calling - letting the model call functions you define, read the results, and keep going until the task is done. This guide builds that loop with the Vercel AI SDK v6 in Next.js, and it is shorter than you would expect.

The mental model

You give the model a set of tools - each one a description, an input schema, and a function to run. The model decides which tools to call and with what arguments; the SDK runs your functions, feeds the results back, and loops until the model produces a final answer. You never write the orchestration loop by hand.

Setup: one package, gateway model strings

Install the ai package. For the model, pass a plain provider/model string and it routes through the Vercel AI Gateway automatically - no provider SDK, no API key juggling, and you can swap models by changing the string. Gateway slugs use dots for versions (anthropic/claude-sonnet-4.6), which is the one naming gotcha to remember.

// app/api/chat/route.ts
import { generateText } from 'ai'

export async function POST(req: Request) {
  const { prompt } = await req.json()

  const result = await generateText({
    model: 'anthropic/claude-sonnet-4.6', // routes through AI Gateway
    prompt,
  })

  return Response.json({ text: result.text })
}

Defining a tool

A tool is a description (so the model knows when to reach for it), an inputSchema built with Zod (so arguments are validated and typed), and an execute function (your actual code). Be prescriptive in the description about when to call it - not just what it does.

import { tool } from 'ai'
import { z } from 'zod'

const getOrders = tool({
  description:
    "Look up a customer's recent orders. Call this whenever the user asks about order status, history, or a specific purchase.",
  inputSchema: z.object({
    customerId: z.string().describe('The customer id from the session'),
    limit: z.number().optional().describe('How many orders to return'),
  }),
  execute: async ({ customerId, limit = 5 }) => {
    const orders = await db.orders.findMany({
      where: { customerId },
      take: limit,
      orderBy: { createdAt: 'desc' },
    })
    return orders
  },
})

In AI SDK v6 the field is inputSchema, not parameters. If you are following an older tutorial that uses parameters, it will not typecheck - the rename is the single most common upgrade error.

The multi-step loop

One tool call is rarely the whole task. The model might call getOrders, read the result, then decide it also needs to check inventory before answering. stopWhen lets the SDK run that back-and-forth automatically - it keeps looping (call tool, feed result back, let the model continue) until the model stops calling tools or you hit the step cap.

import { generateText, stepCountIs } from 'ai'

const result = await generateText({
  model: 'anthropic/claude-sonnet-4.6',
  stopWhen: stepCountIs(5), // cap the loop at 5 steps
  tools: { getOrders, checkInventory },
  prompt: 'Where is my last order and is a replacement in stock?',
})

// result.text is the final answer after all tool calls resolved
console.log(result.text)

That stepCountIs(5) is your safety belt. Without a cap, a confused model could loop indefinitely. Five is a reasonable default for most assistants; raise it for genuinely multi-hop tasks, lower it for simple lookups.

Streaming the whole thing to the UI

For a chat interface you want tokens and tool activity to stream, not arrive in one blob. Swap generateText for streamText - same tools, same stopWhen - and pipe it to the client. The user sees the assistant think, call a tool, and answer in real time.

import { streamText, stepCountIs } from 'ai'

export async function POST(req: Request) {
  const { messages } = await req.json()

  const result = streamText({
    model: 'anthropic/claude-sonnet-4.6',
    stopWhen: stepCountIs(5),
    tools: { getOrders, checkInventory },
    messages,
  })

  return result.toUIMessageStreamResponse()
}

Gating the dangerous tools

Read-only tools (look up orders, search docs) can run automatically. Tools with side effects - refund a payment, delete a record, send an email - should not fire without a human in the loop. The cleanest pattern is to make the execute function return a proposal instead of performing the action, then confirm on the client before a second call actually commits it.

Validate every argument at the boundary - the model's output is untrusted input, so treat customerId like anything else a user could send.
For destructive actions, have execute return what it would do and surface a confirm step in the UI before committing.
Scope your tools to the current session - never let the model pass in a customerId that is not the authenticated user.

From tools to a reusable agent

Once you have a set of tools you reuse across routes, wrap them in an agent instead of re-declaring the config each time. The AI SDK's ToolLoopAgent pattern bundles the model, tools, and stopWhen into one object you can call from anywhere and type end-to-end. Same loop, less repetition.

The whole point of tool calling: your assistant stops being a search box with personality and becomes a teammate that can actually operate your product - safely, because you define exactly what it can touch.

Keel, our AI SaaS starter kit, ships with a streaming assistant, tool-calling wired through the AI Gateway, and the auth and billing around it - so you start from a working agent instead of a blank route handler.

Next.js 16 Cache Components: use cache, PPR, and When to Reach for Each

TheKitBase — Thu, 23 Jul 2026 06:46:38 +0000

Next.js 16 shipped Cache Components - the feature that finally lets a single route mix static HTML, cached data, and per-request dynamic content without splitting it into separate pages. It is Partial Prerendering (PPR) made stable, plus a new use cache directive that replaces the old unstable_cache and the awkward route-segment config flags. This guide covers what changed, the three content types you now think in, and the runtime-data rule that trips up almost everyone on day one.

What actually changed

If you were using the experimental PPR flag, it is gone. Cache Components is a single config switch, and it turns on the whole model - static shell, cached segments, and streamed dynamic content in one route.

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true, // replaces experimental.ppr
}

export default nextConfig

Once it is on, every piece of your route falls into one of three buckets. The whole mental model is learning which bucket each component belongs in.

The three content types

Static - synchronous code, imports, and pure markup. Prerendered at build time and served instantly from the CDN. Your header, nav, and layout shell.
Cached - async data that does not need to be fresh on every request. Marked with use cache. Think product lists, blog posts, dashboard stats.
Dynamic - runtime data that must be fresh (cookies, headers, per-user state). Wrapped in Suspense so it streams in after the shell paints.

import { Suspense } from 'react'
import { cookies } from 'next/headers'
import { cacheLife } from 'next/cache'

export default function DashboardPage() {
  return (
    <>
      {/* Static - instant from the CDN */}
      <header><h1>Dashboard</h1></header>

      {/* Cached - fast, revalidates hourly */}
      <Stats />

      {/* Dynamic - streams in with fresh data */}
      <Suspense fallback={<NotificationsSkeleton />}>
        <Notifications />
      </Suspense>
    </>
  )
}

async function Stats() {
  'use cache'
  cacheLife('hours')
  const stats = await db.stats.aggregate()
  return <StatsDisplay stats={stats} />
}

async function Notifications() {
  const userId = (await cookies()).get('userId')?.value
  const items = await db.notifications.findMany({ where: { userId } })
  return <NotificationList items={items} />
}

The payoff: the user sees the static shell and cached stats instantly, and the personalized notifications stream in a beat later - instead of the whole page blocking on the slowest query.

The use cache directive

use cache works at three levels - the whole file, a single component, or a plain data function. Put it at the top of whatever scope you want cached, and Next.js generates the cache key automatically from the function's arguments and closure variables. No manual key arrays like the old unstable_cache required.

// Function level - cache a query
export async function getPosts() {
  'use cache'
  return db.posts.findMany()
}

// Component level - cache a whole subtree
export async function PricingTable() {
  'use cache'
  const plans = await db.plans.findMany()
  return <Plans plans={plans} />
}

Controlling lifetime with cacheLife

By default a use cache block is stale after 5 minutes and revalidates after 15. Override that with a built-in profile or an inline config. The built-in profiles are default, minutes, hours, days, weeks, and max.

import { cacheLife } from 'next/cache'

async function getData() {
  'use cache'
  cacheLife({
    stale: 3600,      // serve stale for 1 hour while revalidating
    revalidate: 7200, // refresh in the background every 2 hours
    expire: 86400,    // hard expiry after 1 day
  })
  return fetch('https://api.example.com/data')
}

Invalidation: cacheTag, updateTag, revalidateTag

Tag your cached data, then invalidate by tag from a Server Action. The one distinction that matters: updateTag refreshes within the same request (the user who just edited sees fresh data immediately), while revalidateTag is background-only (the next visitor sees fresh data). Reach for updateTag after a mutation the current user made; reach for revalidateTag for everyone else's writes.

import { cacheTag } from 'next/cache'

async function getProduct(id: string) {
  'use cache'
  cacheTag('products', 'product-' + id)
  return db.products.findUnique({ where: { id } })
}

// In a Server Action:
'use server'
import { updateTag, revalidateTag } from 'next/cache'

export async function editProduct(id: string, data: FormData) {
  await db.products.update({ where: { id }, data })
  updateTag('product-' + id)   // same request sees the change
  revalidateTag('products')    // everyone else's next load is fresh
}

The rule that trips everyone up

You cannot call cookies(), headers(), or read searchParams inside a use cache block. It makes sense once you say it out loud - cached output has to be identical for everyone, and those APIs are per-request. The fix is to read the dynamic value outside the cached function and pass it in as an argument, where it becomes part of the cache key automatically.

// Wrong - runtime API inside use cache
async function CachedProfile() {
  'use cache'
  const session = (await cookies()).get('session')?.value // Error
  return <div>{session}</div>
}

// Right - read outside, pass in as an argument
async function ProfilePage() {
  const session = (await cookies()).get('session')?.value
  return <CachedProfile sessionId={session} />
}

async function CachedProfile({ sessionId }: { sessionId: string }) {
  'use cache'
  const data = await fetchUserData(sessionId) // sessionId is part of the key
  return <div>{data.name}</div>
}

If you genuinely cannot refactor (a compliance wrapper, say), use cache: private is the escape hatch - it permits runtime APIs and caches per-user. Use it sparingly; it is not a shared cache.

Migrating from the old world

If you are coming from an earlier Next.js app, most of the migration is deleting things. Here is the direct mapping.

Old	Next.js 16 replacement
experimental.ppr	cacheComponents: true
export const dynamic = 'force-dynamic'	Remove - it is the default
export const dynamic = 'force-static'	'use cache' + cacheLife('max')
export const revalidate = N	cacheLife({ revalidate: N })
unstable_cache()	'use cache' directive

The unstable_cache migration is the big one, and it is mostly deletion: no more manual key arrays, tags move from an options object into cacheTag() calls, and revalidate moves into cacheLife(). The same cookies/headers restriction that applied to unstable_cache applies to use cache, so any code that already respected it ports cleanly.

Limitations worth knowing up front

Node.js runtime only - Cache Components does not run on the Edge runtime.
No static export - you need a server, so next export is out.
Non-deterministic values (Math.random, Date.now) run once at build time inside a cached block. For per-request randomness, call connection() from next/server to defer to request time.

When to reach for each

The decision is almost always about freshness. Does the data change per-user or per-request? Dynamic, wrapped in Suspense. Does it change occasionally and can be a few minutes stale? Cached with use cache and a cacheLife that matches your tolerance. Never changes between deploys? Leave it static. Get those three buckets right and you get CDN-fast first paint with correct, fresh data streaming in - which used to require picking one or the other.

Every TheKitBase template is built on Next.js 16 with this rendering model already wired up - static shells, cached data layers, and streamed dynamic content, so you inherit the fast-by-default architecture instead of retrofitting it.

The Best Free Next.js Templates in 2026 (Sorted by Use Case)

TheKitBase — Tue, 14 Jul 2026 13:14:16 +0000

There are a lot of free Next.js templates out there, and most "best free templates" lists are just a wall of links with no guidance. This one is sorted by what you're actually building, with the genuinely good free options in each category and an honest note on where free stops being enough. Every pick here is free to use; the premium upgrades are called out where they save real time.

Where to find free templates first

Before any list, know the three sources that cover most needs and are always current because their maintainers keep them updated:

The official Next.js examples repo - dozens of minimal starters for specific integrations (auth, CMS, databases, i18n), maintained alongside the framework
The Vercel Templates directory - a large gallery of free and paid templates you can deploy in one click
shadcn/ui - not a template but a component collection you copy into your project; the fastest way to a good-looking UI from scratch

For marketing sites and landing pages

Free marketing starters get you a hero, features, and a footer, which is enough to validate an idea. What they rarely give you is a complete, cohesive multi-page site with blog, pricing, and auth designed as one system. For a quick landing page, the Vercel and Tailwind free starters are fine; when you need a finished marketing site, that's where a premium template earns its price.

For dashboards and admin panels

shadcn/ui ships an excellent free dashboard example, and it's the best free starting point for an admin UI - charts, tables, and a sidebar you can build on. The gap with free dashboards is depth: you typically get one or two screens, not the 9-12 cohesive pages a real admin panel needs (billing, team, settings, reports). Free gets you the shell; a production template gets you the whole app.

For e-commerce

Next.js Commerce, Vercel's open-source storefront, is the standout free e-commerce starter - a real, deployable store wired for a headless backend. It's an excellent foundation if you're comfortable connecting a commerce backend. For a simpler, static storefront with a working cart and no backend to configure, a focused template will be faster to launch.

For docs and content

Nextra is the go-to free documentation framework on Next.js - MDX, search, and a clean default theme, all open-source. For blogs and content sites, the official Next.js blog examples and any of the many free MDX starters will do the job. Docs is one area where free options are genuinely strong.

For AI apps

Vercel's open-source AI Chatbot template is the best free starting point for anything with a streaming AI interface - it's the reference implementation for the AI SDK and stays current with it. Open SaaS (on the Wasp framework) is a capable free full-stack option with AI examples. Both are great to learn from; neither is a complete, polished SaaS with the product shell around the AI.

For portfolios

Portfolios are the most abundant category of free template - GitHub is full of open-source Next.js portfolio starters, and many are genuinely good. If you want something that stands out from the common grey-on-white developer portfolio, that's where a designed premium template is worth it, but for a solid free portfolio you're spoiled for choice.

When free is enough (and when it isn't)

Free templates are perfect for learning, prototyping, side projects, and anything where your time is worth less than the money saved. They stop being enough when you're shipping something people pay for and your time matters: free templates are usually shallow (a few screens, not a whole product), inconsistent (assembled from parts rather than designed as a system), and yours to finish. A good premium template is the finished system - which is the difference between a weekend of setup and an afternoon of shipping.

Rule of thumb: use free templates to learn and prototype; buy a premium one the moment your time is worth more than the price. A $79 template that saves a week is one of the cheapest hours-back trades in software.

When free stops being enough - see TheKitBase templates from $39

The Ultimate Next.js SaaS Tech Stack for 2026

TheKitBase — Tue, 14 Jul 2026 13:10:27 +0000

The hardest part of starting a SaaS in 2026 isn't writing code - it's choosing the stack. Every layer has five defensible options and a dozen strong opinions. This is an opinionated, boringly reliable stack for building a Next.js SaaS: the choices that let you ship fast, scale sanely, and not rewrite everything in six months. Where there's a real fork, I'll name the alternative and when to take it.

The stack at a glance

Layer	Pick	Strong alternative
Framework	Next.js (App Router)	-
Language	TypeScript (strict)	-
Styling	Tailwind CSS v4	CSS Modules
Components	shadcn/ui	Build your own
Auth	Auth.js	Clerk (managed)
Database	Postgres (Neon) + Drizzle	Supabase / Prisma
Payments	Stripe	Dodo / Lemon Squeezy (MoR)
AI	Vercel AI SDK + Claude	-
Email	Resend	Postmark
Hosting	Vercel	-

Framework, language, and styling

Next.js with the App Router is the default for a reason: server components, server actions, and a single codebase for your marketing site and app. TypeScript in strict mode is non-negotiable for anything you'll maintain - the compile-time safety pays for itself the first time you rename a field. Tailwind CSS v4 for styling, with its @theme token system, makes an entire product reskinnable from a handful of variables and keeps styles colocated with markup.

Auth and database

For auth, Auth.js (formerly NextAuth) is the flexible, self-hosted default; reach for Clerk when you'd rather pay to never think about auth UI, sessions, and organizations again. For data, Postgres is the safe forever-choice - Neon and Supabase both give you serverless Postgres with generous free tiers. Pair it with Drizzle (typed, SQL-first, light) or Prisma (batteries-included, more magic). The through-line: pick managed Postgres and a typed query layer, and you won't outgrow it.

Payments

Stripe is the default and the most capable, and the right pick if you're comfortable handling sales tax and VAT yourself (or with a tax add-on). If you'd rather offload tax and compliance entirely, a merchant-of-record provider like Dodo Payments or Lemon Squeezy handles the tax paperwork globally in exchange for a slightly higher fee - often worth it for a small team selling internationally. Decide based on whether you want to own tax compliance or rent it.

AI, email, and hosting

If your SaaS has an AI feature, the Vercel AI SDK is the standard way to build it - one API across providers, first-class streaming, and an easy swap between models. Point it at Claude for strong reasoning and a clean developer experience. For transactional email (receipts, invites, password resets), Resend is the modern default with a great DX and React-based email templates. And for hosting, Vercel is the path of least resistance for Next.js - zero-config deploys, preview URLs, and edge/serverless handled for you.

AI: Vercel AI SDK + Claude - streaming, provider-agnostic, swap models in one line
Email: Resend - transactional email with React templates
Hosting: Vercel - zero-config Next.js deploys and preview URLs
Analytics: Vercel Analytics or PostHog when you need product analytics + flags

The best stack is the one you don't have to think about. Every pick here is chosen to be reliable and swappable, not clever - so you spend your energy on the product, not on infrastructure decisions you'll second-guess at 2am.

Skip the setup - TheKitBase templates ship on exactly this stack

Next.js vs Astro in 2026: Which Should You Actually Use?

TheKitBase — Tue, 14 Jul 2026 13:03:34 +0000

Next.js and Astro get pitted against each other constantly, which is a little unfair because they were built for different jobs. Next.js is a full-stack React framework for building applications; Astro is a content-first framework for building fast, mostly-static sites. They overlap in the middle - marketing sites, blogs, docs - which is exactly where the choice gets interesting. Here's how they actually differ and a clear rule for deciding.

The core difference: apps vs. content

Next.js assumes you're building an application - interactivity, authentication, dashboards, data that changes per user. It ships React, runs server components, supports server actions and dynamic rendering, and gives you a full backend surface. Astro assumes you're building content - articles, marketing pages, documentation - and optimizes ruthlessly for that: it ships zero JavaScript by default and only hydrates the interactive "islands" you explicitly mark.

	Next.js	Astro
Built for	Full-stack apps	Content-first sites
Default JS shipped	React runtime	Zero (islands opt-in)
Rendering	SSR, SSG, ISR, RSC	Static-first, SSR available
UI framework	React	Any (React, Vue, Svelte) or none
Best fit	Dashboards, SaaS, auth'd apps	Blogs, docs, marketing

Performance: Astro's home turf

For a content site with little interactivity, Astro is hard to beat on raw performance because it ships almost no JavaScript - the browser gets HTML and CSS and nothing to parse and execute. Next.js has closed much of the gap with React Server Components, which keep non-interactive components off the client, and a well-built Next.js content site scores excellently. But if your page is genuinely mostly static content, Astro's zero-JS default gives it a structural head start.

Where Next.js pulls ahead

The moment your product becomes an application - users log in, data is personalized, state is complex, you need a real backend - Next.js is the stronger choice. The App Router, server components, server actions, and the enormous React ecosystem are built for exactly this. Astro can do SSR and can embed React islands, but you'd be fighting its content-first grain to build a full SaaS in it.

The rule for picking

Building a blog, docs site, or marketing site that's mostly content - Astro.
Building an app with auth, dashboards, and dynamic data - Next.js.
Building a SaaS whose marketing site and app should share one codebase and stack - Next.js for both keeps it simple.
Not sure and you might grow into an app - Next.js is the safer long-term bet.

It's not really a rivalry - it's a fork in the road. Content site: reach for Astro. Application: reach for Next.js. The trap is picking Astro because it benchmarks faster, then spending months bending it into an app it was never meant to be.

Building an app? Start from a production Next.js foundation

Cursor vs Claude Code vs Copilot: The 2026 AI Coding Tools Compared

TheKitBase — Tue, 14 Jul 2026 12:59:24 +0000

AI-assisted coding stopped being a novelty and became the default way most developers work. By 2026 three tools lead the space, and they're not really the same kind of thing: Cursor is an AI-first editor, Claude Code is an agentic terminal tool, and GitHub Copilot is an assistant that lives inside your existing IDE. They overlap enough to compete and differ enough that the right pick depends on how you actually work. Here's an honest breakdown.

The quick version

Tool	Form factor	Best at	Model
Cursor	AI-first editor (VS Code fork)	Inline editing + in-context chat	Multiple (incl. Claude, GPT)
Claude Code	Agentic terminal / CLI	Autonomous multi-file changes	Claude (Opus / Sonnet)
GitHub Copilot	Plugin for your existing IDE	Completions inside your current setup	Multiple (incl. Claude, GPT)

Cursor - the AI-first editor

Cursor is a fork of VS Code rebuilt around AI. You get everything familiar about VS Code plus deep AI integration: inline edits, a chat that knows your codebase, and an agent mode that can make multi-file changes while you watch. Because it's the editor itself, the AI has rich context about what you're looking at, and the feedback loop is tight - highlight code, describe a change, accept the diff.

Best for developers who want AI woven into the editor, not bolted on
Strong inline editing and codebase-aware chat
You switch editors (from VS Code) to use it
Model choice, with usage-based and subscription pricing tiers

Claude Code - the agentic terminal tool

Claude Code takes a different shape entirely: it lives in your terminal and works agentically. You describe a task in natural language and it explores the codebase, makes changes across many files, runs commands, and iterates - closer to delegating to a capable pair than autocompleting your typing. It's editor-agnostic (your files are just files), which makes it a strong fit for larger, multi-step changes and for developers who live in the terminal.

Best for autonomous, multi-file tasks and refactors you can describe end to end
Editor-agnostic - works alongside whatever you already use
Terminal-native, scriptable, and strong at planning across a codebase
Runs on Claude models; available via subscription and API-based usage

GitHub Copilot - the assistant in your IDE

Copilot is the incumbent and the least disruptive to adopt: it's a plugin for the IDE you already use (VS Code, JetBrains, and others), so nothing about your setup changes. It started as autocomplete and has grown chat and agent capabilities, plus tight integration with GitHub itself - pull requests, issues, and code review. If you don't want to change editors and you live in the GitHub ecosystem, it's the path of least resistance.

Best for staying in your current IDE with zero workflow change
Deep GitHub integration (PRs, issues, review)
Completions, chat, and agent mode across many editors
Predictable per-seat subscription pricing

How to choose

Want AI as the center of your editor and you'll switch from VS Code - Cursor.
Want to delegate whole multi-file tasks from the terminal - Claude Code.
Want to keep your exact IDE and GitHub workflow - Copilot.
Honestly, many developers run two: a completion/edit tool in the editor and an agentic tool for big changes.

Whichever you pick, the same rule applies: AI tools accelerate work within a structure far better than they invent structure from nothing. Start from a real, well-architected foundation and any of these tools becomes dramatically more useful - the coherence is already there for them to build on.

Give your AI tool a real foundation - browse TheKitBase templates

Serif Is the New Sans: Editorial Typography Comes to SaaS

TheKitBase — Fri, 10 Jul 2026 18:14:36 +0000

For about ten years, every SaaS site looked typographically identical: a clean, neutral sans-serif for everything, usually Inter or something close to it. Safe, legible, and completely interchangeable. In 2026 that's changing - the products that look most distinctive are leading with a characterful serif for their headlines, and it's the single fastest way a site now signals taste. Here's why the serif revival happened and how to use one without looking like a wedding invitation.

Why sans-everywhere got boring

There was nothing wrong with Inter. That was the problem. When every startup uses the same neutral sans for headlines and body, typography stops carrying any personality - it becomes a delivery mechanism for words and nothing more. Once a look becomes universal, it stops signaling "modern" and starts signaling "default." The serif revival is a reaction to that sameness: a display serif immediately makes a page feel like someone made a choice.

The new serifs aren't your grandfather's serifs

This isn't Times New Roman. The serifs driving the trend are modern, variable, and full of character - faces like Fraunces, Instrument Serif, GT Sectra, and the new wave of expressive display serifs. They have high contrast, distinctive details, and optical sizing that lets them go from elegant at large sizes to sturdy at small ones. Used big, they carry a page. The move is editorial - closer to a magazine masthead than a corporate letterhead.

How to pair without looking dated

The winning formula is contrast: a characterful serif for display, a clean sans or mono for everything functional. The serif provides personality where it's read slowly (headlines, hero, pull quotes); the sans provides clarity where it's read fast (body, UI, labels). Mixing them is what makes it feel intentional rather than nostalgic.

/* Display serif + clean body sans + mono for data */
@theme {
  --font-display: "Fraunces", serif;       /* headlines only */
  --font-body:    "Hanken Grotesk", sans-serif;
  --font-mono:    "Geist Mono", monospace;  /* labels, prices, code */
}

h1, h2, .display { font-family: var(--font-display); }
body { font-family: var(--font-body); }
.label, .price { font-family: var(--font-mono); }

The rules that keep it tasteful

Serif for display only - headlines, hero, quotes. Never set body text in a display serif.
Maximize the contrast - a big elegant serif over a small clean sans reads as considered; two similar faces read as an accident.
Use optical sizing if the face has it, so the serif looks right large and small.
One serif, used with intent - a second decorative face is one accessory too many.
Let the serif be the personality, and keep everything around it quiet.

Typography is the cheapest way to make a product look like it has a point of view. Swapping a neutral sans headline for a characterful serif - and keeping the body clean - changes the entire personality of a page without touching the layout.

See Agency Studio - editorial serif typography done right

Your Shadows Are Flat Gray (That's the Tell)

TheKitBase — Fri, 10 Jul 2026 18:12:29 +0000

Here's a detail almost nobody consciously notices but everybody feels: shadows. Put a default card next to a carefully designed one and the designed one looks more expensive, even if the layout is identical. A big part of that difference is the shadow. The default box-shadow everyone reaches for is flat, gray, and a single layer - and it's one of the clearest tells that a design was defaulted rather than considered. Here's what's wrong with it and how to fix it in a few lines of CSS.

Why flat gray shadows look cheap

Real shadows in the physical world aren't pure gray, and they aren't a single hard edge. They pick up the color of the surface they fall on, they get softer and fainter the further they travel, and they're really a stack of overlapping shadows at different distances. The stock box-shadow: 0 4px 6px rgba(0,0,0,0.1) violates all of that - one flat, evenly-gray blur - so it reads as artificial. Your eye doesn't articulate why; it just clocks the element as flatter and cheaper.

Tinted shadows: carry the color

The single highest-leverage fix is to stop using gray. Instead of black at low opacity, tint the shadow toward the background or the accent color. On a warm paper background, a warm-tinted shadow feels natural; a cool gray one feels pasted on. The shadow should belong to the scene it's in.

/* Default - flat, gray, pasted-on */
box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);

/* Tinted - shadow carries the surface/accent hue */
box-shadow: 0 4px 14px rgba(80, 40, 10, 0.12);   /* warm surface */
/* or tinted toward a brand accent on colored buttons */
box-shadow: 0 8px 20px -6px rgba(229, 64, 42, 0.35);

Layer them for real depth

The second upgrade is to stack multiple shadows. A close, tight shadow grounds the element; a larger, softer one gives it height. Together they mimic how light actually falls, and the element reads as genuinely lifted off the page rather than stickered on.

/* Layered, tinted elevation - close + far */
box-shadow:
  0 1px 2px rgba(20, 17, 11, 0.06),
  0 4px 8px rgba(20, 17, 11, 0.06),
  0 16px 32px -8px rgba(20, 17, 11, 0.10);

Use it with restraint

Better shadows are not more shadows. Elevation should mean something - a card that floats, a menu that pops, a button you can press. If everything on the page has a heavy shadow, nothing reads as elevated and the whole thing looks heavy. Reserve the richest shadows for the elements that are genuinely lifted, and let everything else sit flat.

Tinted, layered shadows are one of those details that never gets mentioned in a testimonial but quietly does half the work of making a product feel premium. Swap gray for a hue that belongs to your palette and stack two layers - it's ten minutes and it changes how expensive the whole UI feels.

See Keel - tinted, layered shadows throughout the "Gilt" design system

Bento Grids Ate SaaS Design in 2026 (And How to Build One)

TheKitBase — Fri, 10 Jul 2026 18:09:16 +0000

Scroll any SaaS landing page shipped in the last year and you'll hit one: a grid of cards in different sizes, one big feature anchoring the corner, smaller ones filling in around it, each with its own little visual. The bento grid went from an Apple keynote flourish to the default feature section in about eighteen months. It's everywhere because it solves a real problem - and it's easy to get wrong. Here's why it took over, how to build one, and the rules that separate a bento grid from a cluttered mess.

What a bento grid actually is

The name comes from the Japanese bento box - a single tray divided into compartments of different sizes, each holding something different, the whole thing composed to feel balanced. In UI terms it's an asymmetric grid: cards that span different numbers of rows and columns, so a primary item gets a large cell and supporting items get smaller ones. Apple popularized it on hardware and OS feature pages, and SaaS marketing adopted it wholesale because it fixed the thing everyone hated about feature sections.

Why it beat the 3-column grid

The old feature section was three identical columns of icon + title + paragraph. Everything the same size means everything reads as equally important, which means nothing stands out, and the eye glazes over. A bento grid encodes hierarchy into the layout itself - the biggest cell is your headline feature, and the reader knows that instantly, before reading a word.

Visual hierarchy - cell size signals importance, so your best feature leads without a label saying so
Scannable - varied shapes give the eye anchors instead of a wall of equal boxes
Room for visuals - a large cell can hold a real product shot or animation, not just an icon
Density without clutter - you can show more features in less vertical space
It just looks modern - the asymmetry reads as designed, not defaulted

Building one with CSS grid

You don't need a library. CSS grid with column and row spans does the whole thing. Define a grid, then let specific cells span extra tracks - the featured cell takes two columns, the rest fall into place.

.bento {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-auto-rows: 200px;
  gap: 1rem;
}

/* the hero feature - twice as wide and tall */
.bento > .featured {
  grid-column: span 2;
  grid-row: span 2;
}

/* a wide-but-short supporting cell */
.bento > .wide {
  grid-column: span 2;
}

@media (max-width: 640px) {
  .bento { grid-template-columns: 1fr; }  /* stack on mobile */
  .bento > * { grid-column: auto; grid-row: auto; }
}

That's the entire mechanism. The design work is deciding which cells get the spans and what goes inside each one - the CSS is trivial once the composition is right.

The rules that keep it from looking messy

A bento grid fails when it becomes a random assortment of boxes. What makes it feel composed rather than chaotic is restraint and rhythm.

One clear hero cell - exactly one item should dominate. Two large cells fight each other.
Limit the size variations - two or three cell sizes, not six. Too many breaks the rhythm.
Each cell communicates in under five seconds - title, one line, one visual. If it needs a paragraph, it's a doc, not a bento cell.
Keep the gaps and radii consistent across every cell so the grid reads as one object.
Collapse cleanly to a single column on mobile - the spans should reset, not overflow.

The bento grid works because it does the reader's prioritizing for them: the layout itself says "look here first." A three-column grid makes every feature shout at the same volume; a bento grid gives one feature the mic.

See AI SaaS Landing - ships a bento feature grid with custom visuals

Warm Dark Mode Is the New Dark Mode: 2026 SaaS Design Trends

TheKitBase — Fri, 10 Jul 2026 17:57:26 +0000

Look closely at the dark mode on the SaaS products that feel most premium right now and you'll notice something: none of them are actually black. The pure #000 background that defined the first wave of dark mode is quietly being replaced by warm dark - near-black backgrounds with a hint of temperature, grays that lean slightly warm, and accents chosen to glow against them rather than vibrate. It's a small shift with a big effect on how expensive a product feels. Here's what changed and how to build it.

Why pure black is a mistake

Pure #000 seems like the obvious choice for dark mode, and it's usually the wrong one. On OLED screens, black next to bright white text creates harsh contrast that causes halation - text appears to smear or glow for tired eyes. Pure black also flattens depth: with nothing darker to recede to, shadows and elevation stop working, so every surface looks like it's on the same plane. And it reads as cheap, because it's the default a framework gives you before anyone has made a design decision.

What "warm dark" actually means

Warm dark starts the background a few points above black and nudges the hue toward warmth instead of the default cool blue-gray. The surfaces layer up from there, so elevation reads. Text is off-white rather than pure white, which softens the contrast without losing legibility. The whole palette shares a subtle temperature, which is what makes it feel considered rather than generated.

/* Cool default dark (the framework default) */
--bg:      #000000;
--surface: #0a0a0a;
--text:    #ffffff;

/* Warm dark - near-black with temperature, off-white text */
@theme {
  --color-bg:      #0b0b0c;  /* not black - a hair of warmth */
  --color-surface: #151412;  /* layers up so elevation reads */
  --color-border:  #262320;  /* warm hairline, not cool gray */
  --color-ink:     #f7f3ea;  /* off-white, softer than #fff */
  --color-muted:   #a8a29a;  /* warm-leaning muted text */
}

Accents that glow instead of vibrate

On a warm near-black, saturated cool accents (electric blue, pure violet) tend to vibrate and feel harsh. Warm accents - amber, gold, coral, terracotta - sit naturally against the background and read as a glow rather than a clash. This is why so many premium 2026 dark themes have converged on warm accent colors: they're working with the background temperature, not against it. If you want a cool accent, desaturate it slightly and it'll settle down.

The other trends riding alongside it

Subtle film grain or noise texture over flat backgrounds, to kill banding and add analog warmth
Editorial typography - a characterful display face paired with a clean UI face, instead of one neutral sans everywhere
Tinted shadows - shadows that carry a hint of the accent hue rather than flat black
Flash-free theme switching as table stakes - a blocking inline script so there's no white flash on load
Restraint with the accent - one confident color used sparingly beats a rainbow of tints

The tell of a considered dark theme in 2026 is that the "black" isn't black and the grays aren't gray - everything shares a quiet temperature. It's the difference between a theme someone designed and a theme a framework defaulted to.

See Keel - "Gilt" warm dark theme, reskin from two CSS variables

Vibe Coding a Next.js SaaS in 2026: What Actually Works

TheKitBase — Fri, 10 Jul 2026 17:54:10 +0000

"Vibe coding" started as a half-joke - describe what you want, let the AI write it, keep the good vibes, ship. In 2026 it's a real workflow that real products are built with. It's also wildly oversold. The honest version is more useful than either the hype or the backlash: AI-assisted building is genuinely transformative for some parts of shipping a SaaS and actively dangerous for others. Here's where the line actually falls, from someone who builds Next.js products for a living.

What vibe coding is genuinely great at

For the first 80% of a UI, AI is astonishing. Describe a pricing page, a settings form, a dashboard layout, and you get a working, decent-looking first draft in seconds. It's a phenomenal accelerator for the parts of building that are pattern-heavy and low-stakes.

First-draft UI - layouts, forms, marketing sections, empty states
Boilerplate - types, mock data, repetitive CRUD, config
Unblocking - a rough version of something you're not sure how to start
Refactors with a clear shape - rename, extract, convert patterns across files
Learning - explaining an unfamiliar API in the context of your own code

Where it falls apart

The trouble starts exactly where software gets hard: the parts that require holding the whole system in your head. Vibe coding optimizes for something that looks done, and "looks done" and "is done" diverge fast in the places that matter most.

Architecture - AI will happily build the same logic five different ways across five files; coherence is on you
Auth and security - subtly wrong auth looks identical to correct auth until it's exploited
State and edge cases - the empty, loading, error, and race-condition states it quietly skips
Streaming and real-time UX - the "feels smooth" details are exactly what a quick prompt drops
Knowing what good looks like - AI gives you an answer; it can't tell you it's the wrong answer

The hybrid that actually ships

The teams shipping real products with AI aren't vibe coding from an empty folder. They're starting from a solid foundation - a real architecture, real patterns, tested core logic - and using AI to move fast within it. The foundation constrains the AI toward coherence; the AI accelerates the work the foundation left to you.

Start from a real structure, not a blank create-next-app - established patterns keep AI output coherent
Let AI draft components and content; you own architecture, data flow, and the security boundary
Keep the hard-won logic (auth, billing, streaming) tested, so AI edits can't silently break it
Review like it's a junior PR - fast, but never blind merge

Vibe coding isn't a replacement for knowing how to build - it's a multiplier on it. On a good foundation it's a rocket. From an empty folder with no taste to steer it, it's a fast way to build something that looks finished and falls over in production.

This is exactly why starting from a production-grade template pays off in the AI era rather than despite it: a real Next.js foundation - typed data, tested session and billing logic, a coherent design system - is the structure that makes AI-assisted building safe. You spend your prompts on your product, not on re-deriving auth and layout for the fifth time.

Browse TheKitBase templates - production-grade Next.js foundations