DEV Community: Neo Gamers

How I Built a Self-Learning YouTube AI on AWS Aurora (And Barely Survived the Weekend)

Neo Gamers — Sun, 28 Jun 2026 11:03:07 +0000

Eight months ago, I couldn't write a single line of code. I was just a guy in Tunisia trying to figure out how to make things work on the web, tinkering with old Volkswagen engines—specifically trying to wrap my head around the suspension geometry of a Golf MK3 and the quirky reliability of Passat B6 diesels—and dreaming of building real software.

Fast forward to today, and I just shipped a self-learning vector database application on AWS for a massive international hackathon.

It feels like an absolute fever dream, but it's real. Here is the story of how Virantics came to be, the suspense of building it under severe time pressure, and why I decided to take on the "H0: Hack the Zero Stack" challenge.

The Catalyst and The Problem

If you've ever tried to run a YouTube channel—especially the automated or faceless kind—you know the pain. The algorithm is brutal. You spend hours strategizing, editing, and designing, only to realize that by the time you spot a video trend, the window of opportunity has already closed.

The usual AI tools out there just guess. They wrap a basic prompt around a language model and spit out generic, hallucinated ideas. I absolutely hate generic software. When I build my own micro-utilities, like the custom tools I host on Elevato, I build them to solve actual, specific problems. No fluff.

When I saw the announcement for the H0 hackathon, I knew I had to jump in. The premise was daunting but exactly what I was looking for: "Front-end in minutes. Back-end designed for scale". The rules required us to build a full-stack app that could realistically go to production, deploying the frontend on Vercel or v0, and strictly using designated AWS Databases.

I didn't want to build just another stateless wrapper for this event. I wanted a machine that gets smarter the more people use it.

The Blueprint

The concept: a suite of YouTube growth tools that self-learns using real-world performance data. I designed a three-layer memory system. The brain of the operation would be AWS Aurora Serverless PostgreSQL, utilizing the pgvector extension.

Instead of hallucinating trends, the database stores the top 30% of real YouTube winners as vector embeddings. Every single time a user runs a query, the system accumulates more evidence.

For the stack, I went with:

Frontend: Next.js hosted on Vercel, scaffolded rapidly with v0.
Backend: AWS Aurora Serverless PostgreSQL + pgvector.
AI Engine: Google Gemini 2.5 Flash.
Dev Environment: Kilo IDE. (My local machine recently ran out of disk space, forcing a quick pivot, but Kilo handled the heavy lifting flawlessly).

The Build (or, The Suspension Geometry of Software)

Building this felt a lot like diagnosing a mysterious rattle in a Golf MK6. You fix one thing, tighten a bolt, and suddenly another part starts shaking.

I started off strong using Vercel's v0 to scaffold the Next.js UI. Having an AI generate the React and Tailwind boilerplate felt like having a superpower. I had the skeleton of the Virantics dashboard up in no time, matching the dark, sleek aesthetic I envisioned.

But then came the backend integration. Setting up AWS OIDC Federation with Vercel IAM roles is a brilliant way to handle security without hardcoding long-lived secrets, but getting the permissions perfectly aligned took some serious, head-scratching debugging.

The real boss fight, however, was architecting the pgvector implementation on Aurora. I had to ensure that when the Idea Brainstormer feature fired up, it wasn't just doing a basic keyword search. It needed to execute an actual semantic similarity search against proven winning patterns in specific niches.

The Midnight Crisis

There was a tense moment late Saturday night. The Tunisian summer heat was creeping in, the coffee was running dangerously low, and staring at my Kilo IDE screen, I realized the API route for the Title Engine kept timing out. This engine is supposed to produce title variations tagged with psychological triggers (like Curiosity or FOMO) and account for recency decay. But it was just spinning into the void.

After digging through the logs, I realized my database query was scanning sequentially instead of using the index I thought I had built. Fixing that was the software equivalent of finally getting a rusted control arm bolt loose. I restructured the query, rebuilt the index, and held my breath.

I hit the endpoint again.

Everything just clicked. The latency dropped from a terrifying 30 seconds to absolute milliseconds. The data flowed perfectly into the UI.

The Final Polish

With the database humming, I wired up the remaining features:

