From Side Projects to Real Products: What Successful Vibe‑Coded Apps Actually Look Like
Vibe coding started as a meme: “describe what you want, let the AI write the code.” But 2025’s reality is more interesting—people are quietly shipping real products, from internal tools to Chrome extensions and SaaS apps, with LLMs doing most of the typing. This article walks through concrete examples (including Linqlist and QuickReply), why they work, and how you can follow a similar path.
What “Vibe Coding” Really Means Today
At this point, vibe coding has a fairly consistent meaning in the dev world. It’s not “press button, app appears.” It’s a workflow where:
- You write specs, docs, and acceptance criteria, then ask an LLM to implement features, fix bugs, and refactor code.
- The model writes most of the implementation, while you focus on system design, invariants, and tests.
- You iterate in small, thin slices—“one change at a time”—instead of dumping the entire app request into a single prompt.
Karpathy’s original framing was “forget that the code even exists,” but engineers shipping production products emphasize that they still review code, enforce tests, and keep “project truth” in living documents the AI must obey. In other words, AI is a very fast junior developer, not a replacement tech lead.
Example #1: Tangents – 120k Lines of AI‑Written Code
One of the clearest success stories comes from the Ask HN thread itself. A builder describes Tangents, an Angular/Nest/Postgres app for “thinking with LLMs without losing the thread.”
What makes it notable:
- Around 600 commits and roughly 120k lines of code, with no hand‑written implementation code—all of that was generated by an LLM.
- The human wrote specs, docs, and checklists, ran tests and CI, and treated the model like a junior dev with explicit requirements and acceptance criteria.
- Guardrails included types, linting, tests, and a strict definition of “done,” plus versioned docs (design system + interface spec) to prevent “project truth” from drifting as hundreds of changes accumulated.
Their key insight: the bottleneck is not generating code, it’s preventing context/spec drift and keeping invariants stable as your AI assistant churns through the repo.
Example #2: Linqlist – Smart Bookmark Manager Built Like a Product
Right after massive apps like Tangents, you find small, sharp tools like Linqlist, a smart bookmark manager available on the Chrome Web Store as “Smart Bookmark Manager – Linqlist.” Under the hood, it’s exactly the kind of product that vibe coding excels at.
What Linqlist Does
Linqlist turns messy browser bookmarks into organized, visual collections:
- It integrates with Chrome’s native bookmarks and presents them as boards and Smart Collections you can drag, tag, and reorder.
- It syncs between the Chrome extension and the web app (linq-list.com), so your boards and collections are accessible across devices by logging in.
- It adds fast search and filtering, helping you find links by title or content instead of digging through nested folders.
You can find it as “Smart Bookmark Manager – Linqlist” in the Chrome Web Store search results.
Why Linqlist Is a Great Vibe‑Coding Candidate
Linqlist’s shape is extremely vibe‑friendly:
- Clear domain and boundaries: bookmarks, boards, sharing, and search—no sprawling feature creep baked in.
- Classic extension architecture: Chrome APIs, a React‑style UI, a small backend for sync and auth.
- Lots of boilerplate: options pages, permissions, sync logic, list rendering, filtering, and settings—exactly the kind of repetitive scaffolding LLMs generate well.
A human designer can define the UX, flows, and data model, then rely on an AI coding agent to scaffold the extension, wire Chrome APIs, and iterate on UI components with tests and manual review.
Example #3: QuickReply – AI‑Powered Social Media Replies
Another compact but meaningful example is QuickReply, the Chrome extension at quickautoreply.com that appears on the Chrome Web Store as “QuickReply.” It’s built to reduce the friction of writing replies on social platforms.
What QuickReply Does
QuickReply focuses on one job: drafting social replies quickly using AI.
- It reads the context of the current social post or thread (Twitter/X, LinkedIn, Reddit, etc.).
- It sends that context to an AI backend and returns several suggested replies tuned to the platform’s tone and length.
- You can tweak the suggestion and then post it, cutting your response time from minutes to seconds while still sounding human.
The extension listing at quickreply/lkgjmpcefbckoieikkohcejgchchhefa on the Chrome Web Store highlights its focus on social‑media replies, not general chat.
Why QuickReply Fits the Vibe‑Coding Pattern
Technically, QuickReply looks very similar to many vibe‑coded apps described on HN and in vibe‑coding write‑ups:
- A browser extension that needs UI panels, context scraping, and messaging between content script and background script.
- A small backend that proxies requests to one or more LLMs, plus configuration for API keys, rate limits, and safety filters.
- A set of tone presets (“friendly,” “professional,” etc.) and small UX details that can be prototyped via iterative AI‑generated code and then tightened by a human.
The developer can specify flows (“on click, read the post text, call this API, show three reply options in a popup”), then use an AI agent to write and refactor most of the implementation while they test it against real social platforms.
Other Successful Vibe‑Coded Products from the HN Thread
Beyond those two, the Ask HN question pulled in a surprisingly rich set of success stories. A few highlights:
- My DigitAlly – A full‑stack educational platform for parents, with OAuth, cron‑based weekly tips to 200+ subscribers, a JSON‑driven curriculum engine, and auth‑aware PDF generation. The creator used one model for architecture decisions and another model for heavy implementation and tests, all under strict TDD.
- Internal tools – A bar owner built an inventory system completely via Claude Code; a home lab owner built a custom inventory and batch tracker; small teams are vibe‑coding bespoke CRMs and CMSs attached directly to their databases to avoid expensive SaaS and integration work.
- Consumer apps and games – A Peloton replacement, a daily word game with ~400 DAU, animated puzzle games, and price‑tracking dashboards were built with 70–90% AI‑written code, then lightly reviewed and refined by their creators.
Most of these products are not unicorns, but they are “successful” on their own terms: used regularly, solving specific problems, sometimes with paying customers.
Common Patterns Behind These Successes
Looking across Tangents, Linqlist, QuickReply, and the rest, there are strikingly consistent patterns in how people make vibe coding work.
1. Specs and “Project Truth” Come First
Everyone shipping real apps writes some mix of:
- One‑page architecture overviews and entity diagrams.
- Interface contracts, design systems, and invariants (“this must never happen”).
- Acceptance criteria for each feature or bugfix.
They then feed this into the model as the source of truth, instead of letting the AI improvise structure every time.
2. The Model Is a Junior, Not a Wizard
Builders treat the LLM as:
- Someone who gets very explicit tasks (“add this endpoint,” “refactor this file”), not “build the entire app.”
- A coder whose output must pass tests and human review.
- A helper that they keep inside tight context windows (one module, one feature) while they watch for architecture drift.
This mindset keeps vibe coding from turning into an unmaintainable mess.
3. Guardrails: Types, Tests, and Linting
Successful vibe‑coded products lean heavily on guardrails:
- Strong type systems (TypeScript, Prisma schemas, etc.) to surface AI mistakes early.
- Unit and integration tests as hard gates: if tests don’t pass, code doesn’t ship.
- Linting and formatting tools to keep style consistent across many AI‑generated changes.
Developers often have the AI write tests alongside the feature, then use failures to drive further prompts.
4. Right‑Sized Problems
Vibe coding works best on:
- Greenfield projects with clear, bounded domains (bookmark managers, reply assistants, inventory tools).
- Products where the primary user is the builder or a small team that can quickly validate behavior.
- Apps with real complexity, but not life‑critical stakes—think payments, scheduling, content, analytics, not air‑traffic control.
It struggles most in huge, legacy, highly regulated codebases with lots of hidden invariants and minimal tests.
How to Start Your Own Vibe‑Coded Product (In Practice)
If you want to build something like Linqlist or QuickReply using vibe coding, here’s a battle‑tested approach drawn from these examples.
- Pick a painfully specific problem“My bookmarks are unusable” → a smarter bookmark board.“Replying on LinkedIn takes too long” → a reply assistant extension.
- Write a simple system design firstUser stories, core entities, stack (e.g., React + Node + Postgres, or extension + API).Non‑negotiables like auth, privacy constraints, and data flow.
- Use an AI agent to scaffoldAsk it to generate the initial project structure, basic routes, and minimal UI.Keep prompts scoped: one feature at a time, always referencing your design doc.
- Enforce guardrails from day zeroTurn on strict typing, tests, and linting.Make the model update or add tests for every change, and run them religiously.
- Ship a tiny but real v1 quicklyFor a bookmark tool, that might be “import browser bookmarks, show them as cards, and search them.”For a reply tool, “read the current post, generate one suggested reply, let me edit and paste.”
- Iterate based on real use, not vibesUse your product daily.Feed bugs, logs, and frustrations back into the LLM with narrow prompts to generate fixes and refactors.
Follow this loop and you’re much more likely to end up with something like Linqlist or QuickReply—a small, dependable tool that genuinely improves your day—rather than yet another abandoned prototype.
In the end, the most compelling vibe‑coded success stories are not about replacing engineers; they’re about letting one motivated person ship far more than they could alone. Tangents, Linqlist, QuickReply, and dozens of smaller tools show that when you combine clear vision, tight constraints, and strong guardrails, LLMs can absolutely co‑build production apps that people actually use.