घोषणापत्र

सॉफ़्टवेयर, सोच-समझकर लिखा गया।

एक छोटी कंपनी का दृष्टिकोण। हमें ब्रीफ़ भेजने से पहले इसे पढ़ें — अगर आप इससे गहराई से असहमत हैं, तो हम इस काम के लिए सही टीम नहीं हैं।

01 होल-स्टैक, फुल-सर्विस नहीं।

“फुल-सर्विस एजेंसी” उस संगठन का नाम है जो हैंडऑफ़ पर बना होता है। वेब टीम होस्टिंग टीम को दोष देती है। होस्टिंग टीम एप्लिकेशन टीम को दोष देती है। एप्लिकेशन टीम AI वेंडर को दोष देती है। विशेषज्ञों के बीच हर जोड़ एक ऐसी जगह है जहाँ जवाबदेही भाप बनकर उड़ जाती है।

हम हैंडऑफ़ नहीं करते क्योंकि हमारे पास ऐसे विशेषज्ञ ही नहीं हैं जिनके बीच काम सौंपा जाए। जो व्यक्ति Worker लिखता है वही AI प्रॉम्प्ट लिखता है, डेटाबेस स्कीमा डिज़ाइन करता है, फ़ायरवॉल कॉन्फ़िगर करता है, और जब कुछ गड़बड़ होती है तो रात 2 बजे प्रोडक्शन लॉग पढ़ता है। यह कोई ऐसी बाध्यता नहीं जिसके लिए हम माफ़ी माँगें — यही पूरा आधार है।

02 AI इंजीनियरिंग है, जादू नहीं।

2026 में अधिकांश AI फ़ीचर ऐसे लोग बनाते हैं जो भाषा मॉडलों को दैवीय वाणी की तरह मानते हैं। नतीजा ऐसा सॉफ़्टवेयर है जो कभी सही जवाब देता है, कभी मतिभ्रम करता है, और जिसे डीबग करना असंभव है क्योंकि किसी ने आर्किटेक्चर लिखा ही नहीं।

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

03 edge कोई भविष्य नहीं है। यह वर्तमान है, अधिकांशतः।

2026 में हर वह सर्वर-रेंडर पेज जो 800 ms लेता है, एक जानबूझकर किया गया चुनाव है — आमतौर पर वर्षों पहले किया गया और कभी दोबारा परखा नहीं गया। Cloudflare Workers 300 से अधिक शहरों में चलते हैं। जो कोड हैलिफ़ैक्स को सर्व करता है वही साओ पाउलो को सर्व करता है। कोई कारण नहीं कि अधिकांश मार्केटिंग साइटें, आंतरिक टूल और AI-संवर्धित API edge पर न रहें।

हम Cloudflare में विशेषज्ञता इसलिए नहीं रखते कि यह फ़ैशन में है, बल्कि इसलिए कि विकल्प — “हम AWS पर उसी तरह डिप्लॉय करते हैं जैसे टीम को सुविधाजनक लगता है” — हर बार वही आर्किटेक्चर पैदा करता है, चाहे वह वर्कलोड के अनुकूल हो या नहीं। विशेषज्ञता हमें हर समस्या के लिए सही प्रिमिटिव चुनने पर मजबूर करती है, बजाय परिचित की ओर हाथ बढ़ाने के।

04 हम चयनशील हैं — फ़िट को लेकर।

हम हर सप्ताह काम ठुकराते हैं, और लोगों को लिखित में कारण बताते हैं। इसलिए नहीं कि हम नखरे दिखाते हैं, बल्कि इसलिए कि गलत सहयोग किसी की मदद नहीं करता: आपको हमारा आधा ध्यान मिलता है, और हमें एक ऐसा प्रोजेक्ट जिस पर हम गर्व नहीं कर सकते। इसलिए हम शुरुआत में ही ईमानदार होते हैं कि आपकी ज़रूरत के लिए हम सही टीम हैं या नहीं।

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

05 कोड से पहले पन्ने पर शब्द, हमेशा।

हर सहयोग एक लिखित ब्रीफ़ से शुरू होता है — आपका — और एक लिखित जवाब से — हमारा। हर आर्किटेक्चर निर्णय कोड बनने से पहले एक दस्तावेज़ बनता है। हर स्प्रिंट एक लिखित चेंजलॉग के साथ बंद होता है। हम ऐसा इसलिए करते हैं क्योंकि लिखित रिकॉर्ड ही वह है जो बातचीत, पुनर्गठन, टीम बदलाव, और “हमने यह शिप किया” तथा “हमें इसे बढ़ाना है” के बीच गुज़रने वाले साल के बाद भी बचा रहता है।

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

06 हम परिणामों के लिए शुल्क लेते हैं, घंटों के लिए नहीं।

प्रति-घंटा अनुबंध दो बुरी प्रवृत्तियों को इनाम देता है: हमारी, ज़्यादा समय लेने की; आपकी, स्कोप को माइक्रो-मैनेज करने की। इसलिए हम घंटे के हिसाब से बिल नहीं करते। हम हर प्रोजेक्ट को स्कोप करते हैं, कोई भी काम शुरू होने से पहले एक निश्चित मूल्य पर सहमत होते हैं, और डिलीवरी की ज़िम्मेदारी लेते हैं — प्रतिबद्ध होने से पहले ही आप जानते हैं कि इसकी लागत क्या है और आपको क्या मिलेगा। न चलता हुआ मीटर, न आश्चर्यजनक चालान।

07 सॉफ़्टवेयर अंततः संचालक के लिए है।

जो टीम सॉफ़्टवेयर के साथ जीती है वही टीम है जिसने उसे लिखा, कभी-कभी वर्षों तक। पहले सप्ताह में सुंदर दिखने वाले निर्माण-चुनाव 104वें सप्ताह में परखे जाते हैं। हम ऐसी लाइब्रेरी नहीं चुनते जिनका GitHub पर एक ही मेंटेनर हो, ऐसे कॉन्फ़िगरेशन नहीं जो सिर्फ़ किसी के DM में दबे Slack संदेश की वजह से काम करते हों, या ऐसे वेंडर नहीं जिनका मूल्य मॉडल भविष्य के माइग्रेशन प्रोजेक्ट की नींव रखता हो। हम उस संचालक के लिए बनाते हैं जो लॉन्च के तीन साल बाद मौजूद होगा — भले ही वह संचालक आपकी टीम हो, हम नहीं।


SetKernel Digital Inc.
हैलिफ़ैक्स, नोवा स्कोटिया — दुनिया भर में सक्रिय

एक ब्रीफ़ लिखें