said7388/developer-portfolio: A Next.js 16 and Tailwind 4 Portfolio Template

The gap said7388/developer-portfolio fills

Most portfolio templates give you a layout and leave the content plumbing to you. This one inverts that: the README describes the project as "data-driven configuration", and the repository layout backs it up. There is an app/ directory for routes and a utils/ directory that the README treats as the place your own content lives. Sections are fixed (Hero, About Me, Experience, Skills, Projects, Education, Blog, Contact), so the decision you make is not what to build but what to type into existing shapes.

The target user is a working or junior developer who wants a personal site live this week and does not want to maintain a CMS. Freelancers are named in the README's own description. The trade-off is explicit: you get a finished visual design and lose layout freedom. If your portfolio needs a case-study format, a writing-heavy layout, or anything the eight sections do not cover, you are fighting the template rather than using it.

How the Next.js App Router build is put together

The stack is Next.js 16.2.7 with React 19.2.7 and Tailwind CSS 4, per package.json. The README's feature table lists App Router, Server Components, Server Actions, the Metadata API, next/image and next/font. In practice that means the static parts of the page render on the server, the contact form submits through a Server Action instead of a hand-written API route, and page metadata comes from the framework's typed metadata API rather than raw head tags.

The blog section is the one piece that reaches outside the repository: the README says posts are "auto-fetched" from dev.to, and axios is a dependency, which fits an HTTP call to a public API. Everything else is local. The contact form is the most coupled part. It uses nodemailer for email and a Telegram bot for a second notification channel, and the README documents both as tutorial steps rather than as optional extras. That means a working contact form depends on Gmail app-password configuration and a bot token, not just on deploying the site.

Installing said7388/developer-portfolio and editing your first section

The README requires Node.js 18.17.0 or later (20+ recommended), Git, and pnpm as the recommended package manager. It also documents npm and yarn as alternatives, so the choice is yours. Fork the repository first, since the README's clone command expects your own GitHub username in the URL.

git clone https://github.com/<YOUR_GITHUB_USERNAME>/developer-portfolio.git
cd developer-portfolio
pnpm install

After install, copy the environment template. The README gives this exact command, and the resulting .env file is where the contact form and analytics keys go.

cp .env.example .env

The .env.example file lists six keys, all empty: NEXT_PUBLIC_GTM, NEXT_PUBLIC_APP_URL, TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID, GMAIL_PASSKEY and EMAIL_ADDRESS. Leave the Telegram and Gmail values blank at first and the site still builds; the contact form is the part that will not deliver. Start the dev server with the script defined in package.json:

pnpm dev

That runs next dev, which serves on port 3000 by default. Open it, then edit the data behind each section in the utils/ directory. Which file holds which section is not spelled out in the README excerpt, so read the imports in app/ before you start renaming fields.

Docker deployment and the two Dockerfiles

The repository ships Dockerfile.dev, Dockerfile.prod and a docker-compose.yml with two services. The dev service mounts the working directory into /app, sets WATCHPACK_POLLING=true for file watching inside the container, and maps port 3000 to 3000. The prod service maps host port 3005 to container port 3000. That asymmetry is easy to miss: if you copy the prod configuration into a platform that expects 3000, your health check will fail.

docker compose up dev

Both services read from .env via env_file, so the same keys you set for local development carry into the container. The compose file also declares a node_modules and a .next volume so the host directories do not shadow the container's installed packages. That detail matters on macOS and Windows, where bind-mounting node_modules across the filesystem boundary is a common source of confusing module-not-found errors.

Where the template pushes back

The biggest limitation is the unverifiable licence. The README carries an MIT badge, but the repository metadata reports no licence, and there is no LICENSE file in the top-level entries. Those two signals disagree. Before you ship this on a commercial site, check the repository yourself rather than trusting the badge.

Second, the fixed section list is a real constraint, not a stylistic preference. There is no documented way to add a section without writing React components, and the README does not describe a plugin or block system. Third, the contact form's dependency on Gmail app passwords and a Telegram bot means a broken form is the most likely first bug you hit after deploying, and the failure is silent from the visitor's side. Fourth, the README does not document rollback, version pinning strategy, or how to upgrade between major Next.js releases. The repository's last push was on 2026-06-05, so the dependency versions in package.json are roughly four months old as of this writing; a Next.js 16 minor bump may or may not be drop-in.

How it compares to a static-site portfolio

The obvious alternative is a static site generator such as Astro or Eleventy, or a hand-written HTML page deployed to GitHub Pages. The difference is not speed; it is where the work happens. A static generator gives you a build step that outputs plain HTML with no server runtime, so hosting is free and there is nothing to keep patched. This template keeps a Node server in the loop for Server Components and Server Actions, which is what makes the contact form work without a separate backend service.

That trade is worth naming. If your portfolio is five pages of text and images, the static route removes an entire class of maintenance. If you want a contact form that sends mail without wiring up a third-party form service, the Server Action model here is genuinely less work. The template also bundles more than a static starter would: Lottie animations, react-fast-marquee for the skills strip, react-toastify, and react-google-recaptcha, all visible in package.json. Each one is a dependency you inherit and eventually have to update.

Maintenance cost and licence status

The dependency surface is the maintenance cost. Next.js, React, Tailwind, ESLint, Sass, axios, nodemailer and six UI libraries all move independently. The repository provides pnpm-lock.yaml and package-lock.json, which is unusual and slightly confusing: two lockfiles for two package managers, so pick one and delete the other from your fork to avoid drift. The scripts are minimal (dev, build, start, lint), which keeps CI simple.

On licensing, the README badge says MIT, but the repository metadata does not declare a licence and no LICENSE file appears in the top-level listing. Treat the badge as a claim to verify, not a fact. If you need a clear licence for commercial use, resolve that before you invest time in customisation. This is a description of what the repository shows, not legal advice.

Editorial conclusion

Adopt it if you want a portfolio that runs on the current Next.js App Router and you are willing to edit utils/data files rather than design a layout. Skip it if you need a CMS, multi-language pages, or a licence you can verify: the repository does not state one, even though the README badge claims MIT. Before deploying, confirm which data file drives each section, whether the contact form works without GMAIL_PASSKEY and TELEGRAM_BOT_TOKEN, and whether you accept the 3005:3000 port mapping in docker-compose.yml.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. said7388/developer-portfolio on GitHub