हैरान हुए? $1000 भरिए

 (forestwalk.ai)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मुफ़्त ट्रायल से शुरू हुई एक CI सेवा ने लिमिट पार होने के बाद सेवा रोकने के बजाय $1,000 का बिल भेज दिया, और उपयोगकर्ता पर अनपेक्षित खर्च आ गया
  • Blacksmith GitHub Actions का विकल्प बनने की कोशिश करने वाला एक YC startup है, जो खुद को अधिक तेज़ और सस्ता drop-in replacement बताता है
  • "मुफ़्त ट्रायल·क्रेडिट कार्ड की ज़रूरत नहीं" शर्तों के तहत लिमिट पार होने पर काम रुकने के बजाय प्रकाशित दरों पर उपयोग लगातार जुड़ता रहा और उसी का बिल बना
  • ज़्यादातर उपयोगकर्ता भुगतान जानकारी देने से पहले मुफ़्त सीमा को hard cap मानते हैं, इसलिए यह नीति 5% से भी कम लोगों को पहले से अपेक्षित लगने वाली असामान्य व्यवस्था है
  • बिना क्रेडिट कार्ड वाले उपयोगकर्ताओं को overage में जाने देना और फिर overdue invoice भेजना दुरुपयोग करने वाले उपयोगकर्ताओं के पक्ष में जाता है और भरोसा कमज़ोर करता है

पृष्ठभूमि — GitHub Actions का विकल्प आज़माने की कोशिश

  • PR throughput बढ़ने के साथ यह साफ़ होने लगा कि CI jobs धीमी और महंगी हैं, और GitHub Actions को लेकर असंतोष बढ़ता गया
  • सुझाव मिलने पर Blacksmith अपनाने की कोशिश की गई
    • Blacksmith एक YC startup है जो GitHub Actions का drop-in replacement होने का दावा करता है और तेज़ी व कम लागत पर ज़ोर देता है
  • GitHub settings को import करके लागू किया गया, और नतीजे में यह वास्तव में ज़्यादा तेज़ निकला; लागत स्पष्ट नहीं थी क्योंकि मुफ़्त ट्रायल चल रहा था

बिल आने तक क्या हुआ

  • पहला चेतावनी ईमेल: उस organization ने इस महीने के मुफ़्त minutes का 80% इस्तेमाल कर लिया है, और रुकावट से बचने के लिए क्रेडिट कार्ड जोड़ने को कहा गया
    • इस समय usage जाँचना चाहिए था, लेकिन coding रोके बिना काम चलता रहा
  • 2 हफ़्ते बाद "इस महीने Blacksmith पर $500.60 खर्च हुआ" संदेश मिला
    • चूँकि ट्रायल अभी भी चल रहा था, यह सच जैसा नहीं लगा; न कोई क्रेडिट कार्ड था, न production users पर असर, और यह कई usage warning ईमेलों में से एक लगा
  • फिर 2 हफ़्ते बाद कम अंतराल में लगातार "रुकावट से बचने के लिए कार्ड जोड़ें" संदेश → $1,081 invoice → दो दिन बाद overdue notice मिला
    • overdue notice की कुल राशि $1,081.45 थी
    • contract के अनुसार भुगतान शर्त थी invoice बनते ही भुगतान

"disruption" शब्द पर स्पष्टीकरण

  • आम तौर पर बिना क्रेडिट कार्ड किसी मुफ़्त सेवा का उपयोग करते हुए लिमिट पहुँचने पर सेवा रुक जाती है (=सेवा में रुकावट), लेकिन इस मामले में नतीजा तुरंत overdue हुए $1,000 के बिल के रूप में निकला
  • Blacksmith support team का स्पष्टीकरण
    • "disruption" का मतलब सेवा बंद होना नहीं, बल्कि संदिग्ध गतिविधि की समीक्षा जैसी account flagging था
    • कहीं यह नहीं लिखा था कि चल रहे jobs अपने-आप रुकेंगे; मुफ़्त सीमा पार होने पर भी workflows नहीं रुके और उपयोग प्रकाशित दरों पर जुड़ता रहा
  • वास्तव में कहीं यह स्पष्ट नहीं कहा गया था कि लिमिट पहुँचने पर काम रुक जाएगा, और न ही यह कि "मुफ़्त·कार्ड की ज़रूरत नहीं" का मतलब हज़ारों डॉलर का खर्च असंभव है; ये सब प्रचलित व्यवहार के आधार पर धारणाएँ थीं

