$20/महीना स्टैक के साथ $10K मासिक रेवेन्यू वाली कई कंपनियां कैसे चलाएं

 (stevehanov.ca)
64 पॉइंट द्वारा GN⁺ 2026-04-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एकल VPS, Go भाषा, SQLite और लोकल GPU का उपयोग करके महीने के 20 डॉलर से कम इंफ्रास्ट्रक्चर लागत में $10K से अधिक MRR वाली कई SaaS कंपनियां चलाने की बूटस्ट्रैपिंग रणनीति
  • AWS या जटिल cloud orchestration की जगह 5~10 डॉलर का एक VPS लेकर सभी services चलाना, और infra management नहीं बल्कि request handling पर फोकस करना
  • backend language के रूप में Go चुनकर dependency management के बिना single binary में compile करके server पर deploy करने वाली बेहद सरल deployment process हासिल करना
  • लोकल GPU (RTX 3090) पर VLLM चलाकर AI batch processing की लागत शून्य करना, और केवल user-facing features के लिए OpenRouter के जरिए frontier models का उपयोग करना
  • venture capital के बिना भी अगर लागत लगभग शून्य रखी जाए तो लगभग अनंत runway हासिल किया जा सकता है, और product-market fit खोजने के लिए पर्याप्त समय मिल सकता है

Lean server संचालन रणनीति

  • 2026 में web app launch करने का सामान्य तरीका AWS में EKS cluster, RDS instance, NAT Gateway provision करना है, और इस स्थिति में एक भी user न होने पर भी महीने के 300 डॉलर से अधिक खर्च हो जाता है
  • इसके विकल्प के रूप में Linode या DigitalOcean पर महीने के 5~10 डॉलर का VPS लेकर single server के रूप में चलाना
  • 1GB RAM भी सही तरीके से इस्तेमाल की जाए तो पर्याप्त है, और extra headroom चाहिए तो swapfile इस्तेमाल करें
  • server एक ही हो तो logs कहाँ हैं, crash क्यों हुआ, और restart कैसे करना है, यह सब ठीक-ठीक पता रहता है
  • AWS की जगह VPS चुनने की वजह है predictable cost और simple architecture बनाए रखना

Go भाषा चुनने की वजह

  • Python या Ruby में interpreter boot और gunicorn worker management भर से RAM का आधा हिस्सा खर्च हो जाता है
  • Go web workloads में कहीं बेहतर performance देता है, इसमें strict type system है, और 2026 के हिसाब से LLM के लिए reason करना बेहद आसान भाषा है
  • Go का मुख्य फायदा है deployment process की simplicity: पूरे application को single statically linked binary में compile करें, laptop पर build करें, फिर scp से server पर भेजकर run करें
  • pip install वाली dependency hell या virtual environment की जरूरत नहीं, और bloated frameworks के बिना भी production-grade web server बनाया जा सकता है
  • केवल Go standard library से ऐसा server लिखा जा सकता है जो प्रति सेकंड दसियों हज़ार requests संभाल सके

लोकल AI का उपयोग: batch jobs की लागत शून्य करना

  • अगर घर में graphics card है, तो आपके पास पहले से ही unlimited AI credits हैं
  • eh-trade.ca बनाते समय हज़ारों कंपनियों की quarterly reports का विश्लेषण करने वाली large-scale qualitative stock research की जरूरत थी, और OpenAI API इस्तेमाल करने पर सैकड़ों डॉलर लग सकते थे
  • इसकी जगह Facebook Marketplace से 900 डॉलर में खरीदे गए RTX 3090(24GB VRAM) पर VLLM चलाकर AI provider को भुगतान करने की जरूरत खत्म कर दी गई
  • लोकल AI upgrade path:
    • Ollama से शुरुआत: एक लाइन के command (ollama run qwen3:32b) से setup करें, अलग-अलग models तुरंत test करें, और prompt iteration के लिए बेहतरीन
    • VLLM के साथ production में जाएँ: Ollama concurrent requests में bottleneck बन जाता है, जबकि VLLM PagedAttention का उपयोग करके बहुत तेज़ हो जाता है. 8~16 async requests एक साथ भेजने पर GPU memory में batch processing होती है और समय लगभग एक request जितना ही लगता है
    • Transformer Lab: model pretraining या fine-tuning की जरूरत हो तो लोकल hardware पर आसानी से किया जा सकता है
  • इसे manage करने के लिए खुद बनाया गया laconic: 8K context window के लिए optimized agent research tool, जो OS के virtual memory manager की तरह बातचीत के गैर-ज़रूरी हिस्सों को "page out" करके केवल core facts को active LLM context में रखता है
  • llmhub: सभी LLMs को provider/endpoint/apikey संयोजन के रूप में abstract करके text और image IO को, चाहे लोकल हो या cloud, सहज रूप से handle करने वाला tool

