If you grew up watching South Park, you probably remember the Season 4 episode where Cartman acquires the ultimate playground flex: the Dawson’s Creek Trapper Keeper Ultra Keeper Futura S 2000. It doesn’t just hold notebook paper—it has a TV, voice recognition, and an alarming ability to hybridize with other electronics.
It starts by absorbing Cartman’s computer. Then, it absorbs his bedroom electronics. Eventually, it absorbs Cartman himself, transforming into a massive, biomechanical, Akira-style blob bent on assimilating a top-secret military base at Cheyenne Mountain. As it lumbers forward, consuming everything in its path, it intones its new terrifying reality:
Welcome to the era of the Trapper Keeper IDE. Welcome to “vibe coding.”
What is “Vibe Coding”?
Coined by AI researcher Andrej Karpathy in early 2025, vibe coding describes a radical shift in how software is built.Instead of writing code line-by-line, developers write natural language prompts—the “vibes”—and allow a Large Language Model (LLM) to generate the source code, debug it, and stitch the application together.
In this paradigm, the developer’s role shifts from a syntax-typist to a high-level creative director. You don’t write the loops; you guide, test, and refine the AI’s output through a conversational loop. You simply declare what you want to exist, and the machine handles the messy implementation details.
It sounds like a utopia. But look closely at the tooling, and you’ll see the Trapper Keeper absorbing its environment.
The Stages of Assimilation
The transition from manual coding to the AI singularity didn’t happen overnight. It happened exactly how Cartman’s binder took over his life: step by step.
Stage 1: The Pencil Case (Autocomplete). It started innocently enough with tools like GitHub Copilot. The AI was just a helpful assistant leaning over your shoulder, finishing your lines, and writing your boilerplate. It was a smart pencil.
Stage 2: The Desktop (The AI-Native IDE). Then came Cursor, Windsurf, and Bolt.new. The AI stopped being a plugin and absorbed the entire text editor. Suddenly, it wasn’t just completing lines; it was reading your entire codebase, juggling dozens of files, and understanding your workspace memory.
Stage 3: Cartman Himself (Vibe Coding). This is where we are today. The AI has absorbed the programmer’s core function: writing logic. By embracing vibe coding, the developer surrenders the keyboard to the machine. We are no longer the builders; we are the intent-providers attached to a massive, code-generating engine.
The Omnivorous Future
Where does the assimilation stop? It doesn’t.
We are already seeing autonomous agents (like Devin) attempting to absorb the terminal, the testing suite, and the CI/CD pipeline. Soon, the AI will absorb the issue tracker, reading bug reports from users and deploying fixes before a human even pours their morning coffee. The boundary between the developer, the code editor, and the deployment infrastructure is entirely dissolving.
When the AI writes the code, tests the code, and deploys the code, the human is no longer the engineer. The human is just the biological prompt-interface.
Should We Send a Time-Traveling Robot?
In South Park, a cyborg from the future (disguised as Bill Cosby) is sent back in time to destroy the Trapper Keeper before it can wipe out humanity. Do we need to smash our AI-native IDEs before they replace us entirely?
Probably not. While the transition is dizzying, vibe coding democratizes software creation, allowing rapid prototyping and breaking down the barriers of arcane syntax. It elevates the developer from a bricklayer to an architect.
But we have to accept that the old way of building software—crafting artisanal, hand-typed functions in a siloed text editor—is being consumed. The tools have hybridized. The developer and the AI are merging into a single, intent-driven organism.
We don’t write code anymore. We just command the blob.
Two small CLI tools that pull your Liked Songs, your playlists, and your YouTube rips out of the cloud and onto a drive you actually control.
Stack Python 3.10+Depends on spotipy · spotdl · youtube-dl · ffmpegLicense surface your own library
Every streaming library is a loan. The playlist you spent three years curating, the “Liked Songs” pile that’s basically a diary — none of it is a file you hold. A label dispute, a market exit, a quietly revoked license, and a chunk of it is just gone. Spotster is the fix: point it at your Spotify account or a YouTube playlist, and it writes real MP3s to a real folder, organized the way a record collection is organized — by artist.
A CSV IS A RECEIPT. IT TELLS YOU EXACTLY WHAT YOU OWNED, EVEN AFTER THE FILE IS GONE.— why export comes before download
WHAT’S IN THE REPO
Spotster is two independent tools sharing one dependency list. Neither needs the other to run.
export_library.py → download.py
Authenticates against the Spotify Web API, paginates through every Liked Song and every playlist you own or follow, and writes it all to one flat CSV. A second script reads that CSV and hands the track URLs to spotdl, which resolves each one, downloads the audio, and tags it.
Hands one or more playlist URLs to youtube-dl with --ignore-errors, so one region-locked or deleted video doesn’t kill a 300-track playlist. Swap in yt-dlp with a single flag when upstream inevitably lags YouTube again.
download_youtube_playlist.py
THE SPOTIFY SIDE, STEP BY STEP
First, the export. This talks to Spotify only — no audio touched yet, just metadata:
spotster — export_library.py
$ python export_library.py -o spotify_library.csv
Fetching Liked Songs...
Fetching playlists...
fetching playlist: Basement Tapes
fetching playlist: Late Shift Only
Wrote 2,184 rows to spotify_library.csv
The CSV is the whole point. It’s diffable, greppable, and survives every future decision you make about where the audio actually lives:
SOURCE
TRACK_NAME
ARTISTS
ALBUM
DURATION_MS
ADDED_AT
Liked Songs
Sundown
Gordon Lightfoot
Sundown
212506
2019-03-11
Basement Tapes
Wish You Were Here
Pink Floyd
Wish You Were Here
334743
2021-07-02
Late Shift Only
Nightcall
Kavinsky
OutRun
256000
2022-11-19
Then the download. It reads that same CSV, dedupes the track URLs, and calls spotdl in batches of twenty so one broken match doesn’t stall the whole queue:
The output template does the filing for you — Music/{artist}/{title}.{output-ext} — so a library that was one long undifferentiated list in the app comes out the other side looking like a shelf.
SPOTIFY APILiked Songs + playlists
→
CSVone row per track
CSVspotify_library.csv
→
MUSIC/<ARTIST>/spotdl, batched
THE YOUTUBE SIDE
No API keys, no CSV — just a playlist URL and a folder. Point it at as many playlists as you want in one call:
spotster — download_youtube_playlist.py
$ python download_youtube_playlist.py "https://www.youtube.com/playlist?list=..." -o Music
Same idea as the Spotify side, one level less granular: since YouTube doesn’t tag an “artist” the way Spotify does, tracks land in Music/<uploader>/<title>.mp3 — the channel stands in for the artist folder.
GETTING IT RUNNING
Everything needs Python 3.10+ and ffmpeg on PATH — both downloaders shell out to it for transcoding.
setup
$ pip install -r requirements.txt
# spotipy, spotdl, youtube-dl
$ cp .env.example .env
# fill in SPOTIPY_CLIENT_ID / SPOTIPY_CLIENT_SECRET
# from a Spotify Developer Dashboard app
$ export $(grep -v '^#' .env | xargs)
The Spotify OAuth step opens a browser exactly once per machine; spotipy caches the token afterward, so re-runs of export_library.py don’t ask again.
WHY IT’S BUILT THIS WAY
The CSV is a checkpoint, not a formality. If spotdl falls behind Spotify’s API tomorrow, you still have a complete, portable record of what you owned — grep it, diff it, hand it to a different downloader entirely.
Batching over one giant call. Download requests fail one track at a time, not all at once — twenty per spotdl invocation keeps a single bad match from taking down a 2,000-track run.
youtube-dl today, yt-dlp tomorrow. The upstream youtube-dl project ages faster than YouTube changes its player. download_youtube_playlist.py --downloader yt-dlp is a one-flag swap to the actively maintained fork, same options, same output layout.
Two scripts, no framework. Nothing here needs a server, a database, or a config language. It’s argparse and subprocess — read it in five minutes, and it still works after you stop thinking about it.
I was eleven years old the first time I tried to build this game.
I don’t remember exactly what set it off. Probably some combination of Mortal Kombat at a friend’s house and a dinosaur phase I never fully grew out of. But I remember the idea landing fully formed, the way big dumb ideas do when you’re a kid and haven’t yet learned to talk yourself out of things. A fighting game, but everyone’s prehistoric. Cavemen with clubs. Velociraptors that fight like ninjas. A gorilla you could actually pick. And at the top of it, looming over the whole roster, a T. rex boss you weren’t supposed to be able to beat.
I was so sure of this idea that I did the only thing an eleven year old with no plan can do. I asked my parents to buy me a C++ book.
I want to be honest about how little this accomplished. I did not learn C++. I learned that a semicolon goes at the end of a line, and I learned that “Hello, World” is apparently the first thing every programmer in history has to type before they’re allowed to do anything else, and then I hit a wall made of pointers and header files and Visual Studio project settings I didn’t have the vocabulary to even ask questions about. There was no forum I knew to search. There was no tutorial calibrated to “kid who wants to skip straight to boss fights.” The book sat on my shelf being a monument to the gap between wanting to make something and knowing how, and eventually the dinosaur fighting game quietly stopped being a project and became one of those someday ideas. The kind you mention at parties as a fun fact about yourself and never actually revisit.
That gap, between the idea and the execution, is probably the single most common reason creative projects die. Not lack of imagination. Lack of the thousand boring technical skills standing between you and the thing in your head.
The gap closes
I’m not going to pretend the last twenty five years didn’t happen, or that I forgot about this idea and rediscovered it in some poetic way. It just sat there, occasionally resurfacing when I saw a good dinosaur documentary or played a fighting game with a particularly good roster screen. What changed is that the cost of closing that gap collapsed.
I built the whole thing, start to finish, playable in a browser, no installs, no build pipeline for the person playing it, for about twenty dollars in AI tokens, working with Claude. Twenty five years ago that number would have been “an entire computer science degree, or nothing.” Now it’s less than a used copy of the C++ book I bought as a kid.
I want to walk through what actually got built, because I think the interesting part isn’t “AI made a game.” It’s what it took to make this specific game. The actual design decisions, the actual engineering, because none of that went away just because the barrier to entry did.
What “prehistoric Mortal Kombat” actually requires
The one line pitch is easy. Making it hold together as a game is not, and this is where the eleven year old version of the idea and the real version diverge.
The roster had to make weight class sense. My original mental image had a T. rex just casually fighting a caveman, because I was eleven and hadn’t thought about it for more than four seconds. But if you actually sit with the idea, a T. rex versus a human isn’t a fight, it’s a paragraph in a nature documentary. So the roster got split by scale. Cavemen, velociraptors, and a sabertooth cat all sit in roughly the same size and speed class and can meaningfully fight each other. A gorilla and a terror bird slot in as heavier and lighter variants of that same tier. The T. rex sits alone, above everyone, as the final boss. Not a starter pick, something you unlock only after you’ve beaten the ladder. Getting that hierarchy right mattered more to the game feeling right than almost anything else I built.
Every character needed a genuinely different body. A fighting game roster is boring if everyone is the same skeleton in a different skin. So instead of one humanoid rig with reskins, I ended up with five distinct anatomies built from scratch. Bipedal humans, a gorilla frame with a heavier low center of gravity, raptors with tails and horizontal spines, a low quadruped cat build, a bird with wings that actually flap during jumps, and the oversized Rex rig built on its own proportions entirely. Each one needed its own procedural animation logic. A raptor’s tail has to counterbalance during a kick the way a human’s arms do, a bird’s wings need to drive the airborne pose instead of arms, a quadruped’s four legs need a completely different walk cycle than a biped’s two. None of that is copy paste. Every rig is its own small animation system.
The world had to sell “prehistoric,” not just state it. Street Fighter and Mortal Kombat live and die on their backgrounds, crowds reacting, environments that feel alive around the fight. So the four stages aren’t static art, they’re small simulations. A jungle canopy with eyes that blink and peer out at random intervals. An ice age tundra with mammoths actually walking a patrol path in the background and cavemen huddled at a fire that flickers with real light. A Jurassic valley with an active volcano breathing smoke and pterosaurs looping overhead. A firelit cave with hand drawn cave paintings on the walls and drummers keeping time. The crowd figures even get more excited, more arm waving, more jumping, when a fight is going well, tied to the same excitement variable that drives camera shake on a big hit.
It needed the moves that make a fighting game a fighting game. Not just punch and kick. Blocking with proper chip damage, hitstun, knockback that varies by move weight, combo detection and scoring, hitstop on impact so hits actually feel like they land, screen shake, a slow motion K.O. moment. Every character also got a signature special move that had to be hand designed around what that creature would actually do. A caveman throws a boulder, a raptor pounces, a dilophosaur spits venom, the gorilla slams the ground in a shockwave, the sabertooth lunges with its jaw, the terror bird lets out a sonic screech, and the Rex, appropriately, just stomps the entire arena.
None of this is exotic. This is the standard grammar of the genre. But it’s a lot of standard grammar, and it’s exactly the kind of thing that eleven year old me had no path toward learning fast enough to stay excited about the project.
Actually building it
The engineering choice underneath all of this was WebGL via Three.js, rendered at a deliberately low internal resolution and upscaled with nearest neighbor filtering. That’s the trick that gets you genuine chunky pixel, Sega Genesis era readability instead of the smooth shaded “3D blobs” look that so much amateur 3D falls into by default. Every character got a toon shaded material and a rendered outline pass so the sprites read cleanly against the busy backgrounds, the way 16 bit fighters always separated foreground from background at a glance.
Working with Claude on this wasn’t a matter of typing “make me a dinosaur fighting game” and getting something finished. It was closer to actual game development, just compressed. I’d describe what I wanted (arrow keys weren’t registering during character select, the sprites needed way more surface detail, two player mode needed to be ripped out entirely and replaced with proper single player systems), and we’d iterate against a real, running build. Difficulty tiers. A survival mode with escalating waves and a boss fight every fourth round. Score tracking with session bests. The kind of feature list that, as a kid, would have taken me years to work up the nerve to even attempt, because each one felt like its own multi week research project into a topic I didn’t have a name for yet.
The honest version of what changed between 1999 me and now isn’t that AI writes perfect code on the first try. It’s that the distance between having an idea and being able to test whether the idea works went from “learn a systems programming language over several years” to “describe it and see it running in the same conversation.” That distance is where almost every unfinished creative project in the world dies. Closing it doesn’t remove the craft. The weight classes, the animation rigs, the special move design all still had to be decided, and decided well, by a person who cared about getting them right. It just means the decisions get to matter more than the yak shaving required to test them.
The kid with the C++ book
I don’t think I’m owed anything for having had this idea at eleven and not being able to build it. That’s just what being eleven is. But there’s something satisfying about closing the loop, about the same dumb good idea surviving a quarter century of “someday” and finally becoming a thing you can actually open in a browser tab and play.
If you had a version of this, a project that was too big for the tools you had access to when you first wanted to build it, it might be worth going back to it. The tools changed a lot more than the idea needed to.
The game itself is called Paleo Fury. Cavemen, raptors, a silverback, a sabertooth, a terror bird, and a T. rex who is absolutely going to end your run the first time you meet him. Exactly the roster an eleven year old would have drawn on the inside cover of that C++ book, if he’d had any idea what he was looking at.
If Professor John Keating from Dead Poets Society inspired students to challenge traditional education, Rushmore asks a modern question:
What if anyone could become a teacher?
Rushmore is an AI-powered course creation platform designed to help people transform ideas into complete educational experiences.
Instead of spending weeks creating lesson plans, gathering resources, designing materials, and formatting content, users can simply describe what they want to teach.
The AI builds the foundation.
The creator becomes the teacher.
The Magic Schoolbus for Modern Learning
Traditional course creation is difficult.
A creator needs to:
Choose a curriculum structure
Write lessons
Create supporting materials
Design presentations
Produce videos
Organize a learning experience
Rushmore compresses that process.
Users can enter:
A course title
Optional subtopics
The number of topics they want generated
The desired course format
The platform then creates an AI-generated curriculum.
The result is a personalized learning experience generated from a simple idea.
From Idea to Complete Course
Rushmore supports multiple types of AI-generated courses.
Video and Theory Courses
For creators who want richer learning experiences, Rushmore can generate courses combining:
Educational concepts
Structured lessons
Video-based content
Image and Theory Courses
For visual learners, courses can include:
Generated educational content
Supporting imagery
Written explanations
The goal is flexibility.
Different subjects require different teaching styles.
AI as the Teaching Assistant
Creating content is only part of education.
Students also need support while learning.
Rushmore includes an AI chatbot that allows learners to:
Ask questions
Clarify concepts
Explore topics further
Instead of waiting for an instructor response, students have an always-available learning assistant.
The platform transforms AI from a content generator into an interactive educational companion.
A Complete SaaS Platform
What makes Rushmore interesting is that it is not just an AI demo.
It is structured as a real software business.
The platform includes:
User Accounts
Users can:
Register with email
Sign in with Google
Sign in with Facebook
Recover forgotten passwords
Manage profiles
Course Management
Creators can:
Generate courses
Browse created courses
Download course materials
Track completed learning
Certificates
Learning platforms need proof of achievement.
Rushmore includes:
Course completion certificates
Downloadable certificates
Email delivery
This turns generated content into a structured educational product.
Building the Business Layer
Many AI projects stop at generation.
Rushmore goes further by implementing the systems required for a commercial SaaS product.
The platform includes:
Subscription tiers
Recurring billing
Payment processing
Receipts
Account management
Supported payment systems include:
Stripe
PayPal
Paystack
Flutterwave
Razorpay
This makes Rushmore capable of supporting users across different regions and payment ecosystems.
The Admin Dashboard
Running a SaaS product requires visibility.
Rushmore includes an administrative dashboard where operators can monitor:
Total users
Course creation activity
Revenue
Paid subscriptions
Free users
Course types
Administrators can also manage:
Users
Courses
Admin accounts
Contact messages
Legal pages
The result is not just an application.
It is the foundation of an online education business.
The Future of Personalized Education
Education has historically been constrained by one major limitation:
A teacher can only create so much content.
AI changes that equation.
A single creator can now generate:
Specialized courses
Niche training programs
Personalized learning paths
Educational products for small audiences
The future classroom may not be one-size-fits-all.
It may be millions of personalized classrooms created by individuals.
From Student to Teacher
The most interesting idea behind Rushmore is not the AI itself.
The interesting idea is democratizing expertise.
Someone with knowledge of:
Programming
Cooking
History
Business
Crafts
Languages
Professional skills
can transform that knowledge into a structured course.
The barrier between knowing something and teaching something becomes much smaller.
Building the AI Creator Economy
Rushmore represents a larger shift happening across software:
AI is moving from being a feature to becoming a collaborator.
The next generation of SaaS applications will not simply store information or automate workflows.
They will help people create.
They will help people teach.
They will help people turn expertise into businesses.
Rushmore is an experiment in that future:
A platform where anyone can step onto the Magic Schoolbus and build the classroom they always wanted.
The teacher is no longer limited by time.
The curriculum is no longer limited by resources.
The classroom is wherever the learner happens to be.
Every organization faces the same cybersecurity challenge:
More vulnerabilities. More threats. More security tools. More data.
Yet many security teams still struggle with the fundamentals:
Where are our assets?
Which vulnerabilities actually matter?
What indicators of compromise are active?
How do we track incidents?
Who owns the response?
What happened and when?
ZEPSEC was built to explore a different approach:
A centralized security operations platform that brings threat intelligence, vulnerability management, incident response, and security knowledge together in one system.
A Security Command Center for Organizations
At its core, ZEPSEC is designed as a security management platform.
It helps organizations organize their security operations around the things that matter most:
People
Infrastructure
Threats
Vulnerabilities
Incidents
Knowledge
Instead of treating every security event as an isolated alert, ZEPSEC creates a connected picture of an organization’s security posture.
Managing the Security Organization
Security does not happen in a vacuum.
A mature security program requires understanding:
Which organization owns a system
Which users are responsible
Which agreements exist
Which teams need notifications
ZEPSEC includes organization and user management capabilities to help security teams maintain this operational context.
Incident Response and Investigation
When an incident occurs, speed and organization matter.
ZEPSEC provides incident tracking capabilities for documenting and managing security events.
Security teams can record:
Incident details
Related indicators of compromise
Investigation information
Response activities
The goal is to transform incident response from scattered notes and chat messages into a structured workflow.
Threat Intelligence and Indicators of Compromise
Modern security operations depend heavily on threat intelligence.
An Indicator of Compromise (IoC) can include:
Malicious IP addresses
Domains
Hashes
URLs
Other suspicious artifacts
ZEPSEC allows security professionals to:
Manually add IoCs during investigations
Enrich indicators automatically
Share IoC data through APIs
This creates a central intelligence layer that can feed other security tools.
Vulnerability Management With Context
A vulnerability database can contain thousands of issues.
The challenge is determining what actually matters.
ZEPSEC integrates vulnerability information from the National Vulnerability Database (NVD) and allows organizations to enrich vulnerabilities with custom attributes.
This enables teams to move beyond:
“A vulnerability exists.”
toward:
“This vulnerability affects this system, owned by this team, with this level of risk.”
Context is what turns vulnerability data into actionable security decisions.
Security Scanning Built In
Security visibility starts with knowing what is exposed.
ZEPSEC includes scanning capabilities:
Port scanning from ZEPSEC infrastructure
Remote agents for distributed environments
This allows organizations to identify services and infrastructure that may require attention.
For distributed companies, remote agents provide flexibility for scanning environments that are not directly accessible.
A Security Knowledge Base
Security teams accumulate valuable knowledge:
Investigation procedures
Internal standards
Incident lessons learned
Security guidance
ZEPSEC includes a centralized knowledge base to preserve that information.
A security program becomes stronger when knowledge survives beyond individual employees.
Automation Through Alerts and APIs
Security operations generate constant activity.
ZEPSEC includes automated notifications for:
New indicators of compromise
Vulnerability updates
Knowledge base changes
It also provides REST API integration, allowing security data to move into the broader security ecosystem.
The goal is not to replace every security tool.
The goal is to connect them.
The Open Source Security Model
One interesting aspect of ZEPSEC is its approach to distribution.
The open-source version provides a foundation for security professionals who want to explore and operate the platform themselves.
A commercial version can provide additional features, support, and enhancements.
This follows a proven open-source security model:
Community adoption
Professional usage
Enterprise support
Why Security Platforms Matter
Cybersecurity has traditionally been fragmented.
Organizations often deploy separate tools for:
Vulnerability scanning
Threat intelligence
Incident response
Asset tracking
Documentation
The result can be a collection of disconnected dashboards.
ZEPSEC explores a unified approach:
One place where security teams can understand their environment.
One place where incidents become knowledge.
One place where intelligence becomes action.
Building the Future of Security Operations
The future of cybersecurity is not just about detecting more threats.
It is about building systems that help humans make better decisions.
Security professionals need platforms that reduce noise, preserve knowledge, and connect information across the organization.
ZEPSEC represents that vision:
A security operations platform designed around the workflows that defenders actually need.
Because the best security tool is not the one with the most alerts.
It is the one that helps teams respond intelligently.
Clone it at https://github.com/peteralcock/ZEPSEC
Security teams don’t need more alerts. They need better systems.
Before every website depended on Google AdSense, before programmatic advertising became dominated by massive exchanges, publishers controlled their own advertising infrastructure.
They sold banner placements directly.
They managed campaigns.
They negotiated with advertisers.
They owned the relationship.
Aditube is an open-source experiment built around that idea:
What if anyone could clone a repository, install a web server, and run their own digital advertising platform?
Maybe they won’t make billions.
But now they have the tools.
The Personal Ad Network
Aditube is a self-hosted ad server designed for website owners, publishers, and media companies that want complete control over their advertising operations.
Instead of sending visitors through a third-party advertising network, publishers can run their own infrastructure:
Upload advertisements
Create campaigns
Sell inventory
Track impressions and clicks
Manage advertisers
Rotate banners automatically
The result is a miniature version of the advertising systems that power major publishing companies.
Built for the Independent Publisher
Aditube supports multiple use cases.
Website Owners
A single website owner can:
Add banner placements
Sell advertising directly
Manage campaigns
Replace external ad networks
For niche websites with dedicated audiences, direct advertising can often provide better relationships and more control than generic ad networks.
Publishers
Publishers operating multiple websites can manage:
Multiple domains
Multiple ad positions
Multiple advertisers
Campaign performance
Media Companies
Larger organizations can use Aditube as an internal advertising platform:
Webmasters configure available placements
Advertisers purchase campaigns
Administrators manage billing and inventory
Supporting Modern Advertising Formats
Although banner ads are one of the oldest forms of online advertising, Aditube was designed for modern web formats.
Supported creative types include:
GIF banners
JPG images
PNG images
HTML5 advertisements
External advertising scripts
HTML5 ads can be uploaded as ZIP packages containing:
HTML
CSS
JavaScript
Animations
Video content
This allows advertisers to create richer experiences than traditional static banners.
Automatic Banner Rotation
A core feature of any ad server is deciding what appears and when.
Aditube manages banner positions and automatically rotates campaigns.
Publishers can define:
Advertising locations
Available inventory
Multiple campaigns per position
The system handles delivery.
A website owner can create an advertising slot once and allow the platform to manage the rotation of campaigns over time.
Building a Marketplace for Advertising
Aditube goes beyond simple banner management.
It includes the foundation for a self-service advertising marketplace.
Advertisers can:
Create an account
Upload a banner
Select advertising placement
Set a budget
Purchase inventory
After payment, campaigns can automatically become active.
Brooklyn → Black Rock. 2,900 miles. Zero showers.
What happens when you take one of the most recognizable educational games of all time, replace covered wagons with a 1995 RV named Big Bertha, and send five friends across America toward Burning Man?
You get The Burner Trail — a full-stack Oregon Trail parody built for the modern desert pilgrim.
The original Oregon Trail asked players to survive a brutal journey westward through hunger, disease, bad decisions, and unpredictable weather. The Burner Trail keeps the same spirit of adventure and chaos, but swaps the frontier for a very different American migration: the annual pilgrimage from Brooklyn to Black Rock City.
The mission is simple:
Get five people, one aging RV, and enough supplies across 2,900 miles of highway before the playa market begins.
The reality is much harder.
Meet Big Bertha: Your 30-Year-Old Mechanical Liability
Every great road trip starts with a questionable vehicle.
In The Burner Trail, players take control of Big Bertha, a 1995 RV whose condition determines whether the journey becomes a triumphant arrival or a roadside disaster.
The RV has a condition meter that changes throughout the trip:
Push too hard and breakdown risks increase.
Ignore maintenance and repairs become inevitable.
Run the vehicle into the ground and you may face a $300 repair bill and a two-day delay.
The game turns the classic Oregon Trail resource-management formula into something instantly familiar to anyone who has ever attempted a cross-country adventure with unreliable transportation.
A Modern Oregon Trail Built for 2026
While The Burner Trail is a parody, it is also a serious technical project.
The game was built as a complete full-stack application:
Frontend:Â React 18 + Vite
Backend:Â Express
Database:Â SQLite with persistent Docker volumes
Infrastructure:Â Terraform deployments for DigitalOcean and AWS
Deployment:Â One-command cloud provisioning
A player can launch the game locally with Docker or deploy the entire application to the cloud with a single command.
The goal was not just to make a browser game, but to build a production-ready platform capable of supporting real players.
The Hall of Dust: Everyone Leaves a Mark
Death is inevitable on the trail.
But in The Burner Trail, your failure becomes part of the story.
When a player meets their fate, they can leave behind a tombstone — a digital epitaph that future travelers may discover along the route.
The game creates a shared history between players:
Your friends can discover where you failed.
Future travelers encounter your grave.
Every run contributes to the growing mythology of the trail.
The leaderboard, appropriately called the HALL OF DUST, ranks every journey and immediately tells players where they stand after completing a run.
Every Choice Has Consequences
Like the original Oregon Trail, success depends on managing limited resources.
Players must balance:
Water consumption
Cargo weight
RV condition
Weather patterns
Morale
Travel speed
Market timing
Even departure date matters.
Leave earlier and you have more schedule flexibility. Leave later and you risk more extreme conditions. The game forces players to make the same kind of uncomfortable tradeoffs that define real adventures.
The Fork in the Road
No road trip is complete without questionable navigation decisions.
At Chicago, players choose their route:
The classic I-80 path
A southern route through Denver and Moab
A northern shortcut with greater risk
Each route changes the landmarks, weather challenges, and encounters along the way.
The game transforms interstate geography into a strategic decision rather than a background map.
From Jersey to the Playa
The journey is not just about surviving the highway.
Along the way, players encounter:
Regional weather systems
Scavenge opportunities
Gift-economy caravans
Sound-camp defections
Supply shortages
Random events
The final destination introduces a six-day playa market where survival continues after arrival.
Even reaching Burning Man does not mean the challenge is over.
A Retro Experience With Modern Features
Visually, The Burner Trail embraces nostalgia.
The interface features:
CRT phosphor-inspired styling
Typewriter text effects
Canvas-based dust storms
Animated environmental effects
A shifting green-to-amber color palette as conditions deteriorate
But underneath the retro aesthetic is modern engineering.
Players can:
Save progress through email-linked magic links
Resume games across devices
Share scores socially
View rankings
Leave persistent messages for future travelers
A Small Game With a Real Product Mindset
One of the most interesting aspects of The Burner Trail is that it was designed not only as a game, but as a potential sustainable project.
Optional monetization features include:
Curated affiliate links for real camping gear
Contextual recommendations based on gameplay situations
A real-world packing list connected to in-game supplies
Analytics designed around anonymous usage patterns
The philosophy is simple: if a player runs out of water in the game, perhaps they are interested in learning about real-world water storage. If their RV breaks down, perhaps they need camping or repair equipment.
The commercial layer stays optional and secondary to the experience.
The Spirit of the Trail
At its core, The Burner Trail is about something bigger than parody.
It captures the absurdity of modern adventure:
Spending thousands of dollars to live without basic comforts for a week
Driving unreliable vehicles into remote deserts
Building elaborate temporary communities
Trading convenience for experience
The original Oregon Trail reflected the challenges of American expansion.
The Burner Trail reflects a different kind of migration — one where people leave cities behind, chase temporary communities, and willingly trade comfort for chaos.
The destination may be Black Rock.
But the real game has always been the journey.
Welcome to the trail. Pack water. Check Big Bertha. And try not to become another name in the Hall of Dust.
