aulianza.id: a personal site and portfolio that doubles as a template

A portfolio site with a command palette and a guestbook

aulianza.id is a personal website and portfolio, and the repository is the site source rather than a library. The author describes it as carefully crafted from the ground with Next.js and other tools, starting in June 2023, and the project says it was built from scratch with Next.js, TypeScript, Tailwind CSS, SWR, Firebase and Prisma over PostgreSQL. The licence is GPL-3.0, the homepage is at v1.aulianza.com, and the last push was on 2026-10-07 with no tagged releases.

The interesting decision is that the author publishes the whole thing as a starting point for other people, inviting you to use it as a reference, for inspiration, or as a template, following the provided licence, and to access the source code to customise it to your needs.

What makes it more than a blog template is the feature list. There is a ChatGPT feature reached through the command palette with the cmd+k shortcut, which the README marks as unavailable in the deployed version but which you can configure on your own machine with your own OpenAI API key. There is a JavaScript playground described as a no-fuss pure JavaScript playground with a live feedback loop. There is a realtime guestbook where anyone can leave a message, powered by Firebase. There is a Spotify status panel showing the currently playing song in real time, and a WakaTime statistics dashboard.

For a template, that set of features is the point. They are the small things that make a personal site feel like a person built it, and they are all present, working or at least configurable, in the source.

Three data sources, three rendering strategies

The content comes from three places, and the project uses a different rendering strategy for each, which is the most instructive part of the design.

The blog is sourced from a self-hosted headless CMS powered by WordPress. The list of articles is fetched with Client-Side Rendering and the details with Server-Side Rendering, and the documentation gives a reason for the split, namely a content delivery system that stays efficient rather than heavy. The project also references the MDX tooling in the description and the topic tags, and the manifest carries the MDX loader and the MDX React package, so MDX is available for components in the content.

The projects are different again, because they live in a database rather than in a CMS. The data comes from a PostgreSQL database connected through the Prisma Client, hosted on Supabase DB, and the fetch method is Incremental Static Regeneration with a one second revalidation, with Server-Side Rendering for the project details. A one second revalidation is aggressive, which tells you the author wanted the project list to feel live.

The dashboard data is the third source, and it is where the API routes come in. The WakaTime data is retrieved through the WakaTime API and then displayed on the dashboard, built with Next.js API routes deployed as serverless functions. The Spotify panel uses the Spotify API together with SWR for the fetching, which is the client-side data fetching library in the stack.

So the pattern is: a headless CMS for prose, a relational database for structured project data, and third-party APIs for the live widgets, each reached by the mechanism that suits it. A template that mixes all three is more instructive than one that only has one.

The dependency list, and where the README has drifted

The manifest is a good catalogue of what the site actually uses. Next.js is pinned at 15.3.2 with React and React DOM at 18.2.0, TypeScript through the tsconfig, Tailwind with the headlessui React package, Prisma client and prisma at 4.16.2, Firebase at 10.14.1, SWR at 2.3.7, framer-motion at 10.18.0, next-auth at 4.24.13, next-seo, next-sitemap, next-themes, giscus for comments, the Monaco editor wrapper for the playground, axios, clsx and tailwind-merge, date-fns with the time zone helper, moment as well as date-fns, and a long tail of component libraries such as react-slick, aos, react-scroll and react-loading-skeleton.

The drift is worth pointing out, because the README's tech stack list is older than the code. The list says Next.js 13.5.6, while the manifest pins next at 15.3.2, and it names Tailwind CSS 3, Zustand, Jest, Husky with lint staged and conventional commit lint, several of which appear in the manifest under different names or not at all. The README also says the site was built with MDX in the headline while the stack list omits it.

That is not a criticism so much as a warning about what a repository README is. The manifest is the source of truth for what is installed, and the stack list is a description written at one moment. If you are going to build on this, read package.json rather than the list.

The scripts in the manifest show the same pattern of a conventional Next.js setup. Development is next dev, the build is next build with a postbuild step that runs next-sitemap, linting is next lint with a separate fix script that also runs the formatter, there is a typecheck script using tsc with no emit and incremental disabled, the tests are jest with watch, plain and ci variants, husky is installed on prepare, and a postinstall step runs prisma generate.

Getting it running, and the size of the environment file

The setup is three steps plus a configuration step, and the three ways to clone reflect the fact that people arrive with different tools.

   git clone https://github.com/aulianza/aulianza.id

   npx create-next-app -e https://github.com/aulianza/aulianza.id project-name

   npx degit aulianza/aulianza.id YOUR_APP_NAME

