AMcI Dev

AMcIDev started as a straightforward portfolio. I needed somewhere to show my work, track how my projects were changing, and explain the decisions behind them. That worked while everything was public, but it became limiting once I wanted to include projects that were useful for recruiters and clients but not suitable for everyone to see.

Problem/Context

The old React version was fine for a public portfolio. The problem was hidden projects. Some case studies need extra context, some are commercially sensitive, and some are only useful when I can share them with the right person at the right time.

I did not want that to become a manual process where I was sending screenshots, separate documents, or temporary copies of project write-ups. I wanted the site itself to handle it.

Migration To Next.js

That requirement drove the move from React to Next.js. I needed server-side authorisation checks, protected project data, and a way to serve private assets without exposing them through the normal public build. SEO was part of the decision too, but the hidden-project workflow was the main reason.

The migration became a massive refactor in the best way. Routing, metadata, project resolution, protected images, shared UI, and deployment all changed around the same goal: make the portfolio feel public by default, but capable of controlled access when needed.

Protected Projects

Protected projects now behave differently depending on whether someone has access. Public visitors can still see that the project exists, but the detailed summary and original assets stay locked. Authorised visitors can view the full page through a token-based flow.

Tokens are hashed before storage, checked server-side, and stored in Turso through libSQL. That gives me a lightweight database setup without turning the portfolio into something heavier than it needs to be.

Admin Panel

The admin panel came out of the same refactor. I needed a simple way to manage access without touching the database directly, so I added tools for creating, revoking, and reviewing tokens.

It also tracks usage. I can see when a token was last used, how many views it has had, and which protected projects were opened. That makes the sharing workflow much easier to trust, especially when a link is going to a recruiter, client, or someone reviewing sensitive work.

Architecture

The codebase now runs as a Bun and Turborepo monorepo. The web app lives in apps/web, with shared UI, TypeScript, and linting packages split into packages/*.

The frontend uses Next.js, React, Tailwind, Radix UI, and Shadcn/ui. Sharp handles project image generation during the build, including blurred versions for locked projects. Admin sessions use JOSE for JWT signing and verification.

Production builds currently use Webpack because Turbopack output can miss middleware trace files expected by Vercel packaging. I have kept that decision explicit so it can be revisited when the compatibility improves.

CI/CD

GitHub Actions runs type checking, linting, and the production build on pull requests to main and dev. Bun installs dependencies, Turborepo coordinates the tasks, and CI uses placeholder environment variables so server-side code can still build without production secrets.

The site runs on Vercel, with Vercel Analytics giving me a lightweight view of traffic and project interest.

Future Plans

The protected-project workflow is the part I want to keep improving. The admin panel works, but there is room to make access management clearer and more useful over time.

I also want the writing to keep getting better. The site is not just a list of projects anymore. It is becoming a way to explain the decisions behind the work, especially when the most interesting details need a bit of control around who can see them.