व्यक्तिगत सॉफ़्टवेयर का युग: आपके और आपके सात दोस्तों के लिए बनाए गए ऐप्स

आम लोगों के लिए सॉफ्टवेयर एक अस्थायी दौर है, स्थायी स्थिति नहीं। पिछले बीस वर्षों में बड़े पैमाने पर SaaS का प्रचलन वितरण के महंगे होने के कारण एक अस्थायी मोड़ था, और यह मोड़ अब तेज़ी से समाप्त हो रहा है।

कंप्यूटर के उदय के बाद पहली बार, एक व्यक्ति रविवार को नौ विशिष्ट लोगों के लिए एक कार्यशील ऐप लिख सकता है और सोने से पहले उसे प्रकाशित कर सकता है। यह कोई शौकिया काम नहीं है। यह सॉफ्टवेयर बनाने वाले, किसके लिए बनाया जाता है, और डिज़ाइन का अर्थ क्या है, इन सभी में एक संरचनात्मक बदलाव है।

व्यक्तिगत सॉफ्टवेयर वास्तव में क्या है

व्यक्तिगत सॉफ्टवेयर वह सॉफ्टवेयर है जिसे एक व्यक्ति द्वारा बनाया जाता है, अक्सर अपने लिए, कभी-कभी दस विशिष्ट लोगों के लिए, और लगभग कभी भी किसी बाज़ार के लिए नहीं। यह जानबूझकर विशिष्ट बनाया जाता है, संयोग से नहीं। निर्माता प्रत्येक उपयोगकर्ता को नाम से जानता है।

जियोफ्रे लिट वर्षों से लचीले सॉफ्टवेयर के बारे में लिख रहे हैं, यह विचार कि किसी टूल का उपयोग करने वाले लोग भी इसे नया रूप दे सकें। लिनस ली अपने स्वयं के चिंतन के लिए छोटे-छोटे टूल बनाते हैं। मैगी एपलटन ने उन गैर-इंजीनियरों की लहर के लिए "बेयरफुट डेवलपर्स" शब्द गढ़ा, जो अब काम करने योग्य सॉफ़्टवेयर बना सकते हैं क्योंकि ऐसा करने की लागत बहुत कम हो गई है।

इन बातों को मिलाकर देखें तो एक श्रेणी बनती है: ऐसा सॉफ़्टवेयर जिसका लक्षित दर्शक निर्माता और उसके कुछ मित्र, परिवार या सहकर्मी होते हैं, और जिसका मूल्य उस छोटे समूह को सटीक रूप से संतुष्ट करने में निहित है।

अब क्यों, और 2015 में क्यों नहीं

दो चीजें एक साथ बदल गईं। एआई सहायकों ने एक व्यक्ति के लिए एक दोपहर में एक वास्तविक ऐप बनाना किफायती बना दिया। और वितरण लागत, होस्टिंग, परिनियोजन, भुगतान, प्रमाणीकरण, शून्य या लगभग शून्य हो गईं।

2015 में, एक विशिष्ट ऐप बनाने का मतलब था छह महीने की रातें और सप्ताहांत, तीन दिनों में Stripe एकीकरण, और एक सप्ताह में परिनियोजन प्रक्रिया को मजबूत करना। स्टार्टअप से छोटे किसी भी व्यवसाय के लिए यह गणित काम नहीं करता था। उपयोग के मामलों की व्यापक श्रृंखला पहुंच से बाहर थी।

2026 में, वही ऐप एक प्रॉम्प्ट, एक Vercel डिप्लॉयमेंट और एक Convex स्कीमा बन जाता है। किसी सॉफ़्टवेयर के लिए न्यूनतम आर्थिक दर्शक वर्ग "हज़ारों" से घटकर "आप और आपके सात दोस्त" रह जाता है। यह टूलिंग में सुधार नहीं है। यह श्रेणी के लिए एक नया द्वार खोलता है।

तीसरा कारक है पसंद। डिज़ाइनरों और प्रयोगकर्ताओं की एक पीढ़ी सॉफ़्टवेयर पर पली-बढ़ी है, उन्होंने अपने द्वारा प्रतिदिन उपयोग किए जाने वाले ऐप्स में खामियों के बारे में अपनी राय बना ली है, और अब उनके पास किसी की अनुमति मांगे बिना उन्हें ठीक करने के साधन हैं।

