क्या आप Lovable या Replit के साथ POS बना सकते हैं? UI के बाद क्या कमी है

एक तरह से हाँ। आप Lovable या Replit के साथ एक POS बना सकते हैं, बशर्ते कि POS की आपकी परिभाषा केवल स्क्रीन तक ही सीमित हो। दोनों ही दोपहर भर में एक चेकआउट इंटरफ़ेस, एक प्रोडक्ट ग्रिड और एक कार्ट तैयार कर देंगे, और यह उस बहुत से सॉफ़्टवेयर से बेहतर दिखेगा जिसके लिए मर्चेंट वास्तविक पैसे चुकाते हैं। अंतर UI के बाद आता है, पॉइंट ऑफ़ सेल के उन हिस्सों में जिन्हें आप देख नहीं सकते: इन्वेंट्री, रिपोर्टिंग, टैक्स और पेमेंट जो हर एक बार बिल्कुल सही होने चाहिए।

शुरुआत में ही एक चेतावनी: Lovable और Replit लगातार बदलाव लाते रहते हैं, इसलिए नीचे दी गई बारीकियों को प्रकाशन के समय सटीक मानें और दोबारा जाँच करने योग्य समझें।

Lovable और Replit वास्तव में आपको क्या देते हैं?

संदेह करने वालों के अनुमान से कहीं अधिक। Lovable एक फुल-स्टैक वेब ऐप जनरेट करता है: एक React फ्रंटएंड जो डेटाबेस, ऑथेंटिकेशन और फ़ाइल स्टोरेज वाले होस्टेड बैकएंड से जुड़ा होता है, साथ ही ऑनलाइन चेकआउट के लिए पेमेंट इंटीग्रेशन। Replit सर्वर साइड पर और आगे जाता है: इसका एजेंट इन-बिल्ट डेटाबेस, होस्टिंग और ऑथेंटिकेशन के साथ ऐप्स बनाता और होस्ट करता है, जिससे बैकएंड लॉजिक थर्ड-पार्टी सर्विसेज़ को आपस में जोड़े बिना चलता है।

सॉफ्टवेयर के एक बड़े वर्ग (इंटरनल टूल्स, बुकिंग पेजेस, डैशबोर्ड्स) के लिए वास्तव में यही पूरा काम होता है, यही वजह है कि ये प्लेटफॉर्म इतनी तेजी से बढ़ रहे हैं। पेंच यह है कि पॉइंट ऑफ़ सेल उस वर्ग से संबंध नहीं रखता है, ठीक उसी कारण से जिसके लिए एक फ्रंटियर मॉडल जो एक बार में वेब ऐप बना देता है, वह भी एक काम करने वाले POS पर आकर अटक जाता है: कठिन हिस्सा कभी भी इंटरफ़ेस नहीं था।

UI के बाद क्या कमी रह जाती है?

कॉमर्स लेयर। पॉइंट ऑफ़ सेल रिकॉर्ड का एक सिस्टम होता है (आपके पैसे और स्टॉक के लिए सच्चाई का एकमात्र स्रोत) जिसके ऊपर एक ऐप होता है। दोनों में से कोई भी प्लेटफॉर्म कॉमर्स प्रिमिटिव्स नहीं देता है, इसलिए जनरेट किए गए कोड को उन्हें बिल्कुल नए सिरे से बनाना पड़ता है:

• इन्वेंट्री जो कॉनकरेंसी (concurrency) को संभाल सके (दो टिल एक ही समय पर बिक्री कर रहे हों)। स्टॉक कॉलम को घटाना एक डेमो में तो काम करता है लेकिन पहले ही शनिवार को फेल हो जाता है जब दो स्टेशन एक साथ आखिरी यूनिट बेचते हैं।

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

• रिपोर्टिंग जो मेल खाती हो (कुल योग जो आपके पेमेंट डिपॉजिट से पैसे-पैसे तक मेल खाता हो)। एक रिपोर्ट जो केवल "लगभग" सही है, वह बहीखाता की एक ऐसी समस्या है जिसे आप टैक्स के समय खोज पाएंगे।

