Stocketa: वह ऐप जिसे मैंने डिज़ाइन और बनाया, लेकिन कभी लॉन्च नहीं किया

 (paulstamatiou.com)
2 पॉइंट द्वारा GN⁺ 2023-10-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मार्च 2020 में, कोविड आइसोलेशन के शुरुआती दिनों में, Stocketa Swift और SwiftUI सीखने के लिए एक निजी प्रोजेक्ट के रूप में शुरू हुआ और 2 साल से ज़्यादा समय तक हर हफ्ते 10–20 घंटे विकसित किया गया, लेकिन App Store पर रिलीज़ नहीं हुआ
  • लक्ष्य था कई ब्रोकरेज और वित्तीय सेवाओं में बिखरी संपत्तियों को एक जगह देखना, और हर transaction के profit/loss के साथ realized और unrealized gains/losses तक जांचना—casual investors के लिए portfolio tracker
  • ऐप ने standard iOS components से ज़्यादा खुद बनाए गए interactions पर ध्यान दिया और pull-to-search, stock cards, custom sheets/menus, swipe actions, widgets, TSV import वगैरह implement किए
  • लॉन्च में सबसे बड़ी व्यावहारिक बाधा financial data API थी; IEX की quality और coverage की समस्याएं, $100/माह provider की reliability, और $2,000+/माह commercial data pricing एक independent app के लिए ठीक नहीं बैठती थी
  • LLC, Node/Express backend, करीब 1,000 लोगों का TestFlight, और हजारों की waitlist होने के बावजूद data cost, customer support का बोझ और समय की कमी के कारण इसे बंद कर दिया गया; SwiftUI सीखने का अनुभव बाद में Rewind AI पर काम में सीधे काम आया

Stocketa जिस समस्या को हल करना चाहता था

  • Stocketa का लक्ष्य था कई जगह बिखरी investment assets को एक ही screen पर दिखाने वाला अच्छी तरह डिज़ाइन किया गया portfolio tracking app बनना
    • शुरुआत निजी अनुभव से हुई: कई brokerages और financial services में बिखरी assets को check करना झंझट था
    • सिर्फ price check नहीं, बल्कि अपने cost basis को ध्यान में रखते हुए वास्तविक transaction-level profit/loss देखना था
  • उस समय उपलब्ध विकल्प ज़रूरतों के अनुरूप नहीं थे
    • Apple Stocks जैसे simple stock apps charts और news देते हैं, लेकिन holdings quantity और profit/loss tracking नहीं देते
    • Robinhood जैसे brokerage apps सिर्फ उसी brokerage में मौजूद holdings दिखाते हैं
    • TradingView जैसी advanced services mobile-first नहीं थीं या जितना elegant experience चाहिए था, उतना नहीं देती थीं
    • Personal Capital जैसी investment advisory services में account linking होता है, लेकिन individual assets को गहराई से देखना मुश्किल है और उनका focus अपनी advisory service बेचने पर होता है
    • App Store पर छोटे holding-tracking apps का design और UX संतोषजनक नहीं था
  • मौजूदा financial apps आम तौर पर information density को प्राथमिकता देते थे, इसलिए list से detail screens में लगातार जाना पड़ता था; Stocketa first screen के cards में ही ज़्यादा जानकारी दिखाना चाहता था

Custom UI से बनी ऐप संरचना

  • Stocketa को single feed और stock cards को केंद्र में रखकर, आसपास के UI chrome को न्यूनतम करने की दिशा में design किया गया
    • standard tab bar या navigation header इस्तेमाल नहीं करना था
    • अधिकांश functions को home timeline के stock cards के भीतर रखने वाली संरचना थी
  • लगभग पूरा UI SwiftUI-based custom components से बनाया गया
    • pull-to-refresh की जगह नए symbols खोजने और जोड़ने के लिए pull-to-search इस्तेमाल किया गया
    • stock cards chart scrubbing, swipe actions, key statistics जैसी अधिकांश जानकारी inline देते थे
    • card tap करने पर मौजूदा card अपनी जगह रहता और news/holding detail cards animation के साथ दिखाई देते; core implementation में overlayPreferenceValue और anchorPreference इस्तेमाल हुए
    • custom sheets में date picker, guidance screens, twinkling stars वाला background, और drag के अनुसार background opacity interpolation शामिल था
    • custom app menu paid plan या membership status दिखाने की जगह देता था, और tap या scroll से बंद किया जा सकता था
  • swipe actions और header भी सीधे implement किए गए
    • swipe distance के अनुसार actions move करते थे, और एक threshold पार होने पर selected state में animate होते थे
    • header buttons page top पर बिना border दिखते थे और scroll के ऊपर subtle buttons में बदल जाते थे
    • Stocketa text scroll के साथ ऊपर गायब होने के लिए interpolate होता था