Channel DNA: Drops in a channel URL and builds a customized playbook based on the creator's actual historical data.
Thumbnail Blueprint: Uses Gemini's vision analysis to dissect top-performing thumbnails and output a structural checklist.
Trends Explorer: The crown jewel. A dashboard compiled entirely from the accumulated database insights—showing rising audience demands pulled directly from comment sentiment analysis.

To make sure the project was actually discoverable and had a solid SEO foundation—something I learned the hard way when migrating my other projects to Next.js—I polished the metadata and routing structure.

The Finish Line

Submitting the demo video was the final hurdle before collapsing. Going from absolute zero coding knowledge to configuring serverless vector databases on AWS in less than a year is a journey I wouldn't trade for anything. It is exhausting, it is messy, but seeing a complex, multi-layered system work flawlessly is the greatest feeling in the world.

If you are a developer on the fence about jumping into a hackathon, just do it. You will learn more in a weekend of sheer panic and problem-solving than you will in three months of passive tutorials.

Check out the live app, throw some channels at it, and let me know what you think!

Try Virantics Here

H0Hackathon

I had a tech background but couldn't build from scratch. AI changed that. Here's the full story.

Neo Gamers — Fri, 05 Jun 2026 08:39:32 +0000

Let me give you the honest version of where I was starting from.

I'm not someone who had zero tech knowledge. I've been around websites for years — buying PHP scripts from CodeCanyon, customising them, setting up hosting, dealing with cPanel, figuring out why some plugin broke everything. I knew enough to be dangerous but not enough to actually build something the way I wanted it.

That gap always frustrated me. I had ideas. I knew what good looked like. But the moment I needed something that didn't exist as a ready-made script, I was stuck. I'd either pay someone to build it, water down the idea to fit what I could find, or just drop it.

I'm in my 40s. That pattern had been going on for a while.

About a year ago I decided to actually close that gap. Not by taking a course or getting a degree — just by building the thing I wanted to build and figuring it out as I went.

Today that site is live at elevato.pro. It has 13 working AI tools, real traffic coming from Google, and I wrote every line of it myself. No CodeCanyon. No template. Built from scratch, exactly the way I wanted it.

This is how that happened.

The difference between customising and building

If you've spent time with CodeCanyon scripts you know the drill. You buy something that's 80% of what you need, you spend a week bending it to fit your idea, and you end up with something that works but never quite feels right. The underlying structure isn't yours so you're always working around it instead of with it.

I wanted to build an AI tools website — image describers, prompt generators, text extractors, that kind of stuff. Clean, free, no ads, no signup walls. I looked for a script I could buy and customise. Nothing close enough existed.

So for the first time I had to actually build it.

I already understood the web well enough — HTTP, how APIs work roughly, what a database is for, the difference between client and server in general terms. What I didn't have was the ability to sit down and write the code myself. That's the piece AI filled in.

The stack

I'll be specific because vague stack recommendations are useless.

Next.js

The whole site runs on this. If you've been in the CodeCanyon world you're probably used to PHP doing everything on the server. Next.js is a different mental model — React on the frontend, API routes on the backend, file-based routing, and it all deploys as one thing.

The part that took me longest to get comfortable with was the App Router — specifically understanding which components run on the server and which run in the browser, and why that matters. Coming from a PHP background where the server just builds the page and sends it, the React mental model of components re-rendering in the browser felt weird at first.

I broke things a lot in the beginning. That's fine. You learn the rules faster by breaking them than by reading about them.

Supabase

I needed a proper database. I'd worked with MySQL through phpMyAdmin before so I wasn't starting from zero, but setting up a database server from scratch, managing connections, handling auth — that was all new territory.

Supabase made this genuinely easy. It's Postgres under the hood, the dashboard is clean, and the connection to Next.js is straightforward. I had it working in an afternoon. The row-level security took me a bit longer to wrap my head around but once I understood it I actually appreciated how clean the approach is.

Vercel

Deployment. This is the part that used to mean buying a VPS, SSHing in, setting up Nginx, hoping nothing breaks at 2am.

Vercel is just a GitHub push. You connect your repo, it builds automatically, it's live. Preview deployments for every branch. Rollback with one click. I don't miss managing servers at all.

OpenRouter

This one deserves more attention than it gets.

