Dev notes

Work Portfolio

How I turned 10 old jobs into a single interactive page, and the handful of decisions that made it buildable without turning into a museum of dead apps.

The problem with a work portfolio

Past work rots. The apps have dead backends, retired auth, paid licenses, and client names you can't show. A list of "things I built" is either a wall of dead links or a wall of screenshots. I wanted something you could actually touch.

Reconstruction, not emulation. Each feature is rebuilt as a small self-contained component with mock data, not the original app wired to a dead API. It behaves like the feature did, in this site's design system.
22 feature demos drawn from 10 projects, because the interesting projects had more than one idea worth showing. It launched with 24 across 11: Economy & Financial Health overlapped the other analytics demos without adding an angle, and Streaming Ops went out along with the Ops Console project it was the only demo for.

Anonymizing without gutting it

Most of these were client and employer projects, so no real names ship: not the company, not the games, not the wallets. Projects get descriptive codenames ("Analytics Portal v2", "Content Engine").
The rule is enforced in code. A unit test scans every file in the feature for a banned-name list, so a slip fails the build instead of shipping. The interesting nuance: the guard's own list is the one place those strings are allowed, so the test skips itself.

The no-new-dependencies rule

The originals leaned on MUI, ECharts, AG Grid, a node-graph library, gridstack, a code editor. Pulling all of that in to mimic them would bloat the bundle for a portfolio page, which is exactly the kind of thing the tree-shaking write-up argues against.

Every demo is rebuilt on what's already here: Tailwind, framer-motion, and the recharts already in the tree. The drag-drop dashboard is CSS grid, the node graph is hand-built SVG, the "code editor" is a read-only pre.
Every demo is its own lazy chunk. They load through next/dynamic, so the page ships only the demo on screen, never all 22 at once.

The dual-ticker UX, and its tradeoffs

Two marquees: projects scrolling one way on top, features the other way on the bottom. It's playful and it fits a lot of entries in a small space.
A moving target is hard to click. So hover pauses the marquee, touch freezes it for a few seconds, and there are always-stable fallbacks: side arrows, keyboard arrows, and ?feature= deep links. prefers-reduced-motion drops the animation entirely.
Each chip carries an info button that opens an anchored explainer: what the feature did, its original stack, and what's real vs. mocked in the reconstruction. That's where the honesty lives.

Shipping it: merge-order-independent PRs

One base PR ships the whole machinery plus a catalog where every feature points at a ComingSoonDemo placeholder.
Then each demo batch is its own PR that only adds its demo files and flips its own lines in the registry. Different PRs touch different lines, so they merge in any order once the base lands.
The one shared helper (a seeded RNG) is copied byte-for-byte into each batch instead of centralized, because an identical add/add resolves cleanly where a shared edit would conflict.

The takeaway

A portfolio of dead apps is a maintenance trap. Rebuilding the ideas as tiny living demos is more work up front and far less rot later.
Constraints made it tractable: anonymize by default (and enforce it), add no dependencies, and structure the work so the big scary feature ships as a dozen small, independent, reviewable pieces.

Update — August 10, 2026

The tickers stopped being bespoke, and three bugs I had been ignoring

The dual tickers above were written for this page and stayed that way for a while. Two things forced the issue. First, they could not actually reach every chip — the loop scrolled but there was no way to get to items past the fold, so some of the portfolio was unreachable by anything except waiting. That got fixed by pinning the tickers, scrolling the demo area beneath them, and driving the loop from scrollLeft rather than a transform, which makes the same element both the animation and the scroll container instead of fighting between the two.

Once they scrolled properly they were close enough to the ticker on the landing page that keeping two implementations was indefensible, so they moved onto the shared component. That is the sequence I would repeat: make the bespoke thing correct first, then unify. Unifying around a broken shape just spreads the bug.

The drag bugs were the same bug twice. Dragging an NFT between panes and dragging a post between queue columns both failed the same way, because a dragged item rendered inside its source container is clipped by that container the moment it leaves. The fix in both cases is a drag overlay — render the thing being dragged in a layer above the layout rather than in the tree it came from. Worth knowing once, because it is the answer every time.

And a class of bug I keep finding. Side effects had crept into state updater functions here, exactly as they had in the Learn steppers. An updater must be a pure function of previous state; React is allowed to call it twice, and anything with a consequence does not belong in it. Two features, two independent authors of the same mistake, which tells me it is a shape worth watching for rather than a one-off. The referral click tracking moved to the mutation where it belongs, and the Escape handling on the explainer dialog stopped depending on render timing.

What I'd do now, and what I did

The tickers are the shared component rather than a bespoke copy — but only after they were made correct, since unifying around a broken shape spreads the bug rather than fixing it.
Both drag bugs solved with a drag overlay: a dragged item rendered inside its source container gets clipped the moment it leaves, so it belongs in a layer above the layout.
Side effects moved out of state updaters and into the mutation and event handlers where they belong.
The same lesson one layer down, in the workflow editor: the drag handler reached through a ref from inside a setState updater, and since React runs those at flush time rather than event time, a fast drag whose moves and pointerup arrived in one task found the ref already cleared and crashed the demo. Reading the id at event time fixed it — a non-null assertion was the only reason the compiler stayed quiet.
Still no new dependencies for the reconstructions themselves, which was the original rule and the one I would keep.

Where it could go further

The explainers are prose in components. As content grew, editing a description means editing a React file, which is the wrong shape for something that is really copy.
Each reconstruction is hand-built, so there is no shared notion of what a demo is — adding one is a new bespoke component every time.
Nothing proves the anonymisation holds. It is a rule I follow rather than something a test enforces, and a lint rule for the obvious tells would cost little.

Next on this

Stabilise the ticker E2E tests. They failed once on a release and passed on re-run, which is exactly how a real signal gets trained into noise — the fix is to make the assertion wait on the demo being ready rather than a fixed timeout.
Pull the explainer copy out of the components so adding a reconstruction is a data edit.