वास्तविक उदाहरण, काल्पनिक नहीं

यह कोई सैद्धांतिक प्रयोग नहीं है। व्यक्तिगत सॉफ़्टवेयर पहले से ही कई लैपटॉप पर चल रहा है।

लोग Notion को अपने घर के लिए एक निजी मिनी-सीएमएस के रूप में चलाते हैं, जिसमें ऐसे व्यू और टेम्प्लेट होते हैं जो परिवार के बाहर किसी के लिए भी समझ से परे होंगे। रिप्लिट और लवेबल जैसे साइड प्रोजेक्ट एक शाम में तैयार हो जाते हैं, दस सहकर्मी इनका इस्तेमाल करते हैं, और सालों तक चुपचाप असली काम संभालते रहते हैं। पारिवारिक शेड्यूलर, कस्टम इनवॉइस जनरेटर, फूड-प्लान-पाई जैसे खास मील प्लानर, ये सभी चार से पंद्रह लोगों के लिए चलते हैं।

लचीले सॉफ्टवेयर का चलन ऐसे टूल बना रहा है जिनमें उपयोगकर्ता ही एडिटर होता है। ताना लोगों को टेम्पलेट में फिट होने के बजाय अपने खुद के सूचना सिस्टम बनाने की सुविधा देता है। कैपेसिटीज भी ऐसा ही काम करता है। ऑब्सीडियन का प्लगइन इकोसिस्टम व्यक्तिगत टूल की एक पूरी अर्थव्यवस्था है जिसे लगभग एक जैसी सोच वाले लोग आपस में साझा करते हैं।

पैटर्न: एक निर्माता, सीमित उपयोगकर्ता, सीमित दायरे। किसी भी चीज़ का विस्तार नहीं किया जा रहा है। किसी भी चीज़ का विपणन नहीं किया जा रहा है। सॉफ्टवेयर बस मौजूद है, उन लोगों के लिए जिनके लिए इसे बनाया गया था, और यही इसका पूरा उद्देश्य है।

यह नो-कोड से कैसे अलग है

नो-कोड टेम्पलेटेड सॉफ्टवेयर था। पर्सनल सॉफ्टवेयर खास तौर पर बनाया गया सॉफ्टवेयर है। अंतर उद्देश्य का है।

एक नो-कोड टूल आपको एक लेगो सेट देता है और आपसे कैटलॉग में दिखाए गए घर जैसा घर बनाने को कहता है। इसका पूरा मकसद यह है कि हजारों लोग एक ही प्लेटफॉर्म पर मिलते-जुलते घर बनाएंगे। अर्थव्यवस्था इसी पर निर्भर करती है।

व्यक्तिगत सॉफ्टवेयर एक अलग सवाल से शुरू होता है। सवाल यह नहीं होता कि "कौन सा टेम्पलेट मेरी ज़रूरत के हिसाब से सही है", बल्कि यह होता है कि "मेरी वास्तविक स्थिति क्या चाहती है, और मैं उसे कैसे कोड करूं।" निर्माता विकल्पों में से चुनाव नहीं कर रहा होता। वह अक्सर सरल अंग्रेजी में एक एआई सहायक को अपना उद्देश्य बताता है, और उसे एकदम सटीक कोड मिल जाता है।

यह इसलिए महत्वपूर्ण है क्योंकि टेम्पलेटेड टूल्स की एक सीमा होती है। टेम्पलेट में फिट न होने वाली कोई भी चीज़ हटा दी जाती है, जबकि कस्टमाइज़्ड टूल्स की ऐसी कोई सीमा नहीं होती। अगर आपके अकाउंटिंग में "काइल को इस महीने उसकी दस प्रतिशत की निश्चित दर पर मिलने वाली राशि" के लिए एक कॉलम की ज़रूरत है, तो आप बस उसे जोड़ देते हैं। किसी विक्रेता के अनुरोध की ज़रूरत नहीं, किसी फीचर बैकलॉग की ज़रूरत नहीं, किसी इंतज़ार की ज़रूरत नहीं।

