DEV Community: Nayan Kyada

Directus Pricing 2026: Self-Hosted Costs, Cloud Tiers & License Thresholds

Nayan Kyada — Fri, 14 Aug 2026 05:52:26 +0000

Directus pricing is more nuanced than the homepage makes it look. The software itself is MIT-licensed and free to download, but "free" collapses fast once you account for hosting, managed database, storage, and — if your company clears a revenue threshold — a required sponsorship. Here is what it actually costs in 2026 across both deployment paths.

What "free and open source" actually means for Directus

Directus is genuinely open source under the Business Source License (BSL) 1.1, which converts to MIT after four years. For most teams — startups, agencies, indie products — there are no royalties and no per-seat fees. You clone the repo, wire up a Postgres or MySQL database, and run it yourself. The code costs nothing.

The catch is that Directus is not a lightweight tool. At minimum you need:

A Node.js server (the Directus process itself, roughly 512 MB RAM at idle, 1 GB comfortable)
A managed relational database (Postgres is the practical default)
Object storage for assets (S3-compatible)
A reverse proxy or CDN in front

That infrastructure is not free, and it does not manage itself.

Self-hosted: realistic infrastructure costs

Assuming you deploy on a mid-tier cloud provider (Railway, Render, Fly.io, or a VPS like Hetzner or DigitalOcean):

Small project (one editor, low traffic, < 5 GB assets):

Directus on a 1 GB RAM instance: ~$7–12/month (Hetzner CX21, Fly.io shared, Render Starter)
Managed Postgres (Railway Hobby or Supabase free tier → Pro at $25/month): $0–25/month
S3 or Cloudflare R2 (< 10 GB stored): $0–2/month
Total: $7–39/month

Mid-size project (5–15 editors, media-heavy, production SLA needed):

Directus on 2–4 GB RAM instance: $20–50/month
Managed Postgres with daily backups: $25–50/month (Supabase Pro, Neon, or Railway Pro)
S3/R2 with egress at scale: $5–20/month
Monitoring (Uptime Robot, Better Uptime): $0–20/month
Total: $50–140/month

Larger project (multi-tenant, HA, separate read replica):

Directus with horizontal scaling or PM2 cluster: $80–200/month
Managed Postgres with replication: $100–300/month (PlanetScale, RDS, Neon Business)
CDN + egress: $20–100/month
DevOps time for upgrades, migrations, backups: hard to price, but real
Total: $200–600/month before devops labour

Upgrades deserve a mention. Directus ships breaking changes between minor versions more aggressively than most CMSs. Keeping a self-hosted instance current is a quarterly task, not a one-time setup.

Directus Cloud tiers (2026)

Directus Cloud is the managed SaaS path. Directus manages the infrastructure; you get a Studio URL and API endpoint. Pricing as of mid-2026:

Tier	Monthly price	Projects	Users	Asset storage	API requests
Starter	$15	1	5	5 GB	500 k/month
Standard	$99	3	25	50 GB	5 M/month
Professional	$299	10	Unlimited	200 GB	20 M/month
Enterprise	Custom	Unlimited	Unlimited	Unlimited	Unlimited

Starter at $15/month is genuinely useful for a solo developer or a small marketing site. The 500 k API request ceiling sounds generous until you factor in Next.js ISR hitting the API on every revalidation cycle — a busy site can breach it in days. Standard at $99/month is where most real product teams land.

Enterprise pricing is negotiated directly. Directus does not publish a floor publicly, but anecdotally expect a five-figure annual contract for dedicated infrastructure, SLA guarantees, and SSO.

The sponsorship threshold

This is the part that catches companies off guard. Directus's BSL license requires organisations generating more than $5 million USD in annual revenue to become a paying sponsor to use the self-hosted version in production. The sponsorship starts at $1,500/year (the "Silver" tier on GitHub Sponsors or the Directus website).

This is not enforcement via code — there is no license key check. It is a legal obligation in the BSL. For a $5M+ company, $1,500/year is trivial, but teams should account for it in procurement, especially if legal or finance review vendor contracts.

For sub-$5M companies: you owe nothing extra. For companies on the threshold evaluating Directus as part of a longer-term roadmap, the sponsorship should be in the budget from day one.

What Directus Cloud does not include

Custom domains on Starter: only on Standard and above
Private networking / VPC: Enterprise only
Audit logs: not available on Starter tier
Role-based access control at the field level: available across tiers, but complex RBAC configurations need hands-on setup time regardless
Email delivery: Directus Cloud includes transactional email for auth flows but not bulk or custom sending — that is your problem (SendGrid, Resend, etc.)

Self-hosted vs Cloud: which cost path makes sense

Cloud wins if your team does not have a dedicated DevOps resource, you want predictable pricing with no upgrade surprises, and your project fits inside Standard or Professional. At $99/month, Standard is cheaper than most mid-size self-hosted setups once you honestly price DevOps time.

Self-hosted wins if you need to keep all data on your own infrastructure (GDPR, HIPAA, internal policy), you are comfortable maintaining Node.js services and Postgres at the OS level, and you have an existing cloud bill that can absorb the extra workload cheaply — a Hetzner server at $12/month running Directus alongside other services, for example.

Agency freelancers running multiple small client sites sometimes do a single self-hosted instance with Directus's multi-project capabilities. The economics are good; the maintenance burden is real.

How Directus pricing compares to Sanity

If you are also evaluating Sanity, the comparison is not straightforward because Sanity is API-first with no self-hosting option at all. Sanity's free tier is more generous for small teams (three users, unlimited projects in the free plan), and the Growth plan at $15/seat/month scales differently from Directus Cloud's flat project pricing. I covered the full side-by-side — content model, API design, editor experience, and cost at scale — in the Sanity vs Directus for Next.js comparison post.

The short version: Directus is cheaper to run at scale if you self-host and have the ops capability. Sanity is cheaper to get started with for small teams and eliminates infrastructure responsibility entirely.

How I structure React Next.js patterns across every client project

Nayan Kyada — Thu, 13 Aug 2026 05:54:23 +0000

Every new Next.js project I start has the same skeleton. Not because I copy-paste a boilerplate, but because I've converged on a set of React Next.js patterns that solve the same class of problems every time — server-first rendering, predictable data flow, typed boundaries, and consistent error handling. This post documents those patterns so I can point clients and collaborators at something concrete.

Server components by default, client components by exception

The App Router made server components the default. I treat that as a firm rule, not a suggestion. Every file starts as a server component. It only gets the 'use client' directive if it needs browser APIs, event handlers, or client-side state.

The practical test I run before adding 'use client':

Does it need useState or useReducer? → client.
Does it need useEffect or a browser API (window, IntersectionObserver)? → client.
Does it need an event handler (onClick, onChange)? → client.
None of the above? → keep it on the server.

This matters for bundle size. A server component ships zero JavaScript to the browser. Keeping data-heavy list pages, markdown renderers, and layout wrappers as server components keeps the client bundle lean.

When I do need interactivity, I push the 'use client' boundary as far down the tree as possible — often to a small leaf component like a <LikeButton> or <MobileMenuToggle>, not the whole page.

Colocated data fetching, not a central data layer

I fetch data inside the server component that renders it. No global store, no prop-drilling query results from a layout down to a leaf. Each component owns its data.

// app/blog/[slug]/page.tsx
import { client } from '@/sanity/lib/client'
import { postBySlugQuery } from '@/sanity/lib/queries'
import type { PostBySlugQueryResult } from '@/sanity/types'

interface Props {
  params: Promise<{ slug: string }>
}

export default async function PostPage({ params }: Props) {
  const { slug } = await params
  const post: PostBySlugQueryResult | null = await client.fetch(
    postBySlugQuery,
    { slug },
    { next: { tags: [`post:${slug}`] } },
  )

  if (!post) notFound()

  return <PostBody post={post} />
}

Next.js deduplicates fetch calls with the same URL and options within a single render pass, so two sibling components fetching the same resource don't double-hit the API. For Sanity specifically I use tagged revalidation so deploys stay fast.

If a page needs data from multiple sources — say a post plus a related-posts sidebar — I fetch in parallel with Promise.all at the page level and pass results down as props. I don't waterfall fetches through nested components.

Typed API boundaries with Sanity TypeGen

Loose any types at the data boundary kill refactor confidence. I use Sanity TypeGen to generate TypeScript types from GROQ queries, then import those types at the fetch site.

The pattern I follow for every query module:

// sanity/lib/queries.ts
import { defineQuery } from 'groq'

export const postBySlugQuery = defineQuery(`
  *[_type == "post" && slug.current == $slug][0] {
    _id,
    title,
    publishedAt,
    "slug": slug.current,
    body,
    mainImage { asset->, hotspot, crop }
  }
`)