Transaction tracking और ऐप features

  • शुरुआती implementation stock card scrollview, charts और database persistence से शुरू हुआ
    • पहले Core Data इस्तेमाल किया, बाद में Firebase पर shift किया
    • financial data provider calls और polling जोड़ी गई, और पहला provider IEX था
  • Stocketa सिर्फ हर symbol के लिए held shares की संख्या store नहीं करता था, बल्कि transaction-level tracking implement करता था
    • buy/sell के कुल profit/loss के साथ transaction-level profit/loss भी दिखाना था
    • sell करते समय FIFO, LIFO जैसे cost basis methods जानने पड़ते थे, और किस पुराने transaction से shares बेचे जा रहे हैं, यह calculate करना पड़ता था
    • stock splits में पुराने transactions को साधारण रूप से बदलना नहीं था; नए splits की automatic application और manual application दोनों support करने थे
  • features पूरे ऐप में फैल गए
    • Onboarding: सामान्य carousel की जगह z-axis के साथ pages धकेले जाने वाला flow इस्तेमाल किया गया, और stock cards जैसे core components introduce किए गए
    • TSV import: spreadsheet से बने TSV file से transactions import करना, और import status को फिर TSV में लिखना ताकि iCloud sync के बाद re-import support हो सके
    • Buy entry: quantity, price और date पर केंद्रित stock-specific form दिया गया; date बदलने पर उस दिन की historical price placeholder बन जाती थी
    • Sell entry: FIFO, LIFO, Average cost, Highest cost, Lowest cost और specific lot support किए गए
    • Subscription screen: parallax text, scroll के अनुसार blur हटना, motion-based feature cards, और bottom पहुंचने पर छोटे fireworks effect शामिल थे
    • Membership card: active subscription account की status interactive card में दिखाई गई, background starfield effect और shimmer effect जोड़े गए
    • Stock card display settings: कई card forms और settings दिए गए, और toggles पर micro-animations जोड़े गए
    • Holdings summary card: main scroll के top पर settings-based aggregated information दिखाई गई
    • Widgets: individual stock, portfolio और simple portfolio—तीन types दिए गए; performance के अनुसार बड़े gradient colors बदलते थे
    • Face ID grace period: financial assets संभालने वाले app के लिए ज़रूरी मानकर, app switching के दौरान फिर lock होने से पहले grace period adjust करने का option दिया गया
    • Market holiday sheet: stock holding account में market holidays दिखाए गए, और widgets में भी वही handling करने के लिए server code चाहिए था
    • Feedback sheet: known issues और upcoming features दिखाए गए, और account-specific questions के लिए account verification token शामिल किया जा सकता था
    • Account deletion: 2021 के App Store update requirement के अनुसार app के अंदर account पूरी तरह delete करने की सुविधा दी गई

SwiftUI के साथ सीखते हुए फिर से बनाना

  • Stocketa Swift और SwiftUI सीखने की प्रक्रिया के साथ-साथ चला, इसलिए कई screens और app के हिस्से लगातार redesign और reimplement होते रहे
  • SwiftUI iOS 13 के बाद performance, components और capabilities के मामले में विकसित हुआ; iOS 17 में shaders, keyframes, scroll transitions जैसी capabilities भी मिलती हैं
  • SwiftUI code tool होने के साथ-साथ design tool के रूप में भी उपयोगी था
    • designers जल्दी layouts बना सकते हैं
    • interactions जोड़ना आसान है
    • native tools से वास्तविक design feel check किया जा सकता है
  • UIKit की ज़रूरत सीमित मामलों में थी
    • ज़्यादा granular input, style और format control के लिए custom text fields
    • symbol order drag-reordering के लिए CollectionView
    • confetti या night-sky stars जैसे particle emitters
    • long press शुरू होने की position पाने के लिए UILongPressGestureRecognizer