अंत में लंबी पूंछ नीचे तक पहुंचती है

क्रिस एंडरसन ने 2004 में लंबी पूंछ का वर्णन किया था, लेकिन सॉफ्टवेयर कभी भी उस स्तर तक नहीं पहुंच पाया। मास-मार्केट SaaS कर्व के शीर्ष और मध्य वर्ग को लाभप्रद रूप से सेवा प्रदान कर सकता था। इसके बाद का सारा क्षेत्र ऐसी अधूरी जरूरतों का बंजर इलाका था, जो किसी कंपनी के लिए औचित्य साबित नहीं करता था।

पर्सनल सॉफ्टवेयर उस बंजर इलाके को भरता है। वे उपयोग के मामले जो कभी स्टार्टअप को सहारा देने के लिए पर्याप्त बड़े नहीं थे, विशिष्ट कार्यप्रवाह, घर-घर की विचित्रताएं, छह लोगों की टीम के लिए उपकरण, अब एक व्यक्ति द्वारा बनाए गए ऐप्स का स्वाभाविक निवास स्थान हैं।

अर्थव्यवस्था उलट गई। आठ उपयोगकर्ताओं वाला उपयोग का मामला पहले असंभव था। अब यह आसानी से बनाया जा सकता है। इसे दस लाख सूक्ष्म क्षेत्रों में गुणा करें और आपको एक ऐसी सॉफ्टवेयर अर्थव्यवस्था मिलेगी जो ऐप स्टोर के शीर्ष चार्ट से बिल्कुल अलग दिखती है।

क्या खत्म होता है, क्या जीवित रहता है, क्या बढ़ता है

सभी SaaS को पर्सनल सॉफ्टवेयर द्वारा निगल लिया जाना संभव नहीं है। यह बदलाव असमान है, और यदि आप देखें कि वास्तव में मूल्य कहां है, तो विजेता और हारने वाले पूर्वानुमानित हैं।

सबसे पहले खत्म होने वाला है विशिष्ट उपयोग के मामलों को लक्षित करने वाला मास-मार्केट SaaS। "हम डॉग वॉकर्स के लिए Notion हैं" वाली श्रेणी। जिसका भी उत्पाद किसी सामान्य मूलभूत चीज़ पर आधारित एक विशिष्ट तकनीक है, वह अब एक आम आदमी और एक प्रॉम्प्ट से प्रतिस्पर्धा कर रहा है। इस लड़ाई का अंत एक ही दिशा में होता है।

जो चीज़ें टिकी रहती हैं और बढ़ती हैं, वे हैं प्लेटफ़ॉर्म, मूलभूत चीज़ें और बुनियादी ढांचा। Convex, Vercel, Supabase, Stripe, Clerk, AI प्रदाता, Replit, Lovable। जैसे-जैसे ज़्यादा लोग सॉफ़्टवेयर बनाते हैं, वैसे-वैसे बुनियादी ढांचे का दायरा बढ़ता जाता है, छोटा नहीं। डिज़ाइन सिस्टम की मूलभूत चीज़ों, UI लाइब्रेरी, आइकन सेट और उन प्रमाणीकरण प्रवाहों के लिए भी यही बात लागू होती है जिनका हर कोई पुन: उपयोग करता है।

जो चीज़ें टिकी रहती हैं, वे हैं वास्तविक जन-बाजार सॉफ़्टवेयर जिनका उपयोग वास्तव में सार्वभौमिक है। ईमेल, कैलेंडर, ब्राउज़र, ऑपरेटिंग सिस्टम, खोज, सोशल ग्राफ़। व्यक्तिगत सॉफ़्टवेयर WhatsApp की जगह नहीं लेता। यह उस प्रोजेक्ट मैनेजमेंट टूल की जगह लेता है जिसके लिए पंद्रह लोगों की एक एजेंसी हर महीने आठ सौ डॉलर का भुगतान कर रही थी।

मास-मार्केट SaaS बनाम पर्सनल सॉफ्टवेयर, साथ-साथ

दोनों मॉडलों को एक ही टेबल पर रखने से यह अंतर आसानी से समझ में आ जाता है।