export const postListQuery = defineQuery(`
  *[_type == "post"] | order(publishedAt desc) [0...$limit] {
    _id,
    title,
    publishedAt,
    "slug": slug.current,
    "excerpt": pt::text(body)[0..120]
  }
`)

After running sanity typegen generate, I get PostBySlugQueryResult and PostListQueryResult in sanity/types.ts. Every component that touches post data uses those types. If a schema field gets renamed, TypeScript catches every broken usage before CI runs.

Route organisation that scales

I use Next.js route groups to separate concerns without adding URL segments:

app/
  (marketing)/
    page.tsx          # homepage
    about/page.tsx
    layout.tsx        # marketing header/footer
  (content)/
    blog/
      page.tsx        # list
      [slug]/page.tsx # detail
    layout.tsx        # content-specific layout (breadcrumbs, etc.)
  (app)/
    dashboard/
      page.tsx
    layout.tsx        # auth-gated layout
  layout.tsx          # root layout (fonts, providers)

Each group gets its own layout, so the marketing shell never leaks into the dashboard shell. Route groups also let me colocate related server actions and route handlers near the pages that use them rather than dumping everything into a top-level api/ folder.

For route handlers I keep them thin — parse input, call a service function, return a typed response. The logic lives in lib/, not in the handler itself.

Error and loading conventions

Every segment that does async work gets three files: page.tsx, loading.tsx, and error.tsx. Not optional — I add them at project creation.

loading.tsx renders a skeleton that matches the page's visual weight. I size skeleton blocks to match real content dimensions, which prevents CLS when the real content loads. For image-heavy pages the skeleton includes a placeholder div at the same aspect ratio as the image.

error.tsx must be a client component (it receives the error prop and a reset function). I keep it simple:

// app/blog/[slug]/error.tsx
'use client'

interface Props {
  error: Error & { digest?: string }
  reset: () => void
}

export default function PostError({ error, reset }: Props) {
  return (
    <div className="py-24 text-center">
      <p className="text-sm text-neutral-500">
        Something went wrong loading this post.
      </p>
      <button
        onClick={reset}
        className="mt-4 text-sm underline"
      >
        Try again
      </button>
      {process.env.NODE_ENV === 'development' && (
        <pre className="mt-4 text-xs text-red-500">{error.message}</pre>
      )}
    </div>
  )
}

I never leak error messages in production. The digest value is logged server-side by Next.js automatically, so I can correlate client errors with server logs without exposing stack traces.

Typed server actions for mutations

For forms and mutations I use server actions rather than route handlers so I stay in the RSC model. I wrap every action in a result type so the client component always has a typed response to work with:

// lib/actions/subscribe.ts
'use server'

import { z } from 'zod'

const schema = z.object({ email: z.string().email() })

export type ActionResult =
  | { ok: true }
  | { ok: false; error: string }

export async function subscribeAction(
  _prev: ActionResult | null,
  formData: FormData,
): Promise<ActionResult> {
  const parsed = schema.safeParse({ email: formData.get('email') })
  if (!parsed.success) {
    return { ok: false, error: 'Invalid email address.' }
  }
  // call SendGrid / your email service here
  return { ok: true }
}

The client component calls this with useActionState (React 19) and renders feedback based on the discriminated union. No try/catch in the component, no raw error strings.

What this skeleton buys on a real project

These patterns aren't clever. They're boring and consistent, which is exactly the point. When a new developer joins a project or I return to a codebase after three months, the file layout is predictable, the data flow is traceable from query definition to render, and TypeScript catches regressions at the type level before they reach QA. That consistency is worth more than any individual optimisation.

Hire a developer for your startup: scope by outcome, not hours

Nayan Kyada — Wed, 12 Aug 2026 05:51:56 +0000

When founders come to me asking how to hire a developer for a startup website or MVP, the first thing I tell them is this: the scope conversation matters more than the CV review. Most early-stage projects fail to ship not because the developer was bad, but because nobody agreed on what 'done' meant before the first invoice.

Define done before you talk to anyone

Hourly rate is a distraction at the MVP stage. What you need is an outcome definition — a short list of things that are true when the project is complete. Not features, outcomes.

Bad scope: "Build a landing page with a CMS."

Good scope: "Editors can publish a blog post without developer involvement. The contact form sends to our shared inbox. Lighthouse performance score is above 85. The site is live on our domain with SSL."

When you scope by outcome, you can get a fixed-price quote. When you scope by hours, you get an invoice that grows until someone runs out of patience or money.

Write your outcomes down in a short brief before you contact a single developer. Three to five bullet points is enough. If you can't write them down, you're not ready to hire — you need one more internal conversation first.

What each budget tier actually buys in 2026

Budget (USD)	What you get	What you don't get
Under $3,000	Template customisation, basic Webflow or WordPress build, minimal CMS setup	Custom architecture, performance tuning, API integrations
$3,000–$8,000	Custom Next.js marketing site with Sanity CMS, basic SEO, contact form, analytics wiring	Complex e-commerce, authentication, multi-locale, ongoing support
$8,000–$18,000	Full marketing site or lightweight product with headless CMS, solid Core Web Vitals, structured data, staging environment, handoff documentation	Enterprise integrations, design from scratch (budget assumes design exists or is bought separately)
$18,000–$40,000	Complete MVP with auth, payments, content management, performance monitoring, CI/CD pipeline	Scale-ready infrastructure (that comes later, once you have users)
$40,000+	Dedicated team time, iterative sprints, ongoing feature development	A guarantee the product will succeed — no one can sell you that

These are project rates, not hourly projections. A developer quoting you $120/hr with an open-ended timeline can easily land in a higher bucket than a flat-fee quote for the same outcome.

Freelancer vs agency at MVP stage

This question comes up in nearly every early conversation. The honest answer is that for most startups at MVP stage, a single experienced freelancer outperforms a small agency — not always, but often enough to be the default recommendation.

Here's why. A four-person agency charging $15,000 for your MVP will typically assign a junior developer to execute while a senior manages the account. A solo developer charging the same amount is the person who writes every line. At MVP scale, the surface area is small enough that one good person can hold all of it in their head. That matters for speed and consistency.

Where agencies make sense: when you genuinely need parallel workstreams (design, development, and copywriting happening simultaneously), when you need a named point of contact for board or investor reporting, or when your timeline is under six weeks and a single developer would be a bottleneck.

What to ask a freelancer: Can you show me a project you scoped, built, and handed off without a team? What does your handoff documentation look like? Who do I call if something breaks after launch?

What to ask an agency: Who specifically will write the code? What is their seniority level? Can I speak with them directly?

Common founder mistakes that burn runway

Hiring before the design exists. Developers cannot build efficiently against a Figma file that is still changing. Lock the design to at least mid-fidelity wireframes before development starts. Every revision mid-build costs two to four times what it would have cost in design.

Optimising for lowest hourly rate. A $40/hr developer who takes four months costs more than a $120/hr developer who takes six weeks. Do the arithmetic before you anchor on rate.

Skipping the staging environment. Launching straight to production without a staging URL where you can review and break things is a false economy. Any competent developer will insist on one. If they don't, that's a flag.

Not defining who owns the infrastructure. Before work starts, get written agreement on who holds the hosting account, the domain registrar login, the CMS project, and the repository. Founders who skip this step sometimes find they need the developer's cooperation just to change their own DNS settings.

Treating post-launch support as implied. Define it explicitly. 'I'll be around' is not a support agreement. A two-week post-launch support window at a fixed rate is reasonable to ask for in writing.

How to evaluate candidates quickly

You don't need a technical co-founder to vet a developer. You need three things:

A live URL of something they built. Not a mockup, a deployed site. Visit it on mobile. Check how fast it loads. Look at the page source. If the basics are sloppy in their portfolio work, they will be sloppy in yours.

A scope conversation, not a pitch. A good developer will ask you clarifying questions before quoting. If someone sends a price within twenty minutes of your first message without asking anything, they either have a template they're applying to every project or they're not thinking carefully about yours.

A clear handoff expectation. Ask: 'What do I receive at the end of the project?' You want to hear: a repository you own, credentials documented, a brief README or handoff doc, and a walkthrough call. If the answer is vague, the handoff will be vague.

One thing worth spending money on before hiring

If your budget is tight and you're uncertain whether you need a full build at all, spend $300–$500 on a two-hour scoping session with an experienced developer before committing to anything. Ask them to review your requirements and tell you the fastest path to a working MVP. The session pays for itself if it saves you one bad hire or one month of rework.

Freelance web developer for hire: what a good one actually delivers

