Few weeks ago, I had a problem. I would read interesting articles online, save the URLs in various places—browser bookmarks, notes apps, random text files—and then never find them again when I actually needed them. I wanted a personal library where I could save articles, search through them, and keep them organized with highlights and notes.

So I decided to build it myself.

The catch? I’m not a professional software developer. But I had access to AI-assisted coding tools like Claude Code and Cursor, and I was curious to see what was possible in this new era of “vibe coding”—where clear communication matters more than memorizing syntax.

Three weeks later, ReadRecall is live at readrecall.com.

What ReadRecall Does

ReadRecall is a read-it-later application that goes beyond simple bookmarking. When you save an article URL, the app automatically scrapes the webpage and extracts key metadata: the title, author, publication date, featured image, and full article text. Everything becomes searchable. You can add highlights to specific passages, leave notes, and build a personal knowledge base from the articles you actually care about.

It’s built on Next.js for the frontend and backend, PostgreSQL for the database, and deployed in Docker containers with SSL. The entire stack runs on a single Ubuntu server, accessible from any device with a web browser.

The Vibe Coding Experience

What surprised me most wasn’t that I could build this—it was how I built it. Instead of spending hours debugging syntax errors or hunting through Stack Overflow, I spent my time thinking about user experience, data architecture, and feature prioritization. The actual code implementation became almost secondary.

Here’s how the process typically worked: I would describe what I wanted in plain English, Claude Code would generate the implementation, and I would test it. If something didn’t work quite right, I would explain the issue or the desired behavior, and we would iterate. The feedback loop was fast, and I could stay focused on the product rather than getting lost in implementation details.

This doesn’t mean the code wrote itself. I still had to understand what was happening, make architectural decisions, and know enough to guide the AI toward better solutions. But the barrier shifted from “can I write this code?” to “do I know what I want to build?”

Challenges Along the Way

The project wasn’t without obstacles. The biggest technical challenge was mobile responsiveness—getting the interface to work smoothly across different screen sizes proved trickier than expected. It’s still the app’s weakest point and remains on my immediate roadmap.

Another unexpected hurdle was working with large CSS files. When Claude Code tried to rewrite the entire stylesheet at once, it would hit prompt length limits and fail midway through. The solution was learning to make targeted, specific edits rather than wholesale rewrites—breaking large files into smaller, more manageable modules.

Web scraping also had its moments. Different websites structure their content differently, so building a robust metadata extraction system that worked across various sources required multiple iterations and testing against real-world URLs.

The Technology Stack

The app is built with JavaScript and TypeScript on Next.js, which handles both the frontend React components and the backend API routes. PostgreSQL stores user accounts, saved articles, highlights, and notes. For deployment, everything runs in Docker containers on an Ubuntu server, with the frontend mapped to the domain and served over HTTPS.

The development environment used Docker Compose for local testing, which made it easy to spin up the entire stack—frontend, backend, and database—with a single command. This meant I could test features locally before deploying to production, catching issues early in the development cycle.

What This Means for Building Software

The experience fundamentally changed how I think about software development. The bottleneck isn’t coding anymore—it’s knowing what to build and why. AI tools handle the syntax, the boilerplate, and even much of the debugging. What remains is the creative work: understanding user needs, designing interactions, making architectural decisions, and knowing when something is good enough to ship.

This isn’t about replacing developers. Professional engineers with deep technical knowledge will always be essential for complex, large-scale systems. But it does mean the barrier to entry for building functional software has dropped dramatically. If you can articulate what you want clearly and understand your users’ needs, you can build real products.

Lessons Learned

Start small and iterate. I didn’t try to build every feature at once. I focused on the core functionality—saving articles and making them searchable—and then added features incrementally based on what felt most important.

Test continuously. Running the app locally throughout development meant I caught bugs early, before they compounded into bigger problems.

Be specific with AI. Vague prompts produce vague results. The more clearly I could describe what I wanted—including edge cases and error states—the better the output.

Ship imperfect products. ReadRecall isn’t perfect. Mobile responsiveness needs work. There are features I’d like to add. But it’s live, it’s functional, and people are using it. Perfect is the enemy of shipped.

What’s Next

The immediate priority is fixing mobile responsiveness so the app works smoothly on phones and tablets. After that, I’m considering a browser extension for one-click article saving, export functionality for users who want to back up their libraries, and possibly integration with note-taking tools like Notion or Obsidian.

But more than any specific feature, I’m interested in seeing how people actually use ReadRecall. Real user feedback will shape the roadmap far more than my initial assumptions.

Final Thoughts

Building ReadRecall taught me that we’re in a unique moment. The tools for creating software have become so accessible that the limiting factor is no longer technical skill—it’s vision and execution. If you’ve been sitting on a side project idea, waiting until you “learn to code properly,” this might be your sign to just start building.

The question isn’t whether you can code. The question is: what would you build if coding wasn’t the bottleneck?

For me, the answer was ReadRecall. And three weeks later, it exists.

You can try it at readrecall.com.