चार मुख्य मुद्दे

  • 1. क्या इस तरह बिल किया जा सकता है

    • 8 जून के अनुसार Blacksmith की terms यह संकेत देती हैं कि बिलिंग का अधिकार payment information दिए जाने पर आधारित है
    • फिर भी SaaS कंपनियाँ मुफ़्त ट्रायल के दौरान सीमा से अधिक उपयोग पर भुगतान दायित्व terms में रख सकती हैं
    • agent ने बहुत-सी CI jobs चलाईं, इसलिए मुफ़्त सीमा तक पहुँचना अनुमानित था, और सेवा से मूल्य भी मिला; इसलिए इसे मूल रूप से बेईमानी नहीं बल्कि चौंकाने वाला तरीका कहा जा सकता है — यानी "कर सकते हैं"

  • 2. क्या उपयोगकर्ता चौंकेंगे

    • मुफ़्त·कार्ड-रहित सेवा में overage पर invoice आने की उम्मीद करने वाले उपयोगकर्ताओं का अनुपात 5% से कम आँका गया
    • chatbot से पूछने पर, कार्ड जोड़ने वाली warning mail का ज़िक्र न करने पर भी वह मज़बूती से कहता है कि सेवा "कट जाएगी" — यह इस नीति के असामान्य होने का संकेत है
    • अधिकांश उपयोगकर्ता payment information देने तक मुफ़्त सीमा को hard cap मानते हैं

  • 3. क्या सेवा को ऐसा करना चाहिए

    • overage की अनुमति देकर बाद में overdue invoice भेजने से अल्पकालिक revenue metrics बढ़ सकते हैं, लेकिन वसूली दर अनिश्चित रहेगी और receivables व bad debt तेज़ी से बढ़ेंगे
    • निष्कर्ष: यह खराब प्रथा है
      • बिना कार्ड वाले उपयोगकर्ताओं को overage जोड़ने देना provider और customer दोनों के लिए झंझट पैदा करता है, और मुख्यतः भुगतान न करने की मंशा वाले दुरुपयोगकर्ता को ज़्यादा मुफ़्त छूट देता है
      • अल्पकालिक revenue बढ़ाने पर भी यह मानना कठिन है कि भरोसे की क्षति और abuse cost अतिरिक्त revenue से कम होगी
    • विकल्प: "72 घंटे के भीतर कार्ड न जोड़ने पर CI रोक दिया जाएगा" जैसी अग्रिम चेतावनी
    • बाद में बिलिंग का रास्ता क्यों चुना गया, इस पर बस अनुमान लगाया जा सकता है — आक्रामक growth hacking, तिमाही revenue लक्ष्य साधने वाला middle manager, payment और provisioning systems के बीच technical debt, या शायद YC startup दुनिया का चलन
      • वसंत में GitHub की अव्यवस्था के दौरान आई विस्फोटक growth को देखते हुए, लेखक का अनुमान सिर्फ़ एक साधारण oversight है
    • support team ने जवाब दिया कि आगे ऐसी उलझन कम करने के तरीकों पर विचार किया जाएगा

  • 4. फिर भी क्या Blacksmith का उपयोग करेंगे

    • GitHub Actions पर लौटकर देखा गया, लेकिन वह अब भी असुविधाजनक लगा
    • Blacksmith ने development cycle के bottleneck को तेज़ी से दूर किया और इसी वजह से तेज़ी से बढ़ा
    • आख़िरकार व्यावहारिकता जीती — तेज़ development speed की पसंद बिलिंग नीति पर नाराज़गी से भारी पड़ी
      • भुगतान मान लेने के बाद support team का रवैया भी अधिक सहायक हो गया, और फिर से switch करने की संभावना ऊँची है

