2026 में मैं अकेले डेवलपर के रूप में Android ऐप्स कैसे लॉन्च करता हूँ

2026 में अकेले Android ऐप लॉन्च करने का सबसे कठिन हिस्सा कोड नहीं है। Compose परिपक्व हो चुका है, Play की टूलिंग अच्छी है, और इतनी लाइब्रेरियाँ हैं जितनी पढ़ने का समय किसी के पास नहीं। कठिन हिस्सा है पूरा करना। स्कोप फैलता जाता है, पॉलिश कैलेंडर को निचोड़ देती है, और एक दिन आपको एहसास होता है कि तीन महीने पहले शुरू किया ऐप तकनीकी रूप से ज़्यादा प्रभावशाली है और फिर भी स्टोर पर नहीं है।

मैंने इसी तरह दो ऐप्स लॉन्च किए हैं, तीसरा तैयारी में है, और आख़िरकार मैं एक ऐसी प्लेबुक पर आ टिका हूँ जो मुझे विचार से लाइव लिस्टिंग तक लगभग चार से छह हफ़्तों में पहुँचा देती है। इसमें कुछ भी चतुराई भरा नहीं है। यह सब चीज़ों को “नहीं” कहने के बारे में है।

1. बेरहमी से स्कोप तय करें — एक स्क्रीन, एक क्रिया

कोई भी Kotlin लिखने से पहले, मैं एक ही अभ्यास करता हूँ: ऐप को एक क्रिया वाले एक वाक्य में बताना। Granyn — दो टैप में एक खर्च दर्ज करो। Hydrame — पानी पीना भूलने से पहले एक शांत याद दिलावा पाओ। Subly — एक बिल की तस्वीर लो और डिवाइस पर ही सब्सक्रिप्शन निकाल लो। अगर वाक्य में “और” है, तो ऐप दो ऐप हैं।

यही एक वाक्य हर फ़ीचर के फ़ैसले का नियम बन जाता है। चार्ट? सिर्फ़ तभी जब वे क्रिया का साथ दें। क्लाउड सिंक? सिर्फ़ तभी जब उसके बिना क्रिया टूट जाए। सेटिंग्स? जितनी कम, उतना अच्छा। अकेले डेवलपमेंट की सबसे कम आँकी गई तरकीब है चीज़ें न बनाना।

अगर आपकी एक-वाक्य वाली पिच में “और” है, तो आप दो ऐप बना रहे हैं।

इसे लागू करने का एक असली तरीक़ा: कोई कोड लिखने से पहले Play Store लिस्टिंग लिखें — टाइटल, छोटा विवरण, 80-अक्षरों वाला सबटाइटल। अगर आप ऐप को 80 अक्षरों में नहीं बेच सकते, तो उसे आठ हफ़्तों में बना भी नहीं सकते।

2. एक छोटा, उबाऊ स्टैक चुनें

2026 में Android के लिए, मेरा पूरा स्टैक जानबूझकर छोटा है:

• Kotlin + Jetpack Compose (कोई XML लेआउट नहीं, कोई fragment नहीं)
• androidx.navigation.compose के साथ सिंगल-एक्टिविटी
• स्थानीय हर चीज़ के लिए Flow और suspend फ़ंक्शन के साथ Room
• सेटिंग्स के लिए DataStore (preferences वाला रूप)
• बैकग्राउंड के लिए WorkManager, और सिर्फ़ वहीं जहाँ सटीकता ज़रूरी हो AlarmManager
• कंपोनेंट्स के लिए एक कस्टम कलर स्कीम के साथ Material 3
• DI के लिए Hilt — पर सिर्फ़ तभी जब ऐप इतना बड़ा हो कि उसकी ज़रूरत पड़े (Granyn हाँ, एक छोटी सी यूटिलिटी नहीं)

बस यही पूरी सूची है। KSP-भारी जेनरेटर नहीं, नेटवर्किंग लेयर तब तक नहीं जब तक ऐप सचमुच किसी सर्वर से बात न करे, थर्ड-पार्टी UI किट नहीं। नियम: एक नई डिपेंडेंसी को build.gradle.kts में अपनी पंक्ति एक-वाक्य के औचित्य से कमानी होगी जिसे मैं लिखकर देने को तैयार हूँ।

3. पहले उबाऊ स्क्रीन बनाएँ

अंतर्ज्ञान के उलट, पर सच: मैं हीरो फ़ीचर से पहले सबसे कम रोमांचक स्क्रीन बनाता हूँ। खाली स्थितियाँ, सेटिंग्स, ऑनबोर्डिंग, “अभी कोई डेटा नहीं” वाले प्लेसहोल्डर। ये डेटा मॉडल और नेविगेशन ग्राफ़ को किसी भी चीज़ से तेज़ उजागर करते हैं, और यही वे स्क्रीन हैं जिनसे आप बाद में डरेंगे अगर उन्हें अंत के लिए बचाकर रखा।

