The Projects Behind This Portfolio

I wanted the new projects page to feel less like a gallery and more like a map of the systems I have actually shipped.

That sounds obvious, but a lot of portfolio pages still do the old thing. A nice screenshot. A vague sentence. Maybe a stack badge cloud. Not much sense of what the product is for, how it behaves, or what kind of engineering decisions are holding it up.

The product and engineering blogs I keep coming back to tend to do a few things well:

• they open with a clear point rather than a generic intro
• they explain what the product is for before they disappear into implementation details
• they show how the system works, not just what tools were used
• they are honest about constraints, trade-offs, and why certain choices were made

So that is what I wanted this page and this post to do, at minimum.

If you just want the working index, it is here: Portfolio projects on rajeevg.com.

Quick scan

Here is the short version of what is now on the portfolio page.

Why I wanted this page in the first place

I have a few different kinds of projects in Code/, and they are not all trying to prove the same thing.

Some are product experiments. Some are publishing systems. Some are data-heavy tools. Some are really about workflow design more than UI. If I present them all the same way, they flatten out.

That is usually where portfolio pages stop being useful.

A good portfolio page should answer practical questions quickly:

• what problem does this project solve?
• who is it for?
• is there a live public version?
• is the code public?
• what is the actual implementation shape?

That is why the new /projects route is driven by one checked-in data source. Each entry needs a working public product and enough evidence to explain what it does. Source code is linked when it is public; private-source products only appear when the visitor-facing product is complete and understandable on its own. Adapted software is labelled clearly so a deployment is not mistaken for original authorship. In other words, this is not a wish list, and it is not a private backlog dressed up as shipped work.

Local LLM Lab

AI research product

Local LLM Lab

A measured guide to every local AI model installed on my Apple Silicon workstation.

PythonReactVite

Build write-upGitHubLive site

Local LLM Lab started as a collection of benchmark notes and became a current field guide to the models actually installed on my Apple Silicon workstation.

The important distinction is between a model family and an exact local build. Quantisation, runtime, and file format can change memory use, speed, tool support, and output quality enough that two builds with the same model name should not be treated as interchangeable.

The public guide brings together:

• the exact builds currently installed through MLX, Ollama, and Apple system tooling
• measured task quality, response speed, and peak memory use
• text, image, audio, tool-use, reasoning, and code-completion support
• tuned local aliases that reuse the same underlying model weights
• historical results for models that were tested and later removed

Python scripts refresh the machine inventory and join it to checked-in benchmark evidence. The generated React site then presents the result as a guide a person can use without reopening raw JSON, shell logs, and benchmark folders.

Workflow Garden

Education product

Workflow Garden

A public learning site for issue-driven AI development workflows.

Next.jsReact 19Velite

GitHubLive site

Workflow Garden is probably the clearest example of the kind of software I like building right now. It is part educational product, part publishing system, and part documentation experiment.

The basic idea is simple: take an issue-driven AI development workflow and explain it in a way that does not assume the reader already lives inside GitHub, Linear, or terminal tooling all day.

What makes it interesting is the shape of the content system behind it. The site is not just a pile of static pages. It has evergreen articles, concept pages, project pages, search, and a generated diary that reflects meaningful activity from the local Code/ workspace. So there is a real content-pipeline problem hiding inside what looks, at first glance, like a regular content site.

The stack choice there was pretty deliberate:

• Next.js for routing and deployment ergonomics
• Velite for typed content and static build-time transforms
• Pagefind for on-site search without needing a server-side search product
• generated JSON for diary content so Vercel can serve the site statically

I like this project because it forces product thinking and systems thinking into the same room. You have to care about editorial clarity, information architecture, content generation, and proof of correctness at the same time.

Proof Pack

Review tool

Proof Pack

A launch-review app that turns a URL into a concise critique pack.

Next.jsReact 19Tailwind CSS

GitHubLive site

Proof Pack came from a very familiar feeling: a page is technically done, but nobody has really said whether it is understandable.

That gap matters more than people admit. A launch can fail in much more boring ways than "the server crashed." The layout can bury the main action. The mobile version can make the sequencing feel wrong. The messaging can sound clear to the maker and fuzzy to everyone else.

So Proof Pack is intentionally scoped around review, not content management. A user gives it a public URL and gets back a concise pack that looks at:

