วิธีบริหารหลายบริษัทที่ทำรายได้ต่อเดือน $10K ด้วยสแตกเดือนละ $20

 (stevehanov.ca)
63 คะแนน โดย GN⁺ 17 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กลยุทธ์การบูตสแตรปเพื่อบริหารบริษัท SaaS หลายแห่งที่มี MRR มากกว่า 10,000 ดอลลาร์ โดยมี ค่าอินฟราต่อเดือนต่ำกว่า 20 ดอลลาร์ ด้วยการใช้ VPS เครื่องเดียว, ภาษา Go, SQLite และ GPU ภายในเครื่อง
  • แทนที่จะใช้ AWS หรือ cloud orchestration ที่ซับซ้อน ให้รันทุกบริการบน VPS ราคา 5~10 ดอลลาร์เพียงเครื่องเดียว และโฟกัสกับการประมวลผลคำขอแทนการดูแลอินฟรา
  • เลือก Go เป็นภาษาแบ็กเอนด์เพื่อให้ได้กระบวนการดีพลอยที่เรียบง่ายมาก: คอมไพล์เป็นไบนารีไฟล์เดียวโดยไม่ต้องจัดการ dependency แล้วอัปโหลดไปยังเซิร์ฟเวอร์
  • รัน VLLM บน local GPU (RTX 3090) เพื่อลดต้นทุนงาน AI แบบแบตช์ให้เหลือศูนย์ และใช้โมเดล frontier ผ่าน OpenRouter เฉพาะฟีเจอร์ที่ผู้ใช้โต้ตอบโดยตรง
  • แม้ไม่มี venture capital หากคงต้นทุนไว้ใกล้ศูนย์ได้ ก็จะมี runway ที่แทบไม่จำกัด และมีเวลามากพอในการหาความเหมาะสมระหว่างผลิตภัณฑ์กับตลาด

กลยุทธ์การดูแลเซิร์ฟเวอร์แบบ Lean

  • วิธีทั่วไปในการเปิดตัวเว็บแอปในปี 2026 คือ provision EKS cluster, RDS instance และ NAT Gateway บน AWS ซึ่งทำให้มีค่าใช้จ่ายเกิน 300 ดอลลาร์ต่อเดือนแม้ยังไม่มีผู้ใช้เลย
  • ทางเลือกคือเช่า VPS ราคา 5~10 ดอลลาร์ต่อเดือน จาก Linode หรือ DigitalOcean แล้วรันทุกอย่างบนเซิร์ฟเวอร์เดียว
  • แม้มี RAM 1GB ก็เพียงพอหากใช้อย่างเหมาะสม และถ้าต้องการเผื่อก็ใช้ swapfile ได้
  • เมื่อมีเซิร์ฟเวอร์เพียงเครื่องเดียว ก็จะรู้ได้ชัดเจนว่าล็อกอยู่ที่ไหน สาเหตุของการแครชคืออะไร และต้องรีสตาร์ตอย่างไร
  • เหตุผลที่เลือก VPS แทน AWS คือการรักษา ต้นทุนที่คาดการณ์ได้ และ สถาปัตยกรรมที่เรียบง่าย

ทำไมถึงเลือกภาษา Go

  • Python หรือ Ruby ใช้ RAM ไปครึ่งหนึ่งแล้วเพียงแค่เริ่ม interpreter และ จัดการ gunicorn worker
  • Go ให้ประสิทธิภาพที่ดีกว่ามากสำหรับงานเว็บ มีระบบ type ที่เข้มงวด และเป็นภาษาที่ LLM ในปี 2026 ให้เหตุผลกับโค้ดได้ง่ายมาก
  • จุดเด่นสำคัญของ Go คือ ความเรียบง่ายของกระบวนการดีพลอย: คอมไพล์ทั้งแอปเป็น static-linked binary ไฟล์เดียว สร้างบนโน้ตบุ๊กแล้วส่งไปยังเซิร์ฟเวอร์ด้วย scp เพื่อรันได้ทันที
  • ไม่ต้องเจอกับ dependency hell ของ pip install หรือ virtual environment และสามารถสร้าง เว็บเซิร์ฟเวอร์ระดับ production ได้โดยไม่ต้องพึ่งเฟรมเวิร์กที่บวมเกินจำเป็น
  • แค่ใช้ Go standard library พื้นฐาน ก็เขียนเซิร์ฟเวอร์ที่รองรับคำขอได้หลายหมื่นครั้งต่อวินาทีแล้ว