OpenRouter के जरिए frontier models तक पहुँच

  • हर काम लोकल पर नहीं किया जा सकता, और user-facing low-latency chat interactions के लिए Claude 3.5 Sonnet या GPT-4o जैसे cutting-edge reasoning models की जरूरत होती है
  • Anthropic, Google, OpenAI के अलग-अलग billing accounts, API keys और rate limits संभालने के बजाय सब कुछ OpenRouter में एकीकृत
  • सिर्फ एक OpenAI-compatible integration code लिखकर सभी प्रमुख frontier models तक तुरंत पहुँचा जा सकता है
  • seamless fallback routing का support: Anthropic API में समस्या आने पर अपने-आप equivalent OpenAI model पर switch हो जाता है, इसलिए user को कोई error screen नहीं दिखती और जटिल retry logic की जरूरत नहीं पड़ती

GitHub Copilot के साथ cost-efficient AI coding

  • जब हर हफ्ते नए महंगे models लॉन्च हो रहे हैं, तब developers Cursor subscription और Anthropic API keys पर हर महीने सैकड़ों डॉलर खर्च कर रहे हैं
  • इसके उलट Claude Opus 4.6 को पूरे दिन इस्तेमाल करने पर भी मासिक लागत शायद ही 60 डॉलर से ऊपर जाती है
  • इसका रहस्य है Microsoft के pricing model का लाभ उठाना: 2023 में GitHub Copilot subscription खरीदी गई और उसे standard VS Code से जोड़ा गया
  • Copilot की मुख्य ट्रिक: Microsoft token के आधार पर नहीं बल्कि request के आधार पर charge करता है, और एक "request" मतलब chat box में डाली गई एक input. एजेंट 30 मिनट तक पूरे codebase का विश्लेषण करे और सैकड़ों files बदल दे, तब भी लगभग 0.04 डॉलर ही खर्च होते हैं
  • सबसे बेहतर रणनीति: कड़े success criteria के साथ detailed prompt लिखें, और निर्देश दें कि "जब तक सभी errors ठीक न हो जाएँ, जारी रखें", फिर इसे run करें

SQLite को हर database के रूप में इस्तेमाल करना

  • नया venture शुरू करते समय हमेशा sqlite3 को main database के रूप में इस्तेमाल किया जाता है
  • enterprise नज़रिए से लोग मानते हैं कि अलग process वाला database server चाहिए, लेकिन वास्तव में C interface या memory के जरिए communicate करने वाली लोकल SQLite file, TCP network hop के साथ remote Postgres server तक जाने की तुलना में कई गुना तेज़ होती है
  • concurrency issue को लेकर गलतफहमी: यह मानना कि SQLite हर write पर पूरे database को lock कर देता है, सही नहीं है; Write-Ahead Logging(WAL) सक्षम करने से यह हल हो जाता है
    • PRAGMA journal_mode=WAL; और PRAGMA synchronous=NORMAL; सेट करने पर reads और writes एक-दूसरे को block नहीं करते
    • NVMe drive पर एक single .db file से हज़ारों concurrent users संभाले जा सकते हैं
  • user authentication को आसान बनाने के लिए खुद की library smhanov/auth बनाई गई: यह उपयोग में लिए जा रहे database के साथ सीधे integrate होती है और signup, sessions, password reset, Google/Facebook/X/SAML login को support करती है

निष्कर्ष: जटिल infra के बिना startup बनाना

  • tech industry अक्सर दावा करती है कि असली business बनाने के लिए complex orchestration, AWS पर भारी मासिक खर्च, और millions of dollars की venture capital चाहिए, लेकिन ऐसा नहीं है
  • single VPS, statically compiled binary, लोकल GPU hardware से batch AI jobs, और SQLite की raw speed को मिलाकर महीने में कुछ कप coffee की कीमत पर scalable startup को bootstrap किया जा सकता है
  • इससे project को लगभग अनंत runway मिलता है और burn rate की चिंता के बजाय user problems सुलझाने पर ध्यान देने का समय मिलता है

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