• what the page appears to do
• where the visual hierarchy drifts
• what mobile or accessibility risks are likely
• what concrete changes would make the page easier to ship

The tech choices are modest on purpose. Next.js, React, Tailwind, and Vitest are more than enough here. The interesting part is not framework novelty. It is the product boundary: keeping the tool focused on a specific review moment instead of letting it turn into a generic website auditor with a thousand weak heuristics.

Choice Compass

Decision tool

Choice Compass

A weighted decision helper for comparing a small set of options.

ReactTypeScriptVite

GitHubLive site

Choice Compass is small, and I have a soft spot for small products that do one useful thing cleanly.

The job here is to help someone compare a few options without ending up in spreadsheet chaos. That might be software tools, purchases, plans, or even internal workflow choices. The pattern is the same: define the options, define the criteria, decide how much those criteria matter, score the options, and get a recommendation you can actually act on.

This one is intentionally browser-local. That matters because the app does not need accounts, backend storage, or a database just to help someone think. React, TypeScript, and Vite keep it quick, and localStorage is enough persistence for the problem shape.

I like that constraint because it keeps the product honest. A lot of tools add infrastructure before they have earned the right to. Choice Compass does not. It stays close to the user job and resists turning a simple comparison workflow into a platform.

Model Intelligence Maintainer

Data product

Model Intelligence Maintainer

A workbook and static guide for comparing model quality, price, and provider coverage.

PythonuvOpenRouter

GitHubLive site

This is the most data-heavy project in the current portfolio, and probably the most operational one.

The problem it is solving is not "show me benchmark charts." There are already plenty of dashboards for that. The harder problem is keeping a comparison system maintainable and explainable when model metadata is coming from multiple sources with different identifiers, different coverage, and different failure modes.

That is why the repo is built around a refreshable pipeline rather than a single front-end app. It pulls together data from:

• OpenRouter for routed model and pricing metadata
• Artificial Analysis for performance and provider coverage
• Vals for application-style quality signals
• LiveBench for public benchmark enrichment

The output is not just one website. It is a dataset layer, a workbook, and a static guide. That split is important. Some people want a browsable site. Some want a spreadsheet they can sort, annotate, and pass around. The system needs to support both.

This is also the sort of project where the unglamorous engineering work matters most: cohort rules, provenance, mapping diagnostics, and deterministic refreshes. If those parts are sloppy, the polished guide on top is not worth much.

rajeevg.com

Personal site

rajeevg.com

This portfolio and writing site, built for clear technical storytelling.

Next.jsReact 19Velite

Site analyticsGitHubLive site

This site is now part portfolio, part blog, and part publishing system for the rest of the work.

I rebuilt it around Next.js, Velite, MDX, and shadcn/ui because I wanted a setup that could handle both straightforward writing and more structured technical storytelling. Plain markdown is still great for a lot of things, but once you want richer article layouts, reusable callouts, or project cards embedded directly into posts, the component model starts to matter.

That is exactly what this article is using.

The Velite layer turns the content into typed build output. MDX lets me mix prose with React components. shadcn/ui gives me a stable set of primitives for cards, buttons, tables, alerts, and layout pieces. That combination is what made it straightforward to add a portfolio page and then write a post that reuses the same project metadata rather than copying everything by hand.

That reuse is the part I care about. Good publishing systems should reduce duplicated thinking, not just duplicated markup.

What ties these projects together

If I step back, the common thread is not one language or one framework.

It is a bias toward systems that make work clearer.

Sometimes that means a public educational site. Sometimes it means a review tool. Sometimes it means a data pipeline that turns scattered model signals into something a person can actually use. Sometimes it just means refusing to add more infrastructure than the problem needs.

The portfolio page is meant to make that pattern legible.

Not every repo in Code/ belongs there. Some are still scaffolds. Some are still internal. Some do not have a public live URL yet. That is fine. I would rather have a smaller portfolio of projects that are real, inspectable, and live than a bigger page full of half-claimed work.

Where to browse next

• Start with the projects page if you want the concise version.
• Open Workflow Garden if you want the best example of a content-rich product system.
• Open Proof Pack if you want the clearest review-oriented tool.
• Browse Choice Compass if you want the smallest product with the cleanest scope.
• Check the GitHub repositories if you want the implementation side.

This is the version of a portfolio I find most convincing now: less "here are some screenshots," more "here is the product, here is the code, and here is how it actually works."