पाठकों के लिए दो सलाह

  • अगर आप SaaS बना रहे हैं, तो ध्यान रखें कि अधिकांश उपयोगकर्ता उम्मीद करते हैं कि मुफ़्त account overage जुड़ने से पहले pause हो जाएगा, इसलिए invoice भेजना बहुतों को नकारात्मक लगेगा
  • अगर आप Blacksmith आज़माते हैं, तो कम से कम फ़िलहाल ट्रायल सीमा तक पहुँचने से पहले उपयोग घटा देना ज़्यादा सुरक्षित है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • कुछ साल पहले जब मैंने पहली बार इंटरनेट चलने वाला मोबाइल फ़ोन खरीदा, तो carrier ने trial period में 300 मिनट free का विज्ञापन किया था, इसलिए मुझे यह अच्छा लगा था
    पहले महीने मैंने internet service 297 मिनट इस्तेमाल की, लेकिन बाद में पता चला कि वे “मिनट” सिर्फ कॉल पर लागू होते थे, और mobile internet charges के लिए लगभग 12,000 डॉलर का overdue bill आ गया। कीमत कुछ 360 डॉलर प्रति MB जैसी बेहूदा थी
    आखिरकार एक बड़े class action lawsuit में carrier हार गया, और वजह “मिनट” वाला विज्ञापन नहीं बल्कि यह थी कि उसने data cost किसी को भी ठीक से बताई ही नहीं थी। अंत में शायद मैंने लगभग 300 डॉलर चुकाए, और 600 डॉलर के settlement को collections में भेजे जाने के बाद collection agency से 50% पर समझौता किया

    • इसलिए default रूप से कड़ी usage limit रखने वाली बात से मैं काफ़ी सहमत हूँ
    • बहुत पहले मेरी उस समय की girlfriend अपनी माँ के साथ छुट्टी पर गई थी और उसने फ़ोन में Roaming Bundle जोड़ लिया था
      यात्रा के दौरान carrier का फ़ोन आया कि roaming charges 1,700 pounds तक पहुँच गए हैं, और agent ने कहा “चिंता मत कीजिए”, एहतियात के तौर पर इस महीने direct debit रोक दीजिए और bill बन जाने पर फिर कॉल कीजिए
      कुछ हफ़्तों बाद उन्होंने पुष्टि की कि final amount लगभग 2,000 pounds है, और जब मैंने पूछा, “कहा गया था कि bundle आधा इस्तेमाल होने पर और लगभग पूरा होने पर SMS alert आएगा, तो वे क्यों नहीं आए?”, तो उन्होंने माना कि वे call recording सुन चुके हैं और वास्तव में ऐसा ही बताया गया था
      फिर उन्होंने कहा कि असल में 150-pound वाला दूसरा bundle ऑफ़र करना चाहिए था, और वास्तविक usage उस data का लगभग 75% था, इसलिए मौजूदा 25-pound bundle को ध्यान में रखते हुए 75 pounds पर निपटा लेते हैं। इसलिए मैं आज भी उसी carrier का customer हूँ
    • क्या उस समय data भी मिनटों के हिसाब से गिना जाता था? मुझे तो सिर्फ kB और MB की pricing याद है

  • वाह, मैंने तो बिल्कुल उम्मीद नहीं की थी कि bill आएगा जबकि card भी register नहीं किया था
    यह भी आखिरकार उसी बात का उदाहरण लगता है कि “billing और metering कठिन हैं, और असली service से भी बड़ा engineering काम हो सकते हैं”
    हमारा GitHub Actions बहुत धीमा है, इसलिए मैं आज यह service देख रहा था। यह अच्छी तो लगती है, लेकिन अगर मामला ऐसा है तो ज़्यादातर trials से भी ज़्यादा मुझे खुद इसे ध्यान से monitor करना पड़ेगा, इसलिए और समय लगेगा
    आम तौर पर ऐसी services में trial ख़त्म होने पर service रुक जाती है, और तब आप चुनते हैं: “यह क़ीमती है, तो subscribe करो” या “क़ीमती नहीं है, तो वापस कर दो”

    • अगर चीज़ plausible लगे और कामकाजी justification हो, तो काफ़ी कंपनियाँ बस bill pay कर देती हैं
      इसी को निशाना बनाने वाले scams भी हैं, और कुछ vendors भी इस बात का फ़ायदा उठा सकते हैं। अगर 30% customers बस bill भरना शुरू कर दें, तो बाक़ी inquiries संभालना फ़ायदेमंद हो जाता है। कम से कम तब तक, जब तक reputation damage शुरू न हो जाए
      domains रखने वाले लोगों ने शायद इसका सरल उदाहरण देखा होगा: expiry date पास आते ही कई कंपनियों से ऐसे “bills” आते हैं जो domain renewal fee जैसे लगते हैं। छोटे अक्षरों में लिखा होता है कि यह “sales solicitation” है, लेकिन ऊपर से बिलकुल invoice जैसा दिखता है, और कुछ लोग बस भुगतान कर देते हैं
    • मैं Depot का founder हूँ। इसे बेझिझक इस्तेमाल करके देख सकते हैं
      हमारे यहाँ समय-आधारित वास्तविक free trial है, और हम इस तरह की अजीब चीज़ें नहीं करते। unexpected cost explosion से बचने के लिए usage limits भी सेट की जा सकती हैं
      [0] https://depot.dev
    • यहाँ “billing कठिन है” वाली बात और user trust की समस्या एक-दूसरे पर चढ़ जाती हैं
    • OpenAI भी पहले billing कुछ इसी तरह करता था
    • startups को survive करने के लिए innovate करना पड़ता है, और YC शायद ऐसे startups को, जिनमें बहुत पैसा बनने की संभावना दिखती है, इस तरह के “innovation” से नहीं रोकता

  • इससे Austrian NIC की business practices याद आती हैं
    आम तौर पर domain renew न करो तो वह expire हो जाता है, लेकिन Austria में अगर आप fax से साफ़ तौर पर cancel नहीं करते, तो वह अपने-आप अगले साल के लिए renew हो जाता है, और पैसे न देने पर collections में भेज दिया जाता है[1]
    कम से कम country-code top-level domains (ccTLD) के लिए ऐसा कोई नियम नहीं है कि “renew न करने पर domain expire होना चाहिए।” यह बस एक convention है, और conventions assumptions पैदा करती हैं, और उन assumptions का इस्तेमाल लोगों को गुमराह करने में किया जा सकता है
    आम तौर पर business में prepaid model होता है, जैसे McDonalds, और postpaid model होता है, जैसे बैठकर खाने वाले restaurants। जो service convention के हिसाब से prepaid हो, उस पर postpaid pricing लागू कर दो तो वह पूरी तरह scam बन जाती है
    [1] https://www.reddit.com/r/sysadmin/comments/1bnjus/the_austri...

    • अगर यह कोई German service provider हो तो हैरानी की बात नहीं। हालाँकि पिछले 10 सालों में चीज़ें काफ़ी बेहतर हुई हैं
    • दरअसल जिस तरह कोई देश अपने ccTLD को manage करता है, उस पर gTLD की तरह US द्वारा लगाए गए rules बिल्कुल लागू नहीं होते
    • क्या वे अब भी ऐसा करते हैं, या यह सिर्फ पहले होता था? जो post link की गई है वह 10 साल पुरानी है

  • terms में लिखा है कि Blacksmith Software Inc service इस्तेमाल करने के लिए आपको account बनाना होगा, account setup के दौरान GitHub account connect करना होगा, अपनी organization में Blacksmith का GitHub integration install करना होगा, और Stripe द्वारा process होने वाला credit card जैसा valid payment method जोड़ना होगा
    invoice payment सिर्फ बड़े contracts के मामले में माँगी जा सकती है, और payment information देने पर आप usage fees को credit card पर charge करने की अनुमति देते हैं, या यदि invoice-based contract है तो billing terms के अनुसार समय पर भुगतान करने के लिए सहमत होते हैं
    अगर इस व्यक्ति ने बड़ा contract नहीं किया और invoice billing नहीं माँगी, तो यह terms violation है, इसलिए उन्हें सीधे कह देना चाहिए कि दफ़ा हो जाओ

  • महीने के 1,000 डॉलर? CI में आख़िर कर क्या रहे हैं?
    हम Warp build इस्तेमाल करते हैं, जो GitHub से लगभग 50% सस्ता है, और 6 लोग कई repositories में काफ़ी heavy usage के बावजूद महीने का लगभग 150 डॉलर ही खर्च करते हैं। इसमें Rust builds भी हैं, जो build time के हिसाब से कहीं बदतर case है
    मुझे नहीं पता Blacksmith बड़े runners देता है या नहीं, लेकिन अगर आप बड़े runners इस्तेमाल कर रहे हैं, तो देखना चाहिए कि वे सचमुच उतने क़ीमती हैं या नहीं। 2x runner build को 2x तेज़ नहीं करता। मैंने target तय किया और उसी के हिसाब से CI sizing की
    caching भी ज़रूरी है। अगर TypeScript code packages में split है, तो Nx से इसे संभाला जा सकता है
    पिछली नौकरी में हमने job execution के बाद time measurement task रखा था, और GitHub Markdown Mermaid support करता था, इसलिए उसे Gantt chart में दिखाया था। मुझे याद नहीं कि GitHub API current workflow का समय ला सकती थी या नहीं, इसलिए शायद वह दूसरा workflow था
    पहला हिस्सा थोड़ा manual है, और बाक़ी एजेंट शायद 5 मिनट के भीतर कर देगा

  • लंबे समय में इस तरह बिज़नेस चलाना सही तरीका नहीं लगता।
    भले ही किस्मत से कोई सच में “बिल” भर दे, इससे काफी goodwill खत्म हो जाती है और पूरे tech industry में संदिग्ध हरकत के तौर पर पहचान बनती है।

    • जहाँ free trial के लिए credit card माँगा जाता है, वहाँ मैं हमेशा virtual card इस्तेमाल करता हूँ और फिर cancel कर देता हूँ। वे जब असल में charge नहीं कर पाते और शिकायत करते हैं, तो वह देखना काफ़ी मज़ेदार होता है।

  • Blacksmith, Depot, और Ubicloud — इन तीनों को अलग-अलग समय पर संतोषजनक ढंग से इस्तेमाल कर चुके एक ग्राहक के रूप में, मैं इस बात से सहमत हूँ कि तीनों GitHub से सस्ते GitHub Actions runners देते हैं, लेकिन यह billing अजीब है।
    हाँ, यह भी कहना चाहिए कि 1,000 डॉलर का बिल आने के लिए CI time सच में बहुत ज़्यादा इस्तेमाल करना पड़ता है। यह hobby level से काफ़ी आगे की बात है, और इतनी ही usage पर पुराना GitHub लगभग दोगुना महंगा पड़ता। यह ज़्यादा उस माँग के करीब है कि वास्तविक compute demand वाले बिज़नेस सच में पैसे दें।

    • लागत के हिसाब से शायद dedicated server जैसी किसी चीज़ का इस्तेमाल करना बेहतर होता या नहीं, यह भी सोचने वाली बात है।

  • इससे मुझे Gusto के साथ हुआ अनुभव याद आ गया।
    पिछले साल मई में मैंने R&D tax credit payroll offset service के लिए sign up किया था, और उसकी fees हमें मिलने वाले benefit के एक तय हिस्से के आधार पर तय होती थीं। हमने federal tax filing सितंबर में की, इसलिए स्वाभाविक रूप से अक्टूबर से पहले कोई payroll offset नहीं था।
    फिर भी उन्होंने ऐसी service के लिए charge किया जो दी ही नहीं गई थी, और उस tool के मकसद के उलट, पहले ही दिन से cash outflow बढ़ गया। उनका कहना था कि जब मैंने checkbox दबाया था, तब छोटे अक्षरों में “sign-up पर charge” लिखा था। मुझे यह तब भी काफ़ी बेतुका लगा था, और अब भी वैसा ही लगता है।

    • क्या मैं पूछ सकता हूँ कि उन्होंने कितना charge किया, और कितने समय तक किया?

  • Blacksmith को इस thread में आकर सीधे सफाई देनी चाहिए।
    और क्या लेखक यह भी बता सकता है कि यही usage GitHub Actions पर कितने की पड़ती?

  • “अप्रिय surprise और रूखे support response के बावजूद, क्या आप Blacksmith का इस्तेमाल जारी रखेंगे?” — यह सवाल दिलचस्प है, और व्यावहारिक नज़रिए से लिया गया फैसला समझ में आता है।
    लेकिन Blacksmith को इस मामले से झटका भी लग सकता है। अगर ऐसा होता है, तो अच्छा होगा कि वह अपना व्यवहार बदले, लेकिन कई startups की तरह वह बस असफल भी हो सकता है।
    इसलिए जब तक इसकी सफलता या असफलता ज़्यादा साफ़ न हो जाए, तब तक इसे इस तरह इस्तेमाल करना समझदारी होगी कि आप service पर निर्भर न हो जाएँ। उसके बाद ही platform features का फायदा उठाने पर विचार किया जा सकता है।
    फिर भी, यह साफ़ नहीं है कि Blacksmith पर कितना भरोसा किया जा सकता है, या क्या वह बाद में छोड़ना मुश्किल बनाना चाहेगा।
    GitHub Actions की बात करें तो, Microsoft platform पर कब्ज़ा करने के बाद ऐसे products और features बनाने में बहुत माहिर है जो बेहतर विकल्प पर जाने लायक नहीं होते, लेकिन काम चलाने लायक पर्याप्त अच्छे होते हैं। GitHub Actions इसका साफ़ उदाहरण है, Teams भी वैसा ही है, और ऐसी सूची लंबी है। मुझे यह 1990 के दशक के anti-competitive behavior का आधुनिक रूप लगता है। यह इतनी रुकावटें खड़ी करता है कि competitors अंदर न आ सकें, और innovation दब जाए। मुझे यह बिल्कुल पसंद नहीं है।