I built an AI video clipping platform called ChatClipThat. You give it a Twitch VOD (sometimes 4+ hours long) and it finds the best moments, generates titles, adds karaoke-style animated captions, and renders them as vertical clips ready for TikTok (pending), Shorts, and Reels.
I'm actively developing and testing live clipping. While a stream is happening, it watches via a VLM every 30 seconds, moments in real time, and creates clips on the fly. If a streamer says "clip that," the audio trigger system catches it and clips the moment immediately.
There's a dense and multi-stage AI pipeline behind this. Parallel GPU rendering. A three-machine hybrid cluster. Stripe billing. A real-time video editor with face tracking, caption styling, and per-user brand templates.
I built this by myself.
Not because I'm some 10x engineer. I'm genuinely not. I don't have a CS degree. I have ADHD and a tendency to ship things before they're ready. The reason I could build something this complex alone is because of the platforms I chose to build on.
I want to talk about those platforms and tech. The supporting pillars. Because your stack choices aren't just technical decisions. They're velocity multipliers or velocity killers. And for me, the biggest multiplier by far has been Xano.
Pillar 1: Xano — The Governance Layer
Every complex system needs governance. Not bureaucracy. Governance. Something that decides who can do what, tracks the state of everything, enforces the rules, and gives every part of the system a shared understanding of reality. In a traditional setup, this means standing up a database, writing an ORM layer, building REST endpoints, implementing auth, designing migrations, and maintaining all of it.
I didn't do any of that. I use Xano.
Xano is my governance layer. It gives me a visual database, server-side logic (XanoScript), instant REST APIs with input validation and Swagger docs, and built-in JWT authentication. But calling it a "backend" undersells what it actually does in a system like mine. It's the thing that keeps a distributed, multi-machine AI platform organized.
When my CPU analysis node finishes processing a VOD, it doesn't write to a local database. It POSTs the results to Xano. When my GPU render node finishes a clip, it PATCHes the clip record in Xano with the output URL. When the live monitoring engine deducts a credit every 60 seconds, it calls a Xano endpoint. When the frontend needs to show a user their jobs, templates, or clips — Xano.
Every machine in my cluster talks to the same Xano instance. That means every machine is stateless. If one crashes, the state is safe. If I need to scale a node, I just point the new one at the same API. The workers don't know about each other. They only know about Xano.
This is a legitimate distributed systems pattern (centralized state with stateless workers) and I implemented it without writing a single line of backend infrastructure code. I just designed my tables, wrote the logic in XanoScript, and every node talks to the resulting API.
The result is that I have 15+ database tables, multiple API groups, and full authentication powering a production SaaS.
Pillar 2: GCP — The Muscle
Google Cloud gives me the compute I can't run locally. An e2-standard-4 CPU instance handles the heavy AI analysis. An NVIDIA L4 GPU instance handles video rendering with hardware acceleration. Google Cloud Storage holds every VOD, metadata, artifact, and rendered clip.
The key decision was splitting the work across purpose-built machines. Analysis requires CPU and memory. Rendering requires a GPU. The VPS handles web traffic. Each node does one thing well and talks to Xano for coordination.
I spent a lot of time fighting GCP — zone resource exhaustion, disk space problems, firewall misconfigurations, IAP tunnel race conditions. But the underlying model works: cheap CPU for analysis, expensive GPU on-demand for rendering, and Xano as the coordinator between them.
Pillar 3: The AI Layer
The AI models are the product. They're what actually watches the video, understands what's happening, and decides what's worth clipping. I won't go deep on the specifics here, but the pipeline uses a combination of vision models, transcription, and audio analysis to find moments worth sharing.
The important thing in the context of this article isn't how the AI works. It's that AI outputs are useless without infrastructure to organize them. A model can tell you "something interesting happened at 47 minutes." Cool. Now where does that data go? How does the editor access it? How does the renderer know what to render? That's where the other pillars come in.
Pillar 4: The Vibe Coding Philosophy
This is the meta-pillar. The reason any of this works is because I optimized for speed of iteration, not perfection of architecture.
I use FastAPI with Jinja2 server-side rendering instead of a React frontend because I can ship a page in 20 minutes. I use Alpine.js for reactivity because it's 15 lines of JavaScript instead of a component tree. I use vanilla CSS where I need control and Tailwind where I need speed.
The pipeline is modular. Every stage is a Python class with name() and run(ctx).
If a stage breaks, I replace it. If I want to test a new ranking algorithm, I swap one class. The architecture isn't elegant. It's fast to change.
And this philosophy extends to the backend choice. Xano lets me iterate on data models without writing migration scripts. If I need a new field on the jobs table, I add it in the visual editor and it's immediately available in the API. If I need a new endpoint, I build the XanoScript function, click publish, and it's live. I haven't even mentioned the GitHub and CI/CD pipeline, but Xano has also allowed me to test in isolated environments and push to prod when my tests pass.
When you're building alone, the speed at which you can react to what the product needs is everything. The pillars I chose aren't the "best" in any objective sense. They're the ones that let me move the fastest while maintaining enough structure to not collapse.
The Honest Part
I work at Xano. I do education and developer advocacy. So no, I'm not an unbiased source.
But I chose Xano for ChatClipThat because I already knew the platform inside and out... and I knew it could handle what I was building. The advocacy is easy when the thing you're advocating for is the same thing you'd pick anyway.
The "governance layer" framing isn't a solo dev thing. It's an architecture thing. Enterprise teams use Xano to centralize their backend logic and data governance across services. Indie devs use it to ship without building infrastructure from scratch. The use case scales. The platform is the same.
Pick platforms that let you focus on the thing only you can build. For me, that's the AI pipeline. Everything else is a pillar.
Top comments (0)