The One-Person Framework का व्यावहारिक उपयोग

 (bramjetten.dev)
35 पॉइंट द्वारा GN⁺ 2025-04-30 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • एक solo developer की व्यावहारिक कहानी, जिसने Rails पर पूरा service develop और maintain करते हुए सालाना €1 million ARR (recurring revenue) हासिल किया
  • शुरुआत में सिर्फ basic MVP के साथ शुरू किया, लेकिन full rewrite और structural improvements के बाद इसे एक maintainable structure में बदला
  • मुख्य ताकत Rails की consistent philosophy, built-in components, और Turbo Native के जरिए mobile support देने की क्षमता रही
  • पूरे traffic और usage को संभालते हुए भी मासिक €1,500 से कम server cost पर service चलाने वाली efficient structure
  • अंत में long-term सोच वाले investor को कुछ equity बेची गई, और 14 साल बाद दूसरे developer की hiring के साथ एक नए चरण की शुरुआत हुई

The One-Person Framework का व्यावहारिक उपयोग

सिर्फ Rails के दम पर €1 million ARR

  • 2022 की शुरुआत में, PlanGo ने सालाना recurring revenue (ARR) €1 million पार कर लिया, और यह एक single Rails codebase और सिर्फ एक developer से बनी service के लिए किसी सपने जैसा achievement था
  • टेक्नोलॉजी के अलावा बाकी सभी हिस्से—vision तय करना, customer acquisition, growth strategy—co-founder और customer support team संभालते थे, लेकिन architecture design से deployment, operations, और front/back-end implementation तक सब कुछ अकेले किया गया
  • DHH द्वारा कही गई “One Person Framework” की अवधारणा, यानी ऐसा structure जिसमें एक developer पूरी application संभाल सके, सिर्फ theory नहीं बल्कि वास्तविकता साबित हुई
  • Rails की structural philosophy—database design, business logic, और frontend UI तक सब कुछ एक consistent toolset के भीतर करना—छोटी टीमों या solo founders के लिए खास तौर पर फायदेमंद है
  • यह लेख खास तौर पर इन लोगों के लिए लिखा गया है:
    • Rails developers: जो सोचते हैं कि क्या आज भी अकेले बड़ा product बनाया जा सकता है
    • Tech founders: जो कई भूमिकाएँ निभाते-निभाते overwhelmed महसूस करते हैं
    • वे लोग जो craftsmanship और tech choices को महत्व देते हैं

शुरुआत के समय की स्थिति

  • लेखक ने 2011 में, 21 साल की उम्र में, पहले से चल रहे PHP(CodeIgniter) project पर काम करते हुए Rails सीखना शुरू किया
  • कोई बड़ी strategy नहीं थी; शुरुआत सिर्फ trend को देखकर Rails आज़माने की simple motivation से हुई
  • co-founder के marketing idea के तहत launch week में sign up करने वालों को 1 साल free देने की offer strategy चलाई गई
    • उम्मीद सिर्फ कुछ दर्जन users की थी, लेकिन वास्तव में पहले हफ्ते में 500 से ज्यादा sign-ups हुए
    • क्योंकि product MVP level का था, तुरंत ही सैकड़ों feature requests, सवाल, और support requests आने लगे
  • server तो ठीक चल रहा था, लेकिन product पूरा तैयार होने से पहले ही customer demand फट पड़ी
  • दोनों co-founders की full-time jobs थीं, इसलिए full-time response देना संभव नहीं था
    • नतीजतन, कई शुरुआती users को निराश करना पड़ा
    • इस अनुभव से साफ हुआ कि “software development” और “software business चलाना” पूरी तरह अलग समस्याएँ हैं
  • सिर्फ features बनाना काफी नहीं होता; sustainable customer response, expectation management, और service operations system भी ज़रूरी होते हैं—यह बड़ा सबक मिला

बनाते-बनाते सीखना

  • Rails tutorial और Stack Overflow देखकर development शुरू किया गया, लेकिन production environment में असली customers के business की जिम्मेदारी उठाने वाली application बनाना पूरी तरह अलग स्तर का काम निकला
  • शुरुआती Rails code में ऐसे typical beginner mistakes थे:
    • 200 lines से बड़े controller methods
    • अलग-अलग जिम्मेदारियों से भरे massive models
    • inefficient SQL queries
    • test code का अभाव
    • Git में commit किए गए config values और secret keys
  • features बन रहे थे, लेकिन पूरी application temporary fixes और unstable structure पर टिकी हुई थी
  • user authentication, file upload, PDF generation, admin UI, email handling जैसी कई चीज़ें Gems पर निर्भर होकर जल्दी बनाई गईं, लेकिन समय के साथ हर Gem अपनी नई complexity और problems लेकर आया
  • .round(2) इस्तेमाल करते समय उम्मीद के उलट "banker's rounding" लागू हुआ, जिससे amount calculation में error हुआ
    • साधारण calculation भी external Gem पर छोड़ने का नतीजा यह हुआ कि number handling की बुनियादी समझ की कमी से समस्या पैदा हुई
  • 2013 के आसपास, product operations का अनुभव बढ़ रहा था, लेकिन साथ ही technical debt भी तेज़ी से बढ़ रही थी, और नए features बनाना मुश्किल होता जा रहा था