| आयाम | मास-मार्केट SaaS | पर्सनल सॉफ्टवेयर |

|-----------|------------------|-------------------|

| लक्षित दर्शक | हजारों से लाखों | एक से कुछ दर्जन |

| पोजिशनिंग | "उन टीमों के लिए जो X करती हैं" | "मेरे और सात दोस्तों के लिए" |

| वितरण | सशुल्क विज्ञापन, SEO, बिक्री टीम | ग्रुप चैट में भेजा गया |

| मूल्य निर्धारण | प्रति सीट मासिक सदस्यता | एकमुश्त शुल्क, दान, या दोस्तों के बीच मुफ़्त |

| डिज़ाइन प्राथमिकता | साठ सेकंड में किसी अजनबी को ऑनबोर्ड करें | किसी परिचित व्यक्ति के लिए पूरी तरह से उपयुक्त |

| अनुकूलन | सेटिंग्स मेनू, फ़ीचर फ़्लैग | स्रोत संपादित करें, AI से इसे बदलने के लिए कहें |

| जीवनकाल लक्ष्य | अनिश्चित, निरंतर नई सुविधाओं के साथ | उपयोग का मामला जब तक बना रहता है, उसके बाद संग्रहीत |

| निर्माता प्रोत्साहन | बाजार पर कब्जा करें | एक विशिष्ट समस्या का समाधान करें |

डिजाइन प्राथमिकता वाली पंक्ति पर ध्यान दें। यहीं पर डिजाइनर की भूमिका में सबसे बड़ा बदलाव आता है।

डिजाइनर का नया काम

यदि आप एक डिजाइनर हैं, तो आपके अधीन काम करने का तरीका बदल जाता है। मास-मार्केट डिजाइन में अजनबियों को शामिल करना, सबसे खराब स्थिति के लिए बाधाओं को कम करना और संदर्भ को कभी भी मानकर न चलना शामिल है। पर्सनल सॉफ्टवेयर डिजाइन संदर्भ को मानकर चलता है, उपयोगकर्ताओं को नाम देता है और सामान्यता के बजाय उपयुक्तता को प्राथमिकता देता है।

नए डिजाइन कार्य में तीन मुख्य चरण हैं: संदर्भ स्थापित करना, विवेक का प्रयोग करना और संपादन करना।

संदर्भ स्थापित करने का अर्थ है किसी एआई सहायक या छोटी टीम को यह बताना कि यह किसके लिए है ताकि आउटपुट सटीक हो। "एक मील प्लानर डिजाइन करें" नहीं, बल्कि "चार लोगों के परिवार के लिए एक मील प्लानर डिजाइन करें, जिसमें एक व्यक्ति शाकाहारी हो, बच्चों को टेक्सचर पसंद न हो और रसोइए के पास सप्ताह के दिनों में केवल तीस मिनट हों।" ब्रीफ ही डिजाइन है।

विवेक ही फिल्टर है। जब कोड सस्ता हो और प्रॉम्प्ट मुफ्त हों, तो मुख्य समस्या यह होती है कि आउटपुट अच्छा है या नहीं। एक डिज़ाइनर का काम यह जानना है कि इस विशिष्ट समूह के लिए अच्छा क्या दिखता है और उससे मेल न खाने वाली हर चीज़ को अस्वीकार करना है। कम ड्राइंग, ज़्यादा मूल्यांकन।

संपादन ही पुनरावृति है। व्यक्तिगत सॉफ़्टवेयर को इंजीनियरों को सौंपकर तुरंत शिप नहीं कर दिया जाता, बल्कि इसे समय के साथ, अक्सर लाइव, उस डिज़ाइनर द्वारा आकार दिया जाता है जो निर्माता भी होता है या निर्माता के बगल में बैठा होता है। Figma फ़ाइल अब अंतिम उत्पाद नहीं है। चल रहा ऐप ही अंतिम उत्पाद है।

10 लोगों के समूह के लिए डिज़ाइन कैसे करें

दस लोगों के लिए डिज़ाइन करना दस हज़ार लोगों के लिए डिज़ाइन करने का छोटा संस्करण नहीं है। यह एक अलग विधा है। यहाँ सात सिद्धांत दिए गए हैं जो इस पर खरे उतरते हैं।

