Nzubechukwu.
← All posts
Software engineering6 min read

How I structure a Next.js project so it doesn't rot

Content as data, components as functions of data, and a folder layout that answers questions instead of raising them.

By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer

Generative cover art for the post “How I structure a Next.js project so it doesn't rot”

This site is the third Next.js project I've structured from scratch, and the first one I expect to maintain for years. The difference is a few decisions made early.

The structure that survived

src/
  app/        # routes only — thin, no business logic
  components/ # presentational pieces, data comes in as props
  content/    # the site's truth: projects, posts, identity — typed data
  lib/        # everything that isn't UI: SEO, markdown, helpers

The load-bearing decision is content/. Projects, blog posts, and identity live as typed data, not as JSX. Pages became functions of data, and updating the site means editing a record — not surgery on a component. Content and presentation stopped being entangled, and maintenance got cheap.

The rules that prevent rot

  • routes render; they don't decide. Logic lives in lib, content lives in content, layout lives in components
  • every folder answers a question: "where does X live?" should have one obvious answer
  • types at the boundary: content modules export typed arrays, so a bad entry is a build error, not a broken page

The test

Six months from now, I should be able to change anything — a project status, a blog post, a colour — by touching one file. So far, the structure is holding. That's the whole goal.

Nzubechukwu Cyprian studies Pharmacy at the University of Nigeria, Nsukka and builds software, products, and AI experiments in between.