Nayan Kyada — Tue, 11 Aug 2026 05:33:21 +0000

When you're looking for a freelance web developer for hire, the gap between a smooth engagement and a frustrating one usually comes down to process, not skill. Most developers who struggle with clients aren't bad at code — they're bad at setting expectations. This post lays out what a professional engagement looks like, so you know what to ask for and what to walk away from.

Communication cadence: how often you should actually hear from them

A solo freelancer won't — and shouldn't — be updating you every hour. But silence for more than two or three business days during active development is a red flag. Here's what a reasonable cadence looks like:

Project kick-off: A written summary of what's being built, in what order, and what decisions still need your input. This goes out within 24 hours of the project starting.
Weekly async update: A short message (Slack, email, whatever you agreed on) covering what was completed, what's in progress, and any blockers waiting on you. Not a meeting — a message.
Ad-hoc flags: If something discovered mid-build changes the scope or timeline, you hear about it immediately, not at the weekly update.
Response time: Messages during business hours get a reply within a few hours, not days.

If a developer tells you they'll "be in touch when there's something to show," that's not a communication plan — it's a way to disappear for two weeks and call it focused work.

Staging URLs: you should always have access

Every project, regardless of size, should have a staging URL you can visit. Not screenshots. Not a screen-share call where the developer controls what you see. A live URL you can open in your own browser, on your own device, and share with your team.

For a Next.js project on Vercel, this costs nothing — every push to a branch generates a preview URL automatically. There's no excuse for skipping this.

What a staging environment gives you:

A place to review work before it goes live
A real URL to send to stakeholders or investors without touching production
Confidence that the developer is building something real, not just promising it

If a developer asks you to wait until the project is "done" before they share anything, that's a process problem. Iterative review is how you avoid paying for something that misses the brief.

Fixed-price vs hourly: which to choose and when

Both models are legitimate. The right choice depends on how well-defined the project is.

Scenario	Better model	Why
Well-defined scope, agreed deliverables	Fixed-price	You know the cost upfront; developer has an incentive to finish efficiently
Evolving requirements, ongoing work	Hourly / retainer	Fair to both sides when the scope isn't locked
MVP with unknowns	Fixed-price for Phase 1, hourly after	Caps discovery cost while preserving flexibility
Integrations with third-party APIs	Hourly	API behavior is often unpredictable; fixed-price punishes the developer

Fixed-price doesn't mean no surprises — it means surprises are scoped separately. A good developer will write a change order for anything that wasn't in the original brief rather than silently absorbing it (and resenting you for it) or silently billing extra (and surprising you).

Red flag: a fixed-price quote with no written specification attached. Without a spec, "fixed price" is meaningless — there's no shared definition of done.

Handover: what you should receive when the project closes

A project isn't finished when it goes live. It's finished when you can operate it without the developer. That means handover is a deliverable, not an afterthought.

At minimum, expect:

Repository access: The code lives in your GitHub/GitLab account, not theirs. You should have been invited as owner from day one.
Environment variables documented: Every API key, secret, and configuration value listed in a private document (not in the repo), with a note on where each one is managed.
CMS editor walkthrough: If the project uses Sanity Studio or any other CMS, a recorded or written walkthrough of how editors use it — adding pages, publishing posts, updating images — so your team isn't dependent on the developer for routine content changes.
Deployment process: Where the project is hosted, how deploys are triggered, and who has access to the hosting dashboard.
Third-party service accounts: Domain registrar, email sending, analytics, CDN — you should own every account, not the freelancer.

If any of these are missing, the project isn't actually done. Handover gaps are one of the most common reasons clients get stuck after a freelancer engagement ends.

Warranty period: what's reasonable to expect

A warranty doesn't mean the developer is on-call forever. It means there's an agreed window after launch during which bugs found in the original scope are fixed at no additional charge.

Two weeks is the minimum. Thirty days is standard for a mid-size project. Ninety days is reasonable for a complex build with integrations.

What a warranty covers: functionality that was promised and doesn't work as specified.

What it doesn't cover: new feature requests, design changes, or bugs caused by third-party services changing their APIs.

Get this in writing before the project starts — not after something breaks.

The short version

A good freelance web developer runs a professional process regardless of project size. You get a staging URL early, regular written updates, a clear pricing model with a written spec attached, and a handover that leaves you in control. If a developer can't explain how they handle these things before you hire them, that's your answer.

Tailwind Next.js starter: create-next-app vs popular boilerplates

Nayan Kyada — Mon, 10 Aug 2026 05:53:11 +0000

Picking a tailwind Next.js starter sounds trivial until you're six months in and your chosen boilerplate hasn't touched its dependency tree since the Pages Router was current. This post compares the two main paths — create-next-app with manual Tailwind wiring versus grabbing a community starter — and gives you a concrete checklist for telling the difference between a starter that will serve you and one that will quietly rot.

What "aging well" actually means for a starter

A starter ages well when:

It tracks the Next.js App Router and drops Pages Router patterns as those patterns become legacy.
Its Tailwind config doesn't lock you to v3 conventions that don't translate to v4 (the @import "tailwindcss" directive, CSS-first config, the new @theme block).
Its dependency list is short and each dependency has an active maintainer.
It uses next/image with explicit width, height, or fill — not wrapped in a custom component that papers over CLS.
TypeScript is strict from day one, not added as an afterthought with @ts-ignore patches everywhere.

Those criteria filter out a lot of what you'll find on GitHub.

Option 1: create-next-app + manual Tailwind

This is what I use on client projects. The command:

# Creates App Router project, TypeScript, ESLint, src/ directory, no src/app/page default styles
npx create-next-app@latest my-site \
  --typescript \
  --eslint \
  --app \
  --src-dir \
  --no-import-alias

Then install Tailwind v4 the way the v4 docs say to, not the v3 PostCSS path:

npm install tailwindcss @tailwindcss/vite
# Or with the PostCSS plugin if you need it:
npm install tailwindcss @tailwindcss/postcss postcss

Add a single line to your src/app/globals.css:

/* src/app/globals.css */
@import "tailwindcss";

@theme {
  --font-sans: var(--font-geist-sans);
  --color-brand: oklch(55% 0.2 250);
}

No tailwind.config.ts. No PostCSS config file unless your project actually needs PostCSS plugins. That's it.

This path wins on longevity because:

create-next-app is the official scaffold — it will track App Router, Turbopack, and RSC conventions as they move.
You control every dependency. Nothing sneaks in that you don't know about.
When Tailwind v5 arrives you read the migration guide and update one package, not untangle a boilerplate author's opinions.

The cost is setup time. Budget 30–45 minutes to wire up fonts, a base layout, and next-sitemap or the App Router sitemap.ts convention. That's a one-time cost.

Option 2: community starters and boilerplates