Backend और TestFlight संचालन

  • शुरुआत में backend या user accounts के बिना simple app सोचा था, लेकिन जल्द ही अपना backend ज़रूरी हो गया
    • financial data API key को app के अंदर रखने से बचने के लिए backend proxy बनाया
    • API abuse से costs न बढ़ें, इसके लिए rate-limiting और throttling जोड़ी
    • Sign In With Apple जोड़ा
    • symbol-level statistics को कुछ समय के लिए cache किया ताकि कई accounts वही data मांगें तो उसे सिर्फ एक बार fetch करना पड़े
  • backend Node/Express based था और करीब 13,000 LOC तक बढ़ गया
    • Cloud Run पर चलता था
    • authentication, caching, news, core business logic, data cleanup, notifications, widgets, multiple API integrations और कुछ scraping संभालता था
  • work management Linear से किया गया
    • tasks, ideas, features, customer feedback और milestones manage किए गए
  • TestFlight नज़दीकी दोस्तों के छोटे alpha से शुरू हुआ और धीरे-धीरे expand हुआ
    • एक समय करीब 1,000 लोगों को invite किया गया
    • waitlist में हजारों लोग थे, लेकिन API/hosting costs और support/feedback response के बोझ के कारण इसे और नहीं बढ़ाया गया
    • feedback में अच्छा first impression, feature requests और bug reports का मिश्रण था

Website design और implementation

  • शुरुआती website interest जुटाने और waitlist emails collect करने के लिए एक simple landing page थी
  • शुरुआती design में stock market chart के ups and downs से loosely inspired wave elements और floating mini stock cards शामिल थे
    • mini cards में SVG line charts थे और page load पर animate होते थे
    • background में smoothly moving effect offset-path CSS और 2 keyframe animations से implement किया गया
  • homepage v1.0 2021 की शुरुआत में पूरा हुआ
    • लगा कि app features दिखाने लायक implementation जमा हो चुका है, इसलिए ज़्यादा polished homepage बनाया गया
    • typical app homepage के phone frame + headline layout की जगह, scroll के साथ 3D phone frame move हो और app teaser video play हो—ऐसी composition try की गई
    • Lottie की जगह JavaScript द्वारा canvas और offscreenCanvas पर frame sequence draw करने का तरीका चुना गया
    • Rotato से छोटे Stocketa screencasts को 3D phone video और PNG frame sequences में बनाया गया
    • बाद में frame sequences generate, optimize और update करने की प्रक्रिया बड़ी परेशानी बन गई
  • homepage v2.0 एक साल बाद फिर design किया गया
    • अधिक features और improvements दिखाने के लिए लंबे repetitive modules के बजाय आसानी से skim की जा सकने वाली feature list चाहिए थी
    • दाईं तरफ fixed device frame और बाईं तरफ scrollable feature list वाला two-panel structure अपनाया गया
    • feature item पर mouse hover करने से device frame का screenshot बदलता था
    • mobile पर header को scrollable device-frame carousel में बदला गया
    • scroll-based hero text gradient, icon color changes, hover background gradients और icon particle emitter जोड़े गए

Financial data API से बनी सीमाएं

  • Stocketa जिस financial data quality पर निर्भर था, वह launch-ready level की नहीं थी
  • पहले provider IEX में कई समस्याएं थीं
    • charts पुराने या prices inaccurate होने के cases थे
    • IEX exchange पर कम traded assets में समस्या खास तौर पर बड़ी थी
    • OTC market data नहीं था, और OTC के साथ सीधे महंगा license लेना पड़ता
    • Nasdaq-listed stocks data भी बहुत limited था, और pre-market/after-hours जैसे basic data भी कम थे
    • बिना advance notice के mutual fund data पूरी तरह बंद कर दिया
  • बाद में इस्तेमाल किया गया दूसरा commercially viable provider $100/माह था, लेकिन data और reliability issues और ज़्यादा थे
    • endpoints पुराने या गलत data return करते थे
    • issues बताने पर वे bugs ignore करते या कहते कि ऐसा कुछ है ही नहीं
  • कुछ data paid APIs से भी पाना मुश्किल था, इसलिए backend में scraping engine बनाना पड़ा
    • dividend yield
    • earnings dates
    • OEF data
  • high-quality market data का pricing structure independent app developers के लिए उपयुक्त नहीं था
    • कुछ प्रमुख US market data providers की commercial data pricing $2,000/माह से शुरू होती है
    • index data या options data के लिए extra cost चाहिए होती है
    • एक provider ने startup plan के रूप में $499/माह और MAU-based fee बताई, लेकिन इसे भी ज़रूरत की तुलना में बहुत महंगा माना गया
  • financial data APIs पर निर्भर projects में बाहरी company APIs पर business बनाने का risk होता है, और इसे Twitter व Reddit API changes जैसी समस्या माना गया

