I know it’s become fashionable to trash Replit on this forum and on X, so I’ll break the pattern and share a full-on success story (along with the learnings, the good, the bad and the ugly). In fact, it’s a double-success story, which I know Matt Palmer from Replit’s Success Team will appreciate.
I’ve built my first-ever full-stack app in Replit - front-end, back-end, database and auth. The app is called CastBandit, and it allows podcast owners to turn their podcasts into AI Chatbots trained on the content of the podcast. And while it might still be clunky around the edges, and some bugs might be hiding in places, it really does actually work!
Who is this app for?
Anyone who owns or runs a podcast and wants to drive listener engagement. For example, if you run a health-related show (like the Huberman Lab) and have a few episodes where you discuss low-carb diets, you can use an AI chatbot to recommend these specific episodes to listeners and get them re-engaged with your back catalog. Or, say, you run a history podcast (like The Rest is History) and have a few episodes discussing the role of personal relationships among the European royal families in escalating WWI (I actually don’t know if they do!), the AI Chatbot could recommend these episodes to anyone who asks “Where do they talk about royal families during WWI?”.
You can also use the chatbot as a perk for subscriber-only paywalled podcast pages and have it answer questions in depth, based on all of the content of your entire back catalog, and only to paid subscribers. The applications are infinite!
Why Replit?
It’s the Agent. When I just started with vibe coding, like many, I went straight to Lovable (this is before they built their agent). And very soon, Lovable started breaking healthy code while building new features, veering completely outside what I’d ask it to build.
Then, someone in Ken Moo’s LTD Facebook group recommended I explore Replit as it seemed to be “more comfortable with large code bases”.
And that kind soul was right. What the team at Replit figured out earlier than any of their competitors is that the biggest mountain to climb for any vibe coding development environment is steering the LLM away from poking its nose into the code base it doesn’t need (so it doesn’t break stuff that already works), and improving the quality of one-instruction feature builds (e.g. reducing the amount of tokens the vibe coder must spend on fixing buggy code).
So Replit seems to have baked this philosophy - “touch as little code as possible and only where needed” - to build what the vibe coder wants into its Agent. And it works like a charm. To be fair, the Agent isn’t perfect (more on this later), but it’s the best vibe coding implementation I know. And it got me where I needed to be while Lovable didn’t.
What’s the “double success”?
I knew I needed a static marketing website for the app once it’s done and dusted. I also knew I was keen to vibe-code it so I can publish it on Vercel or Netlify, do it quickly and avoid having to pay outsized monthly hosting fees to website builders. So I started building the website with Bolt because it supports Astro and can deploy directly to Netlify. But very quickly Bolt’s agent tripped over a simple refactor request for the home page, so I started looking for an alternative. And then, as if by magic, Replit announces that their Agent - the General Agent - now supports any framework, not just full-stack apps and games.
So I exported Bolt code to GitHub, imported it into Replit, fed it to the General Agent and - boom - it spun up an Astro development server and finished the job beautifully. I published the marketing website on Netlify, as I intended, via GitHub.
In the end, Replit agent helped me build both the full-stack app and the static Marketing website - and I couldn’t be happier.
What are the key learnings?
The biggest learning for me is that the biggest cost element in brining CastBandit from an idea to a fully operational app is my lack of experience, not Replit’s pricing per se. Which leads me to believe that most people who are complaining about Replit’s costs compared to other vibe coding environments are being stung by the price of the learning curve.
For example, I should have cached early on that, unless given express instructions to use UUID as the primary key in all Neon tables, Replit Agent uses serial IDs. It’s a security risk. And while it can be mitigated by using a dual-id system (e.g. you have an internal serial ID and a Public ID as UUID), Replit agent will often confuse the two fields, leading to costly code fixes and rework. So I ended up starting with internal IDs as serials, then moving to dual ID system ($), and then ripping everything out and re-wiring all tables and code to just have one internal ID in every table and made it a UUID ($$$). This rookie mistake cost me an ugly amount of tokens and money.
Now, I know that a lot of entitled folks out there would blame Replit for this. E.g. they should have known and anticipated it, and instructed Replit Agent to always create tables with UUIDs as Primary Keys.
I preemptively disagree.
Vibe Coding is engineering, assisted by AI. Even while it makes software development accessible for non-devs like me, it cannot and will not be free or have a flat learning curve. As a vibe coder, you must learn to own your system design decisions and research them upfront before paying Replit or anyone else to build to your specifications. Your errors will cost you time and money, and this is absolutely normal.
Which brings me to another big learning: I should have researcedh best practice more often before instructing Replit agent to build. As smart as the LLMs Replit uses are, they don’t know it all, and they hallucinate.
For example, like any other vibe coding agent built on top of LLMs that were rewarded in training for always providing an answer (as opposed to saying “I don’t know”), Replit agent will hallucinate even if it hits its own internal knowledge wall. It will invent non-existent hooks, methods and API endpoints and confidently code them in - only for you to discover later that the reason why you’ve spend $100 debugging faulty code is because it was trying to query a non-existent endpoint.
Thankfully, Replit agent now has web search (which, I’m guessing, pulls no punches and uses
Fire Crawl under the hood) and a Plan mode. So use both modes generously to research best practice and ingest SDKs before connecting external APIs. It will cost you some money upfront, but you’ll save yourself a second mortgage down the line in debugging false negatives.
What is it that I couldn’t crack?
While I know Stripe’s API pretty well from my core business, using it for subscription billing is a mountain I didn’t fully climb. And I spent an ugly amount of money and tokens trying to integrate Stripe subscriptions while running plans that have a combination of static resources, usage tracking, overages and binary entitlements.
Thankfully, I discovered Autumn (www.useautumn.com), a middleware that works on top of Stripe, which takes over Stripe webhooks, monthly entitlement credits and, essentially, telling your app which users have access to what resource at what time. Their SDK is beautifully ingestible by vibe coding agents, and I ended up ripping out direct Stripe integration and replacing it with Autumn (which cost me an ugly amount of tokens and money, but now I know better).
What are my suggestions to Replit?
1. Replit, to my knowledge, is the most expensive vibe coding environment on the market (I might be wrong). Yet, I support and see the logic in effort-based pricing as long as - and it is absolutely imperative - the effort you’re charging us for is USEFUL. I’m happy to pay your prices for code that works; for features that are exactly what I asked for. And while I see how you’re constantly improving the ratio of useful to useless tokens and actions consumed and priced out to us, it’s still not fully there. Do not ever drop this mountain - you must keep climbing it. Do not get distracted by other features at the expense of improving the core value equation of your central Vibe Coding tool - the Agent.
2. Consider reworking Replit Auth to generate user records with UUID as primary key. Unless there’s some specific engineering reason why this is undesirable or impossible.
3. Steer Agent away from trying to make the user whole by manually performing actions that the broken code is meant to do. For example, when asked to fix code that failed to write something to the database, Agent would often decde to dedicate half of its effort to actually fixing and debugging code, and another half - to write the missing records to the database. It’s an enormous waste of our money, and we currently lack mechanisms to stop Replit Agent from executing these useless actions and billing them out to us (it adds up, you know!).
4. Get Agent to double-check with the user on details before making assumptions and spending effort on coding and tool use in case of repeated failed attempts at fixing code. This is a hard one to pinpoint and reproduce, but let me try. Say I’m debugging code that’s meant to interact with an external REST API. After a few unsuccessful attempts, the Agent assumed the code didn’t work because the endpoint didn’t accept the parameters I was instructing the Agent to code, and decided to invent a completely non-workable workaround using its own imagination. A web search on the API’s docs or a question to the user - “Can you confirm the API accepts methods X, Y, Z” would have saved me a lot of money stopping and re-starting Agent only to tell him to stop building a non-workable workaround.
Where to next?
Building CastBandit taught me a ton about vibe coding and Replit, and the app is now in the place where I can start ironing out the quirks, occasional bugs, and start thinking of incremental new features. And, oh, launching it properly as well - that too! If we build it but don’t tell anyone about it, THEY don’t come (apparently). What’s even more important - the skills I picked up while building CastBandit - will prove immensely helpful in my core business where I’ve just picked Replit as my technology platform to move Day One Careers (my core business) AI Story Bank away from Glide Apps (to finish my transition from no-code to Vibe Code), and to build an app component to another core business (related to all things hiring and interviewing) my business partner and I are working on.
So that’s it for now. If you have any questions, feel free to ask in the comments and I will respond.
Happy Vibe Coding. And well done so far, Team Replit!