The most-starred Tailwind Next.js starters on GitHub (as of mid-2026) include next-starter, taxonomy (shadcn's older reference app), and a long tail of personal-portfolio templates. Here's how they compare on the criteria that matter.

Criterion	create-next-app + manual	Actively maintained starter	Abandoned starter (>12 months stale)
App Router native	✓	Usually ✓	Often Pages Router
Tailwind v4 config	✓ (you set it)	Varies — check the config file	Typically v3, sometimes v2
TypeScript strict mode	✓	Varies	Rarely
Dependency count	~6 prod deps	15–40+	15–40+, often outdated
next/image correct usage	✓	Sometimes — check for CLS hacks	Often broken
Last commit	n/a	Check GitHub	Often 2023 or earlier
Ejectable	Trivially	Hard — opinions baked in	Hard

The taxonomy app is worth studying as a reference, but I would not scaffold new client work from it — it was built to demonstrate shadcn component patterns, not to be a generic starting point, and its dependency surface is wide.

If you want a community starter, the ones worth considering in 2026 are the ones where:

The repo has commits in the last 60 days.
package.json shows next at 15.x, tailwindcss at 4.x.
There is no tailwind.config.ts or tailwind.config.js at the root — the v4 config lives in CSS.
"strict": true is set in tsconfig.json.
The README acknowledges App Router, not just Pages Router patterns.

If any of those fail, move on. Boilerplate debt compounds faster than application debt because it's in your foundation.

The shadcn/ui question

Shadcn/ui is a component distribution, not a starter — it adds components into your source tree rather than installing a package. That distinction matters because you own the code. If you want Radix primitives styled with Tailwind, the right move is:

Scaffold with create-next-app as above.
Run npx shadcn@latest init to add the component scaffolding.
Add only the components you actually need.

Do not grab a "shadcn starter" repo that pre-installs all 40+ components. You will carry that weight even if you use three of them.

Red flags in any starter

A next.config.js that disables reactStrictMode — usually done to hide double-render bugs rather than fix them.
images.domains in next config instead of images.remotePatterns — deprecated in Next.js 14, removed behaviour in 15.
A custom <Image> wrapper that passes layout="fill" (v12-era API).
@apply used everywhere in CSS — fine in v3, still works in v4, but often signals the project was written before v4's utility-in-CSS approach was available.
A postinstall script that patches node_modules directly.
Any dependency pinned with "next": "13.x" or similar hard ceiling.

Practical recommendation

For a production Next.js project that needs to last 18–24 months without a painful migration:

Use create-next-app with the flags above.
Wire Tailwind v4 manually — it's four lines.
If you need UI components, add shadcn selectively via its CLI, not a pre-bundled starter.
Commit a package.json engines field locking to Node 22.x so your CI and your client's server stay in sync.

Community starters have their place — especially for portfolio sites where setup speed matters and longevity less so. But for anything where a client will be maintaining or extending the codebase in 12 months, the manual path is the only one I'd hand off with confidence.

API CMS explained: what it's good at and where it breaks down

Nayan Kyada — Sun, 09 Aug 2026 05:29:08 +0000

An API CMS — sometimes called an API-first or headless CMS — decouples content storage from content presentation. Instead of generating HTML server-side like WordPress does, it exposes your content through an HTTP or GraphQL API, and every consuming application — your Next.js site, your mobile app, your digital signage, your email renderer — fetches exactly what it needs. That flexibility is the whole pitch. Whether it pays off depends heavily on what your team actually builds.

What an API CMS is genuinely good at

Omnichannel content delivery

The strongest case for an API CMS is when the same content genuinely needs to appear in more than one place. A product description that lives in Sanity can feed your Next.js marketing site, your React Native app, your Shopify storefront, and a third-party partner API — all from one source of truth, all pulling from the same GROQ or REST endpoint.

With a traditional CMS, you'd be copying content between systems or building fragile sync jobs. With an API-first system, the content model is the integration point. Schema changes propagate to every consumer automatically, because they're all reading from the same API.

This isn't hypothetical. I've worked on projects where the same product document type in Sanity serves a Next.js e-commerce front end and a weekly email digest rendered by a Node.js script hitting the same Content Lake. The editorial team edits once. The field description shows up correctly in both places without any manual export.

Developer control over the data layer

A traditional CMS like WordPress gives you pre-shaped data — a post has a title, body, excerpt, and featured image. If you want something different, you're writing PHP plugins or fighting the REST API.

An API CMS gives you a blank schema. You define exactly what a caseStudy or landingPage document contains, what types are allowed in a Portable Text field, what references are valid. In Sanity, that schema lives as TypeScript:

// sanity/schemas/caseStudy.ts
import { defineType, defineField } from 'sanity'

export const caseStudy = defineType({
  name: 'caseStudy',
  title: 'Case study',
  type: 'document',
  fields: [
    defineField({ name: 'client', type: 'string', validation: r => r.required() }),
    defineField({ name: 'industry', type: 'string' }),
    defineField({ name: 'outcomes', type: 'array', of: [{ type: 'block' }] }),
    defineField({
      name: 'relatedPosts',
      type: 'array',
      of: [{ type: 'reference', to: [{ type: 'post' }] }],
    }),
  ],
})

You own the data model. The CMS stores and serves it. That's a meaningful shift in control compared to fighting a plugin ecosystem.

Performance through selective fetching

Because you write your own queries, you fetch only what the page needs. A GROQ query for a blog listing page grabs slugs, titles, and cover image metadata — nothing else. The payload is small, the response is fast, and Next.js can cache it at the edge.

With a traditional CMS, you often get the whole document whether you want it or not, and either strip it client-side (wasteful) or write a custom endpoint (which is just reinventing API-first architecture anyway).

Where an API CMS falls short

Editor experience is an afterthought

This is the honest part most developer blog posts skip. API-first CMSs are designed by developers for developers. The editing interface — Sanity Studio, Contentful's web app, whatever Strapi ships — is functional, but it's not polished for non-technical editors.

WordPress has fifteen years of UX iteration aimed at writers and marketing teams. Sanity Studio is excellent by headless standards, but an editor coming from WordPress or Squarespace will still face a learning curve. If your client's content team is five non-technical marketers who publish daily, that friction is real and it lands on your project budget as training time and support tickets.

The risk isn't that the CMS can't do it — it's that no one budgets for the onboarding properly.

Preview is genuinely complex

In a traditional CMS, preview is built in. Click "Preview" and you see the page with draft content. In a headless setup, preview requires explicit engineering: a draft mode endpoint in Next.js, a secret token, a Sanity Presentation tool configuration, and a way to pass that context through your entire rendering tree.

// app/api/draft/route.ts
import { draftMode } from 'next/headers'
import { redirect } from 'next/navigation'

export async function GET(req: Request) {
  const { searchParams } = new URL(req.url)
  const secret = searchParams.get('secret')
  const slug = searchParams.get('slug')

  if (secret !== process.env.SANITY_PREVIEW_SECRET) {
    return new Response('Invalid token', { status: 401 })
  }

  draftMode().enable()
  redirect(slug ?? '/')
}

That's the minimal version. Add Sanity's Presentation overlay, overlay components for visual editing, and CORS configuration for the studio domain, and you've got a non-trivial amount of infrastructure just so an editor can see their changes before publishing. It works — I use it on production projects — but it's engineering effort that traditional CMS users get for free.

Glue code accumulates fast

An API CMS solves content storage and delivery. Everything else — sitemap generation, redirect management, form handling, search indexing, email notifications on publish, image transformation pipelines — is your responsibility. You wire it up.

Sanity doesn't email your team when a post is published. You build a webhook handler and call SendGrid. Sanity doesn't update your Algolia index. You write the sync logic. Sanity doesn't generate a sitemap. You write the Next.js route handler.

None of this is hard, but every piece is custom code you now own and maintain. Projects that start with "we just need a blog" end up with 800 lines of infrastructure across webhooks, revalidation handlers, preview routes, and sitemap generators. That's fine if you've budgeted for it. It's a nasty surprise if you assumed the CMS handled it.

Cost scales with API calls, not seat count

Most API-first CMSs price on API requests, bandwidth, or document count — not on how many editors use the system. That's great for small teams. At scale, the math shifts. A site doing millions of page views with aggressive revalidation can hit CDN bandwidth limits or API rate limits on plans that seemed generous at the start.

Sanity's Growth plan includes 500k API CDN requests per month. At 10 requests per page build and aggressive ISR revalidation, that ceiling is reachable on a moderately trafficked site without careful query batching and edge caching in front of the API.

When an API CMS is the right call

Choose an API-first CMS when: you're building for more than one channel; your content model is genuinely custom; you have at least one developer who owns the integration long-term; and your editors are comfortable learning a new tool with proper onboarding.

Avoid it when: the site is a simple brochure with a non-technical owner who will maintain it themselves; your budget doesn't include the glue code engineering hours; or preview and draft workflow are dealbreakers that need to work on day one without custom work.

The API CMS model gives developers real leverage over the content layer. The cost is that you're building the rest of the system yourself — and that cost is real, recurring, and worth naming before you start.

Next.js as a backend: honest limits for production apps

Nayan Kyada — Sat, 08 Aug 2026 05:14:07 +0000

The Next.js backend question comes up on almost every project scoping call I take. A founder wants to ship fast, they already have Next.js on the frontend, and the natural question is: can we just use route handlers for the API too? The honest answer is yes, often — but with specific limits that will bite you if you ignore them.

What the Next.js backend actually gives you

Route handlers (app/api/*/route.ts) are proper HTTP endpoints. They run on Node.js or the Edge runtime, support all HTTP methods, can read cookies and headers, and stream responses. Server Actions give you a direct RPC-style bridge from client components to server code without writing an endpoint at all. For a large category of product work — form submissions, authenticated CRUD, sending emails via SendGrid, triggering Sanity mutations, webhook ingestion — this is genuinely sufficient.

I have production apps where the entire "backend" is a dozen route handlers and a handful of server actions. No Express server, no separate deployment, no ops overhead. It works.

// app/api/contact/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { sendEmail } from '@/lib/sendgrid';

export async function POST(req: NextRequest) {
  const body = await req.json();
  // basic validation omitted for brevity
  await sendEmail({ to: process.env.CONTACT_EMAIL!, ...body });
  return NextResponse.json({ ok: true });
}

That's a real contact endpoint. Deployed to Vercel, zero extra infrastructure, cold starts are under 300ms in practice.

Where it genuinely holds up

Authenticated REST-style APIs for your own frontend. If the only consumer of your API is your Next.js frontend, route handlers are a perfect fit. You share types directly, you can use server actions instead of fetch calls, and you don't need to design a public API contract.

Lightweight webhook receivers. Stripe webhooks, Sanity webhooks, GitHub Actions callbacks — these are short-lived, low-concurrency endpoints. Route handlers handle them fine.

Server Actions for mutations. For forms, optimistic UI, and simple write paths, server actions remove a layer of indirection. The mental model is simpler and TypeScript inference works end-to-end.

Edge middleware for auth guards. Running token validation at the edge in middleware.ts before any page or API handler runs is genuinely useful and hard to replicate cheaply outside of Next.js.

The real limits — where it starts to break

Background jobs and queues. Vercel functions time out. The default is 10 seconds on Hobby, 60 seconds on Pro, 800 seconds on Enterprise. If you need to process a video, crunch a large dataset, or run a job that should survive a deploy, a route handler is the wrong tool. You need a proper queue — BullMQ on a VPS, Inngest, Trigger.dev — with Next.js acting only as the enqueue point.

Long-lived connections. WebSockets are not natively supported in Vercel's serverless model. You can use streaming responses for one-directional pushes, but anything requiring a persistent bidirectional channel needs a separate service — Ably, Pusher, Soketi, or a dedicated Node server.

Third-party API consumers. The moment a mobile app, a partner integration, or a separate service needs to call your API, you need versioning, stable contracts, proper auth (JWT issuance, OAuth), and documentation. Route handlers can technically serve this, but you're now fighting against Next.js's opinionated file structure rather than working with it. At that point, a standalone Fastify or Hono service is cleaner.

Heavy compute. CPU-bound tasks — image processing, PDF generation, ML inference — should not live inside a serverless function you're paying per-invocation for, especially when they might time out mid-work. Offload these to a dedicated worker.

Database connection pooling at scale. Every invocation of a serverless route handler can open a new database connection. With PostgreSQL this will exhaust your connection limit under real traffic unless you're using PgBouncer or Neon's HTTP driver. This isn't unique to Next.js, but it's a sharper problem here than on a traditional server that holds a single connection pool.

// This pattern will exhaust Postgres connections at scale on serverless
// Use @neondatabase/serverless or a connection pooler instead
import { Pool } from 'pg'; // ❌ new Pool() per cold start = connection leak

// Better:
import { neon } from '@neondatabase/serverless'; // ✅ HTTP-based, no persistent conn
const sql = neon(process.env.DATABASE_URL!);

The pattern I actually use

For most marketing + product sites I build, Next.js handles 90% of the backend surface: content mutations via Sanity, auth via NextAuth, transactional emails, simple CRUD. That covers a founder's MVP and often the first 18 months of a real product.

When the project needs background processing or a public API, I introduce a second service — usually a lightweight Hono app deployed to a $6/month VPS or a Fly.io instance — and keep Next.js as the user-facing layer. The two services share a TypeScript types package if they're in the same monorepo. This boundary keeps Next.js doing what it's good at and removes the pressure to hack around serverless constraints.

The anti-pattern I see most often is teams discovering these limits after going to production and then spending two weeks retrofitting a queue system into a codebase that wasn't designed for it. Identifying the constraints early — specifically: do we need background jobs, do we need WebSockets, do we need a public API — takes 20 minutes in a scoping call and saves weeks later.

The verdict

Next.js is a capable backend for a well-defined category of work. It is not a general-purpose application server. Treat it like one and you'll hit a wall. Know the wall before you start building, and it'll serve you well for a long time.

Webflow vs Next.js cost in 2026: where the curve crosses

Nayan Kyada — Fri, 07 Aug 2026 05:55:57 +0000

The Webflow vs Next.js cost question comes up every time a founder is weighing a fast launch against long-term flexibility. The honest answer is that Webflow is genuinely cheaper for the first twelve months on a simple marketing site — but the curve crosses sooner than most Webflow advocates admit, and it crosses hard once you add seats, a CMS, or a developer who needs to extend anything.

This post breaks down real platform costs, developer time, and the hidden line items that don't show up in a pricing page screenshot.

What you actually pay for on each side

Webflow bundles hosting, CDN, CMS, and visual editor into one monthly bill. That's the genuine advantage. You're not juggling Vercel + Sanity + a developer's hourly rate to keep the lights on. For a one-person marketing team publishing blog posts, it's a reasonable call.

Next.js + CMS (I'll use Sanity as the CMS baseline here because it's what I build on and its free tier is the most generous in its class) splits costs into three buckets: hosting, CMS, and developer time. Hosting on Vercel Hobby is free for non-commercial projects; Pro is $20/month per member. Sanity is free up to 2 users and 10k API requests/day. Those numbers stay at zero longer than most people expect for a new site.

The catch is that someone has to wire these together, and that person costs money.

The cost table

Scenario	Webflow (annual)	Next.js + Sanity + Vercel (annual)
Solo founder, static marketing site, no blog	$23/mo Basic = $276	Vercel Hobby $0 + Sanity Free $0 + ~8 hr setup @ $80/hr = $640
5-page site + blog, 1 editor	$39/mo CMS = $468	Vercel Pro $20/mo + Sanity Free $0 + ~20 hr build = $1,840
5-page site + blog, 3 editors	$39/mo CMS + 2 extra seats @ $9/mo = $684	Vercel Pro $20/mo + Sanity Free (3 users covered) + ~20 hr build = $1,840
10-page site + blog, 5 editors, custom forms	$74/mo Business = $888	Vercel Pro $20/mo + Sanity Growth $15/mo + ~40 hr build = $3,380
E-commerce or app logic, 5 editors	Webflow Commerce from $74/mo + 2% txn fee = $888 + fees	Vercel Pro $20/mo + Sanity Growth $15/mo + ~80 hr custom dev = $6,620
Ongoing editorial + design changes, in-house dev	$74/mo Business + dev time at Webflow API limits = $888 + friction	Vercel Pro $20/mo + Sanity Growth $15/mo + dev owns codebase = $420 recurring

Developer rate used: $80/hour (mid-market freelancer in Western markets; adjust for your situation). Build hours are one-time, not annual, but I've included them here because they're the dominant cost in year one.

Where Webflow genuinely wins

No developer on staff, simple site. If you're a founder who can use the Webflow designer yourself, rows 1 and 2 in that table are clear wins for Webflow. You pay $276–$468/year and you're live. A Next.js project requires someone to build it, and even a lean build from a competent freelancer will run $1,500–$2,500 for something production-ready.

Speed to first publish. Webflow's editor is polished. A non-technical marketer can publish a landing page without filing a ticket. The equivalent in a custom Next.js stack — Sanity Studio plus a deployment pipeline — takes a few hours to configure and a couple of hours to train someone on.

Predictable monthly bill. One invoice, one vendor. For a solo operator managing ten other tools, that simplicity has real value.

Where the curve crosses

Seats. Webflow charges $9/month per extra editor above the base plan's allowance. Sanity's free tier covers 3 non-admin users; its Growth plan ($15/month) covers up to 10. At 4–5 editors the per-seat cost on Webflow starts compounding noticeably.

Custom logic. Webflow's CMS is a fixed schema. The moment you need a content type that doesn't map to its built-in fields — a product comparison table, a localized page, a structured job listing with computed fields — you're either fighting the tool or paying for a workaround. Next.js + Sanity lets a developer define exactly the schema the content team needs.

Codebase ownership. Webflow exports HTML/CSS that isn't particularly maintainable. If you ever want a developer to build on top of what you have, they're starting close to scratch anyway. A Next.js repository is a real codebase: version controlled, testable, deployable to any Node host.

Performance ceiling. Webflow generates reasonable Core Web Vitals scores for simple pages. Add a complex homepage with animations, multiple third-party scripts, and a rich blog archive, and you lose fine-grained control. With Next.js you control every byte: streaming SSR, ISR cache headers, image formats, bundle splitting.

Long-term recurring cost. Once a Next.js site is built and live, the recurring bill for a small-to-medium site is $20–$35/month (Vercel Pro + Sanity Growth). Webflow Business runs $74/month. That's a $40–$50/month gap that compounds significantly over a 3–5 year product lifespan.

The real question for founders

It's not "which is cheaper" in the abstract — it's when do you expect to have a developer involved on a recurring basis.

If the answer is never, Webflow is the right call for a straightforward marketing site. You'll pay more over three years but you'll avoid developer coordination overhead entirely.

If the answer is occasionally or soon, the math shifts quickly. A developer working in a Next.js + Sanity codebase can move fast and own the full stack. The same developer working inside Webflow's constraints will spend a disproportionate amount of time on workarounds — and you'll still be paying Webflow's platform fee on top.

The inflection point in practice: once you have more than 3 editors, need any custom content modeling, or expect more than 10–15 developer-hours per year of ongoing work, Next.js + a headless CMS becomes cheaper on a total-cost basis within 18–24 months of launch.

What a web CMS actually owes you: my baseline standard

Nayan Kyada — Thu, 06 Aug 2026 07:11:37 +0000

A web CMS is not a database wrapper with a nice UI. It is the operational centre of a content team and the API contract a developer builds against for years. Most platforms fail on at least one of those two jobs. Here is the standard I have arrived at after shipping enough of these projects to know what breaks down in production.

The draft and preview contract is non-negotiable

Every web CMS I recommend must support a first-class draft state that is completely isolated from published content. Not a "preview" flag on the same document. An actual separate document state that can be routed through a secure preview URL without leaking into public API responses.

The failure mode I see most often: a CMS that returns drafts in the default query unless you explicitly filter them out. That is backwards. Drafts should require opt-in access — a token, a cookie, an edge flag — not opt-out filtering that a tired developer forgets on a deadline.

On the Next.js side this pairs with Route Handlers and the draft mode cookie. On the CMS side it requires perspective-aware content delivery: the same GROQ query (or REST call) should return published data by default and draft data only when a valid secret is present. If a platform cannot do that cleanly, editors will break live pages while saving, and that ends trust in the system fast.

Structured content, not rich text blobs

A web CMS that stores page content as a single HTML or Markdown string is a publishing tool, not a content system. Structured content means each piece of content is a typed document with discrete fields: a string title, a reference to an author document, an array of typed block content, an image with crop and hotspot metadata stored separately from the URL.

Why does this matter? Because structured content is queryable, transformable, and renderable in multiple contexts without scraping HTML. You can build a table-of-contents from block headings without parsing HTML. You can serve a plain-text summary to a search index without stripping tags. You can push content to a mobile app, an email template, and a web page from the same source without maintaining three copies.

Rich text blocks are fine inside a structured document — Portable Text handles this well — but the document itself must be structured. If the CMS treats every page as a freeform WYSIWYG canvas with no schema enforcement, you end up querying a blob and the developer API surface is effectively zero.

Roles and permissions that map to real teams

A basic author/admin split is not enough. Real teams have at least three operational roles: someone who writes drafts and can never publish without review, someone who reviews and publishes but cannot touch schema or studio configuration, and a developer-admin who controls everything.

Beyond role-based access, a mature web CMS needs document-level permissions. A regional marketing team should not be able to edit the global homepage even if they are editors. A contractor should be able to write in one document type and read-only everything else.

The failure mode here is usually a CMS that has roles but no path rules or document-type filtering. Everyone with the "editor" role can edit every document, and when that causes an incident — and it will — the only fix is a custom middleware layer that the developer has to maintain forever.

Versioning that editors can actually use

Version history should be a first-class CMS feature, not an afterthought or an enterprise add-on. Editors need to see who changed a document, when, and what changed. They need to restore a previous version without filing a ticket.

The bar I hold CMS platforms to: every published change creates a named, browsable history entry. Restoring does not require developer access. Diff views show field-level changes, not a JSON dump.

This is one area where many headless platforms still lag behind WordPress. The irony is that WordPress's revision history is one of the reasons content teams resist migrating even when the technical case for headless is clear. If a modern web CMS cannot match a 2004-era feature, that is a real objection, not a comfort-zone complaint.

The developer API surface must be typed and predictable

A CMS that requires runtime JSON parsing with no type information is a liability in a TypeScript codebase. The developer API surface I consider baseline in 2026:

Schema definitions in code (not only a GUI), ideally colocated with the codebase so schema and query types travel together
Generated TypeScript types from the schema so query results are typed at the call site
A query language that is expressive enough to shape the response — projections, joins, conditionals — so the client receives only what it needs rather than fetching whole documents and discarding 80% of the fields

// groq/post.ts — generated type from Sanity TypeGen
import { defineQuery } from 'next-sanity'
import type { POST_QUERY_RESULT } from '@/sanity.types'

export const POST_QUERY = defineQuery(`
  *[_type == "post" && slug.current == $slug][0] {
    title,
    publishedAt,
    "author": author->{ name, image },
    body
  }
`)

// In your RSC:
// const post: POST_QUERY_RESULT = await client.fetch(POST_QUERY, { slug })
// post.author.name is typed — no casting, no any

If the CMS requires REST with no type generation path, that is workable. If it requires GraphQL with a code-gen step, that is workable. If it requires hand-written interfaces that drift from the actual schema because nothing enforces the contract, that is a maintenance debt that compounds.

What a weak web CMS looks like in practice

The tell is usually the handoff. A CMS that fails the standards above produces the same handoff problems every time: editors asking why their draft showed up on the live site, developers maintaining a spreadsheet of "fields that don't exist in the API yet", permission incidents where a contractor deleted a document they should never have touched, and a content type explosion because nobody modelled the schema — they just kept adding pages.

The right platform enforces discipline through its architecture. Draft isolation, schema-first content, RBAC, versioning, and typed queries are not nice-to-haves. They are the conditions under which a content team can move at speed without breaking production. A web CMS that does not provide all five is asking the developer to build the missing pieces as custom middleware, and that cost never shows up in the vendor's pricing page.

Hire a Next.js developer who can actually ship production

Nayan Kyada — Wed, 05 Aug 2026 07:09:23 +0000

When you hire a Next.js developer, the risk isn't finding someone who claims the skill — it's hiring someone who has only run create-next-app and watched a YouTube tutorial. This guide gives you concrete signals to separate developers who can ship and maintain a production Next.js site from those who cannot.

What a credible portfolio actually looks like

A live URL is the minimum bar, not proof of quality. Ask for three live sites and verify each one yourself before the first call.

Run PageSpeed Insights on each URL. Open pagespeed.web.dev and paste the homepage. You want LCP under 2.5 seconds, CLS under 0.1, and INP under 200 ms on mobile. A developer who genuinely owns the performance of a site will know those numbers without looking. If the sites score in the 40s on mobile, that tells you they shipped something but did not own the outcome.

Check whether the site actually uses the App Router. Open DevTools → Network, hard-refresh, and look at the response headers. An App Router site on Vercel will have x-nextjs-cache headers and typically content-type: text/html for RSC payloads on navigation. Alternatively, just ask: "What version of Next.js is this on, and is it Pages Router or App Router?" A developer who built it will answer immediately.

Look for evidence of CMS integration, not just static sites. A portfolio of five identical blog starters proves nothing. You want at least one site that connects to a real data source — Sanity, Contentful, Payload, a custom API — and shows that they have thought about revalidation strategy (ISR tags, on-demand revalidation, or PPR).

Ask about the worst production bug they fixed. The answer reveals operational maturity. "We had a stale cache after a Sanity publish and had to add tag-based revalidation" is a better signal than "I've never had a bug in production."

App Router literacy check

The Pages Router still works, but any developer you hire in 2026 for a new project should be fluent in the App Router. These questions take under five minutes and filter hard.

"When does a Server Component re-render?" The correct answer: it doesn't re-render on the client at all — it fetches fresh HTML/RSC payload on navigation or after a revalidation event. Someone who says "when the state changes" is thinking in Pages Router terms.

"Where would you put a session cookie read — a Server Component or a Client Component?" Server Component, using cookies() from next/headers. If they reach for useEffect and a client-side fetch, that's a Pages Router reflex.

"What is the difference between revalidatePath and revalidateTag?" revalidatePath purges a specific URL from the cache. revalidateTag purges all cached fetches that were tagged with a given string — more granular and more useful for CMS webhook revalidation. A developer who has wired up a real CMS will know this distinction.

"How would you handle a component that needs both static generation and user-specific data?" The right answer in 2026 is Partial Prerendering: wrap the static shell in a normal async Server Component, put the personalised part behind a <Suspense> boundary, and let Next.js stream it from the edge. Alternatively, route-level SSR with export const dynamic = 'force-dynamic' for simpler cases. If they cannot articulate any of this, they have not shipped PPR or streaming SSR in a real project.

Performance red flags to watch for

These show up in code review or in a short technical conversation.

Fetching data inside Client Components with useEffect when a Server Component would do. This pushes network waterfalls onto the browser and increases LCP.
No sizes prop on next/image. Every <Image> without a sizes attribute defaults to 100vw, forcing the browser to download a full-width image for a card that is 300 px wide. CLS spikes follow.
loading="eager" on every image. This is usually a developer who "fixed" LCP on the hero by removing loading="lazy" globally.
No bundle analysis. Ask: "How big is your largest JS chunk and what is in it?" If they have never run @next/bundle-analyzer on a client project, they are shipping blind.
Route handlers used where Server Actions would be simpler. Not a hard rule, but it signals they are pattern-matching from Pages Router API routes rather than thinking in RSC architecture.

Rate benchmarks for 2026

Rates vary by region, experience tier, and engagement type. These are honest benchmarks from what I see in the market.

Profile	Freelance day rate (USD)	Monthly retainer
Junior (1–2 years, Pages Router era)	$200–$350	$2,500–$4,000
Mid (2–4 years, App Router production exp.)	$400–$600	$5,000–$8,000
Senior (4+ years, performance + CMS depth)	$650–$1,000	$9,000–$14,000
Agency team (design + dev + PM)	—	$12,000–$30,000

India-based freelancers typically run 40–60% of the above. That gap is real and the quality range is also wide — the vetting process in this post matters more at that price point, not less, because there are more candidates.

If someone quotes significantly below the junior band and claims senior-level output, ask for a paid two-hour technical task before committing to a project engagement. A small paid test is normal, protects both sides, and tells you more than any interview.

What to send them before the first call

Send a one-paragraph brief: what the site does, rough page count, CMS preference if any, and whether you have an existing codebase or are starting fresh. Then ask them to respond with: their relevant past project (one sentence each), their preferred rendering strategy for this use case and why, and their availability.

The quality of that response — not whether they use the right buzzwords, but whether they ask a clarifying question about your data model or traffic patterns — is the best pre-screening signal you have. Developers who have shipped real projects ask questions. Developers who are guessing give you a generic pitch.

Node.js CMS in 2026: Payload, Strapi, Directus, Keystone, and Sanity compared

Nayan Kyada — Tue, 04 Aug 2026 07:07:43 +0000

If you're building a custom website on Node.js and need a CMS to match, five names keep coming up: Payload, Strapi, Directus, Keystone, and Sanity. They're all JavaScript-native, all TypeScript-friendly, and all capable of feeding a Next.js frontend — but they make very different bets on where complexity lives and who pays for it.

What "Node.js CMS" actually means here

I'm using the term loosely to mean: a CMS whose core runtime is Node.js, whose config or schema is written in JS/TS, and which a JavaScript developer can extend without leaving the language. That rules out Contentful, Storyblok, and Hygraph (all closed-source SaaS platforms with no meaningful Node.js extension layer). It includes Sanity even though the content lake is hosted — the Studio, the schema, the GROQ client, and the document actions are all TypeScript running in Node.

The five options at a glance

	Payload	Strapi	Directus	Keystone	Sanity
License	MIT	SEE / Community	BSL 1.1	MIT	Proprietary
Self-host option	Yes (required on free)	Yes	Yes	Yes	No
Managed cloud	Payload Cloud ($25+/mo)	Strapi Cloud ($29+/mo)	Directus Cloud ($15+/mo)	No official cloud	Sanity Cloud (free tier)
Schema language	TypeScript config	JS/TS files or GUI	Admin GUI + YAML/JSON	TypeScript config	TypeScript config
DB layer	Postgres / MongoDB / SQLite	Postgres / MySQL / SQLite	Postgres / MySQL / SQLite / Mongo	Postgres / SQLite	Managed (proprietary)
REST + GraphQL	Both	Both	REST only (GraphQL plugin)	GraphQL only	GROQ + REST
Real-time / live preview	Via Next.js draft mode	Via Strapi preview	Via Directus Realtime	Limited	Sanity Presentation
Image handling	Basic transforms	Cloudinary/custom plugin	Built-in transforms	None	Sanity CDN + hotspot
TypeScript depth	Deep (schema → types)	Shallow	Shallow	Deep (schema → types)	Deep (TypeGen)
Rough infra cost (small project)	$0 self-host + VPS ~$12/mo	$0 self-host + VPS ~$12/mo	$0 self-host + VPS ~$12/mo	$0 self-host + VPS ~$12/mo	$0 (free tier)

Payload CMS

Payload v3 is my current default recommendation for teams that want full ownership and are comfortable writing schema as TypeScript. The config file is pure TS, collections generate types automatically, and the v3 integration with Next.js App Router means you can run the CMS and the frontend in the same Next.js project — no separate server.

The trade-off is operational. You own the database, the backups, the upgrades. On a $12/mo VPS that's fine for a small marketing site. For a high-availability production app you need managed Postgres, proper backups, and monitoring — suddenly "free" costs real engineering time. Payload Cloud starts at $25/mo and handles that for you, but it's still early and doesn't have the track record of a fully managed SaaS.

// payload.config.ts — minimal collection with typed fields
import { buildConfig } from 'payload/config'
import { postgresAdapter } from '@payloadcms/db-postgres'

export default buildConfig({
  db: postgresAdapter({
    pool: { connectionString: process.env.DATABASE_URL },
  }),
  collections: [
    {
      slug: 'posts',
      fields: [
        { name: 'title', type: 'text', required: true },
        { name: 'body',  type: 'richText' },
        { name: 'publishedAt', type: 'date' },
      ],
    },
  ],
})

Strapi

Strapi is the most widely deployed Node.js CMS by install count. The GUI-based content type builder lowers the entry bar for non-developers, which is genuinely useful when a client needs to add a field without filing a ticket.

The problems I've hit in production: the TypeScript support is bolted on rather than intrinsic (types are generated, not inferred from config), the plugin ecosystem is fragile across major versions, and the BSL-adjacent licensing on Strapi v5's enterprise features can catch teams off guard. For a Next.js project where a developer controls the schema anyway, I don't reach for Strapi first — the GUI builder buys nothing and the type safety gap is annoying.

Directus

Directus takes a different angle: it wraps an existing database and generates a REST API and admin UI from the schema rather than owning the schema itself. That's genuinely powerful for teams migrating an existing Postgres database or building data-heavy internal tools. The Flows feature (visual automation) is also surprisingly capable.

For a greenfield content website it's overkill. The BSL 1.1 license also means you can't offer Directus as a managed service to clients without a commercial agreement. Worth knowing before you propose it.

Keystone

Keystone is the underdog here and it deserves more attention in TypeScript-first teams. The schema is pure TypeScript with deep GraphQL integration — you define a list, Keystone generates the GraphQL schema, the Admin UI, and the TypeScript types in one step. It's maintained by Thinkmill and has been production-stable for years.

The gaps: no official managed cloud, image handling is DIY, and the community is small compared to Strapi or Payload. I'd reach for Keystone on an internal tool or a project where GraphQL is a hard requirement and the team is comfortable managing their own infra.

// keystone.ts — Post list with auto-generated types and GraphQL
import { config, list } from '@keystone-6/core'
import { text, timestamp, select } from '@keystone-6/core/fields'

export default config({
  db: { provider: 'postgresql', url: process.env.DATABASE_URL! },
  lists: {
    Post: list({
      fields: {
        title: text({ validation: { isRequired: true } }),
        status: select({ options: ['draft', 'published'], defaultValue: 'draft' }),
        publishedAt: timestamp(),
      },
    }),
  },
})

Sanity

Sanity is the outlier in this list because you can't self-host the content lake. The Studio and schema are Node.js/TypeScript, but the data lives on Sanity's infrastructure. For some teams that's disqualifying; for most product and agency teams it's the right trade-off — you get a fast global CDN, real-time collaboration, Presentation (live preview), image transforms with hotspot, and a free tier that covers most small projects.

Typegen generates TypeScript interfaces directly from GROQ queries, which is the tightest end-to-end type safety of any option here. The free tier (up to 2 users, 200k API requests/month, 10 GB bandwidth) is genuinely usable in production for a marketing site. Growth plan starts at $15/seat/month.

The constraint worth calling out: if you need custom server-side business logic (e.g., a webhook that writes back to the CMS on an order event), you're adding a separate API layer. With Payload or Keystone that logic lives inside the CMS config.

Which one to pick

Pick Payload if you want full ownership, are running Next.js App Router, and your team is comfortable with TypeScript config and managing a database. Best self-hosted Node.js CMS right now.

Pick Strapi if a non-developer needs to manage the schema through a GUI and you're willing to accept looser TypeScript coverage.

Pick Directus if you're wrapping an existing database or building a data-heavy internal dashboard, not a content-first website.

Pick Keystone if GraphQL is a hard requirement and you want the cleanest TypeScript-to-schema mapping with full infrastructure ownership.

Pick Sanity if you want zero infrastructure management, real-time collaboration, best-in-class image delivery, and you're comfortable trading self-host control for a managed SaaS. It's what I use on most client projects for exactly those reasons.

The honest answer: for a custom Next.js marketing site in 2026, it's almost always Payload or Sanity. Payload when the client needs to own every byte. Sanity when speed of delivery and editorial experience matter more than infrastructure control.

The Next.js + React stack explained: what each layer does and when it's wrong

Nayan Kyada — Mon, 03 Aug 2026 07:55:31 +0000

The Next React stack is what most product teams land on after trying a few alternatives — React for the UI layer, Next.js as the framework, a headless CMS like Sanity for content, Tailwind for styling, and Vercel or a similar platform for deployment. Each of those choices is independent, but they've converged into a default for a reason. This guide explains what each layer actually does, why the combination became dominant, and — just as importantly — the situations where this stack is the wrong call.

What "the Next React stack" actually means

People use "Next.js stack" and "React stack" interchangeably, but there's a useful distinction. React is a UI library — it renders components, manages local state, and handles events in the browser. It has no opinion about routing, data fetching, or how you ship to production. Next.js is the opinionated framework built on top of React that fills those gaps: file-system routing, server components, ISR, image optimisation, metadata API, and so on.

So when a team says "we're on Next React", they usually mean:

React 19 — the UI primitives (hooks, server components, Suspense boundaries)
Next.js App Router — routing, rendering strategy, API/route handlers
A headless CMS — Sanity, Contentful, or Payload for structured content
Tailwind CSS — utility-first styling (v4 as of 2026)
Vercel or Cloudflare — edge deployment, CDN, and preview environments

Those five layers cover the vast majority of what a product or marketing site needs. The rest — search, email, video, auth — gets bolted on as needed.

React: the UI layer

React's job is to describe what the screen looks like as a function of data. With React 19 and the App Router, a large portion of that work now happens on the server. React Server Components (RSC) fetch data and render HTML without sending any JavaScript to the browser — which is a meaningful shift from the client-heavy SPAs React was associated with before 2023.

The practical result: a product page that queries your CMS and renders a list of articles ships zero JavaScript for the article list itself. Only the parts that need interactivity — a search input, a like button — stay as client components.

This isn't free complexity reduction. RSC introduces a clear mental model split: server components cannot use browser APIs, hooks, or event handlers. Client components must be explicitly marked with 'use client'. Teams unfamiliar with this boundary tend to scatter 'use client' everywhere, negating the performance benefit. Getting comfortable with that boundary is the main learning curve in 2026.

Next.js: the framework layer

Next.js sits above React and makes decisions you'd otherwise make yourself:

Routing — The App Router maps the app/ directory to URL segments. Dynamic routes (app/posts/[slug]/page.tsx), catch-all routes, route groups, parallel routes, and intercepted routes cover nearly every URL shape without a separate router library.

Rendering strategy — Each page or segment can be statically generated, server-rendered per request, or incrementally revalidated. With Partial Prerendering (PPR), you can prerender the shell and stream dynamic parts — so a blog post's static body serves from the edge CDN while the dynamic comment count streams in separately.

Image and font — next/image handles format negotiation (WebP/AVIF), lazy loading, and CLS prevention via reserved space. next/font subsetting eliminates render-blocking font requests. Both are opt-in but the defaults are good.

Metadata API — The generateMetadata function in each route segment lets you return <title>, Open Graph tags, and canonical URLs with access to route params and async data — so page titles and descriptions come from your CMS without a third-party library.

// app/posts/[slug]/page.tsx
import { client } from '@/sanity/lib/client'

interface Props {
  params: { slug: string }
}

export async function generateMetadata({ params }: Props) {
  const post = await client.fetch<{ title: string; description: string }>(
    `*[_type == "post" && slug.current == $slug][0]{ title, description }`,
    { slug: params.slug }
  )
  return {
    title: post.title,
    description: post.description,
  }
}

export default async function PostPage({ params }: Props) {
  const post = await client.fetch(
    `*[_type == "post" && slug.current == $slug][0]{ title, body }`,
    { slug: params.slug }
  )
  return <article>{/* render post */}</article>
}

