At what point do you outgrow n8n and need to build a local/physical RAG?
Hey guys,
Quick question for those of you dealing with AI architecture and scaling.
Right now, we rely pretty heavily on n8n at our startup. It s been amazing for moving fast, tying APIs together, and automating workflows. But looking ahead, I'm trying to figure out the long-term play.
At what exact point does it make sense to move away from n8n (and paying for third-party LLM APIs) to actually build out a specialized, local RAG on physical hardware?
Would you rather use 5 tools to build an app, or one AI builder for the whole thing?
I ve been thinking about how messy the current build an app with AI workflow still is.
For a simple website or SaaS-style product, people often end up jumping between multiple tools:
one tool for UI generation
another for backend/database
another for auth
another for payments
another for deployment
and maybe something else for internal dashboards or admin tools
It works, but the workflow can get fragmented pretty quickly especially if you re not a full-stack developer.
40+ builds in one day just to submit. Is building an app always this messy?
Hey everyone, first time posting here. I've been wrestling with production all day.. ended up hitting over 40 builds just trying to get the app to successfully submit.
Nobody really warns you about the absolute nightmare that is app store guidelines and provisioning profiles when you're first starting out.
How do you verify an agent's "this works now" without redoing the work?
Been in a thread lately about the "context tax" of re-explaining project state to an agent every session, and it made me realize the harder problem for me isn't memory, it's trust in the agent's own status reports.
When an agent says "fixed it, tests pass" or "yes that endpoint handles that case," how much do you actually check versus just believing it and moving on? I've gotten burned a couple times by an agent confidently describing behavior it never actually verified, it just pattern-matched to what a fix usually looks like.
When does a vibe-coded product need engineering help?
Vibe coding makes it much easier for non-technical founders to build a first version, test an idea, and get real users without hiring a full engineering team.
But what happens when the product starts working?
You have users. Maybe even paying customers. People depend on it now. But the app starts slowing down, bugs become harder to fix, and adding new features feels risky because the codebase was built mainly to validate the idea.
At that point, the question is no longer: Can this be built?
6 months of vibe coding, here's what actually stuck
Stack settled into this after breaking it a few times:
Cursor for IDE work. Claude Code for longer agentic runs when I trust the spec. Codex for boring tickets while I'm in meetings. v0 when a client needs a UI mock in 10 minutes.
The thing that actually changed how I use all of it: stopped treating them as interchangeable and just routing by task type. Refactors go to Cursor. Full feature from a spec goes to Claude Code. Tedious backlog stuff goes to Codex.
I reviewed 15+ vibe-coded fintech startups and found the same security gaps
Over the last few weeks, I reviewed more than 15 vibe-coded fintech and startup-style web apps.
The surprising part was this:
Even when teams were using AI coding tools, security agents, framework defaults, and modern deployment platforms, I still kept finding serious external security gaps.
Not always one-click hack type issues, but the kind of problems that slowly stack up into real risk:
Setting up monorepos for AI: submodules versus subtrees
I've been building my app for 8 months now, and i ended up having 5 repositories
nextjs app
databases
customer facing API
node-sdk that wraps the api
react-sdk, for both reusing shared component and customer facing components
So i thought, it's gonna be great if i create a mono repo with submodules. But it was terrible. I realized that turborepo does not like external packages, and as i tried to reuse my own customer facing libs, the DX became terrible. It was very time consuming to ship a feature. Even when i wanted to use Codex or Cursor 3, it was not able to show git diff properly, also i was not able to use Cursor's cloud agents properly to ship complex features.
What do you usually do while an AI agent is writing code?
Do you just wait, work on something else, or review the changes as they happen?
For me, every commit tells a story. To really understand the code, I first need to understand why each change was made and how it fits into the bigger picture.
That s why I try to stay involved while the agent is working reviewing the diff, creating a issues, following the logic, and making sure it s heading in the right direction.
Vibe coding what is the truth?
hi everyone,
I have been hearing about the vibe coding app's are entering the market and anyone can do it now,however i still have few doubts about the survival of the app as anyone like me who do not have much experience with building app and trying one.
What are the chances of that app competing and the security of the app against the one who is well known tech person build the app and know what to look for,what to add,what to remove,how to make sure this app will not have any loop holes which will land me in trouble atleast until i have any tech team or tech co-founder.Being a solo founder who is building an app for students it is hard to know all the things and ai only answer to us for what we ask it not what should we be doing instead,what to avoid,what are we already doing wrong.