From Idea to Product in 12 Days with Rails 8

A lot of people are vibe-coding their way to custom apps these days. If you take a few extra steps, it’s actually quite easy to turn a personal solution into a software product available to everyone.

Rails 8 is uniquely suited for this. Rails is “designed for people who love syntactic sugar, and LLMs are sugar fiends” (Garry Tan), and recent versions have increasingly embraced the idea of a “one-person framework” (DHH), with Rails 8 making that direction even more explicit. I recently built a web app with Rails in just 12 days, and I found this framework incredibly powerful for quickly turning an idea into a product, especially in the AI era.

Here is the breakdown of how I built it.

My Idea: An Algorithm-Free YouTube Viewer

The Problem

YouTube is full of “algorithm traps”. I generally want to spend as little time on the platform as possible, even though there is a lot of useful content I want to consume for learning. Existing RSS readers don’t solve this because they aren’t designed to queue up and consume video, so the viewing experience is usually poor. You could use YouTube’s “Watch Later” list, but that experience is also lacking. Videos you’ve watched aren’t automatically removed, and because the list lives on YouTube, you’re constantly exposed to the algorithm.

The Solution

I wanted a dedicated YouTube RSS reader and viewer with a proper watch list. I had been using a standard RSS service, but the experience of managing and consuming video was frustrating for the reasons mentioned above.

There are so many useful videos posted every day. I wanted to efficiently decide what to watch (and what not to), and when I do watch, I want to be completely isolated from the algorithmic swamp.

IDWIW (I Decide What I Watch) is what I came up with and built: https://get.idwiw.app

IDWIW: An algorithm-free YouTube viewer

12 Days to Release

I’d been thinking about the idea for a while, so the rough design was already in my head. I found some focused time in February and started building.

From the start, I used Claude Code and Codex. I didn’t actually write any code myself. I only acted as the reviewer. I also used Gemini to draft the product overview and the high-level technical design. It took exactly 12 days to release, following this timeline:

1. Project Setup & Infrastructure (CI/CD) — 2 days
2. Auth & Core Features — 2 days
3. Free/Pro Tiers & Pro Features — 3 days
4. UX Refinements & Onboarding — 2 days
5. Mobile UI, Security Hardening & Final Polishing — 3 days

1. Project Setup & Infrastructure (CI/CD) — 2 days

I focused on creating instructions for the AI agents and building the CI/CD pipelines first. If these are well-structured, agents can easily understand the project “rules”, which boosts productivity.

When starting a new project, initial data modeling, coding standards, and test structures (unit and system) should be carefully reviewed. These are the “seeds” for all future code generation. How you prepare this stage significantly affects the long-term maintainability of the product. By the end of Day 2, I had a hello-world Rails app running on Hetzner with Litestream backups, deployed via Kamal and GitHub Actions.

2. Auth & Core Features — 2 days

The app only supports Google Login. This makes sense, as potential users are YouTube users who already have a Google account. Finishing the core features, including the feed, watch list, and channel management, was incredibly fast. At this point, the app was already solving my personal problem.

3. Free/Pro Tiers & Pro Features — 3 days

To test the market and leave room for future monetization, I introduced Free and Pro tiers. I added “Pro” features like AI overviews, priority queues, and an “auto-mark as watched” function.

I also worked on the logo design during this phase. I used AI to generate the initial concept, but I ended up using Gimp to manually adjust and polish the final version to get it exactly right.

4. UX Refinements & Onboarding — 2 days

The product was 80% ready, but as they say, the last 20% of the work takes 80% of the time. I focused on search functionality, the onboarding flow, and refining the navigation layout.

5. Mobile UI, Security hardening & Final Polishing — 3 days

I enhanced the mobile usability, did a deep security review of the code, and polished the design. Finally, I opened up sign-ups to the public! 🎉

Handwritten notes worked well for giving UI change requests to agents.

Note on the Landing Page:

While working on steps 3–5, I was concurrently building the landing page, hosted on AWS S3 and CloudFront.

Tech Stack

I stuck closely to the “Rails Way” for Rails 8:

• FE: Rails (Hotwire)
• BE: Rails + Solid Queue (for background jobs)
• Database: SQLite
• Server: Hetzner
• Monitoring/Alerts: Netdata, Honeybadger, Telegram
• CI/CD: GitHub Actions

The Myth: “SQLite isn’t for production”

I used to be a skeptic because of the widely held belief that SQLite’s biggest bottleneck, supporting only linear writes, makes it unsuitable for web applications. However, the Rails World 2024 talk “Supercharge the One Person Framework with SQLite: Rails World 2024”, convinced me to go all-in on a production SQLite setup with Litestream backups.

Unless you are ingesting a lot of data, and by “a lot” I mean on the order of 50,000 writes per second, I promise you that this aspect of SQLite’s architecture will not have a meaningful impact on your application.

Since most newly launched apps will never come close to 50,000 writes per second, starting with SQLite makes perfect sense. It follows the YAGNI (You Ain’t Gonna Need It) principle — saving you time, money, and complexity. If the app ever scales to the point where SQLite actually hits its limit, migrating to a database like Postgres is a well-documented and straightforward process.

Running Cost (USD)

• Domain (GoDaddy): $2.9 per month ($34 per year)
• Server (Hetzner CX23): $4.2 per month (incl. 20% backup charge)
• Litestream backups (Cloudflare R2): $0 (under 10GB)
• Error alert (Honeybadger): $0
• CI/CD (GitHub Actions): $1–$5 per month (usage-based)
• Landing Page (AWS S3 + CloudFront): Less than $1 per month

Total: around $10 per month (or less than that)

I chose the Hetzner CX23 for its affordability. However, Hetzner’s Object Storage pricing turns out to be quite expensive for a project this size; with a base cost of around $7 per month, it felt disproportionate for IDWIW. Instead, I went with Cloudflare R2, which offers a generous 10 GB free tier.

Room for Improvement

I’m looking into ways to further optimize the AI development setup:

• Holdout Test Sets: Moving scenario tests to a separate repo that coding agents cannot access (inspired by StrongDM’s AI team setup). This mimics an external QA team.
• Automation: Automating prompts via project management tool integrations.
• Auto-Review: Using agents to review PRs and having the author agent automatically address comments.
• Mobile Interaction: I’d love to be able to request small fixes via Telegram from my phone.

Final Thoughts

Thanks to AI agents, the effort required to build a new app has fallen significantly. Anyone can vibe-code their way to an app, and with just a few extra steps (and about $10 a month), you can make it available to the world.

Rails makes this even easier thanks to its out-of-the-box setup with Kamal and SQLite, plus the massive amount of great documentation and examples that AI agents can reference online.

Some people are already using IDWIW, and I’m really happy about that. I love building things and seeing others use what I’ve created. At the end of the day, it doesn’t matter to me whether I personally wrote every line of code or not. I just want to keep building things that people find useful.