The CMS layer

Next.js doesn't care where your data comes from, but most teams need structured content — blog posts, product pages, landing page blocks — managed by non-developers. That's where a headless CMS fits in.

Sanity is the most common pairing in this stack because it exposes a real-time content API with typed GROQ queries, stores images on a CDN with on-the-fly transforms, and runs Sanity Studio (the editor UI) either at a separate URL or embedded at /studio inside your Next.js app. The schema lives in code, not in a GUI, which means it's version-controlled alongside your components.

Contentful and Payload are viable alternatives depending on budget and self-hosting preference — but the integration pattern with Next.js is roughly the same: query the CMS in a server component, pass typed props to client components, revalidate on webhook.

Styling: Tailwind CSS v4

Tailwind v4 dropped the tailwind.config.js file in favour of CSS-native configuration via @theme in a root CSS file. In a Next.js project, that means adding one import to app/globals.css and writing utility classes the same way you always did — no breaking change to the component API, just a faster build.

The reason Tailwind became the default in this stack: it eliminates the runtime cost of CSS-in-JS (no hydration penalty, no style injection on the client), produces near-zero unused CSS in production thanks to the scanner, and keeps styling colocated with markup without a separate .module.css file per component.

Hosting: Vercel vs the alternatives

Vercel is the canonical deployment platform for Next.js — it was built by the same team, and features like ISR, PPR, edge middleware, and image optimisation are tested there first. For most teams, the zero-configuration deploy from a GitHub push, plus per-branch preview URLs, is worth the cost until scale makes the per-seat pricing awkward (the hobby-to-pro gap is around $20/month; team pricing scales from there).

