I turned it from a one-off script into a real harness I run with one command against the whole stack. It attacks the backend, replays out-of-order Stripe events to prove a cancelled plan can’t come back, and it screenshots the site and fails if the page renders as a flat white frame. That last one is a real bug I hit: the old checks passed because there were no console errors, but the entire hero was painting white on certain GPUs.
I also added a tripwire that fails the build if I ever delete something already built and verified, or reintroduce a mistake I already fixed. Iterating on a live 3D site, the hard part is not breaking the thing that already worked.
It runs in CI now, so every push gets checked.
Live: xkaii.studio
Security: xkaii.studio/security

The visual layer is hand-written WebGL and GLSL. GPU particle cores that react to your cursor, morphing transitions between pages, adaptive performance that tunes itself to the device. All custom code, no template, no page builder.
But looking expensive is only half the job. I also build and secure the systems behind sites like this: multi-tenant SaaS, Stripe billing, PostgreSQL row-level security. So I wrote an automated red-team loop in Python and ran it against my own live site: attack, triage, patch, verify. It flagged a couple of hardening gaps, I fixed them, and re-ran until it came back clean.
If you want a site that looks like a high-budget trailer and holds up when someone probes it, that is what I build.
Live: xkaii.studio
The security work: xkaii.studio/security

I designed a intake portal and vetting system for the elements Music. This system is designed to vet and organize musicians and artists that join the platform. I designed a intake portal that allowed for creators and artists to give detailed information about their work and who they are and this portal was connected to a workstation which was automated to connect to their CRM.

Why this exists
Musicians who score to picture work across two tools that were never meant to talk to each other. The audio lives in a DAW, the video lives in an editor, and keeping them aligned is manual work that has to be redone every time either side changes.
Backline is one application where the timeline is shared. You cut picture and you cut music against the same clock.
The hard constraint: the audio thread
Real-time audio has a rule that shapes every other decision. The audio callback runs on a high-priority thread with a hard deadline, and if you miss it the user hears a click. Not a slow frame, an audible defect.
That means no allocation on the audio path, no locks, no file access, and no anything that can block for an unbounded time. Communication with the rest of the app happens through lock-free structures, and state the audio thread needs is prepared in advance by threads that are allowed to be slow.
Most application code is written as though waiting is free. On the audio thread it is the one thing you cannot do, and that inverts a lot of ordinary instincts.
Keeping picture locked to sound
Video is slaved to the audio clock rather than the other way around, because audio is the unforgiving one. A dropped video frame is a visual hiccup. A gap in audio is a click that ruins a take.
So the transport derives from where the audio engine actually is, and the video pipeline chases it. That ordering is the difference between a tool a composer trusts and one they stop using after a week.
A timeline that survives leaving the app
The edit model is backed by OTIO, an interchange format for timelines, so a project can round trip to other tools without being flattened into a rendered file.
This is a bet about how people actually work. Nobody uses one application for an entire project. A tool that cannot hand its work to the next tool becomes a dead end, no matter how good it is in isolation.
Why native, and why C++
Cross-platform frameworks are the right answer for most products and the wrong answer here. Real-time audio needs predictable latency and direct access to the platform’s audio stack, and layers of abstraction between you and the hardware are exactly what you cannot afford.
So it is C++ and JUCE for the audio side, with the platform’s own frameworks for video. Harder to write and the only way to hit the deadline reliably.
The honest status
This is a build in progress, not a shipped product, and the architecture and decision records are public in the repo. I am including it because the reasoning is the interesting part: it is the clearest example I have of designing around a constraint that cannot be negotiated with.

The problem it solves
A finished song is only half the job. What comes next is the cover art, the visualizer, the short-form clips, the press kit, the release page, and a plan to get all of it out on the same day. That mountain is where most songs quietly die, not because they were bad but because the artist ran out of energy before anyone heard them.
Rollout takes one finished track and builds the release kit in minutes, then hands back the controls so the artist can direct every piece until it sounds like them.

Why it is a systems problem, not a design problem

The interesting engineering here is not the generation. It is that this is a multi-tenant product where what you are allowed to do depends on what you pay, and that constraint touches everything.
Plan gating lives in the database. Entitlements are not a flag the client checks before showing a button, because a limit enforced in the client is not a limit, it is a suggestion. Consumption goes through security-definer functions that perform the check and the increment together, inside one statement, so the caller supplies no count and cannot reach the counter directly.

Doing the check and the increment in one database call is also what makes the limit correct under concurrency. A read-compare-write pattern in the client has a race between the read and the write, and two simultaneous requests can both see a count below the limit and both proceed.

One compositor, two consumers

Preview and export share a single rendering path. This sounds like an implementation detail and it is actually the whole product promise.

If preview and export are separate renderers, they drift. The artist directs something on screen, exports it, and gets a file that does not match what they approved. Once that happens the tool cannot be trusted, and an artist who cannot trust the output goes back to doing it by hand.

Sharing the compositor costs some flexibility and buys the guarantee that what you saw is what you get.

What the product actually is

Seven connected screens rather than a flat mockup. Import reads the key, BPM, and length off the track. Building shows the kit generating in real time. Ready hands over the finished set. The dashboard is a release command center with every asset, a readiness ring, and a distribution checklist across Spotify, Apple, TikTok, Instagram, and YouTube. Then the directable pieces: cover art, visualizer, and clips, each one steerable rather than take-it-or-leave-it.

What I took from building it

The parts users notice are the generated assets. The parts that decide whether the product works are the entitlement model and the shared render path, and neither is visible in a screenshot.

That is generally true of subscription software. The visible layer is the pitch, and the invisible layer is whether it survives real usage.

Th3Circle is a real, live production platform I designed and built end to end. Creators sign up, build a fan portal, run campaigns, and take payments directly. It includes authentication, Stripe checkout and webhooks, Supabase (Postgres, RLS, real-time), serverless functions, and a full multi-page front end, all shipped and running in production with real users. This is my strongest anchor: a complete product, not a concept.
https://www.twine.net/signin