पूरी तरह से दोबारा लिखना

  • Full Rewrite को आमतौर पर risky और inefficient choice माना जाता है, लेकिन 2014 में Rails 4 के आधार पर सब कुछ शुरू से दोबारा बनाने का फैसला लिया गया
  • पुरानी application को maintain करते हुए, साथ-साथ नई codebase पर focused work कई महीनों तक किया गया
  • architecture को simplify किया गया, Gem dependencies आधे से कम की गईं, और core functionality पर tests जोड़े गए
  • नई structure पहले से ज़्यादा concise और fast थी, और खास तौर पर part-time solo developer भी maintain कर सके, इस स्तर पर design की गई
  • यही rewrite बाद के 10 साल से अधिक समय तक एक solo developer द्वारा चलाए जा सकने वाले technical foundation में बदल गई

Rails एक superpower है

  • PlanGo को 2025 तक सिर्फ एक developer ने चलाया, और इसे संभव बनाने की सबसे बड़ी वजह Rails थी
  • Convention over Configuration, integrated tests, ActiveRecord, ActiveStorage, ActiveJob जैसी Rails की structural खूबियों की वजह से non-essential decisions कम हुए और core value creation पर focus किया जा सका
  • Turbolinks और बाद में Hotwire अपनाने के बाद complex JS framework के बिना भी modern UI बनाना संभव हुआ
  • 2011 की शुरुआती development phase में mobile app की demand लगभग नहीं थी, लेकिन बाद में iOS/Android apps, PlanGo का मुख्य interface बन गईं
  • Titanium, RubyMotion, Objective-C जैसे कई frameworks आज़माते हुए quality और speed के बीच balance की चुनौती झेलनी पड़ी
  • Turbo Native अपनाने के बाद productivity तेज़ी से बढ़ी, और basic native development knowledge के साथ भी Rails codebase का उपयोग करके high-quality apps बनाना संभव हो गया
  • यह तरीका खास तौर पर B2B या SaaS apps के लिए ideal approach है, क्योंकि इसमें छोटे development cost पर native performance और experience हासिल किया जा सकता है
  • नतीजतन सालाना 100,000 से ज्यादा app downloads, और कुछ समय के लिए Netherlands App Store में Duolingo से ऊपर ranking भी मिली
  • सभी apps को एक ही Rails developer ने develop और maintain किया
  • मुख्य metrics:
    • Ruby code: 36,170 lines
    • JavaScript code: 13,495 lines
    • test coverage: 40%
    • daily active users: 6,332
    • peak time requests per minute: 7,000
    • monthly server cost: €1,500 से कम
  • structured monolithic architecture बनाए रखना सबसे अच्छे फैसलों में से एक था; microservices की complexity के बिना Capistrano से आसान deployment और debugging संभव रही
  • tech founders के लिए Rails सिर्फ एक framework नहीं, बल्कि ऐसी superpower है जो एक व्यक्ति को पूरी team का काम करने लायक बना देती है