1. प्रत्येक उपयोगकर्ता का नाम लिखें। सचमुच, एक सूची बनाएं। जानें कि प्रत्येक व्यक्ति को क्या चाहिए, क्या नापसंद है और क्या बर्दाश्त कर सकता है। यदि आप वह दस्तावेज़ नहीं लिख सकते, तो आप अभी भी एक अमूर्त अवधारणा के लिए डिज़ाइन कर रहे हैं।

2. ऑनबोर्डिंग को छोड़ दें। आपके उपयोगकर्ताओं को किसी परिचय की आवश्यकता नहीं है, वे आपके मित्र हैं। उन्हें पहले से कॉन्फ़िगर किए गए ऐप में डालें। प्रश्न के बजाय उत्तर को डिफ़ॉल्ट रूप से चुनें।

3. औसत के बजाय विशिष्ट उपयोगकर्ता के लिए अनुकूलित करें। दस उपयोगकर्ताओं में औसत उपयोगकर्ता जैसी कोई चीज़ नहीं होती। वहाँ केवल आरोन है, जिसे डार्क मोड पसंद है, और सेरिना है, जिसे कीबोर्ड शॉर्टकट की आवश्यकता है। दोनों को अपनी ज़रूरत की चीज़ें मिल जाती हैं।

4. इसे सही जगहों पर थोड़ा भद्दा होने दें। व्यक्तिगत सॉफ़्टवेयर को मार्केटिंग साइट, मूल्य निर्धारण पृष्ठ या आकर्षक चित्र की आवश्यकता नहीं होती। होम स्क्रीन एक सूची हो सकती है, सेटिंग्स एक JSON फ़ाइल हो सकती हैं। अपनी पसंद को वहाँ दिखाएँ जहाँ वह महसूस हो, न कि जहाँ उसकी अपेक्षा की जाती है।

5. इसे संपादन योग्य बनाएँ। आपके उपयोगकर्ता बदलाव चाहेंगे। इस तरह से डिज़ाइन करें जिससे ये बदलाव आसान हों, भले ही इसका मतलब थोड़ा कम परिष्कृत होना हो। इस स्तर पर लचीलापन परिष्करण से बेहतर है।

6. सभी उपकरणों के लिए नहीं, बल्कि एक उपकरण के लिए डिज़ाइन करें। यदि आपके उपयोगकर्ता लैपटॉप पर ऐप का उपयोग करते हैं, तो मोबाइल को अनदेखा करें। यदि वे फ़ोन पर इसका उपयोग करते हैं, तो डेस्कटॉप को अनदेखा करें। यूनिवर्सल रिस्पॉन्सिव डिज़ाइन एक जन-बाजार सोच है।

7. आर्काइव करने की योजना बनाएं, हमेशा के लिए नहीं। इस सॉफ़्टवेयर को हमेशा के लिए चलने की ज़रूरत नहीं है। इसे तब तक काम करना चाहिए जब तक इसका उपयोग होता रहे। उपयोग समाप्त होने पर, इसे बिना किसी औपचारिकता के आर्काइव कर दें।

बेयरफुट डेवलपर लहर

मैगी एपलटन का शब्द "बेयरफुट डेवलपर" उस चीज़ को दर्शाता है जिसे उद्योग अब तक नज़रअंदाज़ करता रहा है। सॉफ़्टवेयर निर्माताओं की अगली पीढ़ी ऐसे इंजीनियर नहीं हैं जिन्होंने डिज़ाइन करना सीखा है। ये डिज़ाइनर, लेखक, शोधकर्ता, लेखाकार, शिक्षक और ऑपरेटर हैं जिन्होंने सॉफ़्टवेयर को लॉन्च करना सीखा है।

ये लोग कभी भी बूटकैंप में जाकर लाखों की इंजीनियरिंग नौकरी नहीं करने वाले थे। उनके पास अपनी रोज़मर्रा की नौकरियां, अपना जीवन और कुछ खास समस्याएं हैं जिनका वे समाधान चाहते हैं। अब उनके पास जो है वह यह है कि वे अपनी ज़रूरत को अंग्रेज़ी में बता सकते हैं, काम करने वाला कोड प्राप्त कर सकते हैं और उसे लैपटॉप या मुफ़्त संस्करण पर चला सकते हैं।

