AI से बनी ऐप्स को maintain करना: हफ़्ते दो के बारे में जो कोई नहीं बताता

Proyecta के साथ पहले weekend में, आप कुछ असली शिप कर देते हैं। यह काम करता है। आपके यूज़र (या आपकी टीम, या आपका भविष्य वाला आप) इसे इस्तेमाल करने लगते हैं। और फिर सोमवार आता है और एक customer email करता है: “क्या आप region से filter करने के लिए एक dropdown जोड़ सकते हैं?”

Maintenance में आपका स्वागत है। यह AI ऐप बनाने का वो हिस्सा है जिसकी कोई बात नहीं करता, और वही हिस्सा जहां ज़्यादातर प्रोजेक्ट या तो एक लंबे समय तक चलने वाली asset बन जाते हैं या चुपचाप एक खाई में गिर जाते हैं। अच्छी ख़बर यह है कि किसी AI-बनाई ऐप को maintain करना traditional code को maintain करने से एक अलग अनुभव है। खरी ख़बर यह है कि “अलग” का मतलब “मुफ़्त” नहीं है।

Maintenance का असल में मतलब क्या है

जब प्रोफेशनल डेवलपर “maintenance” कहते हैं, तो उनका मतलब, कमोबेश, चार चीज़ों से होता है:

  1. छोटे features जोड़ना जो लोग launch के बाद मांगते हैं।
  2. चीज़ें ठीक करना जो टूट गईं या शुरू से ही ग़लत थीं।
  3. साथ बने रहना आपकी ऐप के बाहर के बदलावों के साथ — कोई payments provider अपना API अपडेट करता है, कोई नया browser आता है, आपके डेटा का आकार बदल जाता है।
  4. सफ़ाई करना ताकि codebase धीरे-धीरे एक दलदल में न बदल जाए।

किसी AI-बनाई ऐप के लिए, ये चारों अब भी होते हैं। जो बदलता है वो है कि उन्हें कौन करता है और काम कैसा महसूस होता है।

अच्छी ख़बर: आप उससे बात कर सकते हैं

यह रहा वो हिस्सा जो किसी ने आपको नहीं बताया जब आप पुराने tutorials से कोड copy-paste कर रहे थे। किसी AI app builder के साथ, आप ऐप को उसी तरह maintain करते हैं जैसे आपने उसे बनाया था: यह बताकर कि आप क्या चाहते हैं।

एक असली उदाहरण। हमारी जानने वाली एक founder ने अपनी coaching practice के लिए एक छोटा सा CRM बनाया — clients, sessions, payment tracking, सब कुछ। launch के तीन हफ़्ते बाद, एक client ने कहा कि वो देखना चाहेगी कि उसने उस साल कितने sessions किए। उसने ऐप खोली, कहा, “हर client card में एक ‘sessions this year’ counter जोड़ो, sessions table से खींचते हुए जहां date 2026 में हो।” बारह मिनट बाद, वो live था। वो वापस coaching पर लौट गई।

यह कहानी तब तक सामान्य लगती है जब तक आपको विकल्प याद न आए: किसी freelancer को ping करना, दो दिन इंतज़ार करना, $300 देना, एक ऐसे PR को review करना जिसे वो पूरी तरह समझती भी नहीं थी, और दुआ करना कि कुछ और न टूटे। maintenance loop इसलिए तेज़ नहीं है कि AI freelancer से ज़्यादा समझदार है। यह इसलिए तेज़ है कि loop में कम इंसान हैं।

मुश्किल ख़बर: छोटी चीज़ें जुड़कर बढ़ती जाती हैं

यह रहा वो हिस्सा जो लोगों को पकड़ लेता है। AI-बनाई ऐप्स बदलने में आसान दिखती हैं क्योंकि चीज़ें जोड़ना आसान है। जो आसान नहीं है वो है पूरी चीज़ को बढ़ने के साथ-साथ सुसंगत रखना।

कुछ pattern हम ग़लत होते देखते हैं:

  • अनजाने में बनी उलझन। आप मांगते हैं “checkout में एक discount field जोड़ो।” छह revisions बाद, discount logic तीन जगहों पर रहता है, और उनमें से सिर्फ़ एक सही है। अभी तक कुछ टूटा नहीं, पर अगला बदलाव उलझाने वाला होने जा रहा है।
  • भूली हुई ज़रूरत। आपने मार्च में “$50 से ऊपर free shipping” जोड़ा। मई में, आप AI से कहते हैं “gift cards को support करने के लिए checkout फिर से बनाओ।” वो कर देता है। free shipping का नियम ग़ायब हो गया। किसी को दो हफ़्ते तक पता नहीं चला।
  • खिसकाव। आपकी ऐप “मेरे लिए एक टूल” के रूप में शुरू हुई थी। अब उसे आपकी टीम इस्तेमाल करती है। AI जिस मानसिक मॉडल पर काम कर रहा है वो अब भी “मेरे लिए” है, क्योंकि शुरू में आपने वही कहा था। नए features अजीब तरह से बेमेल लगते हैं, और आप उंगली नहीं रख पाते कि क्यों।