€1 million के आगे

  • 2022 के आखिर में एक अप्रत्याशित turning point आया। विदेशी investor ने PlanGo में रुचि दिखाई और acquisition proposal दिया
  • उस समय PlanGo bootstrap तरीके से €1M ARR पार कर चुका था, और बिना बाहरी funding के भी sustainable revenue structure और efficient operations बनाए हुए था
  • इस प्रस्ताव ने टीम के भीतर "हम आगे क्या चाहते हैं?" यह सवाल खड़ा किया
  • मौजूदा तरीके से चलते रहना, external funding लेकर scale up करना, या पूरी तरह sell करना—कई संभावनाएँ खोजी गईं
  • business के प्रति लगाव अब भी गहरा था, लेकिन यह समझ भी बनी कि ज्यादा resources और expertise के साथ मौकों को ज़्यादा आसानी से action में बदला जा सकता है
  • value realization के लिहाज़ से भी, 10 साल से ज्यादा में बनाई गई value का कुछ हिस्सा निकालते हुए business को आगे बढ़ाते रहना एक तर्कसंगत विकल्प था
  • अंत में चुना गया रास्ता था Netherlands के एक evergreen fund के साथ partnership, जिसके values और long-term direction अच्छी तरह मेल खाते थे
    • कुछ equity बेची गई, लेकिन management control और majority stake बनाए रखी गई
    • अतिरिक्त resources मिले, और साथ ही मौजूदा structure और culture को नुकसान न पहुँचाने वाला मॉडल कायम रहा
  • यह फैसला short-term exit या aggressive expansion नहीं, बल्कि sustainable और customer-centric business पर आधारित stable growth strategy का हिस्सा था
  • इसके बाद भी Rails-based approach जैसी की तैसी रखी गई, लेकिन पहले मुश्किल लगने वाले opportunities को अब ज्यादा सक्रिय रूप से pursue करने का नया चरण शुरू हुआ

सीखी गई बातें

  • PlanGo को 14 साल तक solo tech founder के रूप में चलाते हुए ये सीखें मिलीं
  • Embrace Rails conventions
    • Rails की philosophy और conventions के खिलाफ जाने की कोशिश न करना महत्वपूर्ण है
    • “Rails Way” पहले से साबित problem-solving approach है, और इसे जितना अपनाया जाए, उतना product की unique value पर focus किया जा सकता है
  • Less is more
    • Gem या JS libraries features जल्दी बनवा सकती हैं, लेकिन साथ ही complexity और failure की संभावना भी बढ़ाती हैं
    • नई dependency जोड़ने से पहले खुद से ज़रूर पूछना चाहिए: “क्या यह सच में ज़रूरी है?”
  • Find a community
    • solo developers के लिए दूसरे Rails developers से जुड़ाव बहुत महत्वपूर्ण है
    • उदाहरण के तौर पर, Spina CMS बनाते समय मिली community सहकर्मी न होते हुए भी knowledge sharing और feedback के लिए एक अनमोल connection बनी
  • Technical debt isn't always bad
    • कभी-कभी बाज़ार में जल्दी पहुँचने के लिए practical choices, technical perfection से बेहतर होते हैं
    • technical debt में असली बात यह है कि कब जानबूझकर लेना है और कब चुकाना है, यह समझना
  • You can go far alone
    • Rails के साथ एक developer भी team-scale product को design, scale, और deploy कर सकता है
    • “team तो ज़रूरी है” जैसी आम धारणाओं में बंधे रहने की ज़रूरत नहीं

आगे क्या

  • नए investment partner ने PlanGo के lean operating style से सहमति जताई, लेकिन एक शर्त रखी: एक और Rails developer जोड़ा जाए
  • समस्या solo development पर अड़े रहने की नहीं थी, बल्कि 14 साल में विकसित हुई codebase पर नए developer को onboard कराने की कठिनाई थी
  • यह codebase सिर्फ PlanGo की evolution नहीं थी, बल्कि एक beginner से experienced developer बनने तक की व्यक्तिगत development history भी अपने भीतर समेटे हुए थी,
    जहाँ अलग-अलग समय के खुद के फैसले और code styles साथ-साथ मौजूद थे
  • Rails World (Canada) में मिले दूसरे Rails developer को hire करने के बाद structural changes और positive impact देखने को मिला
    • single point of failure रहे technical risk का समाधान
    • नई दृष्टि और ideas का आना
    • pair programming के जरिए code quality में सुधार
    • एक ही भाषा बोलने वाले fellow developer के साथ collaboration से मिलने वाली बौद्धिक ऊर्जा
  • आगे भी बड़ी development team बनाने की कोई योजना नहीं है
  • जैसा अब तक साबित हो चुका है, सिर्फ Rails-based approach से भी छोटी लेकिन ताकतवर team meaningful software बना सकती है
  • फिर भी, यह महसूस हुआ कि सबसे efficient solo developer भी अच्छे teammate के साथ और आगे बढ़ सकता है
  • PlanGo की यह journey Rails के One-Person Framework के वास्तव में काम करने का उदाहरण है,
    और इस बात का प्रमाण भी कि सही tools के साथ छोटी team अपने मानकों पर गंभीर business खड़ा कर सकती है
  • चाहे आप अपना पहला product बना रहे solo developer हों, या tech stack को लेकर सोच रही छोटी team—यह कहानी Rails का पूरा फायदा उठाने पर क्या-क्या संभव है, यह दिखाती है

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

4 टिप्पणियां

 
xguru 2025-04-30