व्यक्तिगत सॉफ़्टवेयर का निर्माण मुख्य रूप से इन्हीं लोगों द्वारा किया जा रहा है। पूर्णकालिक संस्थापकों द्वारा नहीं। जिन लोगों के पास डोमेन का अच्छा ज्ञान है, इंजीनियरिंग कौशल कमजोर है, और जो AI असिस्टेंट के साथ तब तक काम करने का धैर्य रखते हैं जब तक कि वह सही ढंग से काम न करने लगे। इसका परिणाम यह होता है कि सॉफ्टवेयर उन लोगों द्वारा तैयार किया जाता है जो वास्तव में समस्या को समझते हैं, और यह सॉफ्टवेयर उद्योग में लंबे समय से चली आ रही कमी है।

इसका दूसरा प्रभाव यह है कि व्यक्तिगत सॉफ्टवेयर में डिजाइन की समझ बड़े पैमाने पर बिकने वाले SaaS की तुलना में अधिक स्पष्ट होती है। निर्माता कोई जूनियर प्रोजेक्ट मैनेजर नहीं होता जिसे केवल अपने रोडमैप का बचाव करना हो, बल्कि वह व्यक्ति होता है जो समस्या के साथ जी रहा होता है। जब उन्हें कुछ खराब या गलत दिखता है, तो वे उसे उसी समय ठीक कर देते हैं। फीडबैक प्रक्रिया इतनी सक्रिय होती है कि खराब डिजाइन एक सप्ताह भी नहीं टिक पाता।

सॉफ्टवेयर निर्माण में क्या बदलाव आते हैं

जब उपयोगकर्ता सीमित होते हैं और निर्माता करीब होता है, तो सॉफ्टवेयर निर्माण की प्रक्रिया बदल जाती है। डिफ़ॉल्ट सेटिंग्स बदल जाती हैं। समझौते अलग-अलग जगहों पर होते हैं।

विश्वसनीयता अधिक लचीली हो जाती है। अगर ऐप दस लोगों के लिए काम करना बंद कर देता है, तो निर्माता को ग्रुप चैट में इसकी जानकारी मिल जाती है और वे इसे ठीक कर देते हैं। कोई SLA नहीं है, कोई ऑन-कॉल रोटेशन नहीं है, कोई एस्केलेशन नहीं है। यह सुनने में बुरा लगता है, लेकिन जब आप यह समझते हैं कि मास-मार्केट SaaS की विश्वसनीयता का दिखावा असल में उपयोगकर्ता पर एक बोझ है, तो बात अलग है।

कस्टमाइज़ेशन एक फीचर के बजाय डिफ़ॉल्ट बन जाता है। मास-मार्केट सॉफ़्टवेयर कस्टमाइज़ेशन को एक सेटिंग्स मेनू की तरह मानते हैं, निर्माता द्वारा अनिच्छा से जोड़े गए टॉगल की एक सूची की तरह, जबकि पर्सनल सॉफ़्टवेयर इसे मूल तत्व मानते हैं। अगर आप कोई कॉलम जोड़ना चाहते हैं, तो निर्माता उसे जोड़ देता है, और अगर आप रंग बदलना चाहते हैं, तो वे बदल जाते हैं। उत्पाद का कोई निश्चित स्वरूप नहीं होता जिस पर तिमाही रोडमैप के साथ पुनर्विचार किया जाता हो।

डॉक्यूमेंटेशन अलग दिखता है। दस उपयोगकर्ताओं वाले टूल के लिए README में संदर्भ का एक पैराग्राफ, एक स्क्रीनशॉट और निर्माता का फ़ोन नंबर होता है। तीस-पृष्ठ का नॉलेज बेस, इन-ऐप टूर, सहायता लेख, चैट विजेट, ये सब अनावश्यक हैं जिनकी छोटे उपयोगकर्ता वर्ग को आवश्यकता नहीं है।

