DEV Community: vs7ironman

Why I Stopped Using Static Site Generation for Large Next.js Projects

vs7ironman — Mon, 08 Jun 2026 02:26:45 +0000

For years, Static Site Generation (SSG) felt like the obvious choice for SEO-focused websites.

Pre-render everything, serve static HTML, and enjoy fast page loads.

That works well until your site grows beyond a few hundred pages.

While building a software comparison platform, I ran into a problem: every new record in the database could generate dozens of new pages. What started as a few hundred URLs quickly became thousands.

At that point, traditional static generation started becoming a bottleneck rather than an advantage.

The Scaling Problem

Imagine a site with:

150 software products
Individual product pages
Alternatives pages
Category pages
Comparison pages

The total URL count grows surprisingly fast.

The challenge isn't serving the pages.

The challenge is rebuilding them.

If every deployment requires regenerating thousands of pages, build times eventually become unacceptable.

A deployment that takes 30 seconds at 100 pages can become several minutes once the site reaches tens of thousands of URLs.

My Initial Approach

My original implementation relied heavily on static generation.

The benefits were obvious:

Excellent Lighthouse scores
Fast initial loads
Predictable SEO behavior
Simple hosting requirements

However, every time I added or updated records, I needed to consider regeneration costs.

The larger the dataset became, the more painful deployments became.

Moving to Dynamic Rendering

Instead of generating every page at build time, I moved most pages to dynamic rendering backed by a PostgreSQL database.

The application uses:

Next.js App Router
Route Handlers
Server Components
PostgreSQL via Supabase

A route simply receives a slug and retrieves the relevant record:

export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params

  const { data } = await supabase
    .from("tools")
    .select("*")
    .eq("slug", slug)
    .single()

  return <ToolPage tool={data} />
}

The page template remains the same.

The data changes.

Why Performance Wasn't the Problem I Expected

Many developers assume dynamic rendering automatically means slow rendering.

In practice, database query optimization mattered far more than rendering strategy.

The biggest improvements came from:

Proper indexing
Eliminating unnecessary queries
Caching common lookups
Reducing over-fetching

Once those issues were addressed, page response times remained consistently fast.

Metadata at Scale

One advantage of dynamic rendering is metadata generation.

Every page can generate unique metadata directly from database fields:

export async function generateMetadata() {
  return {
    title: tool.name,
    description: tool.description,
  }
}

This allows thousands of pages to maintain unique titles and descriptions without manual intervention.

What I Learned

1. Build Time Is a Cost

Developers often optimize runtime performance while ignoring deployment performance.

At scale, build times become part of the user experience for the development team.

2. Data Models Matter More Than Templates

The quality of a large content platform depends far more on the structure of the underlying data than on the page templates.

Well-designed schemas create flexibility.

Poor schemas create technical debt.

3. Dynamic Doesn't Mean Slow

Modern server rendering is extremely capable when paired with efficient database queries.

4. Start With Simplicity

Many scaling problems don't appear until later.

It's often better to start with a straightforward implementation and optimize once real bottlenecks emerge.

A Real-World Example

One project where I applied this approach is SoftwareDuel, a software comparison platform that relies heavily on dynamic routes and structured data rather than manually managed content.

The architecture would have been significantly more difficult to maintain using a traditional static-generation-first approach.

Final Thoughts

Static Site Generation remains an excellent tool.

But once a project begins generating thousands of URLs from structured data, it's worth reconsidering whether every page truly needs to exist at build time.

In my experience, moving to a dynamic architecture simplified deployments, reduced maintenance overhead, and made future growth far easier to manage.

The best solution wasn't eliminating complexity.

It was moving that complexity from the build process into the application itself.

The Best AI Coding Tools for Developers in 2026

vs7ironman — Mon, 18 May 2026 16:24:53 +0000

AI coding tools have fundamentally changed how developers write,
review, and ship code. Here's an independent breakdown of the top
options in 2026.

GitHub Copilot

The most widely adopted AI coding tool. Integrates directly into
VS Code and JetBrains IDEs. Best for developers already in the
GitHub ecosystem who want inline code suggestions and completions.

Best for: Developers wanting seamless IDE integration with
minimal setup.

Cursor

An AI-native code editor built on VS Code. Goes beyond autocomplete
— Cursor can understand your entire codebase, answer questions about
it, and make multi-file edits. Gaining ground fast among developers
wanting a more integrated AI experience.

Best for: Developers wanting a fully AI-native coding environment.

Tabnine

Privacy-focused AI coding assistant that can run locally on your
machine. Popular with enterprise teams and developers working with
sensitive codebases.

Best for: Teams needing AI coding assistance with strict data
privacy requirements.

Codeium

Free AI coding assistant with strong multilanguage support. A
compelling alternative to Copilot for developers who want capable
AI assistance without the subscription cost.

Best for: Developers wanting free AI coding assistance across
multiple languages.

How to choose

The right AI coding tool depends on your workflow, IDE, and privacy
requirements. For independent side-by-side comparisons of all these
tools including pricing and fit for different team sizes, visit
AIToolIntel.com.

