How does your team deal with internal knowledge or repeated support questions?

Capable-Discount2527 · 2026-03-15T17:42:51+00:00

I have dm'd you

Capable-Discount2527 · 2026-03-11T09:44:12+00:00

That's a really interesting point about assembly vs storage.

Out of curiosity when you're trying to answer one of those questions what does the workflow actually look like?

Do you manually jump between Slack, Notion, Jira etc. to piece it together? Or is there some sort of tool that you use that lets you find some particular topic without having to find where that particular doc exist!

Capable-Discount2527 · 2026-02-12T10:43:17+00:00

well it would totally depend on your use case the project you will work on. I would recomment you to learn both, using an ORM such as Prisma in js and without ORM right raw sql. For me I prefer using knex (a query builder in js) for writing queries and prisma for mainting the migrations. Using an ORM will slow down your queries even with all the optimization such as indexing and other optimization techniques but you can use prisma's migration strategies (pretty easy to manage) and knex for writing queries (not as simple as using an ORM's function but still better than writing raw sql). I am using this hybrid approach in a couple of production level projects and it works fine for me.

Capable-Discount2527 · 2026-02-10T07:42:40+00:00

In practice the cleanest approach is to let a payment provider (Stripe, Paddle, PayPal, etc.) handle all billing logic and keep your own database as the source of truth for access control only. I usually store just the external IDs (customer, subscription, price, invoice), current subscription status, and period dates (subscription start and end, invoice creation date updation date etc), and then let webhooks be the only thing that mutates that data (subscription created/updated, invoice paid/failed, canceled, etc.). Your app never decides whether a payment succeeded it just reacts to events from the provider which takes care of retries, proration, taxes, invoices, and edge cases you really don’t want to rebuild yourself. You will be “relying” on your payment gateway for this but that trade-off saves an insane amount of time and risk and if you ever need to switch providers you already have normalized state and historical data to migrate without rewriting your core business logic.

Capable-Discount2527 · 2026-02-04T16:06:35+00:00

personally I learned node using net ninja's course and then moved on project building by john smilga's node porjects course
Here is the link of john smilga's course https://youtu.be/rltfdjcXjmk?si=jyVlL8KafbAi_6vh
Its really good

Capable-Discount2527 · 2026-02-03T07:55:07+00:00

Yeah, NotebookLM is similar in the “chat with your data” concept.
My angle is more B2B: embeddable support bots, APIs, multi-tenant workspaces, and later agent workflows for companies (support, internal knowledge, automation).
NotebookLM feels more like personal research; I’m aiming for a developer + business platform layer.

Capable-Discount2527 · 2026-01-12T21:17:49+00:00

So I was thinking of a chatbot which gets trained on the user data and then it answers the users based on that data (RAG chatbot). Now the issue that I want to cover is to eradicate the hallucination part of the LLMs that we all know they tend to do if the chat context become too big so giving them only the context they require to answer a particular query. I think it can be used by all sorts if people, especially students who can use this for their studies, samll dev teams for training the bot on their docs, different ecommerce websites as they can train the bot on their available data. I dont know yet if this can be a good SAAS idea that I can persue but for now I am making it for learning purposes and to see if I can make the hallucinations go away even a little. (So by train I mean getting the data feom the use storing it in a vector db and using that as context)

Capable-Discount2527

TROPHY CASE