कैसे एक इंसान ने $40k/साल वाले टूल की जगह एक दिन में बनी चीज़ ले ली

Marta, Guadalajara में एक 30-लोगों वाली logistics कंपनी का operations चलाती थी। उसकी टीम एक enterprise project management platform इस्तेमाल करती थी जिसकी लागत उन्हें लगभग $40,000 साल पड़ती थी — per-seat licensing, reporting फ़ीचर के लिए premium tier, साथ ही एक consultant जिसे उन्होंने दो साल पहले शुरुआती workflows सेट करने के लिए हायर किया था।

यह रही वो बात जो टीम का कोई भी ज़ोर से कहना नहीं चाहता था: वो उसका शायद 15% इस्तेमाल करते थे।

Drivers टूल में अपने रोज़ के routes लॉग करते थे। Dispatchers एक Kanban board देखते थे कि कौन उपलब्ध है। Marta एक साप्ताहिक report निकालती थी जो on-time deliveries और खुले issues दिखाती थी। बस इतना ही। Gantt charts, resource leveling, sprint planning, time tracking, और portfolio dashboards? किसी ने उन्हें नहीं छुआ। वो लिफ़ाफ़े खोलने के लिए एक Swiss Army knife के पैसे चुका रहे थे।

जब बात समझ आई

Contract renewal फ़रवरी में आया। Marta एक साल से ख़ुद को कहती आ रही थी कि वो “अगली तिमाही” किसी सस्ती चीज़ पर migrate कर लेगी। पर इस बार, एक दोस्त जो एक छोटा e-commerce brand चलाती थी, ने उसे कुछ ऐसा बताया जो दिमाग़ में अटक गया: “मैंने सही टूल ढूंढना बंद कर दिया और बस एक AI को बताया कि मुझे क्या चाहिए। उसने उसे बना दिया।”

Marta एक डेवलपर नहीं थी। उसने एक बार एक Python course लिया था और तीसरे हफ़्ते बाद उसे छोड़ दिया था। पर वो अपने खुद के workflows किसी से भी बेहतर समझती थी। वो ठीक-ठीक बता सकती थी कि उसकी टीम को क्या चाहिए क्योंकि वो उन processes के भीतर हर दिन जीती थी।

उसने renewal साइन करने से पहले खुद एक replacement बनाकर देखने का फ़ैसला किया।

उसने असल में क्या बनाया

Marta एक शनिवार सुबह एक AI app builder के साथ बैठी और बताना शुरू किया कि उसे क्या चाहिए, एक बार में एक टुकड़ा।

एक route logging स्क्रीन। Drivers को अपनी shift की शुरुआत में check in करना, अपने assigned stops देखना, और हर एक को completed मार्क करना था। कोई drag-and-drop Gantt बकवास नहीं — बस checkboxes और एक timestamp वाली एक list। उसने इसे आसान स्पैनिश में बताया और app builder को एक चलता हुआ interface जनरेट करते देखा जिसके पीछे एक database था।

एक dispatcher dashboard। एक अकेला पेज जो दिखाए कि कौन-से drivers active हैं, उनके पास कितने stops बचे हैं, और एक color-coded indicator कि वो रफ़्तार पर हैं या नहीं। Marta ने logic बताया: हरा अगर उन्होंने दोपहर तक कम से कम 60% stops पूरे कर लिए, पीला अगर 40-60% के बीच, लाल उससे नीचे। Builder ने इसे conditional formatting और एक live-अपडेट होने वाले view में बदल दिया।

एक साप्ताहिक report। वो संख्याएं जो Marta सचमुच हर शुक्रवार निकालती थी: कुल deliveries, on-time प्रतिशत, drivers द्वारा flag किए गए issues (जैसे एक गलत पता या एक customer घर पर न होना), और पिछले हफ़्ते से एक तुलना। उसने builder से एक summary table और एक आसान bar chart जनरेट करने को कहा। उसने कर दिया।

एक आसान issue tracker। जब एक driver कुछ flag करे — गलत पता, टूटा हुआ package, customer की शिकायत — उसे कहीं जाना था जहां Marta उसे देख सके और assign कर सके। एक पूरा ticketing सिस्टम नहीं। बस एक status (open / in progress / resolved) वाली एक list और एक note जोड़ने की क्षमता।

पूरी चीज़ में शनिवार भर फैले लगभग आठ घंटे लगे। इसलिए नहीं कि कोई एक हिस्सा मुश्किल था, बल्कि इसलिए कि Marta सुधारती रही। Dispatcher dashboard के पहले version ने बहुत ज़्यादा डेटा दिखाया। उसने उसे छाँटा। Route logging स्क्रीन को एक “skip stop” विकल्प चाहिए था जिसके बारे में उसने शुरू में नहीं सोचा था। उसने उसे बदलाव बताकर जोड़ा।

$40,000 असल में क्या खरीद रहे थे

जब Marta ने अपनी चार-स्क्रीन वाली ऐप की तुलना enterprise platform से की, तो फ़ासला साफ़ था — पर उस दिशा में नहीं जिसकी उसने उम्मीद की थी।

Enterprise टूल में सैकड़ों फ़ीचर थे और उसे configure करने के लिए एक consultant चाहिए था। Marta की ऐप में चार स्क्रीन थीं जो सीधे उसकी टीम के पहले से काम करने के तरीक़े से जुड़ती थीं। कोई training ज़रूरी नहीं। कोई configuration का बोझ नहीं।