ใช้ AI ภายในเครื่อง: ทำให้ต้นทุนงานแบตช์เป็นศูนย์

  • ถ้าคุณมีการ์ดจออยู่ที่บ้าน ก็เท่ากับว่าคุณมี AI credit แบบไม่จำกัด อยู่แล้ว
  • ตอนสร้าง eh-trade.ca จำเป็นต้องทำวิจัยหุ้นเชิงคุณภาพขนาดใหญ่โดยวิเคราะห์รายงานรายไตรมาสของบริษัทหลายพันแห่ง ซึ่งถ้าใช้ OpenAI API อาจเสียค่าใช้จ่ายหลายร้อยดอลลาร์
  • ผู้เขียนจึงเลือกไปรัน VLLM บน RTX 3090 (VRAM 24GB) ที่ซื้อจาก Facebook Marketplace ในราคา 900 ดอลลาร์ เพื่อตัดความจำเป็นในการจ่ายเงินให้ผู้ให้บริการ AI
  • เส้นทางอัปเกรด local AI:
    • เริ่มจาก Ollama: ตั้งค่าได้ด้วยคำสั่งบรรทัดเดียว (ollama run qwen3:32b), ทดสอบโมเดลหลากหลายได้ทันที และเหมาะมากกับการวนปรับพรอมป์ต์
    • ขยับสู่โปรดักชันด้วย VLLM: Ollama จะกลายเป็นคอขวดเมื่อมีคำขอพร้อมกัน แต่ VLLM ใช้ PagedAttention จึงเร็วกว่าอย่างก้าวกระโดด หากส่งคำขอแบบ async พร้อมกัน 8~16 รายการ มันจะประมวลผลแบบแบตช์ในหน่วยความจำ GPU โดยใช้เวลาแทบไม่ต่างจากการประมวลผลคำขอเดียว
    • Transformer Lab: ถ้าต้องพรีเทรนหรือไฟน์จูนโมเดล ก็ทำได้ง่ายบนฮาร์ดแวร์ภายในเครื่อง
  • เพื่อจัดการสิ่งนี้ ผู้เขียนพัฒนา laconic ขึ้นเอง: เครื่องมือวิจัยแบบเอเจนต์ที่ปรับให้เหมาะกับ context window 8K โดย "page out" ส่วนของบทสนทนาที่ไม่จำเป็นออกไปเหมือนตัวจัดการหน่วยความจำเสมือนของ OS เพื่อคงไว้เฉพาะข้อเท็จจริงสำคัญใน active LLM context
  • llmhub: เครื่องมือที่ abstract LLM ทั้งหมดให้อยู่ในรูปแบบ provider/endpoint/apikey เพื่อจัดการ text และ image I/O ได้อย่างลื่นไหลทั้งบนเครื่องและบนคลาวด์

เข้าถึง frontier model ผ่าน OpenRouter

  • ไม่ใช่ทุกอย่างจะประมวลผลบนเครื่องได้ และสำหรับการโต้ตอบแชตแบบหน่วงต่ำที่ผู้ใช้ใช้งานโดยตรง ก็ยังต้องใช้โมเดลการให้เหตุผลระดับแนวหน้าอย่าง Claude 3.5 Sonnet หรือ GPT-4o
  • แทนที่จะต้องจัดการ billing account, API key และ rate limit ของ Anthropic, Google และ OpenAI แยกกัน ก็รวมทุกอย่างผ่าน OpenRouter เพียงตัวเดียว
  • เขียนโค้ดเชื่อมต่อแบบเข้ากันได้กับ OpenAI เพียงครั้งเดียว ก็เข้าถึง frontier model หลัก ๆ ได้ทั้งหมดทันที
  • รองรับ fallback routing ที่ราบรื่น: หาก Anthropic API ล่ม ระบบจะสลับไปใช้โมเดลฝั่ง OpenAI ที่เทียบเท่ากันโดยอัตโนมัติ ทำให้ผู้ใช้ไม่เห็นหน้าจอ error เลย และไม่ต้องเขียน retry logic ที่ซับซ้อน