लॉन्च रोकने के कारण

  • Stocketa शुरुआत से वास्तविक business नहीं, बल्कि side project था
    • इसे असली business बनाने के लिए और features व monetization methods चाहिए थे
    • financial advisory services या stock trading जैसे क्षेत्रों में जाना पड़ सकता था, और ये बड़े players से भरा crowded area है
    • वह दिशा simple और elegant app बनाने वाले शुरुआती उद्देश्य से मेल नहीं खाती थी
  • रुकने के कारण तीन बिंदुओं में संक्षेपित किए गए
    • Data: reasonable subscription price पर launch करने के लिए reliable, affordable और high-quality financial data चाहिए था, लेकिन cost और availability बड़ी चुनौती थी
    • Support: TestFlight usage patterns देखकर लगा कि customer support, email, maintenance और continuous feature development में काफी investment चाहिए होगा
    • Time: focus के लिए Rewind AI चुना गया, और Stocketa ने कई सालों तक nights, weekends और blog-writing time तक ले लिया था
  • मूल लक्ष्य—Swift और SwiftUI सीखना—पूरा हो गया
    • launch नहीं हुआ, लेकिन native iOS development बहुत सीखी
    • Stocketa से मिला SwiftUI knowledge Rewind AI के काम में बहुत मददगार रहा

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