मैंने इस सामग्री को NotebookLM audio overview के साथ podcast में बदलकर देखा।

https://notebooklm.google.com/notebook/…

इस स्तर पर तो यह शानदार है। इसे थोड़ा और निखारना होगा।
 
dlehals2 2025-04-30

वाह.. कमाल है.. सच में। यह इतना स्वाभाविक है, यकीन नहीं होता
 
rococogg 2025-04-30

और जानकारी भी बहुत आसानी से समझ में आ रही है...
 
GN⁺ 2025-04-30
Hacker News राय

  • Django जैसे अनुभव वाला एक उपयोगकर्ता अपना ऐप चला रहा है

    • सबसे बड़ा ऐप एक मध्यम आकार की कंपनी के ERP जैसा है, जिसमें अलग-अलग permission levels शामिल हैं
    • उसने एक महीने में ज़्यादातर features production में डाल दिए, जबकि आम तौर पर टीमों को इसमें 2 साल लगते हैं
    • मासिक page views 10-20 लाख हैं, और server load कम करने के लिए static HTML और Cloudflare का इस्तेमाल किया जा रहा है
    • चीज़ों को जितना हो सके उतना simple रखा गया है, REST/frontend frameworks से बचा गया है और Bootstrap-आधारित HTML forms का उपयोग किया गया है
    • JavaScript का इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर किया जाता है, और अभी AlpineJS/HTMX का उपयोग हो रहा है

  • एक उपयोगकर्ता का कहना है कि framework से ज़्यादा इंसान महत्वपूर्ण होता है

    • उसने अपने development style के हिसाब से framework लिखकर समय और पैसे बचाए
    • उसका मानना है कि generalized frameworks टीम environments में उपयोगी होते हैं, लेकिन solo developer environment में उतने महत्वपूर्ण नहीं होते

  • एक उपयोगकर्ता ने Rails और Phoenix इस्तेमाल करने का अनुभव साझा किया

    • पारंपरिक web apps बनाते समय ये उपयोगी हैं, और Postgres जैसे चयन के समान हैं
    • वह अभी Clojure का उपयोग कर रहा है और server-side domain तथा API calls पर ध्यान दे रहा है

  • एक उपयोगकर्ता ने बताया कि उसने Rails 7+ पर एक प्रस्तुति दी थी, जिसमें कहा गया कि यह solo developers को भी ambitious apps बनाने में मदद करता है

  • एक उपयोगकर्ता ने अपना अनुभव साझा किया जिसमें एक नए partner ने Rails developer जोड़ने की इच्छा जताई थी

    • codebase डेवलपर की growth journey को दर्शाता है, और इसमें अलग-अलग experience levels पर लिए गए निर्णय शामिल हैं
    • उसने यह भी साझा किया कि उसने दूसरी कंपनी में एक ऐसे codebase का सामना किया था जिसे कम अनुभवी developer ने शुरू किया था

  • एक उपयोगकर्ता AdonisJS का इस्तेमाल करके ऐप बना रहा है

    • Rails, Adonis और Fiber की तुलना के बाद उसने Adonis चुना
    • उसने कहा कि tutorial videos और documentation बेहतरीन हैं, लेकिन LLMs पुराने versions की वजह से भ्रमित हो सकते हैं

  • एक उपयोगकर्ता का मानना है कि कई मामलों में Rails, Django से बेहतर है

    • उसने Hotwire, SOLID cache/queue, Turbo Native आदि का ज़िक्र किया
    • फिर भी वह Python ecosystem को ही पसंद करता है

  • एक solo developer Rails का इस्तेमाल करके ऐप बना रहा है

    • वह Hotwire Native का उपयोग करके mobile app भी विकसित कर रहा है
    • उसने कहा कि Rails ecosystem लगभग सब कुछ संभाल सकता है, जो काफ़ी चौंकाने वाला है

  • एक उपयोगकर्ता का कहना है कि पूरा rewrite करने से बचना चाहिए

    • rewrite कई महीनों का गहन काम था, और उसने मौजूदा ऐप को बनाए रखते हुए उसका replacement app बनाया
    • अगर ऐप छोटा हो, तो rewrite की जगह refactoring बेहतर हो सकती है

  • एक उपयोगकर्ता को लगता है कि framework इतना महत्वपूर्ण नहीं है

    • उसका कहना है कि कोई लोकप्रिय विकल्प चुन लेना काफ़ी है, क्योंकि मदद पर्याप्त मिल जाएगी
    • वह 11 साल से Laravel इस्तेमाल कर रहा है और उसका मानना है कि business side ज़्यादा कठिन है