@Alexandre Ibrahim I have built a basic RAG pipeline recently (n8n, not code) so I can at least walk through the theory even though I went the no-code route rather than raw code. The core steps are the same regardless of language/platform: 1. Chunk the source data — split your text (in your friend's case, LinkedIn profile content) into manageable pieces, not too big or you lose retrieval precision, not too small or you lose context. Common starting point is around 512 tokens with some overlap between chunks. 2. Embed each chunk — run it through an embedding model (OpenAI, Google Gemini, Cohere, etc.) which converts the text into a vector, a list of numbers representing its meaning, not just its literal words. This is the part that lets you match on semantic similarity instead of keyword matching. 3. Store in a vector database — Pinecone, Weaviate, Qdrant, or pgvector (a Postgres extension) if he wants to avoid a separate DB. This is where those vectors get stored, indexed for fast similarity search. 4. Query time — when someone searches, you embed the query the same way, then the vector DB returns the chunks whose vectors are closest (cosine similarity is common), meaning most similar in meaning, not exact text. 5. Optional generation step — if he wants an LLM to synthesize an answer instead of just returning raw matches, you'd feed the retrieved chunks into an LLM as context. For his specific use case (matching LinkedIn profiles to each other, not Q&A), steps 1-4 are really the whole thing, he probably doesn't need step 5 at all, since he's not generating text, just finding semantically similar profiles. In terms of language, Python is by far the most common for building this from scratch (LangChain or LlamaIndex are the usual frameworks people reach for), but it's genuinely just calling APIs for embedding + a vector DB SDK, so it's not deeply "hard code," more plumbing.

@Prakhar Shukla 13K company boards discovered by the automation itself, not seeded manually, is the detail that actually impresses me most here. That's a much harder problem than the scraping/filtering logic, since you had to figure out how to find new Greenhouse/Lever/Ashby boards in the first place, not just poll a known list. Piggybacking on Chetan's dedup question since I'd guess this is where it gets messy — with three different ATS sources, are you deduping on something like company + job title + rough posted date, or does the same role sometimes actually differ enough across boards (slightly different titles, req IDs) that exact matching misses duplicates? Feels like that's the kind of thing that looks fine at 3K jobs and gets ugly at 30K.

@Malik Ahmed Really interesting framing — I'd add one thing to what you both said: AI can give someone the right answer if they ask the right question, but it can't tell a non-developer which questions they don't know to ask yet. Someone could prompt "how do I add rate limiting" and get a solid answer, but if they don't already know rate limiting is a thing they need, that question never gets asked in the first place. So it's less a knowledge gap and more a "known unknowns vs. unknown unknowns" gap. AI closes the first one really well. The second one is exactly your 2am scenario — that's usually the moment someone discovers an unknown unknown the hard way, and no amount of good prompting earlier would've surfaced it, because they didn't know to look.

@Malik Ahmed Right, and that's probably why "having someone review it" matters even when the non-developer technically could ask AI to do that review too, they still wouldn't know what to prompt it to look for. The review only works if the reviewer already has the pattern-matching from having seen things break before. Good discussion.

@Malik Ahmed Makes sense, manual overrides for now is the right call until you've got enough data to justify rule-based logic anyway. And good that the invoice locks to the stored snapshot rather than whatever the current rate is at approval time, keeps the guest's original quote honest even if the owner sits on it for a few days. Solid setup end to end.

@Malik Ahmed Right, and it protects the business too, not just the guest, no ambiguity if a rate change happens mid-negotiation. Good system design overall.

@Aashritha Reddy Following this one closely too, multi-tenant SaaS from single-client bots feels like a jump I'd eventually want to understand as well. One thing I'd be curious about on top of what Usman and Mashfi said — for the "separate client data, prompts, settings" part in n8n specifically, is that usually done with something like one shared workflow + client ID as a parameter pulling different configs from a database, or literally duplicating the workflow per client? Feels like that choice alone would decide a lot of how painful client #10 vs client #50 actually is.

@Aashritha Reddy That makes sense, thanks for confirming. Guessing the tradeoff is a shared workflow is way easier to maintain and update once, but any bug affects every client at the same time versus a duplicated-per-client setup where issues stay isolated. Good to have that as a mental model going forward.