व्यावसायिक धारणाओं को समय के साथ ट्रैक करने वाला वेब ऐप बनाएं

ऐप किस समस्या को हल करता है (और कौन उपयोग करता है)\n\nएक व्यावसायिक धारणा वह विश्वास है जिस पर आपकी टीम उस समय काम कर रही है जब तक वह पूरी तरह साबित न हो। यह हो सकती है:\n\n- बाज़ार: “यह सेगमेंट हमारे प्रोडक्ट को समर्थन देने के लिए पर्याप्त तेज़ी से बढ़ रहा है।”\n- ग्राहक: “अगर सेटअप 10 मिनट से कम में हो तो यूज़र्स स्प्रेडशीट छोड़ देंगे।”\n- प्राइसिंग: “टीमें इस फीचर सेट के लिए $49/महीना भुगतान करेंगी।”\n- ऑपरेशंस: “सपोर्ट एक व्यक्ति के साथ ऑनबोर्डिंग संभाल सकता है।”\n- जोखिम: “यह तरीका कंप्लायंस चिंता उत्पन्न नहीं करेगा।”\n\nये धारणाएँ हर जगह दिखती हैं—पिच डेक्स, रोडमैप चर्चा, सेल्स कॉल, कॉरिडोर वार्तालाप—और फिर शांतिपूर्वक गायब हो जाती हैं।\n\n### क्यों टीमें धारणाएँ खो देती हैं\n\nअधिकतर टीमें धारणाएँ इसलिए नहीं खोतीं क्योंकि उन्हें परवाह नहीं है। वे इसलिए खोती हैं क्योंकि दस्तावेज़ीकरण ड्रिफ्ट हो जाता है, लोग भूमिकाएँ बदलते हैं, और ज्ञान कबीलाई बन जाता है। “नवीनतम सच” एक डॉक, एक Slack थ्रेड, कुछ टिकट और किसी की याददाश्त में बंट जाता है।\n\nजब ऐसा होता है, टीमें वही बहसें दुहराती हैं, वही प्रयोग फिर से चलाती हैं, या बिना यह समझे निर्णय ले लेती हैं कि क्या साबित हुआ है और क्या नहीं।\n\n### लक्ष्यों के रूप में क्या चाहिए\n\nएक साधारण धारणा-ट्रैकिंग ऐप आपको देता है:\n\n- स्पष्टता: आप क्या मानते हैं, क्या साबित है, और क्या लंबित है\n- जवाबदेही: किसकी जिम्मेदारी है और आख़िरी बार कब समीक्षा हुई\n- तेज़ सीखना: परिकल्पनाओं, प्रयोगों और सबूतों के बीच तेज़ी से फ़ीडबैक लूप\n- कम पुनरावृत्ति: साझा रिकॉर्ड जो सर्कुलर चर्चाओं को घटाता है\n\n### कौन उपयोग करता है (और कितना बड़ा होना चाहिए)\n\nप्रोडक्ट मैनेजर्स, संस्थापक, ग्रोथ टीमें, शोधकर्ता और सेल्स लीड—जो कोई भी दांव लगा रहा है—लाभान्वित होते हैं। शुरुआत एक हल्के “धारणा लॉग” से करें जो रखवाली में आसान हो, और फ़ीचर तब बढ़ाएँ जब उपयोग इसकी माँग करे।\n\n## कोर डेटा मॉडल परिभाषित करें\n\nस्क्रीन डिज़ाइन या टेक स्टैक चुनने से पहले तय करें कि आपका ऐप क्या “चीज़ें” स्टोर करेगा। एक स्पष्ट डेटा मॉडल प्रोडक्ट को लगातार बनाए रखता है और बाद में रिपोर्टिंग को संभव बनाता है।\n\n### कोर ऑब्जेक्ट्स (इसे छोटा रखें)\n\nटीमों द्वारा विचारों को मान्य करने के तरीके से मेल खाने वाले पाँच ऑब्जेक्ट्स से शुरू करें:\n\n- धारणा (Assumption): वह दावा जिसे आप सत्य मानते हैं (जब तक कि विपरीत न सिद्ध हो)\n- सबूत (Evidence): लिंक, नोट, फ़ाइलें, या मेट्रिक्स जो धारणा का समर्थन या विरोध करते हैं\n- प्रयोग (Experiment): एक संरचित टेस्ट (इंटरव्यू, सर्वे, A/B टेस्ट, प्रोटोटाइप) जो सबूत उत्पन्न करता है\n- समीक्षा (Review): एक नियत चेकपॉइंट जहाँ कोई व्यक्ति नवीनतम स्थिति/विश्वास की पुष्टि करता है\n- टिप्पणी (Comment): धारणा से जुड़ी हल्की चर्चा (वैकल्पिक रूप से सबूत/प्रयोग से भी जुड़ी हो सकती है)\n\n### अनुशंसित धारणा फ़ील्ड्स\n\nएक धारणा रिकॉर्ड तेज़ी से बनना चाहिए, पर पर्याप्त समृद्ध होना चाहिए ताकि वह उपयोगी रहे:\n\n- Statement (आवश्यक): एक वाक्य, टेस्टयोग्य\n- Category (आवश्यक): जैसे customer, problem, pricing, channel, feasibility\n- Owner (आवश्यक): कौन इसे आगे बढ़ाएगा\n- Confidence (आवश्यक): low/medium/high (या 1–5)\n- Status (आवश्यक): draft, active, validated, invalidated, archived\n\nरिव्यू वर्कफ़्लो चलाने के लिए टाइमस्टैम्प जोड़ें:\n\n- Created at, Last updated at (सिस्टम-जनित)\n- Last reviewed at, Next review date (एडिटेबल या व्युत्पन्न)\n\n### संबंध (Relationships)\n\nमान्यता/सत्यापन के फ्लो को मॉडल करें:\n\n- एक धारणा → कई सबूत आइटम\n- एक धारणा → कई प्रयोग\n- एक धारणा → कई समीक्षाएँ और टिप्पणियाँ\n\n### आवश्यक बनाम वैकल्पिक (कर्षण कम करें)\n\nकेवल आवश्यक फ़ील्ड अनिवार्य रखें: statement, category, owner, confidence, status। विवरण जैसे टैग, प्रभाव, और लिंक वैकल्पिक रखें ताकि लोग जल्दी धारणाएँ लॉग कर सकें—और बाद में जैसे-जैसे सबूत आये उन्हें बेहतर कर सकें।\n\n## स्थिति, कॉन्फिडेंस और समीक्षा नियम सेट करें\n\nयदि आपका धारणा लॉग उपयोगी बने रहना है, तो हर एंट्री को एक नज़र में स्पष्ट अर्थ चाहिए: इसका जीवनचक्र कहाँ है, आप कितना मजबूत विश्वास करते हैं, और इसे कब फिर से चेक करना चाहिए। ये नियम यह भी रोकते हैं कि टीमें अनुमान को चुपचाप तथ्य न मान लें।\n\n### एक सरल, सुसंगत जीवनचक्र\n\nहर धारणा के लिए एक ही status फ़्लो उपयोग करें:\n\nDraft → Active → Validated / Invalidated → Archived\n\n- Draft: कैप्चर किया गया, पर अभी ट्रैक करने लायक माना नहीं गया।\n- Active: टीम इस पर निर्भर कर रही है (या कर सकती है) और इसे टेस्ट/मॉनिटर करने का इरादा है।\n- Validated: सबूत आपकी न्यूनतम मानक को पूरा करता है (नीचे परिभाषित)।\n- Invalidated: सबूत स्पष्ट रूप से इसके विरोध में है; सीखने के लिए इसे रखें।\n- Archived: अब प्रासंगिक नहीं (प्रोडक्ट बदला, बाज़ार हिल गया, रणनीति बदली)।\n\n### Confidence स्कोरिंग (1–5)\n\n1–5 स्केल चुनें और इसे साधारण भाषा में परिभाषित करें:\n\n1. अनुमान (कोई सबूत नहीं)\n2. कम संकेत (एक डेटा पॉइंट)\n3. कुछ समर्थन (कई संकेत, फिर भी गैप)\n4. मजबूत समर्थन (संगत सबूत, कम संशय)\n5. बहुत मजबूत (दोहरने योग्य परिणाम, समय के साथ स्थिर)\n\n“Confidence” को सबूत की ताकत के रूप में रखें—न कि कि किसी की चाहत।\n\n### निर्णय प्रभाव: पहले क्या सत्यापित करें\n\nDecision impact: Low / Medium / High जोड़ें। उच्च-प्रभाव वाली धारणाओं का पहले परीक्षण किया जाना चाहिए क्योंकि वे प्राइसिंग, पोजिशनिंग, गो-टू-मार्केट, या बड़े बिल्ड निर्णयों को आकार देती हैं।\n\n### “Validated” का क्या अर्थ है तय करें\n\nप्रत्येक धारणा के लिए स्पष्ट मानदंड लिखें: कौन सा परिणाम गिना जाएगा, और न्यूनतम सबूत क्या चाहिए (उदा., 30+ सर्वे उत्तर, 10+ सेल्स कॉल्स में एक समान पैटर्न, A/B टेस्ट पहले से परिभाषित सफलता मीट्रिक के साथ, 3 हफ्तों का रिटेंशन डेटा)।\n\n### पुनरीक्षण और समीक्षा नियम\n\nस्वचालित समीक्षा ट्रिगर्स सेट करें:\n\n- High-impact धारणाओं की समीक्षा हर 2–4 हफ्ते\n- जब कोर मेट्रिक्स बदलें (conversion, churn, CAC) तब समीक्षा\n- बड़े प्रोडक्ट या मार्केट परिवर्तन के बाद समीक्षा\n\nयह सुनिश्चित करता है कि “validated” का अर्थ “हमेशा के लिए सच” न बन जाए।\n\n## यूज़र एक्सपीरियंस और प्रमुख स्क्रीन डिज़ाइन करें\n\nएक धारणा-ट्रैकिंग ऐप तब सफल होता है जब यह स्प्रेडशीट से तेज़ महसूस हो। डिज़ाइन उन कुछ कार्यों के आसपास करें जिन्हें लोग हर हफ्ते दोहराते हैं: धारणा जोड़ना, अपने विश्वास को अपडेट करना, जो सीख मिले उसे जोड़ना, और अगली समीक्षा तारीख सेट करना।\n\n### प्राथमिक फ़्लोज़ (इन्हें वन-क्लिक रखें)\n\nएक तंग लूप का लक्ष्य रखें:\n\n- Create assumption: टेम्पलेट (Problem, Customer, Pricing, Channel) से शुरू करें, समझदारी से डिफ़ॉल्ट्स के साथ।\n- Update status: जल्दी से Draft → Active → Validated/Invalidated में मूव करें, वैकल्पिक नोट के साथ।\n- Attach evidence: फ़ाइल ड्रैग-एंड-ड्रॉप करें या लिंक पेस्ट करें, फिर उसे एक या अधिक धारणाओं से टैग करें।\n- Schedule review: किसी भी परिवर्तन के बाद “next review” सेट करें ताकि कुछ पुराना न हो जाए।\n\n### कोर स्क्रीन जिनकी आपको वास्तव में ज़रूरत है\n\nAssumptions list होम बेस होना चाहिए: एक पठनीय तालिका स्पष्ट कॉलम्स के साथ (Status, Confidence, Owner, Last reviewed, Next review)। एक प्रमुख “Quick add” रो जोड़ें ताकि नए आइटम के लिए पूरा फ़ॉर्म न भरना पड़े।\n\nAssumption detail वह जगह है जहाँ निर्णय होते हैं: ऊपर छोटा सार, फिर अपडेट्स का टाइमलाइन (status बदलना, confidence बदलना, टिप्पणियाँ) और एक समर्पित Evidence पैनल।\n\nEvidence library सीखने का पुन:उपयोग करने में मदद करती है: टैग, स्रोत, और दिनांक से खोजें, फिर सबूत को कई धारणाओं से लिंक करें।\n\nDashboard का उत्तर होना चाहिए: “किसे ध्यान चाहिए?” आगामी समीक्षाएँ, हालिया बदले गए धारणा, और उच्च-प्रभाव आइटम जिनकी Confidence कम है, दिखाएँ।\n\n### फ़िल्टर, खोज, और क्लटर नियंत्रण\n\nफ़िल्टर स्थायी और तेज़ रखें: category, owner, status, confidence, last reviewed date। टेम्पलेट्स, डिफ़ॉल्ट मान, और प्रोग्रेसिव डिसक्लोज़र (अडवांस्ड फ़ील्ड्स तब तक छुपाएँ जब तक ज़रूरत न हो) से अव्यवस्था कम करें।\n\n### पहुँचनीयता के बुनियादी नियम\n\nहाई-कॉन्ट्रास्ट टेक्स्ट, स्पष्ट लेबल, और कीबोर्ड-फ्रेंडली कंट्रोल्स का उपयोग करें। तालिकाओं को रो फोकस, सॉर्टेबल हेडर, और पठनीय स्पेसिंग का समर्थन करना चाहिए—विशेषकर स्टेटस और कॉन्फिडेंस बैजेस के लिए।\n\n## व्यावहारिक टेक स्टैक चुनें\n\nएक धारणा-ट्रैकिंग ऐप ज्यादा तर फ़ॉर्म्स, फ़िल्टरिंग, सर्च, और ऑडिट ट्रेल का काम है। यह अच्छी खबर है: आप एक सरल, भरोसेमंद स्टैक से वैल्यू शिप कर सकते हैं और अपनी ऊर्जा वर्कफ़्लो (रिव्यू नियम, सबूत, निर्णय) पर खर्च कर सकते हैं बजाय इन्फ्रास्ट्रक्चर पर।\n\n### एक सरल स्टैक जो काम करता है\n\nएक आम, व्यावहारिक सेटअप है:\n\n- Frontend: React, अक्सर Next.js के साथ (तेज़ UI, रूटिंग, सर्वर रेंडरिंग जब उपयोगी हो)\n- Backend: Node.js (Express/Nest) या Python (FastAPI/Django)\n- Database: Postgres\n\nयदि आपकी टीम पहले से किसी एक को जानती है, तो वही चुनें—कंसिस्टेंसी नई चीज़ से बेहतर है।\n\nयदि आप जल्दी प्रोटोटाइप बनाना चाहते हैं बिना हर चीज़ हाथ से जोड़ने के, तो एक वाइब-कोडिंग प्लेटफ़ॉर्म जैसे Koder.ai आपको एक आंतरिक टूल तेज़ी से दे सकता है: अपने डेटा मॉडल और स्क्रीन चैट में बताइए, Planning Mode में इटरेट करें, और React UI के साथ एक प्रोडक्शन-रेडी बैकएंड (Go + PostgreSQL) जनरेट करें जिसे आप बाद में सोर्स कोड के रूप में निर्यात कर सकते हैं।\n\n### क्यों Postgres एक बेहतरीन फिट है\n\nPostgres धारणा-प्रबंधन की “कनेक्टेड” प्रकृति को अच्छे से संभालता है: धारणाएँ वर्कस्पेस की होती हैं, ओनर्स होते हैं, सबूत से लिंक होती हैं, और प्रयोगों से जुड़ती हैं। एक रिलेशनल DB इन लिंक्स को भरोसेमंद रखता है।\n\nयह उन क्वेरीज के लिए भी इंडेक्स-फ्रेंडली है जो आप बार-बार चलाएँगे (status, confidence, due for review, tag, owner), और जब आप संस्करण इतिहास और चेंज लॉग जोड़ते हैं तो यह ऑडिट-फ्रेंडली भी है। आप चेंज इवेंट्स को अलग टेबल में स्टोर कर सकते हैं और रिपोर्टिंग के लिए क्वेरीयोग्य रख सकते हैं।\n\n### होस्टिंग और ऑप्स हल्का रखें\n\nमैनेज्ड सर्विसेज़ के लिए जाएँ:\n\n- Managed Postgres (ऑटोमैटिक बैकअप, अपग्रेड, बाद में रीड रेप्लिका)\n- App hosting Next.js और आपके API के लिए (या एक सिंगल फुल-स्टैक Next.js ऐप)\n\nयह जोखिम घटाता है कि “चलाते रहना” आपका हफ्ता ले ले।\n\nयदि आप शुरुआत में इन्फ्रा नहीं चलाना चाहते, तो Koder.ai डिप्लॉयमेंट और होस्टिंग भी संभाल सकता है, साथ में सुविधाएँ जैसे कस्टम डोमेन और snapshots/rollback ताकि आप असली यूज़र्स के साथ वर्कफ़्लोज़ पर सुधार कर सकें।\n\n### API अप्रोच: पहले REST\n\nCRUD, सर्च, और गतिविधि फ़ीड के लिए पहले REST endpoints से शुरू करें। यह डिबग और डॉक्यूमेंट करने में आसान है। केवल तब GraphQL पर विचार करें जब आपको वास्तव में क्लाइंट-ड्रिवन, जटिल क्वेरीज की ज़रूरत हो।\n\n### स्पष्ट एनवायरनमेंट्स का उपयोग करें\n\nपहले दिन से तीन एनवायरनमेंट्स की योजना बनाएं:\n\n- Local (डेवलपर मशीन)\n- Staging (इम्पोर्ट, नोटिफिकेशन, और परमिशंस टेस्ट करने के लिए सुरक्षित जगह)\n- Production (वास्तविक डेटा, सख्त एक्सेस, मॉनिटरिंग)\n\nयह सेटअप आपकी धारणा-ट्रैकिंग जरूरतों को ओवर-इंजीनियर किए बिना सपोर्ट करता है।\n\n## प्रमाणिकरण, भूमिकाएँ और वर्कस्पेस लागू करें\n\nयदि आपका धारणा लॉग साझा है, तो एक्सेस कंट्रोल उबाऊ और अनुमान्य होना चाहिए। लोगों को पता होना चाहिए कि कौन क्या देख सकता, संपादित कर सकता, या अनुमोदित कर सकता है—बिना टीम को धीमा किए।\n\n### प्रमाणिकरण: सरल से शुरू करें, ज़रूरत पड़े तो SSO जोड़ें\n\nबेशक टीमों के लिए पहली परत email + password पर्याप्त है। बड़े संगठनों, सख्त IT नीतियों, या बार-बार ऑनबोर्डिंग/ऑफ़बोर्डिंग की स्थिति में Google या Microsoft SSO जोड़ें। यदि आप दोनों सपोर्ट करते हैं, तो प्रति वर्कस्पेस एडमिन को विकल्प दें।\n\nलॉगिन सतह को न्यून रखें: साइन अप, साइन इन, पासवर्ड रीसेट, और (वैकल्पिक) बाद में अनिवार्य MFA।\n\n### रोल्स और परमिशन्स (Admin / Editor / Viewer)\n\nएक बार रोल परिभाषित करें और उन्हें पूरे ऐप में सुसंगत रखें:\n\n- Admin: वर्कस्पेस सेटिंग्स, सदस्यों, रोल्स, और इंटीग्रेशंस को मैनेज कर सकते हैं; रिकॉर्ड्स को डिलीट कर सकते हैं (या डिलीट का अनुरोध कर सकते हैं)।\n- Editor: धारणाएँ बना और संपादित कर सकते हैं, सबूत अटैच कर सकते हैं, प्रयोग लॉग कर सकते हैं, और स्थिति/कॉन्फिडेंस बदल सकते हैं।\n- Viewer: धारणा, सबूत, प्रयोग के परिणाम, और डैशबोर्ड पढ़ने तक सीमित।\n\nपरमिशन चेक सर्वर-साइड रखें (केवल UI पर भरोसा न करें)। अगर आप बाद में “approval” जोड़ते हैं, तो उसे एक परमिशन के तौर पर ट्रीट करें, नए रोल के रूप में नहीं।\n\n### वर्कस्पेस: अलग टीमें, प्रोडक्ट्स, और क्लाइंट्स\n\nएक वर्कस्पेस डेटा और सदस्यता की सीमा है। हर धारणा, सबूत आइटम, और प्रयोग ठीक एक वर्कस्पेस का होगा, ताकि एजेंसियाँ, मल्टी-प्रोडक्ट कंपनीज़, या कई इनिशिएटिव्स वाली स्टार्टअप्स व्यवस्थित रहें और आकस्मिक शेयरिंग से बचें।\n\n### इनवाइट्स, ऑफ़बोर्डिंग, और न्यूनतम ऑडिट\n\nईमेल-आधारित इनवाइट्स एक्सपायरी विंडो के साथ उपयोग करें। ऑफ़बोर्डिंग पर, एक्सेस हटा दें पर इतिहास को बरकरार रखें: पिछली एडिट्स में अभी भी मूल अभिनेता दिखाई देना चाहिए।\n\nकम से कम, एक ऑडिट ट्रेल स्टोर करें: किसने क्या और कब बदला (यूज़र ID, टाइमस्टैम्प, ऑब्जेक्ट, और एक्शन)। यह ट्रस्ट, जवाबदेही, और बाद में निर्णयों पर प्रश्न उठने पर डिबगिंग में मदद करता है।\n\n## वर्शन हिस्ट्री और चेंज लॉग के साथ CRUD बनाएं\n\nCRUD उस बिंदु पर आपके धारणा लॉग को एक सिस्टम बनाता है न कि सिर्फ़ एक डॉक। लक्ष्य सिर्फ़ धारणा बनाना और संपादित करना नहीं है—बल्कि हर बदलाव को समझने योग्य और उल्टा करने योग्य बनाना है।\n\n### CRUD endpoints और UI एक्शन्स\n\nकम से कम, धारणा और सबूत के लिए इन एक्शन्स का समर्थन करें:\n\n- धारणाओं को बनाएं, देखें, संपादित करें, आर्काइव (soft-delete), और रिस्टोर करें\n- सबूत आइटम अटैच करें (लिंक्स, फ़ाइल्स, नोट्स) और उनके मेटाडेटा संपादित करें\n- स्थिति बदलें (उदा., Draft → Active → Validated/Invalidated)\n\nUI में इन एक्शन्स को धारणा डिटेल पेज के पास रखें: एक स्पष्ट “Edit,” एक समर्पित “Change status,” और एक “Archive” एक्शन जो जान-बूझकर मुश्किल क्लिक हो।\n\n### वर्शनिंग: रीविज़न बनाम अपेंड-ओनली लॉग\n\nदो व्यावहारिक रणनीतियाँ हैं:\n\n1) फुल रीविज़न स्टोर करें (हर सेव पर एक स्नैपशॉट)। यह “पूर्व का रिस्टोर” करना आसान बनाता है।\n\n2) अपेंड-ओनली चेंज लॉग (इवेंट स्ट्रीम)। हर एडिट एक इवेंट लिखता है जैसे “statement बदला गया,” “confidence बदला गया,” “evidence अटैच किया गया।” यह ऑडिटिंग के लिए अच्छा है पर पुराने स्टेट्स को पुनर्निर्मित करना अधिक काम माँगता है।\n\nबहुत सी टीमें हाइब्रिड अपनाती हैं: प्रमुख एडिट्स के लिए स्नैपशॉट + छोटे एक्शन्स के लिए इवेंट्स।\n\n### हिस्ट्री को पढ़ने योग्य बनाएं (सिर्फ़ स्टोर न करें)\n\nप्रत्येक धारणा पर एक टाइमलाइन प्रदान करें:\n\n- किसने क्या बदला, कब\n- टेक्स्ट फ़ील्ड्स (statement, hypothesis, success criteria) के लिए diff view\n- पिछले वर्ज़न्स पर एक Restore previous बटन (कन्फर्मेशन के साथ)\n\n### संदर्भ: टिप्पणियाँ और निर्णय नोट\n\nमहत्वपूर्ण एडिट्स (स्थिति/कॉन्फिडेंस बदलना, आर्काइव करना) पर एक छोटा “क्यों” नोट आवश्यक करें। इसे हल्का निर्णय-लॉग माना जा सकता है: क्या बदला, किस सबूत ने ट्रिगर किया, और अगले कदम क्या होंगे।\n\n### आकस्मिक संपादन रोकें\n\nविनाशकारी कार्रवाईयों के लिए कन्फर्मेशन्स जोड़ें:\n\n- ऐसी स्थिति परिवर्तन जो धारणा को बंद कर दें\n- आर्काइविंग\n- पुराने वर्ज़न का रिस्टोर (चेतावनी कि यह नया वर्शन बनाएगा)\n\nयह सुनिश्चित करता है कि आपकी धारणा वर्शन हिस्ट्री भरोसेमंद बनी रहे—भले ही लोग तेज़ी से काम करें।\n\n## सबूत अटैच करें और प्रयोग ट्रैक करें\n\nधारणाएँ तब खतरनाक हो जाती हैं जब वे “सही” लगती हैं पर उनके पीछे कुछ भी दिखाने योग्य न हो। आपका ऐप टीमों को सबूत अटैच करने और हल्के-फुल्के प्रयोग चलाने दे ताकि हर दावे का एक ट्रेल हो।\n\n### सबूत: क्या स्टोर करें (बिना गड़बड़ किए)\n\nसामान्य सबूत प्रकार सपोर्ट करें: इंटरव्यू नोट्स, सर्वे परिणाम, प्रोडक्ट या राजस्व मेट्रिक्स, डॉक्यूमेंट्स (PDFs, स्लाइड डेक्स), और साधारण लिंक्स (जैसे analytics डैशबोर्ड, सपोर्ट टिकट)।\n\nजब कोई सबूत अटैच करे, तो थोड़ा मेटाडेटा कैप्चर करें ताकि महीनों बाद भी वह उपयोगी रहे:\n\n- Source (ग्राहक नाम, dataset, टूल, या आंतरिक डॉक ओनर)\n- Date collected (और वैकल्पिक रूप से date uploaded)\n- Method (इंटरव्यू, यूज़ेबिलिटी टेस्ट, A/B टेस्ट, डेस्क रिसर्च, आदि)\n- Quality / strength rating (नीचे अधिक)\n\nडुप्लिकेट अपलोड से बचने के लिए, सबूत को एक अलग एंटिटी के रूप में मॉडल करें और इसे धारणाओं से many-to-many कनेक्ट करें: एक इंटरव्यू नोट तीन धारणाओं का समर्थन कर सकता है, और एक धारणा के पास दस सबूत हो सकते हैं। फ़ाइल एक बार स्टोर करें (या केवल लिंक स्टोर करें), फिर जहां ज़रूरत हो उसे रिलेट करें।\n\n### प्रयोग ट्रैकिंग: “हमें इसे टेस्ट करना चाहिए” को रिकॉर्ड में बदलें\n\nएक “Experiment” ऑब्जेक्ट जोड़ें जो भरना आसान हो:\n\n- Hypothesis (आप क्या उम्मीद करते हैं और क्यों)\n- Method (आप क्या करेंगे)\n- Key metric (वह संख्या जिसे आप देखेंगें)\n- Result (क्या हुआ)\n- Conclusion (धारणा रखें, बदलें, या छोड़ें)