• टैक्स लॉजिक जो वास्तविक क्षेत्राधिकार के नियमों का पालन करता हो और हर रसीद, रिफंड और रिपोर्ट पर सही तरीके से लागू होता हो।

एक AI एजेंट इन चारों के संभावित रूप से सही दिखने वाले वर्ज़न जनरेट कर देगा। संभावित रूप से सही दिखना ही जाल है: एक टूटा हुआ बटन जैसे ही आप उसे टैप करते हैं, दिखने लगता है, जबकि मिलान (reconciliation) का एक बग तब तक अदृश्य रहता है जब तक कि आपका अकाउंटेंट महीनों बाद उसे ढूंढ नहीं लेता।

क्या जनरेट किया गया ऐप वास्तविक पेमेंट ले सकता है?

ऑनलाइन, हाँ: दोनों प्लेटफॉर्म वेब चेकआउट के लिए पेमेंट इंटीग्रेशन से काफी अच्छी तरह जुड़ जाते हैं। व्यक्तिगत रूप से (in person) लेना एक अलग ही खेल है। कार्ड-प्रेजेंट पेमेंट्स के लिए सर्टिफाइड टर्मिनल हार्डवेयर और PCI DSS अनुपालन (कार्ड डेटा को छूने वाली किसी भी चीज़ के लिए कार्ड इंडस्ट्री के सुरक्षा नियम) की आवश्यकता होती है। कोई भी जनरेट किया गया कोडबेस इसे अपने आप पूरा नहीं करता; सर्टिफिकेशन पेमेंट प्रोवाइडर के हार्डवेयर और प्लेटफॉर्म में होता है, आपके ऐप में नहीं। विवाद, मूल कार्ड पर आंशिक रिफंड, और टिप एडजस्टमेंट सभी उसी सर्टिफाइड लेयर से होकर चलते हैं।

यह वह दीवार है जिससे हर DIY रास्ता अंततः टकराता है, चाहे टूल कोई भी हो। हमने MCP पर एक AI मॉडल क्या बना सकता है और क्या नहीं इसका परीक्षण करते समय भी यही पाया।

प्रोडक्शन में सबसे पहले क्या टूटता है?

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

तो, क्या आप Lovable या Replit के साथ एक POS बना सकते हैं?

आप इसका फ्रंट हिस्सा बना सकते हैं: एक वास्तविक इंटरफ़ेस, वास्तविक लॉजिक, जिसे तेज़ी से शिप किया गया हो। आप इसका बैक हिस्सा जनरेट नहीं कर सकते, क्योंकि लोड के तहत इन्वेंट्री, मिलान, टैक्स और सर्टिफाइड कार्ड-प्रेजेंट पेमेंट्स ऐसा कोड नहीं हैं जिसे कोई एजेंट खुद से बना सके; वे इन्फ्रास्ट्रक्चर हैं जिनका पहले से मौजूद होना ज़रूरी है। इससे दो ईमानदार रास्ते बचते हैं: उस इन्फ्रास्ट्रक्चर को खुद दोबारा बनाएं और हमेशा के लिए उसके मालिक बनें, या पहले से चल रहे कॉमर्स इन्फ्रास्ट्रक्चर के ऊपर अपना चेकआउट जनरेट करें, जो कि Final के पीछे का दृष्टिकोण है, जहाँ एक प्रॉम्प्ट या आपका अपना AI टूल लाइव कॉमर्स बैकएंड पर POS बनाता है।

चाहे जो भी हो, किसी भी AI को इसे बनाने देने से पहले एक व्यावहारिक नियम याद रखें: यदि किसी बग की कीमत पिक्सल के बजाय पैसे में चुकानी पड़े, तो आप इन्फ्रास्ट्रक्चर बना रहे हैं, UI नहीं। यदि आप देखना चाहते हैं कि कॉमर्स लेयर शामिल होने पर चेकआउट के नीचे क्या होता है, तो यहाँ देखें कि यह व्यवहार में कैसा दिखता है।