OpenRouter is a single API that connects to dozens of AI models — OpenAI, Anthropic, Google, Mistral, a hundred others. Instead of managing separate accounts and API keys and billing for each provider, you go through one place.

The reason this matters for a site like mine: different tools need different models. Some tasks are simple enough that a cheap, fast model handles them perfectly. Others need something more capable. With OpenRouter you pick the right tool for each job and you only pay for what you actually use.

My running costs for the whole site are low enough that I'm comfortable keeping everything free for users. That was the goal from the start.

How I actually used AI to build this

Having a tech background meant I could have a real conversation with AI about what I was building. I wasn't starting from "what is a variable." I was starting from "I know what I want this API route to do, help me write it in TypeScript."

That context made a big difference. But I still had to develop a way of working that actually taught me things rather than just producing code I didn't understand.

The thing that helped most: I stopped asking AI to fix things and started asking it to explain things first.

When something broke, instead of pasting the error and saying "fix this," I started saying "explain what this error means and why it's happening." Then once I understood the problem I'd ask how to solve it. Slower in the moment, but I stopped seeing the same errors repeatedly.

The other thing: when I got code I didn't fully follow, I'd ask it to walk me through it. Not line by line every time, but at least the parts that felt like black boxes. Coming from a background of buying other people's code I was used to not understanding what was inside things. Building my own meant I actually wanted to know.

The conversations that taught me the most weren't the short ones. They were the ones where I kept pushing — "why did you structure it that way," "what would break if I changed this," "is there a simpler version." That back and forth is where most of the real learning happened.

The mistakes

I over-engineered the first version.

Having just enough knowledge to know what good architecture looks like is dangerous. I spent time setting up things "properly" before I had anything working. A clean folder structure means nothing if the product isn't shipped. I should have gotten something live faster and cleaned up later.

I built features nobody asked for.

I spent a week on a feature that let users save their tool outputs. Thought it was a smart addition. Nobody uses it. I should have shipped two more tools instead. Build what people actually need, not what seems clever at the time.

I ignored SEO for too long.

I came from a background of customising sites that already had traffic baked in from the marketplace. Building from scratch meant I had to earn that traffic myself and I underestimated how much work goes into it. Six months in I had a working site with barely any visitors because I hadn't thought seriously about what people were searching for. Had to go back and redo a lot of the content and structure.

I kept wanting to rewrite things.

Every time I learned something new I'd look at old code and want to rebuild it the right way. I had to force myself to stop. The site works. Users don't care about the code quality. Ship and improve forward, don't rebuild backward.

What I actually built

Elevato is a collection of free AI tools — describe an image, extract text from a photo, generate prompts for Midjourney or Flux, translate prompts, remove image backgrounds, summarise YouTube videos, write and edit content. Everything is free, no account needed.

It's not the most sophisticated codebase in the world and I know it. But it's mine, it does exactly what I wanted it to do, and building it from scratch rather than bending someone else's script to fit — that part still feels good every time I think about it.

What I'd tell someone in the same position

The CodeCanyon mindset is a ceiling. There's nothing wrong with using ready-made solutions when they fit. But if you've been doing that for years and you have ideas that don't fit any script you can find, it's worth pushing past it. The gap between "can customise" and "can build" is smaller than it used to be.

Next.js + Supabase + Vercel is a solid stack for this. Good documentation, big community, and AI assistance works well with all three because there's so much training data on them. If you're coming from a PHP background expect the mental model shift to take a few weeks. It's worth it.

OpenRouter is underrated. If you're building anything with AI and you care about costs, go look at it before you commit to a single provider.

Use AI as a colleague, not a code dispenser. The difference in what you actually learn is significant. Ask why, not just how.

Ship earlier than feels comfortable. Coming from a world where you could preview a CodeCanyon demo before buying, it's tempting to want your own thing polished before anyone sees it. Resist that. Real feedback from real users is worth more than another week of tweaking in private.

Last thing

I still wouldn't call myself a developer in the professional sense. People who do this for a living and have done it for years are operating at a different level and I respect that.

But I build things now. Things I designed, things that work the way I wanted them to, things that exist because I made them rather than because I found them on a marketplace.

For me, after years of hitting that ceiling, that's the whole thing.