What We've Been Building — Studio Devlog, Spring 2026

Spring 2026 has been heads-down and productive. If you've been following along, you know Studio started as a blank canvas — a place to eventually centralize art, music, games, and writing. Over the past several weeks it's become a real, working site. Here's a look at what got built and why.

---

The Blog You're Reading Right Now

The most meta thing first: this blog didn't exist a few weeks ago. At the end of March I built the entire publishing system from the ground up — database table, controller, listing page, and this post detail view you're looking at right now.

It's intentionally simple. Posts have a title, a slug, an author, an excerpt, a featured image, and a published_at date that acts as a draft gate. Nothing is published until that date is set and in the past; drafts sit invisible in the database until they're ready. The listing page shows cards sorted newest-first. The detail page renders full HTML content — which is how I can do things like headings, links, and code blocks right in the post.

Starting simple and building on top of a working foundation beats designing the perfect CMS up front. The blog is live. That's the point.

---

Video Gallery — TikTok + S3

Studio has a Video Log page now. It pulls from two sources: a database-backed TikTok feed (where I track video IDs, thumbnails, and post types) and a direct S3 bucket scan as a fallback. The page displays a grid of video cards, and clicking one opens a modal viewer with inline playback — TikTok embeds for social content, an HTML5 player for anything hosted directly.

The two-source architecture was a deliberate choice. TikTok embeds are great when your content is on the platform and you want the engagement loop, but if something ever gets pulled or the platform changes its embed policy, the S3 fallback means the gallery keeps working. The database table tracks sort order and an is_active flag so I can hide specific videos without deleting them.

---

Illustration Gallery — Facebook + S3

Same idea, different medium. The Illustrations page pulls from a Facebook gallery posts table (synced from posts I've made on the page) and from an S3 prefix scan for direct uploads. Each card shows a title, description, tags, and a date. If the source file is a GIF, hovering the card previews the animation inline before you click. Clicking opens a full-size modal.

The tags system is stored as a JSON array on each row, which keeps the schema simple while giving enough structure to eventually filter by medium, style, or project. For now the gallery is visual and browseable. Filtering comes later when there's enough content to warrant it.

---

Homepage — The Creative Hub

The homepage is structured around four creative areas: Music, Visual Art, Games, and Video Log. Each section has a brief intro and a link into the relevant part of the site. There's also a "What I'm Working On" block that gives visitors a live sense of what's actively in progress rather than just a static portfolio grid.

The FAQ section at the bottom answers questions I actually get — things like what tools I use, how I approach aesthetics across different projects, and what the philosophy behind Studio is. Writing those out forced me to articulate things I usually just do instinctively, which was useful.

---

Noteleks — Game Engine Refactor

The most technically involved work this spring was on Noteleks, a 2D action platformer that's been in R&D under Studio. The old asset loading system was fragile — it probed for files by guessing paths, fell back on timeouts, and had race conditions that made animations load inconsistently.

I replaced the whole thing with a manifest-driven asset loader. At build time a manifest is generated with every texture, animation, and sprite listed explicitly. At runtime the loader reads the manifest and queues assets in two stages: first the manifest itself, then the assets it describes. The loading screen reflects both stages with a proper progress indicator — you see it move from "Loading manifest..." to "Loading assets..." rather than a fake spinner that jumps to 100%.

Spine animations (skeletal 2D animations for characters) are now created deterministically. The old system occasionally produced different animation states depending on load order. The refactor ensures the same input always produces the same animated output.

I also wrote unit tests for the AssetManager frame queuing logic — these didn't exist before and the lack of coverage was part of why the regressions were hard to catch. The test suite now covers manifest parsing, animation alias creation, and the two-phase preload sequence.

There's a README in the game directory now that explains the runtime asset-loading strategies and how to rebuild sprite manifests if the source art changes. This is the kind of documentation that pays off the moment a future-me (or anyone else) needs to touch the build pipeline and doesn't remember how it works.

---

Under the Hood — TypeScript + SSR Stability

Studio is one of seven projects in my portfolio and they all share a TypeScript configuration baseline. Earlier this year there were compilation errors cascading through several of them. By late March, all seven projects compiled with zero TypeScript errors. Studio was part of that cleanup — fixing type issues, aligning the tsconfig inheritance, and stabilizing the Inertia SSR server so React hooks don't throw on the first server-side render.

This is unglamorous work but it matters. A codebase where you can't run npm run types and get a clean exit is a codebase that's accumulating hidden risk. All seven projects are clean now.

---

What's Next

The site is functional and the foundations are solid. The next phase is putting more real content into it — uploading art, publishing writing, and expanding the Noteleks game toward something playable. The infrastructure exists to support all of that. Now it's about filling it in.

More soon.

— Joshua, Graveyard Jokes Studios