Project 3: Digital Portfolio

Role
Sole designer, architect, and builder. I approached this the way I'd approach any product I ship professionally — defining the data model before touching a single visual element, treating design decisions as reversible and revisable rather than permanent, and documenting the reasoning behind each choice as I made it.

The Situation
A Qualifying Exam portfolio isn't just a place to store finished work — it's the artifact a review committee scores directly, organized by program domain. That meant the architecture wasn't a neutral technical choice sitting underneath the "real" content; it was a strategic one. I needed a structure that could hold coursework, service, publications, and professional practice under three QE domains without turning into five disconnected mini-sites that would drift out of sync with each other — and I needed to build it without becoming a full-time web developer in the process, since the actual doctoral work still had to get done.

What I Did
I designed a single master Portfolio Items table with Category and Domain fields doing the work of separation, rather than building parallel tables for each content type — then paired that with slug-based routing and a domain-first accordion layout that mirrors exactly how the QERC committee scores the portfolio, so navigation and evaluation structure are the same structure. I built the site itself with an AI app builder (Lovable) connected to Airtable as the backend, treating prompt-writing as a specification exercise rather than a wish list — feeding in finished copy instead of vague descriptions, stating build order explicitly, and iterating on design with specific critiques rather than open-ended "make it better" requests.

Not every decision survived contact with real content. Early on, items without a photo rendered as a smaller compact row rather than a full card — a reasonable-sounding rule that broke down once the page filled with real academic work, most of it text- or video-based rather than visual. Downgrading serious doctoral work to a smaller layout slot simply because it lacked an image was the wrong call once I could see it next to everything else, so I retired that rule and moved every entry to equal-weight full-card treatment, with a branded fallback icon standing in for a missing photo. I also hit a hard constraint mid-build — Airtable's attachment storage cap — and resolved it by moving slide decks and recordings to Google Drive as linked references rather than stored files, which turned into a deliberate storage strategy rather than a one-time fix.

A later feature — letting case study prose reference a gallery image inline, with a hover preview before the reader clicks through — turned into a genuine debugging exercise across several stacked layers, each one masking the next until it was isolated on its own. Airtable's own rich-text editor was silently escaping the markdown link syntax as I typed it, so my first fix — a regex to reverse that escaping — matched nothing at all, because it assumed a symmetry in the escaping that wasn't actually there. Once corrected, a deeper issue surfaced: the original implementation mutated raw DOM nodes carved out of server-rendered HTML and tried to portal React content into them afterward, a pattern that doesn't reliably survive re-renders under server-side rendering. The real fix was architectural, not incremental — rewriting the renderer to parse markdown into actual React elements directly, rather than manipulating an HTML string and hoping the DOM held still. Even that wasn't the last layer: the markdown renderer's own default link sanitizer was silently stripping the custom URL scheme the gallery links depended on, which took one more explicit allowance rather than disabling sanitization outright. Each step needed genuine confirmation that the fix held, not just a clean build — the same discipline that mattered everywhere else in this project, just tested more thoroughly here.

Outcome
The result is a live, publicly accessible portfolio site (kim-kindred-space.lovable.app) organized around the exact domain structure my QERC review will use to score it, with 26 (and counting!) entries spanning coursework, service, publications, and professional practice. The same architectural pattern — one master table, category-based filtering, prompt-as-specification — proved reusable enough that I extended it to build a separate cohort hub for 192+ C1–K1 colleagues, and I'm now developing a short course to teach that same pattern to classmates building their own portfolios, adapted to their tooling rather than mine.

Reflection
That habit — treat structure as strategy, treat decisions as revisable, document the reasoning as you go — is a competency in its own right, not just a byproduct of the build. Before I could demonstrate anything else in this portfolio, I needed an instrument capable of holding and structuring that demonstration. Fundamentals of Educational Technology Leadership — this entry's placement should reflect what building that instrument actually counts as, once checked against the program's own mapping.
Tools: Lovable, Airtable, Google Drive