हीरो फ़ीचर तीसरे या चौथे नंबर पर आता है। जब तक मैं वहाँ पहुँचता हूँ, डेटा लेयर पहले ही उन उबाऊ स्क्रीनों द्वारा डिज़ाइन हो चुकी होती है जिन्हें उससे पढ़ना था।

एक न्यूनतम ढाँचा जिसे मैं हर प्रोजेक्ट में दोबारा इस्तेमाल करता हूँ:

@Composable
fun App() {
    val navController = rememberNavController()
    Scaffold(
        bottomBar = { AppBottomBar(navController) },
    ) { inner ->
        NavHost(
            navController = navController,
            startDestination = Routes.Home,
            modifier = Modifier.padding(inner),
        ) {
            composable(Routes.Home) { HomeScreen() }
            composable(Routes.Stats) { StatsScreen() }
            composable(Routes.Settings) { SettingsScreen() }
        }
    }
}

मेरे आधे ऐप्स का पूरा “आर्किटेक्चर” बस यही है।

4. डेटा मॉडल जल्दी तय करें, हमेशा माइग्रेट करें

स्कीमा माइग्रेशन इंडी ऐप्स के ख़ामोश हत्यारे हैं। हल है डेटाबेस को एक पब्लिक API की तरह सोचना — एक बार प्रोडक्शन में आ जाने पर, हर बदलाव एक टेस्ट के साथ आने वाला माइग्रेशन होता है। Room इसे संभालने लायक बना देता है:

@Database(
    entities = [Expense::class, Category::class],
    version = 4,
    autoMigrations = [
        AutoMigration(from = 1, to = 2),
        AutoMigration(from = 2, to = 3, spec = MigrateNotesField::class),
        AutoMigration(from = 3, to = 4),
    ],
    exportSchema = true,
)
abstract class AppDatabase : RoomDatabase() { ... }

सबसे उपयोगी चीज़ जो मैं करता हूँ: exportSchema = true और उन JSON फ़ाइलों को git में कमिट करना। फिर एक Room-प्रबंधित टेस्ट स्कीमा रिग्रेशन को किसी यूज़र डिवाइस तक पहुँचने से पहले पकड़ लेता है। इसने मुझे कितने बुरे दोपहरों से बचाया है, मैं गिन नहीं सकता।

5. असली फ़ोन पर मैनुअल टेस्टिंग, ऑटोमेशन सिर्फ़ वहाँ जहाँ मायने रखता हो

अकेले डेवलपर का टेस्टिंग पिरामिड: उन हिस्सों के लिए मुट्ठी भर शुद्ध यूनिट टेस्ट जिन्हें टेस्ट करना आसान और वरना डिबग करना नामुमकिन है (करेंसी गणित, तारीख़ गणित, Subly में OCR फ़ील्ड-निष्कर्षण)। शून्य UI टेस्ट। तीन असली फ़ोन पर भारी मैनुअल स्मोक टेस्टिंग: एक Pixel, एक Samsung मिड-रेंज, और एक सचमुच सस्ता Xiaomi। सस्ता फ़ोन बिना बहस का मुद्दा है — यही वह फ़ोन है जो आपके यूज़र्स के पास सचमुच होता है।

Samsung और Xiaomi दोनों ही ऐसी असली दिक़्क़तें सामने लाएँगे जो एमुलेटर में नहीं दिखतीं। आक्रामक बैटरी ऑप्टिमाइज़ेशन से मार दी गईं नोटिफ़िकेशन, चुपके से फिर से शेड्यूल हुए एग्ज़ैक्ट अलार्म, 200 मिलीसेकंड देर से चलने वाले वाइब्रेशन पैटर्न। अगर आपके ऐप को भरोसेमंद नोटिफ़िकेशन चाहिए (Hydrame को चाहिए), तो Samsung पर टेस्ट करें वरना लॉन्च के बाद पता चलेगा।

6. Play Store लिस्टिंग आपके आधे ऐप के बराबर है

स्टोर लिस्टिंग पर एक वीकेंड लगाएँ। टाइटल और छोटा विवरण ही SEO है। स्क्रीनशॉट ही कन्वर्ज़न है। फ़ीचर ग्राफ़िक वे पहले 1.6 सेकंड हैं जो कोई आपके ब्रांड के साथ बिताता है।

एक यथार्थवादी चेकलिस्ट:

