मैं SaaS प्रोडक्ट शौक के तौर पर बनाता हूँ, और जब मैंने Jurfi लॉन्च किया तब इन प्रोजेक्ट्स से मेरी कमाई अभी भी शून्य थी। यह लिखना थोड़ा चुभता है, लेकिन कहानी का हिस्सा यही भी है: मैं बनाता रहता हूँ क्योंकि मुझे सच में प्रोडक्ट बनाना पसंद है। Jurfi.com उन्हीं में सबसे नया है।
Jurfi संरचित कानूनी दस्तावेज़ों के ड्राफ्ट बनाने के लिए ब्राउज़र-आधारित स्टूडियो है। मैंने इसे एक बहुत साफ समस्या से शुरू किया। खाली पेज से शुरू करना धीमा है, लेकिन AI का अस्पष्ट जवाब उलटी समस्या पैदा कर सकता है: टेक्स्ट बहुत होता है, पर दस्तावेज़ की साफ संरचना और उसे जाँचने का स्पष्ट तरीका नहीं। मुझे बीच का रास्ता चाहिए था—स्पष्ट इनपुट, दस्तावेज़ का तय आकार, और ऐसा वर्किंग ड्राफ्ट जिसे बस मान लेने के बजाय जाँचा जा सके।
खाली पेज से संरचित ड्राफ्ट तक
कई व्यावहारिक दस्तावेज़ उन्हीं असहज सवालों से शुरू होते हैं: यहाँ कौन-सी जानकारी चाहिए, किस क्रम में, और मैं क्या भूल रहा हूँ? Jurfi वेबसाइट और SaaS पॉलिसी, सर्विस एग्रीमेंट, किराये के दस्तावेज़, पत्र, दावे, रसीदें और दूसरे ऐसे दस्तावेज़ों में यह घर्षण कम करने के लिए बनाया गया है जिनकी लोगों को सच में जरूरत होती है।
मूल विचार सरल है: खाली पेज के बजाय फॉर्म या टेम्पलेट से शुरू करें। जरूरी इनपुट दें, संरचित वर्किंग ड्राफ्ट बनाएँ, फिर परिणाम को जाँचें और सुधारें।
- सरल फॉर्म और टेम्पलेट से कानूनी दस्तावेज़ों के ड्राफ्ट बनाना।
- संरचित ड्राफ्ट सीधे ब्राउज़र में तैयार करना।
- हर संस्करण को डिस्पोजेबल टेक्स्ट मानने के बजाय ड्राफ्ट लोकली रखना।
- डॉक्यूमेंट की अव्यवस्था और दोहराए जाने वाले मैनुअल असेंबली काम को कम करना।
मैं जानबूझकर परिणाम को ड्राफ्ट कहता हूँ। कोई दस्तावेज़ बहुत साफ-सुथरा दिख सकता है और फिर भी किसी खास jurisdiction, contract, business या dispute के लिए गलत हो सकता है। अच्छी formatting कानूनी correctness का प्रमाण नहीं है।
फीचर लिस्ट से ज्यादा जरूरी सीमा है
सबसे महत्वपूर्ण प्रोडक्ट निर्णय कोई नया टेम्पलेट जोड़ना नहीं था। असली निर्णय यह था कि Jurfi को किस चीज़ का दिखावा नहीं करना चाहिए। यह वकील नहीं है, और मैं इसे ऐसा सिस्टम नहीं बताता जो हर जटिल कानूनी स्थिति हल कर सके।
जिस value को मैं लक्ष्य बनाता हूँ वह सीमित और व्यावहारिक है: गति, संरचना और स्पष्टता। खाली पेज से coherent working draft तक जल्दी पहुँचना, inputs को स्पष्ट करना, दोहराई जाने वाली assembly कम करना, और फिर परिणाम को आलोचनात्मक ढंग से पढ़ना। अगर किसी दस्तावेज़ में महत्वपूर्ण कानूनी या वित्तीय जोखिम है, तो professional review अभी भी समझदार अगला कदम है।
यह सीमा महत्वपूर्ण है क्योंकि generated text आत्मविश्वासी लग सकता है और फिर भी अधूरा या गलत हो सकता है। कानूनी दस्तावेज़ के tool में इस uncertainty को छिपाना खराब product decision होगा। मैं product को जादुई दिखाने के बजाय उसकी सीमाएँ साफ रखना पसंद करता हूँ।
यहाँ “ब्राउज़र-आधारित” का क्या मतलब है?
वर्कफ़्लो ब्राउज़र के आसपास है और ड्राफ्ट लोकली रखे जा सकते हैं। यह मेरे लिए जरूरी था क्योंकि हर revision अलग-अलग tabs, chats और copied text में बिखर जाए तो document work बहुत जल्दी messy हो जाता है।
लेकिन मैं इस feature को facts से बड़ी privacy claim में बदलना नहीं चाहता। ठोस capability यह है: drafts local रखे जा सकते हैं। यह कहने के बराबर नहीं कि हर workflow की हर operation जरूरी तौर पर केवल device पर ही होती है। व्यावहारिक बात सरल है: draft ऐसा document रह सकता है जिस पर आप आगे काम करें, न कि एक और one-off answer।
प्रोडक्ट लॉन्च करना और खोजा जाना अलग बातें हैं
लॉन्च के बाद सबसे अनिश्चित हिस्सा discovery है। मैंने wording, review process और document quality पर सच में मेहनत की। उसके बाद वह हिस्सा आता है जिसे मैं सीधे control नहीं कर सकता: लोग product को पाएँगे या नहीं।
भावनात्मक संस्करण है: “अब Google अपनी तरफ का काम करे।” तकनीकी रूप से बात कम आरामदायक है। Google की अपनी documentation कहती है कि requirements पूरी करने वाला page भी crawl, index या Search में serve होने की guarantee नहीं पाता। Crawling, indexing, ranking और traffic अलग चरण हैं; ध्यान से product ship करना इनमें से किसी को अपने आप पैदा नहीं करता।
Side projects के लिए यह फर्क उपयोगी है। मैं control कर सकता हूँ कि क्या बनाता हूँ, क्या publish करता हूँ और उसे कितनी सावधानी से समझाता हूँ। मैं यह control नहीं कर सकता कि search उसे कितनी जल्दी discover करेगा या discovery users में बदलेगी या नहीं।
इस प्रोजेक्ट से मैं क्या ले रहा हूँ
Growth धीमी रहे तब भी मुझे खुशी है कि मैंने Jurfi बनाया। मेरी सीख यह नहीं है कि legal drafting आसान है या AI मुश्किल हिस्से हटा देता है। बल्कि उलटा: दस्तावेज़ के परिणाम जितने गंभीर हों, explicit workflow और visible limits उतने ही महत्वपूर्ण होते हैं।
- जब output का रूप predictable हो, structured inputs इस्तेमाल करें।
- Generated text को working draft मानें, correctness का proof नहीं।
- Software assistance और professional judgment की सीमा साफ रखें।
- Review को workflow में रखें; generation को finish line न मानें।
- Product quality और search performance को अलग रखें; एक दूसरे की guarantee नहीं है।
jurfi.com के लिए मेरा मानक यही था: कम document chaos, कम repetitive work, और “मुझे यह document चाहिए” से “मेरे पास ऐसा draft है जिसे मैं सच में review कर सकता हूँ” तक साफ रास्ता।