प्रदर्शन संबंधी विकल्प बदलते हैं। आप अपने भरोसेमंद दस उपयोगकर्ताओं के लिए एक धीमा ऐप भेज सकते हैं क्योंकि वे आपको बता देंगे कि यह कब बाधा बन रहा है। आप लाखों अजनबियों के लिए धीमा ऐप नहीं भेज सकते। व्यक्तिगत सॉफ़्टवेयर में बहुत सारे प्रारंभिक अनुकूलन की आवश्यकता नहीं होती है।

नैतिकता, पोर्टफोलियो और मूल्य निर्धारण के लिए इसका क्या अर्थ है

व्यक्तिगत सॉफ़्टवेयर डेटा स्वामित्व, लॉक-इन और दीर्घायु के बारे में वास्तविक प्रश्न उठाता है, और इनके उत्तर अधिकांशतः SaaS द्वारा दिए गए उत्तरों से बेहतर हैं। डेटा वहीं रहता है जहाँ आप इसे रखते हैं, अक्सर आपके अपने डेटाबेस में या आपके नियंत्रण वाली फ़ाइल में। लॉक-इन कम होता है क्योंकि निर्माता स्वयं मौजूद होता है, कोई विक्रेता नहीं जिसके पास आपको फंसाए रखने के कारण हों।

दीर्घायु अधिक कठिन है। व्यक्तिगत सॉफ़्टवेयर तब समाप्त हो जाता है जब उसका निर्माता उसका रखरखाव बंद कर देता है, जो कि होता है। इसका सीधा जवाब यह है कि यह ठीक है। अधिकांश सॉफ़्टवेयर हमेशा के लिए नहीं चलने चाहिए, और उपयुक्तता और स्वामित्व के बदले में आपको यह स्वीकार करना होगा कि ऐप दो साल तक चल सकता है और फिर समाप्त हो सकता है।

मूल्य निर्धारण मॉडल में बदलाव आता है क्योंकि मूल्य की इकाई बदल जाती है। प्रति सीट मासिक सदस्यताएँ एक बाजार को मानकर चलती हैं। व्यक्तिगत सॉफ़्टवेयर के ग्राहक नहीं बल्कि क्लाइंट होते हैं, और क्लाइंट अलग तरह से भुगतान करते हैं।

परियोजना के लिए निश्चित शुल्क, चल रहे संपादनों के लिए रिटेनर संबंध, मित्रों के बीच उपहार अर्थव्यवस्था, विशिष्ट सुविधाओं के लिए इनाम-शैली का भुगतान। निर्माता SaaS नहीं चला रहा है। वे एक छोटी सी कस्टम शॉप चला रहे हैं, या अपने प्रियजनों के लिए मुफ्त में निर्माण कर रहे हैं। दोनों ही अब आर्थिक रूप से व्यवहार्य हैं।

अपनी सेवाएं बेचने वाले डिज़ाइनरों के लिए, बदलाव "SaaS लॉन्च के लिए डिज़ाइन सिस्टम" से "किसी विशिष्ट टीम या परिवार के लिए एक विशेष टूल डिज़ाइन और निर्माण" की ओर है। डिलीवरेबल चलने वाला ऐप है, न कि Figma फ़ाइल। मूल्य निर्धारण हल की गई समस्या के मूल्य पर आधारित है, न कि बिल किए गए घंटों पर।

पोर्टफोलियो के लिए, काम अधिक विचित्र दिखेगा। कम पॉलिश वाली मार्केटिंग साइटें, वास्तविक समूहों के लिए वास्तविक समस्याओं को हल करने वाले विचित्र आंतरिक टूल के अधिक स्क्रीनशॉट। केस स्टडी यह नहीं है कि "हमने एक सीरीज़ बी स्टार्टअप के लिए डैशबोर्ड को फिर से डिज़ाइन किया।" यह है कि "हमने तीस अभिभावकों के लिए एक स्कूल ट्रिप आयोजन टूल बनाया और इसका वास्तव में उपयोग हुआ।"

इस साल डिज़ाइनरों को क्या करना चाहिए

बदलाव हो रहा है, चाहे आप इसमें हिस्सा लें या न लें। 2026 में समझदारी भरा कदम क्या होगा, यहाँ बताया गया है।