Browse all AI tool comparisons → AIToolIntel.com

How I Got 15,000 Pages Indexed in 3 Weeks with Programmatic SEO (Next.js + Supabase)

vs7ironman — Fri, 08 May 2026 02:38:01 +0000

How I Got 15,000 Pages Indexed in 3 Weeks with Programmatic SEO (Next.js + Supabase)

I built SoftwareDuel — an independent software
comparison site for SMB buyers — and got 15,000 pages indexed by Google in
under 3 weeks without writing a single page manually.

Here's exactly how it works.

The idea

Most software review sites rank tools based on who pays for placement.
I wanted to build something independent — honest side-by-side comparisons
across HR, payroll, CRM, ATS, project management, and accounting tools.

The problem: building thousands of comparison pages manually would take years.

The solution: programmatic SEO.

What is programmatic SEO?

Programmatic SEO means using structured data to automatically generate
pages at scale. Instead of writing each page, you define a template and
let the data do the work.

The formula:

1 tool in the database = 1 review page + ~20 comparison pages + 1 alternatives page
120 tools × ~22 pages = 2,600+ same-category pages
Plus Google indexes cross-category pages = 15,000+ total indexed

The tech stack

Next.js 16 — dynamic routes handle everything
Supabase (Postgres) — stores all tool data
Vercel — free tier hosting
Cloudflare — DNS

Total monthly cost: $0 on free tiers.

How the database works

Each tool in Supabase has these fields:

CREATE TABLE tools (
  id uuid PRIMARY KEY,
  name text,
  slug text,
  category text,
  description text,
  pros text,
  cons text,
  best_for text,
  features text,
  pricing_model text,
  website_url text,
  affiliate_url text,
  updated_at timestamp
);

How Next.js generates the pages

Three dynamic routes handle everything:

/tools/[slug] — individual tool review
/compare/[slug] — where slug is tool-a-vs-tool-b
/alternatives/[slug] — alternatives to a specific tool

The compare page splits the slug on -vs- to get both tool slugs,
then fetches both from Supabase:

const parts = slug.split('-vs-')
const slugA = parts[0]
const slugB = parts.slice(1).join('-')

const [{ data: toolA }, { data: toolB }] = await Promise.all([
  supabase.from('tools').select('*').eq('slug', slugA).single(),
  supabase.from('tools').select('*').eq('slug', slugB).single(),
])

The sitemap

The sitemap dynamically generates all URLs from the database:

export default async function sitemap() {
  const { data: tools } = await supabase
    .from('tools')
    .select('slug, category, updated_at')

  const comparePages = []
  for (let i = 0; i < tools.length; i++) {
    for (let j = 0; j < tools.length; j++) {
      if (i !== j && tools[i].category === tools[j].category) {
        comparePages.push({
          url: `https://www.softwareduel.com/compare/${tools[i].slug}-vs-${tools[j].slug}`,
          lastModified: new Date(tools[i].updated_at),
        })
      }
    }
  }
  // ... tool pages and alternatives pages
}

Key detail: same-category comparisons only. Cross-category comparisons
(Gusto vs Salesforce) are low quality and hurt crawl budget.

SEO optimizations that made a difference

Schema markup on every page:

FAQPage schema on tool, compare, and alternatives pages
BreadcrumbList schema on all pages
SoftwareApplication schema with dateModified on tool pages
ItemList schema on alternatives pages
Article schema on blog posts

Canonical tags on every dynamic page pointing to the exact URL.

Metadata generated dynamically from database fields — unique title
and description for every page.

Results after 3 weeks

15,000+ pages indexed by Google
12,800+ impressions in first 15 days
Average position: 33-35
58 linking websites acquired organically
11 affiliate programs approved

What I learned

1. Crawl budget matters more than I expected
Google doesn't index everything at once. It allocates crawl budget based
on site speed and quality signals. One slow deployment day caused a 5-day
crawl pause. Keep response times under 200ms.

2. Same-category comparisons only
I initially generated all possible comparisons (tool A vs every other tool).
Google saw thousands of low-quality cross-category pages and deprioritized
the site. Restricting to same-category only immediately improved quality signals.

3. Schema pays off fast
Adding FAQ schema to 80+ pages got them appearing in Google's Enhancements
report within days. Review snippets and breadcrumbs followed. These increase
CTR when you do start ranking.

4. Affiliate programs are harder than expected
Many high-traffic tools (Jira, Trello, Salesforce, Asana, Monday.com) don't
have affiliate programs. Plan your tool list around monetizable tools first.

5. The Google crawl pause is real
At the 3-week mark Google paused crawling for 5 days. I initially panicked
but it recovered fully. This appears to be a standard new-site evaluation
period. Don't make major changes during it.

What's next

Still early days — impressions are growing but clicks are still low.
The next milestone is consistent affiliate conversions as rankings mature.

If you're building something similar I'm happy to answer questions in
the comments.

SoftwareDuel is live at softwareduel.com