पर enterprise टूल की असली लागत कभी subscription नहीं थी। वो वो friction था जिसके इर्द-गिर्द उसकी टीम हर दिन काम करती थी। Dispatchers WhatsApp पर तालमेल करते थे क्योंकि platform की mobile ऐप को एक delivery status अपडेट करने में चार taps लगते थे। Marta साप्ताहिक report के लिए एक अलग Google Sheet रखती थी क्योंकि built-in reporting module को वही पांच संख्याएं निकालने के लिए तीन menus में जाना पड़ता था। Drivers ने route logging स्क्रीन के लिए help docs में एक workaround पेज bookmark कर रखा था क्योंकि default flow ऐसे project phases मान लेता था जिन्हें वो इस्तेमाल नहीं करते थे।

Marta की ऐप में workarounds नहीं थे क्योंकि वो workarounds से ही बनी थी। हर स्क्रीन इसलिए मौजूद थी क्योंकि टीम का कोई न कोई वो काम अनौपचारिक रूप से कर रहा था — WhatsApp पर, एक spreadsheet पर, एक whiteboard पर — और Marta ने बस अनौपचारिक version builder को बता दिया।

वो हिस्से जिन्होंने उसे हैरान किया

तीन चीज़ें जिनकी Marta ने उम्मीद नहीं की थी:

सुधार तेज़ था। जब एक driver ने हर stop में एक notes field जोड़ने का सुझाव दिया, Marta ने अपने lunch break के दौरान बदलाव builder को बताया और उसी दोपहर उसे deploy किया। Enterprise टूल के साथ, ऐसे बदलाव एक support ticket queue से गुज़रते और कभी-कभी हफ़्ते लगते।

उसकी टीम ने इसे फ़ौरन अपनाया। कोई training sessions नहीं। कोई “कृपया यह onboarding video देखें” नहीं। Dispatchers ने इसे सोमवार सुबह खोला और समझ गए क्योंकि यह उस whiteboard जैसा दिखता था जिसे वो अनौपचारिक रूप से इस्तेमाल कर रहे थे, बस digital।

उसने इसे सुधारना जारी रखा। अगले दो हफ़्तों में, उसने एक पांचवीं स्क्रीन जोड़ी: उसके boss के लिए एक मासिक view जो delivery trends और cost-per-route अनुमान दिखाए। Enterprise टूल के साथ, यह एक कस्टम report request होती। उसकी अपनी ऐप के साथ, यह builder के साथ एक 20-मिनट की बातचीत थी।

यह क्या नहीं है

यह enterprise software के बुरे होने की कहानी नहीं है। अगर आप एक 500-लोगों वाली कंपनी हैं जो dependencies, resource बाधाओं, और compliance ज़रूरतों के साथ जटिल cross-functional प्रोजेक्ट चलाती है, तो आपको शायद वो Swiss Army knife चाहिए।

पर अगर आप एक 30-लोगों वाली टीम हैं जो एक ऐसे टूल का 15% इस्तेमाल कर रही है जो आपके एक कर्मचारी से ज़्यादा महंगा है, तो कुछ गड़बड़ है। टूल समस्या नहीं है — बेमेल है।

और वो बेमेल पहले अनिवार्य था। इससे पहले कि आप बिना कोडिंग के एक ऐप बना सकें, आपके विकल्प थे: बड़े टूल के पैसे चुकाओ, spreadsheets में कुछ जोड़-तोड़ करो, या कस्टम software बनाने के लिए एक डेवलपर हायर करो (जो अपनी लागत और timeline लाता है)। अब एक चौथा विकल्प है: बताओ कि तुम्हें क्या चाहिए और उसे खुद बना लो।

गणित

एक महीने बाद Marta की संख्याएं:

• Enterprise टूल: ~$3,300/महीना ($40k/साल)
• AI app builder subscription: $100/महीना से कम
• बनाने में समय: 8 घंटे (एक शनिवार)
• सुधार में समय: प्रति बदलाव 20-30 मिनट
• टीम के अपनाने में समय: शून्य — उन्हें पहले दिन समझ आ गया

उसे एक CTO या एक engineering टीम नहीं चाहिए थी। उसे यह बताना था कि उसकी टीम असल में कैसे काम करती है — और एक AI app builder जिसने उस विवरण को चलते हुए software में बदल दिया।

किस बारे में सोचें

अगर आप Marta की कहानी में अपनी ख़ुद की स्थिति पहचानते हैं, तो अपने अगले software renewal से पहले एक उपयोगी अभ्यास यह रहा: हर वो फ़ीचर लिख लें जो आप अपने मौजूदा टूल में सचमुच इस्तेमाल करते हैं। वो फ़ीचर नहीं जो आपको लगता है कि आपको इस्तेमाल करने चाहिए या जिन्हें आप कभी इस्तेमाल करने की योजना बनाते हैं। वो जिन्हें आपकी टीम हर हफ़्ते छूती है।

अगर वो list एक sticky note पर समा जाए, तो हो सकता है आप ऐसी जटिलता के लिए ज़्यादा चुका रहे हों जिसकी आपको ज़रूरत नहीं।

आपको replacement एक दिन में बनाना ज़रूरी नहीं। आप बस एक स्क्रीन से शुरू कर सकते हैं — वो जो सबसे ज़्यादा मायने रखती है — और देख सकते हैं कि कैसा लगता है। आज़माने की लागत कुछ घंटे हैं। न आज़माने की लागत उन फ़ीचरों के लिए चुकाने का एक और साल है जिन्हें आप कभी नहीं छुएंगे।

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