इनमें से कोई भी AI app builders की नाकामी नहीं है। ये memory और साझा context की नाकामियां हैं — वही समस्याएं जो इंसानी डेवलपर्स की एक टीम को होती हैं, बस एक अलग शक्ल में।

खुद को कैसे तैयार करें

जो टीमें maintenance में अच्छा करती हैं, उनकी कुछ आदतें साझा होती हैं। ज़्यादातर ये तकनीकी आदतें नहीं हैं। ये इस बारे में आदतें हैं कि आप कैसे बताते हैं कि आपकी ऐप क्या है और क्या बदला।

एक “यह ऐप क्या है” doc रखें। एक पन्ना। audience, goals, नियम (“$50 से ऊपर free shipping,” “हम यूज़र्स को रविवार को कभी email नहीं करते,” “phone primary key है, email नहीं”)। जब आप AI से कुछ बदलने को कहें, तो प्रासंगिक नियम prompt में paste कर दें। आप AI की समझदारी को दरकिनार नहीं कर रहे; आप उसे वो context दे रहे हैं जो उसे मुमकिन ही नहीं कि याद रहे।

बदलावों को behavior के तौर पर बताएं, code के तौर पर नहीं। “मैं चाहता हूं कि यूज़र्स को उनका region filter sessions के बीच याद रहे” “filter में localStorage जोड़ो” से कहीं बेहतर request है। पहली बताती है कि आप क्या चाहते हैं; दूसरी उसे करने के पंद्रह में से एक तरीक़े को तय कर देती है, और शायद वो सबसे अच्छा नहीं है।

बदलाव एक बार में एक करें। एक ही prompt में दो बदलाव का मतलब है कि एक चुपचाप fail हो सकता है और आपको पता नहीं चलेगा कौन सा। AI ऐप maintain करने का सबसे तेज़ तरीक़ा है अपने iterations को इतना छोटा रखना कि आप एक नज़र में बता सकें कि नतीजा सही है या नहीं।

देखें कि क्या बदला। ज़्यादातर AI app builders आपको एक preview दिखाते हैं। उसका इस्तेमाल करें। नया feature काम करता है और पुराने features अब भी काम करते हैं — यह पक्का करने के लिए इधर-उधर क्लिक करने में आप जो तीस सेकंड लगाते हैं, वो इस साल का सबसे सस्ता बीमा है जो आप खरीदेंगे।

जो आप नहीं कर सकते (और शायद नहीं करना चाहिए)

एक लालच होता है, एक बार AI से ऐप बना लेने के बाद, यह सोचने का कि वो आपके लिए ऐप को चला भी सकता है। वो नहीं चला सकता, और यह फ़र्क असली है:

  • जब कुछ चुपचाप टूट जाए तो वो आपको नहीं बताएगा। Logs, monitoring, on-call rotations — वो अब भी एक अलग चिंता हैं। ज़्यादातर AI app builders आपकी production ऐप पर वैसी नज़र नहीं रखते जैसी एक backend engineer रखता।
  • उसे आपकी ऐप के बाहर की दुनिया के बारे में पता नहीं है। अगर कोई payment provider किसी API को बंद कर देता है, तो AI को तब तक पता नहीं चलता जब तक आप न बताएं। अपने providers के changelogs को subscribe करें। अपनी email पढ़ें।
  • वो आपके लिए product फ़ैसले नहीं ले सकता। कोई feature जोड़ना या नहीं, कौन सा trade-off करना है, आपके यूज़र असल में क्या चाहते हैं — वो अब भी आप हैं। AI एक बहुत तेज़ हाथ है; दिमाग़ आपका है।

हक़ीक़त वाली तस्वीर

किसी AI-बनाई ऐप के साथ छह महीने बाद, जिन ज़्यादातर लोगों से हम बात करते हैं वो कुछ ऐसी जगह पहुंचते हैं: वो बदलावों पर शायद महीने में दो से चार घंटे लगाते हैं, उसका लगभग सब बातचीत के ज़रिए। वो बड़े rebuilds जिनसे वो डरते थे — “मैं एक पूरा नया section जोड़ना चाहता हूं” — एक अच्छी दोपहर जैसे लगते हैं। बोरिंग चीज़ें — “export पर date का format ग़लत है” — एक अच्छे prompt जैसी लगती हैं।

जो उनके पास नहीं है वो है किसी traditional codebase का लगातार पीछे चलता शोर: dependency updates, framework migrations, security patches, build configurations। वो शोर platform में सोख लिया गया है। आप platform को उसे संभालने के पैसे दे रहे हैं, जो किसी डेवलपर को उसे संभालने के पैसे देने से कहीं बेहतर सौदा है।

अगर आप अपनी पहली ऐप बनाने वाले हैं, तो आपकी पहली AI-बनाई ऐप क्या होनी चाहिए, इस पर वाली पोस्ट शुरू करने से पहले पढ़ने लायक है। और अगर आप पहले से कुछ हफ़्ते आगे हैं और ऊपर बताए कुछ pattern महसूस कर रहे हैं, तो वो सामान्य है। इस weekend अपना “यह ऐप क्या है” doc लिखें। तीन महीने बाद वाला आप, जब एक नया dashboard मांग रहा होगा, बहुत खुश होगा कि आपने ऐसा किया।