หยุด Overengineer ตอนลูกค้ายังเป็น 0 · บทความ

ผมเสียเวลา 2 สัปดาห์ setup CI/CD, auth, error monitoring ครบ

ตอนนั้นยังไม่มีคนใช้แม้แต่คนเดียว

pitfall ที่เจอซ้ำแล้วซ้ำเล่า: dev จำนวนมาก (รวมตัวเอง) ใช้เวลาหลักสัปดาห์ setup testing pipeline, error boundary, logging, type safety 100%, auth — ก่อนเขียน feature แรก

ถ้าทำงานอยู่ในทีม 50 คน ดูแล product ที่มีคนใช้หลักพัน — ถูกแล้ว

แต่ถ้าลูกค้ายังเป็น 0? มันไม่ใช่ "production-grade from day 1" — มันคือ premature optimization ที่กิน runway

framework หลายตัวพูดเรื่องเดียวกัน:

Lean Startup (Ries) — Build-Measure-Learn loop ยิ่ง loop เร็ว ยิ่ง validated learning เร็ว code ที่ดีแต่ไม่มีคนใช้ = waste
Feedback Loop — ทุก feature ที่ ship คือ hypothesis ถ้าไม่ ship ก็ไม่ได้ feedback ถ้าไม่ได้ feedback ก็ไม่รู้ว่าผิดทาง
YAGNI (Extreme Programming) — You Aren't Gonna Need It อย่า build สิ่งที่ยังไม่ต้องใช้ เพราะ 80% ของ feature ที่คิดว่าจะใช้ ไม่เคยถูกใช้จริง
Theory of Constraints (Goldratt) — bottleneck ตอน pre-PMF คือ learning speed ไม่ใช่ code quality ถ้า optimize ผิดจุด ระบบทั้งหมดก็ช้าตาม

ยิ่งรู้เร็วว่าสิ่งที่สร้างผิดทาง ยิ่งเสียน้อย ยิ่งดี

CLAUDE.md เขียนไว้ชัด: decision ทุกอันต้องถูกจัดระดับตาม reversibility

R0 — ย้อนไม่ได้ (deploy contract, production DB migration) → หยุดคิดก่อน
R1 — ย้อนได้แต่แพง (API contract, major refactor) → ทำได้ แต่ต้องรู้ตัว
R2 — ย้อนง่าย (UI, config, feature flag, prompt tweak) → ทำเลย ไม่ต้องขอ

(เคยเขียนละเอียดไว้ในโพสต์ CLAUDE.md rules — ย้อนไปอ่านได้)

ตอน pre-PMF decision เกือบทั้งหมดเป็น R2

UI สีอะไร? R2 ไม่สำคัญ ทำเลย
API endpoint ชื่ออะไร? R2 เปลี่ยนทีหลังได้
state management ใช้อะไร? R2 refactor ได้เสมอ
error handling ครบมั้ย? R2 user ยังไม่มี error ก็ยังไม่เกิด

ถ้า decision เปลี่ยนได้ใน 30 นาที — ไม่ต้องคิดเกิน 5 นาที

guardrail ที่ใส่ใน CLAUDE.md เพื่อกัน pitfall นี้:

happy flow first, error handling later — ทำให้ path ปกติทำงานได้ก่อน error จัดการทีหลัง (Lean: validated learning > defensive code)
ship the ugly version — ถ้ามันทำงานได้ ship ไป เพราะ feedback จาก user จริง > code สวยที่ไม่มีคนเห็น
ถ้าตัดสินใจไม่ได้ใน 2 ชั่วโมง แปลว่า decision นั้นยังไม่สำคัญพอ — ข้ามไปทำอย่างอื่น (YAGNI in practice)

เวอร์ชันแรกเป็น spaghetti มาก ไม่มี test ไม่มี proper error handling ไม่มี type safety หลายจุด

แล้วมันก็ทำงานได้

พอมีคนใช้จริง คนเจอ bug จริง ตอนนั้นถึงค่อยกลับมา tighten ค่อย refactor ค่อยเพิ่ม test — เพราะตอนนั้นรู้แล้วว่า fix ตรงไหนถึงจะ matter

แต่ advice นี้มีเส้นที่ห้ามข้าม

ไม่ใช่ทุกอย่างเป็น R2

deploy smart contract ขึ้น mainnet? R0 ย้อนไม่ได้
production DB schema ที่มี data จริง? R0 migrate ผิดคือเสีย data
token deployment? R0 ออกไปแล้วคือออกไปแล้ว

R0 ต้องหยุดคิดเสมอ ไม่ว่าจะ pre-PMF หรือไม่ ไม่ว่าจะมีลูกค้า 0 หรือ 10,000

ผิดพลาดตรง R2 เสียเวลา 30 นาทีแก้ ผิดพลาดตรง R0 อาจจะแก้ไม่ได้

เส้นนี้ต้องรู้

ถ้าคุณกำลังสร้างอะไรบางอย่าง ยังไม่มีคนใช้ ยังไม่รู้ว่าคนอยากใช้มั้ย — ถามตัวเองก่อนที่จะ setup อะไรก็ตาม:

decision นี้ R อะไร? feedback loop ถูก block อยู่ตรงไหน?

ถ้า R2 → ทำเลย ทุกชั่วโมงที่ใช้ polish สิ่งที่ยังไม่มีคนใช้ คือชั่วโมงที่ไม่ได้เรียนรู้

learning speed > code beauty
reversibility > correctness
feedback > assumption

แล้วจะรู้ได้ไงว่าถึงเวลาต้องทำให้ดี? ศุกร์นี้ครับ