अपने लिए बनाना शुरू करें। अपनी ज़िंदगी या काम से जुड़ी कोई ऐसी समस्या चुनें जिसका आप सच में सामना कर रहे हों, और Replit, Lovable, Cursor या सिर्फ़ Claude Code और एक Vercel अकाउंट का इस्तेमाल करके टूल बनाएं। मकसद टूल्स सीखना नहीं है, बल्कि यह महसूस करना है कि किसी सॉफ़्टवेयर के लिए पूरी टीम का हिस्सा बनना कैसा होता है।

अपने जान-पहचान के दस लोगों के लिए बनाना शुरू करें। एक निजी टूल बनाने के बाद, एक छोटे समूह के लिए बनाएं। परिवार, क्लब, या काम पर टीम। ध्यान दें कि जब आप हर उपयोगकर्ता को नाम से जानते हैं तो डिज़ाइन संबंधी निर्णय कैसे बदलते हैं।

अपने डिज़ाइन कार्य को बड़े पैमाने पर बाज़ार के लिए तैयार किए गए दिखावे के इर्द-गिर्द सीमित न रखें। अपनी स्थिति बदलें। बाज़ार अब "बड़े पैमाने पर उपयोगकर्ताओं के लिए सहज ऑनबोर्डिंग" नहीं खरीद रहा है। वह "उपयुक्तता, पसंद और वास्तविक उत्पाद को सफलतापूर्वक लॉन्च करने की क्षमता" खरीद रहा है। इसे अपने पोर्टफोलियो में प्रदर्शित करें।

लचीले सॉफ़्टवेयर लेखन पर ध्यान दें। लिट, ली, एपलटन, इंक और स्विच के सहयोगी, ट्विटर और Threads पर छोटे टूल बनाने वाले। व्यक्तिगत सॉफ़्टवेयर की शब्दावली, पैटर्न और डिज़ाइन भाषा इन चर्चाओं में अभी आकार ले रही है। इसमें पारंगत हो जाएं।

व्यक्तिगत सॉफ़्टवेयर का युग पिछले पंद्रह वर्षों में सॉफ़्टवेयर डिज़ाइन में सबसे दिलचस्प घटना है। बड़े पैमाने पर SaaS उन श्रेणियों में मौजूद रहेगा जहां यह उपयुक्त है। लेकिन अब एक बड़ा बाज़ार खुल गया है, और जो लोग सबसे पहले वहां पहुंचेंगे, वे ही यह परिभाषित करेंगे कि दस लोगों के दर्शकों के लिए डिज़ाइन का क्या अर्थ है। उनमें से एक बनें।

hero: key: hero prompt: "Voxel illustration. A small house-sized app glowing warmly, with 10 little floating screens around it, each tailored to a different person. Soft pastel. Editorial. The composition does not include any human figures." alt: "Voxel illustration of a small house-sized app glowing warmly with ten tiny tailored screens floating around it" width: 1600 height: 900 inline-1: key: mass-vs-personal prompt: "Voxel split illustration: left, a giant generic SaaS dashboard. Right, ten tiny bespoke apps, each warm and specific. Soft pastel. The composition does not include any human figures." alt: "Voxel split image showing one giant generic SaaS dashboard on the left and ten tiny bespoke apps on the right" width: 1400 height: 900 inline-2: key: distribution-collapse prompt: "Voxel illustration showing a long-tail curve labeled 'use cases' with tiny apps populating the previously-empty tail. Soft pastel." alt: "Voxel long-tail curve labeled use cases with tiny apps filling the previously empty tail" width: 1400 height: 900 inline-3: key: design-for-ten prompt: "Voxel illustration of a designer's workspace tuned for an audience of 10: name tags on the wall, context notes, an obvious local fit. Soft pastel. The composition does not include any human figures." alt: "Voxel designer workspace with name tags and context notes tuned for an audience of ten" width: 1400 height: 900 inline-4: key: what-dies-what-survives prompt: "Voxel illustration: on one side, generic SaaS dashboards crumbling into mist. On the other, infrastructure platforms growing taller. Soft pastel. The composition does not include any human figures." alt: "Voxel illustration of generic SaaS dashboards crumbling on one side and infrastructure platforms growing on the other" width: 1400 height: 900