The create-next-app route takes the repository as an example, and degit downloads the template without the git history, which is the one you want if you intend to publish your own site under your own history.

Dependencies are installed with yarn, and the README says it is encouraged to use yarn so the husky hooks work properly:

yarn install

Then the environment file is copied from .env.example and filled in, with the third-party variables pointing you at each provider's own documentation. The development server is started with:

yarn dev

and the site is at http://localhost:3000, with the starting point of the edit being src/pages/index.tsx.

The environment file is the interesting part of the setup, because it is long. It covers the bundle analyser flag and the site URL, the blog API URL, an OpenAI key, a DEV.to key, Spotify client credentials and a refresh token, a WakaTime API key, two GitHub read tokens for personal and work accounts, the Prisma database URL as a postgres connection string, a contact form API key, the Firebase configuration with its NEXT_PUBLIC prefixed client values, and the Next-Auth settings with a URL and Google client credentials.

That is a lot of credentials for a personal site, and it is worth noticing that a template ships with all the integrations turned on, so a fork that is deployed without trimming the .env file has a large surface of third-party integrations configured against keys you have not set.

Two environment files that do not quite match

The README shows an environment listing and the repository ships a .env.example, and the two are not identical, which is a small trap for anyone setting this up.

The README version ends its Next-Auth block with NEXTAUTH_URL, GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET. The .env.example file in the repository ends with the same three plus GITHUB_ID and GITHUB_SECRET, so the file on disk is the more complete one and the README has dropped the GitHub credentials from the listing. Everything else lines up, including the DATABASE_URL as a quoted postgres connection string and the run of NEXT_PUBLIC Firebase variables.

The next_auth dependency in the manifest makes the difference meaningful rather than cosmetic. With Google credentials but no GitHub credentials, the sign-in flow has one provider; with both, it has two. So the README, taken literally, produces a site with fewer sign-in options than the repository intends.

The general lesson for a template with this many integrations is that .env.example is a starting point rather than a complete specification. It names the variables the code reads, it does not tell you which features work with which subset, and a fork that wants only a blog and a portfolio should delete the rest rather than leaving placeholders for a dozen services.

One more detail in that file is the DATABASE_URL, which points at a Postgres database and is used through Prisma. The README says the project database is hosted on Supabase, so a fork that keeps the projects feature needs its own Postgres instance, which is the one piece of the setup that cannot be avoided with a free tier elsewhere.

Performance reporting, tooling and what a fork inherits

The README points at PageSpeed Insights and GTmetrix reports for the deployed site, and the links themselves have a small problem: the GTmetrix label is attached to a pagespeed.web.dev URL, so one of the two report links does not go where its name says. It is the kind of copy and paste slip that survives in a README for years.

The tooling around the code is worth knowing about if you plan to contribute rather than fork. The repository has an ESLint configuration, a Prettier configuration and ignore file, husky hooks, a commitlint configuration for conventional commits, jest with a config and a setup file, next-seo and next-sitemap configurations, giscus configuration for comment threading, a prisma directory with the schema and migrations, a vercel.json, and a tailwind config. The Depfu badges in the README indicate automated dependency updates, with a badge saying dependencies are updated every Sunday, which is a useful signal for a template that other people are expected to run.

What a fork inherits is the licence, and for a website template GPL-3.0 is a genuine constraint rather than a formality. The licence is permissive in the sense that you may use, study, modify and redistribute the code, and the source is open, but it is copyleft, so a site you derive from this one and distribute is expected to carry the same terms. The LICENSE file in the repository is the text that governs it, and the project says to follow it.

The other inheritance is the feature set. A fork that only wants a writing site has to remove the guestbook, the Spotify panel, the WakaTime dashboard, the playground and the projects database, and the integrations each of those depends on. That is real work, and it is the same work in reverse that the author did to build the site.

Editorial conclusion

aulianza.id fits a developer who wants a personal site that does more than list blog posts, since the guestbook, the Spotify panel, the WakaTime dashboard and the JavaScript playground are exactly the kind of feature set people want and rarely write, and the code is readable enough to take apart. It is the wrong starting point if you want a minimal blog, since you would be deleting most of the application, and it is the wrong starting point if the licence does not suit you, because GPL-3.0 asks you to keep derived sites under the same terms. Before you fork it, read the .env.example in the repository rather than the environment list in the README, since the two differ, and check the dependency versions yourself, because the stack list in the README is older than the versions actually pinned in package.json.

Frequently asked questions

Official sources

1. aulianza/aulianza.id on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README