Mở đầu — vì sao bài này quan trọng
Có một sự thật phũ phàng mà nhiều founder kỹ thuật phải học bằng tiền và thời gian: ở giai đoạn MVP, kẻ thù lớn nhất không phải là đối thủ cạnh tranh, mà là tốc độ học hỏi của chính bạn. Bạn đang đua với đồng hồ đếm ngược của số tiền trong ngân hàng, và mỗi tuần trôi qua mà chưa kiểm chứng được giả định cốt lõi là một tuần bạn đốt vốn vô ích.
Trong các bài trước, bạn đã học cách thiết kế experiment, chọn loại MVP phù hợp (smoke test, concierge, Wizard of Oz...), dùng no-code, và đo lường validation. Bài này tập trung vào một câu hỏi rất cụ thể và rất kỹ thuật: khi bạn buộc phải viết code thật cho MVP, làm thế nào để kỹ thuật phục vụ tốc độ học hỏi thay vì cản trở nó?
Đây không phải bài dạy bạn viết code ẩu. Đó là hiểu lầm tai hại nhất. "Engineering for speed" là một bộ nguyên tắc kiến trúc và ra quyết định giúp bạn ship nhanh mà không tự đào hố cho chính mình. Một engineer giỏi ở giai đoạn MVP không phải người viết hệ thống đẹp nhất, mà là người biết chỗ nào được phép cẩu thả và chỗ nào tuyệt đối không. Phần lớn nội dung bài này là về nghệ thuật phân biệt hai vùng đó.
Khái niệm cốt lõi
Triết lý nền tảng: ở giai đoạn MVP, code của bạn là chi phí, không phải tài sản. Mỗi dòng code bạn viết là một thứ phải bảo trì, debug, và rất có thể... vứt đi sau khi pivot. Vì vậy, code tốt nhất ở giai đoạn này thường là code bạn không phải viết.
Nguyên tắc 1: Boring tech > shiny tech (Công nghệ "nhàm chán" thắng công nghệ "hào nhoáng")
Cám dỗ lớn nhất của engineer là dùng MVP để thử framework mới, ngôn ngữ mới, database vừa ra mắt tuần trước. Đừng. Ở giai đoạn MVP, bạn cần công nghệ đã được kiểm chứng, có cộng đồng lớn, nhiều tài liệu, nhiều câu trả lời trên Stack Overflow.
Lý do rất thực tế: khi gặp bug lúc 2 giờ sáng trước ngày demo cho nhà đầu tư, bạn không muốn là người đầu tiên trên thế giới gặp bug đó. Với một framework "nhàm chán" như Laravel, Rails, Django, hay Next.js, gần như mọi vấn đề bạn gặp đều đã có người giải. Với công nghệ mới ra, bạn tự biến mình thành QA không lương cho nhà phát triển framework đó.
Khái niệm này gọi là "choose boring technology" — chọn công nghệ nhàm chán. Mỗi công nghệ mới bạn đưa vào stack tiêu tốn một "token đổi mới" (innovation token). Ở MVP, bạn chỉ có 1-2 token, và bạn nên tiêu chúng vào thứ tạo khác biệt thật sự cho sản phẩm — chứ không phải vào hạ tầng.
Nguyên tắc 2: Buy > Build (Mua tốt hơn tự xây)
Đây là nguyên tắc tiết kiệm thời gian khủng khiếp nhất. Có những phần của sản phẩm không hề là lợi thế cạnh tranh của bạn, nhưng lại tốn cực nhiều công nếu tự làm cho đúng và an toàn. Hãy mua/thuê chúng:
- Authentication (đăng nhập, đăng ký, quên mật khẩu, OAuth): dùng Firebase Auth, Supabase Auth, Auth0, hay Clerk. Tự viết hệ thống auth an toàn là cái bẫy ngốn hàng trăm giờ và đầy rủi ro bảo mật.
- Payment (thanh toán): dùng Stripe, hoặc ở Việt Nam là VNPay, MoMo, ZaloPay, PayOS. Đừng bao giờ tự xử lý thẻ tín dụng.
- Email giao dịch: dùng SendGrid, Resend, Amazon SES thay vì tự dựng mail server (việc gần như chắc chắn sẽ vào spam).
- Hạ tầng: dùng PaaS như Vercel, Railway, Render, Heroku thay vì tự cấu hình server từ đầu.
Nguyên tắc 3: Lean architecture (Kiến trúc tinh gọn)
Sai lầm kinh điển là thiết kế kiến trúc cho 1 triệu người dùng khi bạn còn 0 người dùng. Microservices, Kubernetes, message queue, event sourcing... đều là những thứ tuyệt vời ở quy mô lớn nhưng là gánh nặng chí mạng ở giai đoạn MVP.
Kiến trúc tinh gọn cho MVP thường là:
- Monolith (một ứng dụng duy nhất) thay vì microservices. Một codebase, một deployment, dễ hiểu, dễ sửa.
- Một database quan hệ duy nhất (PostgreSQL hoặc MySQL). Không cần Redis, Elasticsearch, MongoDB cùng lúc khi mới bắt đầu.
- Server-side rendering hoặc framework full-stack để không phải duy trì frontend và backend như hai dự án riêng.
- Tránh tối ưu hóa sớm (premature optimization). Đừng cache, đừng đánh index phức tạp, đừng tối ưu query cho đến khi bạn thực sự thấy nó chậm với dữ liệu thật.
Vùng được phép "nợ" và vùng không được phép
Có một khái niệm gọi là technical debt có chủ đích (intentional technical debt). Ở MVP, bạn vay nợ kỹ thuật một cách có ý thức ở những vùng "an toàn":
| Được phép cẩu thả / nợ | Tuyệt đối không được nợ |
|---|---|
| Code lặp lại, copy-paste | Bảo mật dữ liệu khách hàng |
| Giao diện admin xấu, thủ công | Xử lý tiền/thanh toán |
| Chưa có test cho mọi thứ | Mất dữ liệu (backup) |
| Tính năng hard-code, chưa cấu hình được | Lỗ hổng để lộ dữ liệu cá nhân |
Tình huống thực tế
Ví dụ 1: Startup giao đồ ăn ở TP.HCM và cái bẫy "tự xây tất cả"
Một startup giao đồ ăn cho dân văn phòng (gọi là "CơmGo") gọi được vòng seed nhỏ khoảng 2 tỷ đồng, đủ chạy 8 tháng. CTO là một engineer giỏi, quyết định xây hệ thống "chuẩn ngay từ đầu": microservices cho order, payment, restaurant; Kubernetes để dễ scale; tự viết module thanh toán tích hợp trực tiếp với ngân hàng để "tiết kiệm phí cổng thanh toán".
Kết quả sau 5 tháng: họ vẫn chưa launch. 60% thời gian engineer dồn vào việc DevOps cho cluster Kubernetes, debug giao tiếp giữa các service, và vật lộn với quy trình tích hợp ngân hàng (mất gần 2 tháng chỉ riêng phần này vì thủ tục và bảo mật). Tiền cạn dần mà chưa có một khách hàng thật nào để học hỏi.
Bài học: Đáng lẽ CơmGo chỉ cần một monolith Laravel chạy trên Railway, tích hợp MoMo/ZaloPay qua SDK có sẵn (mất 2 ngày thay vì 2 tháng), và bỏ hoàn toàn Kubernetes. Họ đã tiêu cả "ngân sách kỹ thuật" vào hạ tầng không ai trả tiền, trong khi giả định thật sự cần kiểm chứng — "dân văn phòng có đặt cơm qua app này không?" — vẫn chưa được động tới. Engineering xịn mà sai vùng đầu tư còn nguy hiểm hơn engineering yếu.
Ví dụ 2: Một SaaS B2B nhỏ và sức mạnh của "buy > build"
Một nhóm 2 người làm công cụ quản lý lịch hẹn cho các phòng khám nha khoa nhỏ ở Đông Nam Á. Họ chỉ có một lập trình viên. Thay vì tự xây mọi thứ, họ ráp MVP từ các mảnh mua sẵn:
- Auth: Clerk (cài trong 1 buổi sáng).
- Database + backend: Supabase (database, API tự sinh, auth, storage — tất cả trong một).
- Thanh toán gói subscription: Stripe.
- Gửi nhắc lịch qua email: Resend; nhắc qua tin nhắn: Twilio.
- Frontend: Next.js trên Vercel.
Bài học: Khi bạn xác định đúng đâu là "logic lõi" (10% tạo ra 90% giá trị) và mua tất cả phần còn lại, một engineer có thể làm được việc của cả một đội. "Buy > build" không phải lười — đó là tập trung hỏa lực.
Ví dụ 3: Khi "boring tech" cứu một buổi demo gọi vốn
Một startup edtech ở Hà Nội xây MVP trên một framework JavaScript rất mới (mới ra bản 1.0 được vài tháng). Mọi thứ chạy tốt khi dev, nhưng ba ngày trước buổi demo cho nhà đầu tư, họ gặp một bug deploy lạ: ứng dụng chạy local thì ổn, lên production thì trắng trang. Họ tìm khắp nơi không ra lời giải vì... gần như chưa ai gặp bug này. Cuối cùng phải thức trắng hai đêm và viết lại phần build bằng tay.
So sánh: một startup khác cùng cohort dùng Next.js (boring, ổn định, hàng triệu người dùng). Khi gặp bug, họ gõ thông báo lỗi lên Google và tìm thấy đúng issue đã được trả lời trên GitHub trong 10 phút.
Bài học: Sự ổn định và "có người đi trước" là một tính năng. Ở giai đoạn MVP, mỗi giờ bạn dành để gỡ một bug hiếm gặp của công nghệ hào nhoáng là một giờ bạn không dành cho khách hàng. Hãy để token đổi mới cho sản phẩm, không phải cho stack.
Hướng dẫn từng bước
Đây là quy trình ra quyết định kỹ thuật cho MVP, áp dụng được ngay:
Bước 1 — Vẽ ra "bản đồ giá trị lõi". Viết một câu duy nhất: "Sản phẩm này tạo giá trị nhờ ___." Phần điền vào chỗ trống chính là vùng duy nhất bạn được phép đầu tư công sức kỹ thuật. Mọi thứ khác là ứng viên để mua hoặc làm tối giản.
Bước 2 — Lập danh sách "mua sẵn" cho mọi thứ không phải lõi. Quét qua từng phần: auth, payment, email, SMS, storage, hosting, analytics. Với mỗi phần, mặc định lựa chọn là "dùng dịch vụ có sẵn". Chỉ tự xây nếu có lý do thật sự thuyết phục (ví dụ chi phí dịch vụ quá cao ở quy mô bạn cần — nhưng điều này hiếm khi đúng ở MVP).
Bước 3 — Chọn stack "nhàm chán" và quen tay. Chọn ngôn ngữ và framework mà bạn (hoặc đội bạn) đã thành thạo, có cộng đồng lớn. Không học công nghệ mới giữa lúc đua MVP. Quy tắc: tối đa 1 thứ mới trong toàn bộ stack.
Bước 4 — Thiết kế kiến trúc tối giản nhất có thể chạy được. Một monolith. Một database. Một nền tảng deploy. Bỏ qua cache, queue, microservices cho đến khi có bằng chứng cần đến chúng.
Bước 5 — Khoanh vùng "không được nợ". Liệt kê rõ ràng các vùng bất khả xâm phạm: bảo mật, dữ liệu khách hàng, backup tự động, xử lý thanh toán. Ở những vùng này bạn làm cẩn thận. Mọi vùng còn lại: chấp nhận "đủ tốt".
Bước 6 — Thiết lập deploy nhanh ngay từ ngày đầu. Đảm bảo bạn có thể đưa code lên production trong vài phút bằng một lệnh (hoặc một lần push). Tốc độ ship lại bản sửa là thứ quyết định nhịp độ học hỏi của bạn (chủ đề này được đào sâu hơn ở các bài về continuous deployment và iteration cadence).
Bước 7 — Ghi lại các khoản "nợ kỹ thuật có chủ đích".
Mỗi lần bạn cố tình làm tắt, ghi một dòng vào file TECH_DEBT.md. Khi MVP được kiểm chứng và chuyển sang V1, bạn sẽ biết chính xác cần dọn chỗ nào — thay vì để nợ ẩn trở thành quả bom hẹn giờ.
Lỗi thường gặp & mẹo
Lỗi 1: Tối ưu hóa cho quy mô chưa tồn tại. Đây là lỗi phổ biến nhất của engineer giỏi. Bạn lo lắng "lỡ có 1 triệu user thì sao?". Sự thật: 95% MVP không bao giờ chạm tới con số đó, và nếu may mắn đến mức cần scale, bạn sẽ có tiền và thời gian để viết lại. Đừng giải bài toán bạn chưa có.
Lỗi 2: Nhầm "MVP nhanh" với "code rác không kiểm soát". Engineering for speed không có nghĩa là bỏ mọi nguyên tắc. Bạn vẫn dùng version control, vẫn có backup, vẫn bảo mật dữ liệu. Bạn chỉ cắt giảm ở những vùng an toàn. Hai thái cực — cầu toàn và bừa bãi — đều giết MVP.
Lỗi 3: Tự viết auth/payment "cho nó chủ động". Đây gần như luôn là quyết định sai. Bạn không có lợi thế cạnh tranh nào ở việc tự làm đăng nhập, và rủi ro lộ dữ liệu hoặc sai sót thanh toán có thể giết chết niềm tin của những khách hàng đầu tiên.
Lỗi 4: Sa vào "vọc công nghệ" thay vì giải quyết vấn đề khách hàng. Nếu thấy mình đang đọc tài liệu của một công cụ DevOps phức tạp trong khi chưa có khách hàng, hãy dừng lại và tự hỏi: "Việc này có giúp tôi học được gì về khách hàng nhanh hơn không?"
Mẹo 1: "Wizard of Oz" cả ở backend. Bạn không cần tự động hóa mọi thứ ngay. Nhiều phần phức tạp (gửi báo cáo, duyệt nội dung, ghép cặp) có thể để con người làm thủ công sau hậu trường thời gian đầu. Code phần tự động chỉ khi bạn đã chắc khách hàng cần.
Mẹo 2: Đo "thời gian từ ý tưởng đến production". Đây là chỉ số sức khỏe kỹ thuật quan trọng nhất ở MVP. Nếu sửa một dòng chữ mà mất nửa ngày mới lên được production, kiến trúc của bạn đang cản tốc độ học hỏi.
Mẹo 3: Tận dụng template và boilerplate có sẵn. Các starter kit (ví dụ kết hợp Next.js + Supabase + Stripe sẵn) giúp bạn bỏ qua hàng tuần setup. Đứng trên vai người khác là chiến lược tốc độ hợp pháp.
Bài tập thực hành
- Bản đồ mua-hay-xây. Lấy ý tưởng sản phẩm của bạn (hoặc một sản phẩm bạn ngưỡng mộ). Liệt kê 8-10 thành phần kỹ thuật cần có. Với mỗi thành phần, đánh dấu "MUA" hay "XÂY", kèm tên dịch vụ cụ thể nếu chọn mua. Tô đậm duy nhất phần "logic lõi" mà bạn buộc phải tự xây.
- Câu một dòng về giá trị lõi. Viết câu "Sản phẩm này tạo giá trị nhờ ___." Sau đó kiểm tra: trong kế hoạch kỹ thuật của bạn, có bao nhiêu phần trăm thời gian được dành cho phần điền vào chỗ trống? Nếu dưới 50%, bạn đang đầu tư sai chỗ.
- Bảng vùng nợ kỹ thuật. Vẽ bảng hai cột: "Được phép nợ" và "Tuyệt đối không nợ" cho dự án của bạn. Điền tối thiểu 4 mục mỗi cột. Đây sẽ là kim chỉ nam mỗi khi bạn phải quyết định "có nên làm tắt chỗ này không".
- Thử thách stack nhàm chán. Chọn stack bạn sẽ dùng cho MVP và tự trả lời: framework này đã ra đời bao lâu? Có bao nhiêu câu hỏi trên Stack Overflow? Nếu gặp bug deploy lúc 2 giờ sáng, bạn có tự tin tìm được lời giải không? Nếu câu trả lời khiến bạn lo lắng, hãy đổi.
Tóm tắt
Ở giai đoạn MVP, kỹ thuật phục vụ một mục tiêu duy nhất: tăng tốc độ học hỏi từ khách hàng thật. Code là chi phí chứ không phải tài sản, vì vậy code tốt nhất là code bạn không phải viết.
Ba nguyên tắc trụ cột: (1) Boring tech > shiny tech — chọn công nghệ đã được kiểm chứng để không phí thời gian gỡ bug hiếm; (2) Buy > build — mua auth, payment, email, hạ tầng và chỉ tự xây phần logic lõi tạo giá trị; (3) Lean architecture — monolith, một database, tránh tối ưu hóa sớm, đủ đơn giản để hiểu trong nửa ngày.
Bí quyết then chốt là biết phân biệt vùng được phép "nợ" kỹ thuật (giao diện admin, code lặp, thiếu test) và vùng tuyệt đối không được nợ (bảo mật, dữ liệu khách hàng, thanh toán, backup). Founder thắng ở giai đoạn này không phải người viết hệ thống đẹp nhất, mà là người dồn đúng hỏa lực vào đúng 10% quan trọng và mạnh dạn làm tối giản 90% còn lại — để có thể ship nhanh, học nhanh, và sống sót đến khi tìm ra product-market fit.