1 टिप्पणियां

 
GN⁺ 2026-04-13
Hacker News की राय

  • एंटरप्राइज़ माहौल में अक्सर यह मान लिया जाता है कि external DB server इस्तेमाल करना चाहिए, लेकिन हक़ीक़त में लोकल SQLite फ़ाइल, C interface या memory के ज़रिए बात करते समय remote Postgres से काफ़ी तेज़ होती है
    बेशक SQLite शानदार है, लेकिन localhost पर Unix domain socket के जरिए Postgres से कनेक्ट करने पर network overhead लगभग ख़त्म किया जा सकता है
    इसे SQLite से ज़्यादा मुश्किल हुए बिना इस्तेमाल किया जा सकता है, Postgres की सारी features का फ़ायदा लिया जा सकता है, और reports चलाना या read replica सेट करना, HA कॉन्फ़िगर करना भी काफ़ी आसान हो जाता है
    app के उसी server पर Postgres चलाना Kubernetes cluster खड़ा करने जैसी overkill तैयारी से बिल्कुल अलग स्तर का फ़ैसला है

    • एक ही मशीन पर भी SQLite, domain socket इस्तेमाल करने वाले Postgres से काफ़ी तेज़ है (100,000 TPS उदाहरण)
      single machine पर monolithic app चलाते समय Postgres, SQLite की तुलना में बहुत ज़्यादा features नहीं देता
      SQLite को Application functions के ज़रिए app language में सीधे extend किया जा सकता है, और Litestream की वजह से backup और replication भी काफ़ी बेहतर हो जाते हैं
      लेकिन इसकी default settings अच्छी नहीं हैं, इसलिए read/write connections अलग करने पड़ते हैं और app को ख़ुद write queue मैनेज करनी पड़ती है
    • अगर सच में 100,000 बार SELECT 1 query चलाई जाए, तो Postgres को 2.77 सेकंड लगते हैं, जबकि SQLite(in-memory) को 0.07 सेकंड, यानी बड़ा फ़र्क़ है (benchmark link)
    • मैंने ख़ुद SQLite को extensions के साथ high-performance scenarios में इस्तेमाल किया है, जहाँ हर सेकंड लाखों documents प्रोसेस होते थे
      remote server से भी यह किया जा सकता था, लेकिन वह कहीं ज़्यादा complex होता
      उसकी जगह DB को S3 पर रखा गया, ताकि हर instance उसकी copy लेकर parallel processing कर सके. SQLite उन मामलों में एक साबितशुदा विकल्प है जहाँ features से ज़्यादा performance चाहिए
    • “Postgres की सारी features इस्तेमाल कर सकते हैं” कहना क्या वही YAGNI(You Ain’t Gonna Need It) approach नहीं है जिसकी TFA आलोचना कर रहा है?
    • जितनी ज़्यादा ऐसी features हों जिनकी ज़रूरत नहीं है, उतना ही वह शुद्ध नुकसान है. आदर्श DB वही है जो सिर्फ़ ज़रूरी features दे

  • बहुत से लोग मानते हैं कि शुरुआत से ही serverless, Kubernetes, multi-zone HA जैसी complex setup ज़रूरी है
    अगर आप कहें कि “बस किसी सस्ते VPS पर चला लो,” तो जवाब आता है “scaling का क्या?”, “backup का क्या?”, “maintenance का क्या?” — जबकि असल में वे cloud marketing slogans ही दोहरा रहे होते हैं
    यह रवैया learned helplessness के काफ़ी क़रीब है

    • consultant के तौर पर काम करते हुए मैं 200 से भी कम users वाले app के लिए 25 cloud components डिज़ाइन किया करता था. यह सब ‘cloud = complex होना चाहिए’ वाली training का नतीजा था
    • IT procurement वाले लोग कंपनी का पैसा ऐसी चीज़ों पर खुलकर खर्च करते हैं जिन्हें समझना न पड़े
    • आजकल agent-based workflows में भी यही दिखता है. training data बड़े teams के codebase से भरा होने के कारण छोटे projects भी बहुत विशाल structure की तरफ़ धकेले जाते हैं
      मिसाल के तौर पर, कुछ साधारण input forms वाले SPA में Shadcn, Tailwind, React, Zod, Vite सब कुछ डाल दिया जाता है. maintenance burden बहुत बड़ा हो जाता है
      ऐसा setup “सही जवाब” हो सकता है, लेकिन स्थिति के हिसाब से सही जवाब नहीं होता
    • “cloud native generation” को free plans की वजह से यह सीखने का मौका ही नहीं मिला कि एक basic app को वास्तव में क्या चाहिए
    • फिर भी, मुझे लगता है कि backup ज़रूरी है

  • मैं Linode या DigitalOcean इस्तेमाल करता हूँ और महीने के सिर्फ़ 5~10 डॉलर देता हूँ. 1GB RAM काफ़ी है
    कई projects को एक dedicated server पर इकट्ठा कर दें तो लागत और घट सकती है
    उदाहरण के लिए, मैं Hetzner server auction से 40 यूरो/महीना वाला server लेता हूँ, उस पर Proxmox चलाता हूँ और कई VM चलाता हूँ (Proxmox link)
    15 VM बना लेने पर भी प्रति VM लागत 2.66 यूरो के आसपास आती है, इसलिए scale के मुकाबले cost efficiency बहुत अच्छी है
    refurbished equipment हो तो backup ज़रूरी है, लेकिन वह तो वैसे भी ज़रूरी काम है
    Hetzner, Contabo, Scaleway जैसी जगहें अब भी सस्ते विकल्प हैं

    • Hetzner की क़ीमतें बढ़ी हैं, लेकिन OVH मिलती-जुलती कीमत पर ज़्यादा नया hardware दे रहा है
    • यह जानने की उत्सुकता है कि VM क्यों इस्तेमाल किए जा रहे हैं और containers क्यों नहीं
    • IPv4 को कैसे संभाला जाता है, यह भी जानना है. hypervisor के रूप में बड़ा VM किराए पर लेना commercial use के लिए allowed भी है या नहीं, यह भी सवाल है
    • क्या इसे बस Docker containers में चलाना ज़्यादा efficient नहीं होगा?

  • मुझे लगता है SQLite का WAL mode लागत घटाने वाला सबसे बड़ा factor है
    Python या Node भी Go जितने ही अच्छे से इस्तेमाल किए जा सकते हैं. Hetzner का 4GB RAM, 10TB network वाला VPS लगभग 5 डॉलर/महीना पड़ता है
    लेकिन अगर dedicated server इस्तेमाल कर रहे हों, तो DB backups बार-बार लेने चाहिए, और security की ज़िम्मेदारी भी ख़ुद लेनी होगी
    मैं Terraform से SSH access सिर्फ़ अपने IP तक सीमित करता हूँ, फिर Tailscale सेट करता हूँ और public SSH port बंद कर देता हूँ

    • backup के लिए VM provider से अलग कंपनी का storage इस्तेमाल करना ज़्यादा सुरक्षित है. account suspend हो जाए तब भी recovery संभव होनी चाहिए
      मैं Backblaze B2 इस्तेमाल करता हूँ, लेकिन Restic से दूसरे services पर भी आसानी से backup किया जा सकता है
    • SSH security के लिए बहुत complex setup हमेशा ज़रूरी नहीं होता. मज़बूत password भी काफ़ी हो सकता है
    • पहले मैंने Postgres को default password के साथ खुला छोड़ दिया था और एक ही दिन में वह bot server के रूप में hack हो गया
      हाल में भी SSH attempts के logs एक घंटे के अंदर जमा हो गए थे. अब मैं password login बंद रखता हूँ और सिर्फ़ Tailscale से access करता हूँ
      internet पर exposed server सच में बहुत ख़तरनाक होता है
    • यह मानना मुश्किल है कि SSH के ज़रिए एक घंटे में infection हो सकता है. कमज़ोर password या खुला VNC न हो तो यह संभव नहीं लगता
    • मैंने भी Django site को Docker Compose पर ले जाते समय Postgres हटाकर SQLite WAL पर switch किया. इससे management और backup बहुत आसान हो गए

  • मुझे नहीं लगता कि 1GB RAM की सीमा ज़रूरी है. 20 डॉलर/महीना में 8GB RAM मिल सकती है, जिसे cache या DB के लिए इस्तेमाल किया जा सकता है
    15 डॉलर का अंतर business चलाने में बहुत बड़ा असर नहीं डालता. 5 डॉलर VPS के हिसाब से सोचते रहना business growth में मदद नहीं करता

    • लेकिन 15 डॉलर भी नज़रअंदाज़ करने लायक नहीं हैं. अगर 1GB काफ़ी है, तो बेवजह ज़्यादा खर्च करने की ज़रूरत नहीं
      पहले 128MB पर भी LAMP stack अच्छे से चलता था, और आज भी websites इतनी complex नहीं हैं
    • NVMe read latency लगभग 100µs होती है, इसलिए SQLite से भी प्रति सेकंड सैकड़ों requests संभाले जा सकते हैं
      cache के बिना भी 1.7 करोड़ requests/day संभाले जा सकते हैं, तो उससे पहले infra को 4 गुना बढ़ाना फ़िज़ूल है
    • 1GB limit की असली वजह over-engineering से बचना और customer value पर ध्यान रखना है
    • आधुनिक systems में page compression और NVMe swap की वजह से RAM efficiency काफ़ी बेहतर है
      Macbook Neo 8GB model इसका अच्छा उदाहरण है
    • मैं भी मानता हूँ कि 15 डॉलर का अंतर बहुत बड़ा नहीं है, लेकिन असली बात hosting cost को न्यूनतम रखना है

  • WebSequenceDiagram एक बढ़िया product लगता है
    लेकिन technical implementation से भी मुश्किल काम है ऐसी समस्या ढूँढ़ना जो वाकई मूल्यवान हो और users तक पहुँचना. असली value वहीं है

    • मैं भी यही सोचता हूँ. काम और परिवार के बीच दिन छोटा पड़ जाता है. लेकिन जब किसी खास domain problem का पता चलता है, तो solution बहुत साफ़ दिखाई देता है
    • competing products पहले से बहुत हैं. उदाहरण के लिए Excalidraw जैसी चीज़ें

  • मैंने 2023 में GitHub Copilot subscribe किया, उसे VS Code से जोड़ा, और तब से लगातार इस्तेमाल कर रहा हूँ
    अहम बात यह है कि Microsoft per-request billing करता है. एक request में कई दसियों मिनट तक पूरा codebase बदलवा लिया जाए, तब भी लगभग 0.04 डॉलर ही लगता है
    इसलिए मैं बहुत specific prompts लिखता हूँ और कहता हूँ “जब तक सारी errors ठीक न हो जाएँ, जारी रखो,” फिर मैं कॉफ़ी पीने चला जाता हूँ. यानी Satya Nadella मेरे computing cost को subsidize कर रहे हैं

    • लेकिन ऐसे per-request abuse की वजह से account suspend होने के मामले भी हैं (Reddit case)
    • लेखक GPT‑4o और Sonnet 3.5 को SOTA कहता है, इसलिए AI tips को थोड़ा संदेह के साथ देखना चाहिए
    • (हटाई गई टिप्पणी) कहा गया कि समझ नहीं आया downvote क्यों मिला

  • इस लेख से मुझे कुछ नया नहीं मिला. ज़्यादातर यह बुनियादी सलाह को AI से सजाकर पेश करने जैसा लगा
    सिर्फ़ शीर्षक देखकर लगा था कि बात idea discovery और successful launch पर होगी

    • “5 डॉलर/महीना से कम में” जैसे title से बुनियादी सलाह आना स्वाभाविक है. लेकिन हैरानी की बात है कि बहुत लोग यह भी नहीं जानते
    • अगर ऐसा है, तो blog शुरू करने की सलाह है. जो ज्ञान आपको basic लगता है, वही किसी और के लिए नया हो सकता है
    • अगर मैं महीने के 5,000 डॉलर खर्च करके 10,000 डॉलर कमा सकूँ, तो मैं ख़ुशी से करूँगा. समस्या है revenue बनाने का तरीका ढूँढ़ना
    • “Claude 3.5 Sonnet या GPT‑4o की state-of-the-art reasoning चाहिए” जैसी पंक्ति AI-generated writing की निशानी लगती है
    • लेकिन लेखक की कही resource inflation वाली बात सच है. अक्सर ऐसा देखा जाता है कि जो काम एक simple Python script से हो सकता है, उसे AWS और Spark से बेवजह overcomplicate कर दिया जाता है

  • मेरी तरह जिन लोगों को जिज्ञासा हो, उनके लिए MRR का मतलब “Monthly Recurring Revenue(मासिक आवर्ती राजस्व)” है

    • हैरानी है कि 16 साल पहले sign up करने के बाद भी किसी को MRR नहीं पता था
    • ARR(Annual Recurring Revenue) भी होता है, लेकिन अक्सर यह MRR को बस 12 से गुणा करके बढ़ा-चढ़ाकर दिखाया गया नंबर होता है
      मैंने ऐसे लोगों को भी देखा है जो सिर्फ़ दो महीने चलाने के बाद ARR घोषित कर देते हैं

  • cloud-केंद्रित सोच कई मामलों में जटिलता और लागत को बेवजह बढ़ा देती है
    ज़्यादातर projects के लिए medium-sized VPS ही काफ़ी होता है
    हमारी कंपनी 6 लाख user pages को 30 यूरो VPS पर चला सकती थी, लेकिन AWS पर migrate करने के बाद 800 यूरो/महीना देने पड़े. कोई फ़ायदा नहीं हुआ
    अगर कोई ठोस वजह न हो, तो दशकों से अच्छी तरह काम कर रहे simple server approach पर टिके रहना बेहतर है
    वैसे सुना है कि StackOverflow भी कुछ शक्तिशाली root servers पर ही चलता है