1 टिप्पणियां

 
GN⁺ 2023-10-17
Hacker News टिप्पणियाँ

  • कई सालों का कोई प्रोजेक्ट असल में इस्तेमाल न हो, तो यह लगभग सम्मान के बैज जैसा भी महसूस होता है। समझदारी वाला बैज तो नहीं, लेकिन मेरे जैसे डेवलपर के लिए—जो अच्छे अर्थों में over-obsess होकर पूरी तरह डूब जाता है—यह लगभग ज़रूरी सबक भी है।
    पुराने अनुभव और उससे मिली तकलीफ़ के बारे में बताने पर लगता है लोग सुन्न पड़ जाते हैं। अगर आपने एक साल से ज़्यादा समय तक रोज़ 10 घंटे से अधिक किसी चीज़ पर नहीं लगाया है, तो हज़ारों घंटे डालकर भी कोई नतीजा न मिलने का एहसास समझना मुश्किल होगा।
    सफल प्रोजेक्ट भी बहुत हैं और अभी भी अच्छा चल रहा है, लेकिन वे कई सालों वाले प्रोजेक्ट वापस नहीं लाए जा सकते। सीखने के लिए शायद ज़रूरी थे, लेकिन उन्हें याद करने पर अब भी उदासी और खालीपन महसूस होता है।

    • 2016 में Swift और UIKit खुद सीखते हुए iOS ऐप बनाते समय मेरे साथ भी कुछ ऐसा ही हुआ था। 2 साल तक हफ्ते में 5 दिन, रोज़ करीब 2 घंटे लगाकर 1,000 घंटे से ज़्यादा डाले, लेकिन वह ऐप अंततः कभी पब्लिश नहीं हुआ।
      बदले में मुझे कहीं बेहतर प्रोग्रामर बनने की skills मिलीं और Swift से लगाव हो गया। आज होता तो पिछले 7 वर्षों में Apple developer tools और APIs में हुई प्रगति की वजह से शायद उस पूरे ऐप को एक weekend में शून्य से फिर बना सकता।
      ऐसे प्रोजेक्ट्स को यादगार मानना चाहिए। Programming कला हो सकती है, और कला एक creative outlet के रूप में सिर्फ़ अपने लिए भी बनाई जा सकती है।
    • ऐसी चीज़ों पर पछतावा तभी मायने रखता है जब उस समय आपको पहले से पता था कि यह नहीं चलेगा, फिर भी आपने अपने बेहतर judgment के खिलाफ़ जाकर उसे धक्का दिया। अगर उस समय उपलब्ध जानकारी के आधार पर आपने सबसे अच्छा निर्णय लिया था, तो आप बस वही कर सकते थे; बाकी सब किस्मत पर निर्भर था।
      बाद में मिली जानकारी के आधार पर पुराने प्रोजेक्ट पर दुखी होना, यानी result-oriented thinking, बहुत उपयोगी नहीं है। ज़्यादातर प्रोजेक्ट और businesses fail होते हैं, यही वास्तविकता है।
      मुझे एक पूर्व finance professional की लिखी बात याद है: “खराब trade से संयोग से पैसे कमा लेने पर किसी को नौकरी से नहीं निकाला जाता।” परिणाम-केंद्रित culture में हम आसानी से भूल जाते हैं कि हमारे वास्तविक नियंत्रण में सिर्फ़ process होता है।
    • मैंने एक software project पर 10 साल लगाए, और उसे पूरा हुए 6 महीने हो चुके हैं, फिर भी अभी तक एक पैसा नहीं कमाया :(
      कब रुकना है, यह जानने जैसा कीमती सबक तो मिला, लेकिन यह बहुत ही लंबा सबक था। मैं अब भी उसे ठीक से पलटकर सोच नहीं पा रहा हूँ।
    • किसी प्रोजेक्ट में कई साल लगाने के बाद जैसे ही आप उसे किसी को दिखाएँ और वह “अच्छा नहीं है” कहकर किनारे कर दे, या बस X करने को कहे—इससे ज़्यादा मनोबल तोड़ने वाली बात कम ही होती है।
    • शायद दर्द इसलिए ज़्यादा है क्योंकि लक्ष्य सफलता था—यानी ऐप usage या revenue। अगर मुख्य वजह आनंद या सीखना होती, तो शायद एहसास अलग होता।
      सोच रहा हूँ कि क्या यह सलाह देना सही होगा कि अगर आपको पूरा भरोसा नहीं है कि कोई इस्तेमाल न करे तब भी पछतावा नहीं होगा, तो 1 साल से ज़्यादा चलने वाला प्रोजेक्ट शुरू न करें।

  • बेहतरीन लेख है, लेकिन निष्कर्ष दुखद लगा। ऐसे “बिना फालतू चीज़ों वाले version” की ज़रूरत वाले ऐप बहुत हैं, और इसमें लगा काम सचमुच अद्भुत है।
    मैंने एक और सरल iOS ऐप launch किया था, जो organic traffic से रोज़ करीब 1,000 active users तक पहुँचा, लेकिन अंततः बंद कर दिया। Ads हटाने के लिए $1.99 या $2.99 का एक in-app purchase लगाया था और bug reports संभालते हुए महीने के करीब $70 कमा रहा था।
    उस समय SwiftUI अभी mature नहीं था, इसलिए UIKit इस्तेमाल करना पड़ता था, और ऐसे edge cases बार-बार आते थे जिन्हें ठीक करना मुश्किल था।
    निर्णायक झटका तब लगा जब Google ने दावा किया कि मैंने अपने ही ads पर click किया है और ads serve करना बंद कर दिया। असल में सारी कमाई रुक गई, और मुझे एहसास हुआ कि चाहे इसे कितनी मेहनत से बनाऊँ, आखिरकार यह बड़ी tech कंपनियों की सनक पर निर्भर है।
    Apple हर in-app purchase से 30% लेता था, ad revenue बहुत कम था, और Google बिना वजह उसे बंद कर सकता था, appeal का कोई रास्ता भी नहीं था। मैं कोई बड़ी रकम कमाने नहीं निकला था, लेकिन समय और ऊर्जा लगाने की कोई वजह चाहिए थी, और अब उसे justify नहीं कर पा रहा था।

    • Google का अपने ही ads पर click करने के कारण ads बंद कर देना बेहद कठोर और बकवास लगता है।
      समझ नहीं आता कि वे developer को revenue-excluded devices, IP ranges, और locations की list register करने क्यों नहीं देते। आखिर आप अपना ऐप इस्तेमाल तो करेंगे ही, और scroll करते समय कई बार ad पर गलती से tap न करना लगभग असंभव होता है।
      real-world testing भी ज़रूरी है, और यह छोटी-सी संभावना भी रहती है कि ad सचमुच रोचक हो और आप potential customer के रूप में वैध रूप से click करें। लेकिन मौजूदा तरीका असल में कहता है कि अपना ऐप इस्तेमाल मत करो।
      समझ नहीं आता कि ऐसी मूल रूप से मूर्खतापूर्ण policy पर अड़े रहने से Google के developers या managers के अलावा किसका भला होता है। क्या इसे थोड़ा भी ठीक से handle करना सच में इतना मुश्किल है?

  • 20 साल से कोई performance या album न निकालने वाला bedroom musician, 18 साल की उम्र के बाद गेंद फिर कभी न छूने वाला बचपन का athlete, race में न उतरने वाला runner, और न पढ़ाने वाला intellectual—इनके बारे में भी इसी तरह सोचा जा सकता है।
    अगर वही “external output = value” वाली धारणा मानें, तो इसे उन इंसानों तक भी बढ़ाया जा सकता है जिन्होंने दशकों जीकर भी बच्चे नहीं किए। यह मेरा विश्वास नहीं है, बस logic के प्रवाह में बात वहाँ तक जाती है।
    लेकिन ऐसे judgments इंसानों द्वारा बनाई गई constructs हैं, और लंबे समय से सँजोए “हमारे बच्चे” को दुनिया में भेजने की जैविक आज्ञा का आईना लगते हैं। हम पूछते हैं कि वे अपनी life क्यों न पाएँ, और चाहते हैं कि वे अपने दम पर आगे भी perform करते रहें और भविष्य में कुछ जोड़ें।
    क्या उस आज्ञा का पालन करना नैतिक, आचारिक और आनंद का शिखर है? कुछ लोगों के लिए हाँ, और मैं judgment नहीं करना चाहता। लेकिन कुछ लोगों के लिए, अजीब तरह से, ऐसा नहीं है।

  • सोच रहा हूँ कि क्या वे इस project को बेचने में रुचि रखते हैं। concept अच्छा लगता है और लगता है interested customers भी हैं, लेकिन वे support burden और commercialization संभालना नहीं चाहते।
    मैंने asset tracker (https://jch.app) करीब एक साल पहले बनाया था, लेकिन features और user experience में अभी बहुत पीछे है।
    ज़बरदस्त काम है और यात्रा का गहरा रिकॉर्ड भी अच्छा लगा। rewind.ai से आगे क्या आता है, इसका भी इंतज़ार रहेगा।

  • यह उन अनगिनत लोगों से बहुत अलग नहीं है जिन्होंने ऐसे अनगिनत projects पर अंतहीन समय लगाया जिनका किसी और के लिए ज़्यादा मतलब नहीं था। यह साइकिल hack करने या model trains से छेड़छाड़ करने जैसा है
    फर्क बस इतना है कि apps को इस तरह आसानी से public, document और preserve किया जा सकता है, लेकिन “अजीब साइकिल parts काटने और weld करने में बिताया गया समय” YouTube पर सब कुछ upload किए बिना ऐसा करना मुश्किल है
    बेशक बहुत लोग ऐसा करते हैं, और उसका कुछ मतलब भी होता है, लेकिन जब hobby और personal pursuits को, उनके अपने लिए होने के बजाय, किसी दूसरे लक्ष्य वाले product में बदलने की कोशिश करते हैं, तो बात का मूल थोड़ा छूट भी जाता है
    इसका मतलब यह नहीं कि यह लेख गलत है। यह शिकायत या गुस्से जैसा नहीं लगता, बल्कि शुरुआत में कही बात की तरह “कहीं न कहीं किसी तरह इसे दर्ज कर देना चाहता हूं” जैसा एहसास है। मेरे GitHub का ज़्यादातर हिस्सा भी ऐसा ही है

    • यह बात गहरी है कि क्या संभव हो सकता था, वही सच में जो हुआ उसे आंकने का benchmark बन जाता है
      इस तरह evaluation benchmark का जल्दबाज़ी में adjustment बहुत उपयोगी नहीं हो सकता, क्योंकि यह वास्तविक नतीजे को धुंधला कर देता है। इस मामले में author के लिए अपने “wasted” effort पर शर्मिंदा होना आसान है, लेकिन ज़्यादा उचित प्रतिक्रिया सीखी गई चीज़ों के लिए आभार होना चाहिए
      ऐसे projects से मिलने वाली सीख बहुत बड़ी होती है

  • यह लेख डरावना इसलिए है क्योंकि इसमें मुझे अपनी झलक बहुत ज़्यादा दिखती है। एक बेहतरीन product बनाने में गहराई से डूब जाना, craftsman वाली identity में रम जाना, और तेज़ व गंदे MVP और बार-बार market testing जैसे “बेरूह” approach से चिढ़ महसूस करना
    अगर आप r/SaaS subreddit पर गए हैं, तो वह software developer के तौर पर जिन चीज़ों का मैं आनंद लेता हूं, उसके ठीक उलट है
    लेकिन मुझे यह भी पता है कि अगर market testing और तेज़, messy iteration को लेकर अपनी सोच बदल सकूं, तो शायद वही मुझे निश्चिंत होकर craftsmanship पर focus करने की बेहतर नींव दे

  • समझ आता है। मैं भी अभी तक bank backend बना रहा हूं। Core, accounting, customers, accounts, payments (SEPA और cards), notifications (ServiceNow जैसा), sanctions screening, risk और monitoring engine, event flows, reporting—सब मिलाकर 5 साल हो गए
    अब मुझे शक होने लगा है कि इतना बड़ा काम अपने ऊपर लेना पागलपन था या मूर्खता। अभी landing page भी design नहीं किया है, और code करीब 1.5 लाख lines का हो गया है

    • इस field में होने के नाते, मेरी मजबूत सलाह है कि जितनी जल्दी हो सके potential customers से contact करें और trust बनाना शुरू करें
      मौजूदा platform में bugs, limitations और security issues बहुत थे, फिर भी customers को हमारे core banking platform पर migrate करने के लिए राज़ी कराने जितना trust हासिल करने में 5 साल से कहीं ज़्यादा समय लगा
    • मैंने भी payments, REST messaging, email server (IMAP/SMTP), affiliate ads और अपने payments, reporting व access control तक वाली e-commerce solution बनाई थी। Desktop और mobile web frontend सहित पूरी solution को alpha state तक बना लिया था
      लेकिन जैसे-जैसे mobile apps महत्वपूर्ण होने लगे, मैंने native apps भी बनाना शुरू कर दिया, और वह बहुत ज़्यादा हो गया। आखिर burnout हुआ और bankruptcy तक पहुंच गया, इसलिए मैं mega-projects की सलाह नहीं दूंगा
      बहुत कुछ सीखा, लेकिन wasted effort उसकी कीमत के लायक नहीं था। इतनी सारी चीज़ें दोबारा बनाने के लिए समय बहुत महत्वपूर्ण है। अब मैं अधिकतम 6–12 महीनों वाले “छोटे” projects ही करता हूं
    • क्या आप bank backend को side project के तौर पर बना रहे हैं? दिलचस्प है। जानना चाहूंगा कि यह मज़े के लिए किए जा रहे project जैसा है या इसका कोई commercial goal है
      यह भी जानना चाहूंगा कि इसके open source होने की संभावना है या नहीं
    • इसे launch करना चाहिए। Screenshots, feature list और planned feature list को अलग-अलग करके डालें और beta signup form से शुरुआत करें
      अगर आप अपनी जोड़ना चाही हर चीज़ हटाकर भी basic version launch नहीं कर सकते, तो इसे कुछ समय के लिए side में रखने पर विचार करना चाहिए
      पिछले 20+ सालों में मैंने कई projects और products बनाए हैं, और 2–3 काफी बड़े हुए। बाकी के हजारों users हैं लेकिन recurring revenue stream नहीं है
      जो एक profitable business बना, उसे “weekend build” version के रूप में launch किया था, और फिर अगले 7 सालों में उसे build up किया
    • खुद से यह भी पूछना चाहिए: “अगर यह successful हो तो कैसा दिखेगा?” अगर 5 साल तक कोई revenue नहीं आया है, तो शायद आप अभी वाली stage के आदी हो गए हैं
      परिचित state एक trap बन सकती है जो आपको launch से पहले करने के लिए और काम ढूंढते रहने पर मजबूर करती है। इसलिए अपने मन में frame को फिर से set करना अच्छा हो सकता है

  • हाल ही में मैंने पढ़ा कि Leonardo DaVinci बहुत बड़े टालमटोल करने वाले थे, और उनके अधूरे projects बहुत ज़्यादा थे
    कई क्षेत्रों में इतनी सफलता पाने वाले व्यक्ति के रूप में मैं हमेशा उनकी प्रशंसा करता था, लेकिन यह जानने के बाद procrastination को लेकर मेरा नजरिया बदल गया—यह हम creative लोगों का एक हिस्सा है
    इसे failure भी माना जा सकता है, लेकिन process के हिस्से के रूप में फिर से interpret भी किया जा सकता है। आखिरकार, हमें कुछ न कुछ बनाना पसंद है

  • उन्होंने असल में “MVP बनाओ, जल्दी launch करो, iterate करो” वाली आम सलाह स्वीकार की और फिर ठीक उसका उलटा किया

    • बड़े tech companies में 10 साल तक subpar experiences ही ship करने के बाद, ठीक उलट जाकर quality पर focus करना expected था। https://paulstamatiou.com/craft/
    • पता नहीं वह सलाह solo developer पर भी लागू होती है या नहीं। ऐसी app जैसे स्वाभाविक रूप से maximalist products में, आपको बहुत छोटे-छोटे हिस्सों की जिम्मेदारी अकेले लेनी पड़ती है, इसलिए तेज़ी से move करना जैसी कोई चीज़ नहीं होती

  • शानदार दिखने वाले side project पर बेहतरीन लेख है। दिलचस्पी से पढ़ते-पढ़ते rewind.ai मिला, और वह भी अच्छा लग रहा है
    लगातार automatic screen/audio recording जैसी संभावित रूप से intrusive चीज़ों में privacy बहुत अहम है, इसलिए “Privacy first” सेक्शन देखते हुए मेरे मन में सवाल आया
    इसमें लिखा है, “FileVault से डेटा encrypt करें। Apple FileVault Rewind के साथ काम करता है। इसे चालू करने पर आपका डेटा encrypt हो जाता है” — क्या Rewind कुछ ऐसा करता है जिससे Apple FileVault “Rewind के साथ काम” करे?
    या फिर यह बस सामान्य disk encryption की बात है जो हर चीज़ पर लागू होती है? सचमुच पूछ रहा हूँ। मैं Rewind इस्तेमाल करना चाहता हूँ, लेकिन यह wording बेवजह की packaging जैसी समझी जा सकती है
    “केवल relevant text-based data cloud पर भेजा जाता है और transit में encrypted रहता है” वाली पंक्ति भी वैसी ही लगती है। क्या “encrypted in transit” से standard TLS encryption मतलब है? Rewind अच्छा लग रहा है, लेकिन उस पर भरोसा किया जा सकना चाहिए

    • Rewind वेबसाइट पर यह लिखा है
      “Cloud integration की ज़रूरत नहीं है। Gmail, Dropbox, Slack जैसी कई services से connect किए बिना सब कुछ अपने-आप काम करता है”
      लेकिन https://www.rewind.ai/privacy पर official privacy policy की details देखें तो यह लिखा है
      “[हम जो collect करते हैं:] OpenAI द्वारा बनाई गई जानकारी। Rewind AI के OpenAI integration के हिस्से के रूप में, हम OpenAI द्वारा generated output भी collect कर सकते हैं, जैसे audio recordings के transcription summaries और OpenAI integration द्वारा generate किया गया अन्य data”
      तो फिर “cloud integration की ज़रूरत नहीं” है, लेकिन क्या मेरा audio OpenAI के साथ share होता है?
      साथ ही https://www.rewind.ai/privacy-first पर लिखा है, “जब आप Rewind में search करते हैं तो क्या होता है? सारी recording data local ही रहती है”
      समझ नहीं आ रहा कि दोनों में से सच क्या है। मैं Rewind पर भरोसा करना चाहता हूँ, लेकिन user data कैसे handle होता है, इसे समझाने वाली बातों में inconsistency के कारण हिचक रहा हूँ
    • बताने के लिए धन्यवाद। लगता है उस page को update करना होगा, और इसमें अपनी encryption भी है। अधिक जानकारी यहाँ है: https://help.rewind.ai/en/articles/7242593-is-the-rewind-dat...