ใช้ GitHub Copilot เพื่อเขียนโค้ด AI แบบคุ้มต้นทุน

  • ในช่วงที่มีโมเดลราคาแพงตัวใหม่ออกมาทุกสัปดาห์ นักพัฒนาหลายคนจ่ายเงินหลายร้อยดอลลาร์ต่อเดือนให้กับ Cursor subscription และ Anthropic API key
  • แต่ในทางกลับกัน ต่อให้ใช้ Claude Opus 4.6 ทั้งวัน ค่าใช้จ่ายต่อเดือนก็แทบไม่เกิน 60 ดอลลาร์
  • เคล็ดลับคือ อาศัยโมเดลราคาของ Microsoft: ซื้อ GitHub Copilot subscription ตั้งแต่ปี 2023 แล้วเชื่อมกับ VS Code มาตรฐาน
  • กลเม็ดสำคัญของ Copilot คือ Microsoft คิดเงินตามจำนวนคำขอ ไม่ใช่ตามจำนวนโทเคน และ “คำขอ” ก็คือสิ่งที่พิมพ์ลงในกล่องแชตหนึ่งครั้ง แม้เอเจนต์จะใช้เวลา 30 นาทีวิเคราะห์ทั้ง codebase และแก้หลายร้อยไฟล์ ก็มีค่าใช้จ่ายเพียงประมาณ 0.04 ดอลลาร์
  • กลยุทธ์ที่เหมาะที่สุดคือเขียนพรอมป์ต์อย่างละเอียดพร้อมเกณฑ์ความสำเร็จที่ชัดเจน แล้วสั่งว่า “ทำต่อไปจนกว่าจะแก้ข้อผิดพลาดทั้งหมดได้” จากนั้นก็ปล่อยให้ทำงาน

ใช้ SQLite เป็นฐานข้อมูลสำหรับทุกอย่าง

  • เมื่อเริ่มโปรเจกต์ใหม่ ผู้เขียนจะใช้ sqlite3 เป็นฐานข้อมูลหลักเสมอ
  • ในมุมมองแบบ enterprise หลายคนคิดว่าจำเป็นต้องมี database server แยก process แต่ในความเป็นจริง ไฟล์ SQLite ภายในเครื่องที่สื่อสารผ่าน C interface หรือหน่วยความจำ เร็วกว่าเป็นลำดับขั้น เมื่อเทียบกับการต้องกระโดดผ่านเครือข่าย TCP ไปยังเซิร์ฟเวอร์ Postgres ระยะไกล
  • ความเข้าใจผิดเรื่อง concurrency: การคิดว่า SQLite จะล็อกทั้งฐานข้อมูลทุกครั้งที่เขียนนั้นไม่ถูกต้อง และแก้ได้ด้วยการเปิด Write-Ahead Logging(WAL)
    • เมื่อตั้งค่า PRAGMA journal_mode=WAL; และ PRAGMA synchronous=NORMAL; การอ่านและการเขียนจะไม่บล็อกกัน
    • ไฟล์ .db ไฟล์เดียวบนไดรฟ์ NVMe สามารถรองรับ ผู้ใช้พร้อมกันหลายพันคน ได้
  • เพื่อให้ทำระบบยืนยันตัวตนของผู้ใช้ได้สะดวก ผู้เขียนยังพัฒนาไลบรารี smhanov/auth ขึ้นเอง: เชื่อมกับฐานข้อมูลที่ใช้อยู่ได้โดยตรง และรองรับการสมัครสมาชิก, session, รีเซ็ตรหัสผ่าน และการล็อกอินผ่าน Google/Facebook/X/SAML