\nप्रयोगों को उन धारणाओं से लिंक करें जिनका वे परीक्षण कर रहे हैं, और वैकल्पिक रूप से जेनरेटेड सबूत (चार्ट, नोट्स, मेट्रिक स्नैपशॉट) ऑटो-अटैच करें।\n\n### सबूत की ताकत: झूठी निश्चितता से बचाने वाली मार्गदर्शिका\n\nएक सरल रूपरेखा (उदा., ) उपयोग करें और टूलटिप्स दें:\n\n- राय, एकल किस्सा, अनवेरिफाइड लिंक\n- कई इंटरव्यू, सुसंगत सर्वे सिग्नल, प्रारंभिक मेट्रिक ट्रेंड\n- विभिन्न सेगमेंट में दोहराए जाने वाले परिणाम, स्पष्ट मेट्रिक प्रभाव, नियंत्रित प्रयोग\n\nलक्ष्य पूर्णता नहीं है—लक्ष्य यह है कि कॉन्फिडेंस स्पष्ट हो ताकि निर्णय “वाइब्स” पर न बनें।\n\n## रिमाइंडर और समीक्षा वर्कफ़्लो जोड़ें\n\nधारणाएँ चुपचाप पुरानी हो जाती हैं। एक सरल समीक्षा वर्कफ़्लो आपके लॉग को उपयोगी बनाये रखता है और “हमें इसे फिर से देखना चाहिए” को एक प्रेडिक्टेबल हार्ट बनाता है।\n\n### जोखिम के अनुसार समीक्षा कैडेंस सेट करें\n\nरिव्यू फ़्रीक्वेंसी को और से जोड़ें ताकि हर धारणा एक जैसी न मानी जाए।\n\n- high impact + low confidence (उदा., मुख्य प्राइसिंग, मुख्य अधिग्रहण चैनल)\n- high impact + medium confidence, या medium impact + low confidence\n- low impact + high confidence\n\nNext review डेट को धारणा पर स्टोर करें, और impact/confidence बदलने पर इसे स्वचालित रूप से पुनर्गणना करें।\n\n### रिमाइंडर्स बिना स्पैम बने\n\nदोनों और नोटिफिकेशन सपोर्ट करें। डिफ़ॉल्ट्स रूक्ष रखें: ओवरड्यू होने पर एक नज़दीकी नudge, फिर एक हल्का फॉलो-अप।\n\nनोटिफिकेशंस को उपयोगकर्ता और वर्कस्पेस अनुसार कॉन्फ़िगर करने योग्य रखें:\n\n- चैनल प्राथमिकताएँ (email/in-app)