Cloudflare Pages supports Next.js with the @cloudflare/next-on-pages adapter. It's cheaper at scale and has better global edge coverage, but some App Router features — specifically certain streaming and middleware behaviours — have lagged behind Vercel's support. AWS Amplify Gen 2 and Railway are options for teams that need VPC-adjacent deployment or want to avoid Vercel lock-in entirely.

Why this combination won

The short answer: each layer solved a real problem that its predecessor left open.

Create React App gave you React without a build opinion, but nothing else — no SSR, no routing, no image handling. Gatsby added static generation but required a GraphQL layer for everything, which felt overengineered for most content sites. Next.js Pages Router fixed Gatsby's data fetching complexity while keeping SSR an option. The App Router completed the picture by making server components the default, which finally made the "zero JS for static content" promise practical rather than theoretical.

Tailwind replaced CSS-in-JS libraries that were introducing hydration overhead and unpredictable specificity. Sanity replaced WordPress for teams that needed structured content without PHP. Vercel replaced DigitalOcean droplets for teams that didn't want to manage Nginx configs.

Each swap was motivated by a concrete pain point, not trend-chasing. That's why the stack has staying power.

When this stack is the wrong choice

The Next React stack is not universally correct. Three scenarios where you should think twice:

Mostly static, no interactivity. If you're shipping a documentation site or a blog with no dynamic personalisation, no real-time content, and no complex UI, Astro will produce smaller bundles and simpler deployment with less configuration. Next.js adds framework overhead that documentation sites don't need.