• प्राथमिक कीवर्ड के साथ टाइटल (चालाकी न दिखाएँ — “Granyn — Budget & Expense Tracker”, “Granyn” से बेहतर है)
• क्रिया और एकमात्र विभेदक के साथ छोटा विवरण (80 अक्षर)
• तीन से पाँच छोटे पैराग्राफ़, सब-हेडर, और कम मात्रा में इस्तेमाल किए गए इमोजी के साथ लंबा विवरण
• 1080×2400 या उससे ज़्यादा पर स्क्रीनशॉट, जिनमें पहला स्क्रीनशॉट आपका हीरो शॉट हो। ज़्यादातर यूज़र कभी स्वाइप नहीं करते।
• फ़ीचर ग्राफ़िक (1024×500)। टेक्स्ट कम से कम रखें — यह एक बैनर है, बिलबोर्ड नहीं।
• प्राइवेसी पॉलिसी URL — अनिवार्य। इसे ख़ुद होस्ट करें (GitHub Pages काम करता है) ताकि आप किसी रिलीज़ के बिना इसे संपादित कर सकें।
• कंटेंट रेटिंग — प्रश्नावली ईमानदारी से भरें। यह आपकी सोच से जल्दी हो जाती है।
• ऐप वर्गीकरण — डेटा सेफ़्टी (Data Safety) फ़ॉर्म। इसे गंभीरता से लें; यह आपकी प्राइवेसी पॉलिसी का सार्वजनिक संस्करण है।

डेटा सेफ़्टी फ़ॉर्म वही है जिसे ज़्यादातर लोग जल्दबाज़ी में निपटा देते हैं। इसे ऐसे भरें जैसे किसी वकील को समझा रहे हों। अगर आप “कोई डेटा एकत्र नहीं किया गया” पर निशान नहीं लगा सकते, तो ठीक-ठीक बताएँ कि कौन सा थर्ड पार्टी (Firebase, AdMob, Play Billing) कौन सी फ़ील्ड प्रोसेस करता है। Google हर साल रनटाइम व्यवहार से इसकी और सख़्ती से जाँच करता है।

7. चुपचाप लॉन्च करें, फ़नल पर नज़र रखें

पहले अपने देश में सॉफ़्ट-लॉन्च करें। इसकी घोषणा न करें। पहली 50 इंस्टॉल आपकी बीटा हैं — क्रैश रिपोर्ट, ANR, और इंस्टॉल/अनइंस्टॉल अनुपात पर ध्यान दें। अगर पहले दिन का रिटेंशन 30% से नीचे है, तो कोई भी मार्केटिंग करने से पहले ऑनबोर्डिंग ठीक करें।

पहले दो हफ़्तों तक हर सुबह Play Console में मैं सबसे पहले जो देखता हूँ:

• क्रैश-फ़्री यूज़र %
• ANR दर
• Vitals (अत्यधिक wakeups, फ़्रोज़न फ़्रेम)
• 1-स्टार रिव्यू — हर शब्द पढ़ें। ये सोना हैं।

फिर मैं और व्यापक रोलआउट करता हूँ — बाक़ी यूरोप में, फिर विश्व स्तर पर। चरणबद्ध रोलआउट (10% → 25% → 50% → 100%) मुफ़्त है; इसका इस्तेमाल करें।

8. लॉन्च के बाद का उबाऊ काम

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

यहीं ASO भी जुड़ता चला जाता है। टाइटल और विवरण में कीवर्ड, छोटे अपडेट का स्थिर प्रवाह, और ऑर्गैनिक रिव्यू की धीमी बूँदाबाँदी — इसमें कुछ भी चमकदार नहीं है, सब कुछ काम करता है।

अगली बार मैं क्या अलग करूँगा

एक छोटी सूची, क्योंकि पश्चदृष्टि सबसे अच्छी शिक्षक है:

1. पहले Play Store लिस्टिंग लिखें। इसे स्पेसिफ़िकेशन की तरह लें। मैं मज़ाक नहीं कर रहा।
2. पहले दिन से बड़ी खाली स्थितियाँ। एक कोरी स्क्रीन पहली छाप मार देती है; एक सोची-समझी खाली स्थिति आपको दूसरी बार खुलने का मौक़ा दिलाती है।
3. ऑनबोर्डिंग को एक स्क्रीन मिलती है। शायद दो। अगर आपको तीन चाहिए, तो आपके पास ऐप में ठीक करने लायक एक UX समस्या है, न कि लंबी ऑनबोर्डिंग।
4. पहले दिन Crashlytics सेट करें। हाँ, एक छोटी सी यूटिलिटी के लिए भी।
5. प्राइवेसी पॉलिसी अपने ख़ुद के डोमेन या GitHub Pages पर होस्ट करें। आप इसे अपनी सोच से ज़्यादा बार अपडेट करेंगे और आप हर छोटे बदलाव के लिए Play Console की दोबारा समीक्षा नहीं चाहेंगे।

पूरी प्लेबुक जानबूझकर ग़ैर-रोमानी है। इंडी डेवलपमेंट का रोमांस लॉन्च करने की आज़ादी है; प्लेबुक वह चीज़ है जो उस आज़ादी को आपके अपने स्कोप क्रीप से बचाती है।

अगर आप अभी किसी आधे बने Android ऐप के बीच कहीं हैं, तो इस हफ़्ते आप जो सबसे उपयोगी काम कर सकते हैं वह है एक फ़ीचर हटा देना। फिर जाकर Play Store विवरण लिखें। लॉन्च आपकी सोच से ज़्यादा क़रीब है — जो आपको रोक रहा है उसका ज़्यादातर हिस्सा स्क्रीन के आपकी तरफ़ है।