บทสรุป: สร้างสตาร์ตอัปโดยไม่ต้องมีอินฟราซับซ้อน

  • วงการเทคมักบอกว่าการสร้างธุรกิจจริงต้องมี orchestration ที่ซับซ้อน ค่า AWS รายเดือนมหาศาล และ venture capital หลายล้านดอลลาร์ แต่ความจริงไม่ใช่แบบนั้น
  • หากนำ VPS เครื่องเดียว, static compiled binary, งาน AI แบบแบตช์บน local GPU และความเร็วระดับดิบของ SQLite มารวมกัน ก็สามารถบูตสแตรปสตาร์ตอัปที่ขยายได้ด้วยค่าใช้จ่ายเพียง ราคาราวกับกาแฟไม่กี่แก้วต่อเดือน
  • นี่ทำให้โปรเจกต์มี runway แบบไม่จำกัด และมีเวลาไปโฟกัสกับการแก้ปัญหาให้ผู้ใช้แทนการกังวลเรื่อง burn rate

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 17 일 전
ความคิดเห็นจาก Hacker News

  • ในสภาพแวดล้อมองค์กร คนจำนวนมากเชื่อว่าต้องใช้ เซิร์ฟเวอร์ฐานข้อมูลภายนอก แต่ในความเป็นจริง ไฟล์ SQLite แบบโลคัลเร็วกว่า Postgres ระยะไกลมากเมื่อสื่อสารผ่าน C interface หรือหน่วยความจำ
    แน่นอนว่า SQLite ยอดเยี่ยมมาก แต่ถ้าเชื่อมต่อ Postgres บน localhost ผ่าน Unix domain socket ก็แทบจะตัด network overhead ออกไปได้
    ใช้งานได้ไม่ยากไปกว่า SQLite, ใช้ความสามารถทั้งหมดของ Postgres ได้, และยังจัดการการรันรายงานหรือการตั้งค่า read replica กับ HA ได้ง่ายกว่ามาก
    การรัน Postgres บนเซิร์ฟเวอร์เดียวกับแอปนั้นเป็นคนละระดับกับการเตรียมเกินเหตุแบบตั้ง Kubernetes cluster

    • แม้อยู่บนเครื่องเดียวกัน SQLite ก็ยังเร็วกว่า Postgres ที่ใช้ domain socket มาก (ตัวอย่าง 100,000 TPS)
      เมื่อรัน monolithic app บนเครื่องเดียว ฟีเจอร์ที่ Postgres ให้เหนือกว่า SQLite มีไม่มากนัก
      SQLite สามารถขยายความสามารถได้โดยตรงด้วย Application functions ในภาษาแอป และการสำรองข้อมูลกับการทำ replication ก็ดีขึ้นมากด้วย Litestream
      แต่ค่าตั้งต้นยังไม่ดีนัก จึงควรแยกการเชื่อมต่ออ่าน/เขียน และให้แอปจัดการ write queue เอง
    • ถ้ารันคำสั่ง SELECT 1 จำนวน 100,000 ครั้งจริง Postgres ใช้เวลา 2.77 วินาที ส่วน SQLite (in-memory) ใช้ 0.07 วินาที ต่างกันมาก (ลิงก์ benchmark)
    • ฉันเคยใช้ SQLite พร้อมส่วนขยายใน งานประสิทธิภาพสูง ที่ประมวลผลเอกสารหลายล้านรายการต่อวินาที
      จะทำกับเซิร์ฟเวอร์ระยะไกลก็ได้ แต่คงซับซ้อนกว่ามาก
      แทนที่จะทำแบบนั้น เราอัปโหลด DB ไปที่ S3 แล้วให้แต่ละอินสแตนซ์ดึงสำเนาไปประมวลผลแบบขนาน SQLite เป็น ทางเลือกที่พิสูจน์แล้วเมื่อความต้องการคือประสิทธิภาพ มากกว่าฟีเจอร์
    • คำพูดที่ว่า “ใช้ความสามารถทั้งหมดของ Postgres ได้” นี่ไม่ใช่แนวคิด YAGNI (You Ain’t Gonna Need It) ที่บทความต้นฉบับกำลังวิจารณ์อยู่พอดีหรือ?
    • ยิ่งมีฟีเจอร์ที่ไม่จำเป็นมากเท่าไร ก็ยิ่งเป็น ผลเสียสุทธิ มากขึ้นเท่านั้น ฐานข้อมูลในอุดมคติควรมีเฉพาะสิ่งที่จำเป็น

  • หลายคนเชื่อว่าต้องเริ่มต้นด้วยสถาปัตยกรรมซับซ้อนอย่าง serverless, Kubernetes, multi-zone HA ตั้งแต่แรก
    ถ้าบอกว่า “แค่รันบน VPS ราคาถูกก็พอ” ก็มักจะเจอคำถามอย่าง “แล้ว scaling ล่ะ?”, “backup ล่ะ?”, “maintenance ล่ะ?” ซึ่งจริงๆ แล้วเป็นแค่การท่อง สโลแกนการตลาดของคลาวด์ ซ้ำเท่านั้น
    ท่าทีแบบนี้ใกล้เคียงกับภาวะหมดหนทางที่ถูกปลูกฝังมา

    • ตอนทำงานเป็นที่ปรึกษา ฉันเคยออกแบบ องค์ประกอบคลาวด์ 25 ตัว สำหรับแอปที่มีผู้ใช้ไม่ถึง 200 คน ทั้งหมดเป็นผลจากการถูกฝึกว่าคลาวด์ต้องซับซ้อน
    • คนจัดซื้อฝั่ง IT พร้อมจ่ายเงินบริษัทอย่างไม่อั้นเพื่อ ไม่ต้องเข้าใจระบบเอง
    • ทุกวันนี้ก็เห็นปรากฏการณ์เดียวกันใน เวิร์กโฟลว์แบบเอเจนต์ ข้อมูลฝึกเต็มไปด้วย codebase สำหรับทีมใหญ่ เลยชักนำให้โปรเจ็กต์เล็กๆ กลายเป็นโครงสร้างขนาดยักษ์
      ตัวอย่างเช่น SPA ที่มีแค่ฟอร์มกรอกข้อมูลง่ายๆ ไม่กี่หน้า แต่ยัด Shadcn, Tailwind, React, Zod และ Vite มาครบชุด ภาระการดูแลรักษาสูงมาก
      ชุดเทคโนโลยีแบบนี้อาจเป็น “คำตอบที่ถูก” แต่ไม่ใช่ คำตอบที่เหมาะกับบริบท
    • “คนรุ่น cloud native” ไม่ค่อยมีโอกาสได้เรียนรู้ว่า แอปพื้นฐานจริงๆ ต้องการอะไร เพราะมี free plan ให้ใช้ตลอด
    • ถึงอย่างนั้นก็ยังคิดว่า การสำรองข้อมูล สำคัญ

  • ฉันใช้ Linode หรือ DigitalOcean จ่ายแค่ 5–10 ดอลลาร์ต่อเดือน 1GB RAM ก็พอ
    ถ้ารวมหลายโปรเจ็กต์ไว้บน เซิร์ฟเวอร์เฉพาะ เครื่องเดียวก็ลดต้นทุนได้อีก
    ตัวอย่างเช่น ใช้ Hetzner server auction เดือนละ 40 ยูโร แล้วลง Proxmox เพื่อรันหลาย VM (ลิงก์ Proxmox)
    ต่อให้สร้าง VM 15 ตัว ก็ยังตกเพียง 2.66 ยูโรต่อ VM ทำให้ คุ้มค่ามากเมื่อเทียบกับขนาด
    ถ้าใช้อุปกรณ์รีเฟอร์บิช การสำรองข้อมูลเป็นสิ่งจำเป็น แต่ก็เป็นสิ่งที่ต้องทำอยู่แล้ว
    ผู้ให้บริการอย่าง Hetzner, Contabo และ Scaleway ยังเป็นตัวเลือกที่ราคาถูกอยู่

    • ราคา Hetzner ขึ้นแล้วก็จริง แต่ OVH ให้ฮาร์ดแวร์ใหม่กว่าที่ราคาใกล้กัน
    • สงสัยว่าทำไมถึงใช้ VM แทนคอนเทนเนอร์
    • สงสัยด้วยว่าจัดการ IPv4 อย่างไร และการเช่า VM ใหญ่หนึ่งตัวมาใช้เป็นไฮเปอร์ไวเซอร์นั้นอนุญาตในเชิงพาณิชย์หรือไม่
    • รู้สึกว่ารันด้วย Docker container ตรงๆ น่าจะมีประสิทธิภาพกว่าไหม

  • คิดว่า โหมด WAL ของ SQLite เป็นปัจจัยลดต้นทุนที่ใหญ่ที่สุด
    Python หรือ Node ก็ใช้งานได้ดีพอๆ กับ Go Hetzner มี VPS 4GB RAM พร้อมทราฟฟิก 10TB ในราคาราว 5 ดอลลาร์ต่อเดือน
    แต่ถ้าใช้เซิร์ฟเวอร์เฉพาะ ก็ต้อง สำรองฐานข้อมูลบ่อยๆ และรับผิดชอบเรื่องความปลอดภัยเอง
    ฉันตั้งค่าด้วย Terraform ให้ SSH เข้าได้เฉพาะจาก IP ของตัวเอง, ตั้ง Tailscale, แล้วปิดพอร์ต SSH สาธารณะ

    • สำหรับ backup ควรใช้ storage ของ คนละบริษัทกับผู้ให้บริการ VM จะปลอดภัยกว่า เผื่อบัญชีถูกระงับก็ยังต้องกู้คืนได้
      ฉันใช้ Backblaze B2 แต่ถ้าใช้ Restic ก็แบ็กอัปไปบริการอื่นได้ง่าย
    • การทำ SSH ให้ปลอดภัยไม่จำเป็นต้องตั้งค่าซับซ้อนเสมอไป แค่มี รหัสผ่านที่แข็งแรง ก็พอแล้ว
    • ฉันเคยเปิด Postgres ไว้ด้วยรหัสผ่านค่าเริ่มต้น แล้วโดน แฮ็กไปเป็น bot server ภายในวันเดียว
      ไม่นานมานี้ log ความพยายาม SSH ก็สะสมภายในหนึ่งชั่วโมง ตอนนี้เลยปิด password login และเข้าได้ผ่าน Tailscale เท่านั้น
      เซิร์ฟเวอร์ที่เปิดออกสู่อินเทอร์เน็ตนั้นอันตรายจริงๆ
    • ยากจะเชื่อว่าแค่ SSH จะติดเครื่องภายในหนึ่งชั่วโมงได้ ถ้าไม่ใช่ รหัสผ่านอ่อน หรือเปิด VNC ทิ้งไว้ก็น่าจะเป็นไปไม่ได้
    • ฉันเองก็ย้ายเว็บ Django ไป Docker Compose แล้วเลิกใช้ Postgres เปลี่ยนมาเป็น SQLite WAL ทำให้ ดูแลง่ายและแบ็กอัปง่าย ขึ้นมาก

  • คิดว่าข้อจำกัด 1GB RAM ไม่จำเป็น เดือนละ 20 ดอลลาร์ก็ได้ RAM 8GB แล้ว เอาไปใช้กับ cache หรือ DB ได้
    ส่วนต่าง 15 ดอลลาร์ไม่ได้ส่งผลใหญ่ต่อการทำธุรกิจ การพยายามยัดทุกอย่างให้ลงใน VPS 5 ดอลลาร์ไม่ได้ ช่วยให้ธุรกิจเติบโต

    • แต่ 15 ดอลลาร์ก็ไม่ใช่เงินเล็กน้อย ถ้า 1GB พอก็ไม่มีเหตุผลต้องจ่ายเพิ่ม
      เมื่อก่อน 128MB ก็รัน LAMP stack ได้ดี และทุกวันนี้เว็บไซต์ก็ไม่ได้ซับซ้อนขนาดนั้น
    • ความหน่วงในการอ่านของ NVMe อยู่ราว 100µs จึงทำให้ SQLite รองรับได้หลายร้อย request ต่อวินาที
      ต่อให้ ไม่มี cache ก็ยังรับได้ 17 ล้าน request ต่อวัน ดังนั้นการขยายอินฟราก่อนหน้านั้นถึง 4 เท่าจึงเป็นความสิ้นเปลือง
    • เหตุผลที่แท้จริงของการจำกัดไว้ที่ 1GB คือการฝึก หลีกเลี่ยง overengineering และโฟกัสที่คุณค่าต่อลูกค้า
    • ระบบสมัยใหม่มี page compression และ NVMe swap ทำให้ใช้ RAM ได้มีประสิทธิภาพกว่ามาก
      Macbook Neo รุ่น 8GB เป็นตัวอย่างที่ดี
    • ฉันก็เห็นด้วยว่าส่วนต่าง 15 ดอลลาร์ไม่มาก แต่ประเด็นสำคัญคือ ลดต้นทุนโฮสติ้งให้ต่ำที่สุด

  • WebSequenceDiagram ดูเหมือนเป็นผลิตภัณฑ์ที่ยอดเยี่ยม
    แต่สิ่งที่ยากกว่าการลงมือทำทางเทคนิคคือ การหาโจทย์ที่มีคุณค่าและเข้าถึงผู้ใช้ ตรงนั้นต่างหากที่มีมูลค่าจริง

    • ฉันก็คิดแบบเดียวกัน เวลาไปกับงานและครอบครัวก็แทบหมดวันแล้ว แต่พอเจอปัญหาเฉพาะโดเมนบางอย่าง วิธีแก้กลับดูชัดเจนมาก
    • มีคู่แข่งอยู่แล้วจำนวนมาก เช่น Excalidraw

  • ฉันสมัคร GitHub Copilot ตั้งแต่ปี 2023 แล้วเชื่อมกับ VS Code ใช้มาตลอด
    ประเด็นสำคัญคือ Microsoft คิดเงินเป็นราย request ต่อให้ request เดียวแก้โค้ดทั้งชุดเป็นเวลาหลายนาที ก็จ่ายแค่ราว 0.04 ดอลลาร์
    เพราะแบบนั้นฉันจึงเขียนพรอมป์ต์ให้เฉพาะเจาะจงมาก แล้วสั่งว่า “ทำต่อไปจนกว่าจะแก้ทุก error หมด” จากนั้นก็ไปชงกาแฟ เท่ากับว่า Satya Nadella กำลัง subsidize ค่า compute ให้ฉัน

    • แต่ก็มีกรณีที่บัญชีถูกระงับจากการ ใช้ประโยชน์จากโมเดลคิดค่าบริการราย request แบบนี้เกินควร (กรณีบน Reddit)
    • ผู้เขียนเรียก GPT‑4o กับ Sonnet 3.5 ว่าเป็น SOTA ดังนั้น ควรอ่านคำแนะนำด้าน AI แบบเผื่อใจไว้บ้าง
    • (ความเห็นถูกลบ) บอกว่าไม่รู้ว่าทำไมตัวเองถึงโดนดาวน์โหวต

  • ฉันไม่ได้เรียนรู้อะไรใหม่จากบทความนี้เลย ส่วนใหญ่เหมือนเป็น คำแนะนำพื้นฐานที่ถูก AI เอามาแพ็กใหม่
    เห็นแค่ชื่อเรื่องก็นึกว่าจะพูดถึง การหาไอเดียและการเปิดตัวให้ประสบความสำเร็จ

    • ถ้าตั้งชื่อประมาณ “ทำให้ต่ำกว่า $5 ต่อเดือน” ก็เป็นเรื่องธรรมดาที่จะได้คำแนะนำพื้นฐาน แต่ก็ยังมีคนจำนวนมากที่ไม่รู้เรื่องนี้
    • ถ้าอย่างนั้นก็แนะนำให้ เริ่มเขียนบล็อก ความรู้ที่คุณคิดว่าเป็นพื้นฐาน อาจใหม่สำหรับคนอื่น
    • ถ้าฉันจ่ายเดือนละ 5,000 ดอลลาร์แล้วทำรายได้ 10,000 ดอลลาร์ได้ ฉันก็ยินดีทำเหมือนกัน ปัญหาคือการหา วิธีสร้างรายได้ ต่างหาก
    • ประโยคอย่าง “ต้องการการให้เหตุผลล้ำสมัยของ Claude 3.5 Sonnet หรือ GPT‑4o” เป็น ร่องรอยของงานเขียนจาก AI
    • แต่เรื่อง resource inflation ที่ผู้เขียนพูดถึงนั้นมีอยู่จริง เรามักเห็นงานที่ Python script ง่ายๆ ก็พอแล้ว แต่กลับถูกแก้ด้วย AWS และ Spark แบบเกินความจำเป็น

  • เผื่อใครสงสัยเหมือนฉัน MRR หมายถึง “Monthly Recurring Revenue (รายได้ประจำต่อเดือน)”

    • น่าประหลาดใจที่สมัครมา 16 ปีแล้วแต่ยังไม่รู้จัก MRR
    • ยังมี ARR (Annual Recurring Revenue) ด้วย ซึ่งโดยมากก็เป็นแค่การเอา MRR คูณ 12 เพื่อทำให้ตัวเลขดูใหญ่ขึ้น
      เคยเห็นคนทำได้แค่สองเดือนก็ประกาศ ARR แล้ว

  • แนวคิดที่ยึดคลาวด์เป็นศูนย์กลางในหลายกรณีทำให้ ความซับซ้อนและต้นทุนเพิ่มขึ้นโดยไม่จำเป็น
    โปรเจ็กต์ส่วนใหญ่ใช้ VPS ระดับกลางก็เพียงพอ
    บริษัทของเราเคยรันหน้าผู้ใช้ 600,000 หน้าได้ด้วย VPS 30 ยูโร แต่พอย้ายไป AWS กลับต้องจ่าย 800 ยูโรต่อเดือนและ ไม่ได้อะไรเพิ่มเลย
    ถ้าไม่มีเหตุผลชัดเจน ก็ควรใช้แนวทางเซิร์ฟเวอร์เรียบง่ายที่ใช้งานได้ดีมาหลายสิบปีต่อไป
    และเท่าที่ได้ยินมา StackOverflow ก็ยังรันอยู่บน เครื่อง root server แรงๆ เพียงไม่กี่เครื่อง