Highly interactive, app-like UI. If your product is closer to Figma than to a marketing site — lots of canvas interaction, real-time collaboration, drag-and-drop at scale — React's concurrent model is still the right choice but you may not need Next.js's server rendering machinery at all. A Vite-built SPA with a dedicated API backend is simpler to reason about.

Very small teams with no React experience. The App Router's RSC model has a non-trivial learning curve. If your team is two developers who know Vue well and need to ship in six weeks, adopting Next.js will slow you down. The stack rewards teams who already know React; it taxes teams who don't.

Putting the layers together

A minimal Next React stack project structure looks like this:

app/
  layout.tsx          # root layout, fonts, global CSS
  page.tsx            # home page — server component
  posts/
    [slug]/
      page.tsx        # post detail — server component + generateMetadata
sanity/
  lib/client.ts       # Sanity client config
  schemas/            # document type schemas
components/
  ui/                 # Radix-based primitives
  blocks/             # CMS-driven page sections
public/
tailwind.css          # @import "tailwindcss"; @theme { ... }

The app/ tree handles routing and rendering. The sanity/ tree owns the CMS integration — client, schemas, and GROQ query helpers. Components are split between generic UI primitives (usually Radix-wrapped) and CMS-driven blocks that map a content type to a layout.

This separation isn't arbitrary. When a designer changes a component, they touch components/ui. When an editor adds a new content block type, the schema and the block component change together, nothing else. That's the modularity the stack is designed to produce — and it holds as long as each layer stays in its lane.