KISS hoặc Chết: Tại sao các Kỹ sư Cấp cao Thất bại tại Công ty khởi nghiệp

Công ty khởi nghiệp đầu tiên của tôi là một thất bại, và một số công ty khởi nghiệp lân cận cũng thất bại. Chúng tôi có: 100K USD tín dụng GCP, một kỹ sư sáng lập đã xây dựng hệ thống trong doanh nghiệp, và chiến lược tiếp cận thị trường. Và chúng tôi đã thất bại, không phải vì chúng tôi xây dựng nó sai, mà vì chúng tôi xây dựng nó quá tốt. Đó là vấn đề.

Trong khi chúng tôi dành thời gian vật lộn với thứ có vẻ như là một ngăn xếp công nghệ "không tối ưu", chúng tôi đã đánh mất điều quan trọng nhất: thời gian, động lực, và về mặt chiến lược là một cơ hội.

Câu chuyện này không phải về những người thiếu lẽ thường. Tôi có lẽ thường, và chúng tôi biết rằng chúng tôi nên giữ mọi thứ đơn giản. Nhưng khi mô hình tư duy của bạn không phù hợp với tình huống, tất cả lẽ thường của bạn bị cuốn trôi. Bạn đưa ra những quyết định "đúng" nhưng lại giết chết bạn.

Đây cũng không phải là câu chuyện về kỹ thuật tồi. Đó là về cách kỹ thuật tốt giết chết các công ty khởi nghiệp. Làm thế nào kinh nghiệm giúp bạn trở thành senior lại trở thành trách nhiệm lớn nhất của bạn. Làm thế nào "làm đúng" hoặc thậm chí "làm đơn giản" thường là làm sai.

Bài viết này trình bày mô hình tư duy để giúp bạn đưa ra những quyết định đúng đắn và tránh những sai lầm mà tôi đã mắc phải.

:::tip Dành cho ai: kỹ sư senior bắt đầu hoặc tham gia vào các công ty khởi nghiệp giai đoạn đầu. Nếu bạn đã dành hơn 5 năm trong doanh nghiệp hoặc Big Tech, đây là lời cảnh báo cho bạn.

:::

\

Mô hình tư duy #1 - Cơ sở hạ tầng "Miễn phí" Là Đắt Nhất

100K USD tín dụng GCP có vẻ như một món quà, nhưng đó là một cái bẫy. Nó đẩy bạn đến việc thiết kế quá mức vì "nó đã được trả tiền rồi." Bạn nhận được các máy chủ, bộ cân bằng tải, đăng ký container, và các công cụ doanh nghiệp đòi hỏi thiết lập doanh nghiệp. Bạn cần có gì? Một nút "push để triển khai".

Chắc chắn, bạn có thể xây dựng quy trình "triển khai từ GitHub đến VM" trên GCP/AWS/Azure. Một số sản phẩm gần đạt được điều đó. Nhưng nó đòi hỏi các bước bổ sung: cấu hình Cloud Build, thiết lập vai trò IAM, viết script triển khai, quản lý bí mật, và cấu hình kiểm tra sức khỏe. Bạn đốt thời gian xây dựng cơ sở hạ tầng triển khai trước khi triển khai sản phẩm thực tế.

Trong khi đó, các nền tảng như Railway hoặc Fly.io cung cấp cho bạn những gì các công ty khởi nghiệp thực sự cần: một VM liên tục với triển khai start-and-go từ GitHub. Dễ dàng nhất có thể: bạn đẩy mã của mình, và nó được triển khai. Chỉ cần VM sẵn sàng sử dụng với biến môi trường, SSL, bộ cân bằng tải, nhật ký, v.v. Nó không "miễn phí," nhưng nó sẵn sàng.

Tín dụng miễn phí đẩy bạn đến việc thiết kế quá mức vì "nó đã được trả tiền rồi." Bạn tự thuyết phục mình rằng bạn đang tiết kiệm tiền trong khi đang tiêu tốn nguồn tài nguyên quý giá nhất của mình: thời gian.

\

Mô hình tư duy #2 - "Tối thiểu" <> "Đơn giản"

Nguyên tắc KISS truyền thống nói với chúng ta hãy giữ phần mềm của chúng ta đơn giản. Nhưng trong các công ty khởi nghiệp, đó là mục tiêu sai. Bạn không nên giữ PHẦN MỀM đơn giản; bạn nên giữ GIẢI PHÁP đơn giản.

Sự đơn giản thực sự nên được đo bằng tổng nỗ lực, không phải độ phức tạp của mã:

Tổng nỗ lực = Xây dựng ban đầu + Bảo trì + Gỡ lỗi + Thêm tính năng + Cập nhật bảo mật + Thay đổi quy mô

Khi bạn xây dựng từ đầu, bạn sở hữu tất cả những điều này mãi mãi. Khi bạn sử dụng một dịch vụ, hầu hết những điều này trở thành số không. Dịch vụ bên thứ ba "cồng kềnh" thực sự là giải pháp đơn giản vì nó giảm thiểu tổng nỗ lực.

Ví dụ OAuth của tôi

Kỹ sư sáng lập của chúng tôi quyết định xây dựng OAuth từ đầu thay vì sử dụng một "thư viện không xác định." Một tuần sau, anh ấy đã gửi một PR: triển khai OAuth sạch sẽ với token JWT, xoay vòng token làm mới, quản lý phiên, và kiểm soát truy cập dựa trên vai trò. Không có phụ thuộc, không có khóa nhà cung cấp, chỉ có mã chúng tôi kiểm soát.

Tôi đã không từ chối PR. Và đây là một sai lầm. Vứt bỏ một tuần làm việc sẽ làm giảm tinh thần. Nhưng nó tạo ra độ phức tạp của mã và đặt nó trên đường ray sai. Hơn nữa, không thảo luận về cách tiếp cận trước đó là sai lầm thực sự của chúng tôi. Chúng tôi để niềm tự hào kỹ thuật đưa ra quyết định chiến lược.

Sau đó, một khách hàng cần Microsoft OAuth và Google OAuth. Triển khai tùy chỉnh có nghĩa là nhiều ngày tái cấu trúc, xoay vòng token làm mới, các trường hợp biên, RBA, và những thứ khác. Mỗi bổ sung "đơn giản" đòi hỏi hiểu biết sâu sắc về xác thực tùy chỉnh của chúng tôi. Mọi cập nhật bảo mật là của chúng tôi để thực hiện. Mọi yêu cầu mới là của chúng tôi để viết mã.

Nguyên tắc

Sai lầm cổ điển của kỹ sư senior: tối ưu hóa cho kiểm soát thay vì kết quả. Trong các công ty khởi nghiệp, thực tế đòi hỏi đảo ngược hoàn toàn cách kỹ sư senior suy nghĩ:

1. DỪNG suy nghĩ: "Đây chỉ là vài ngày viết mã" \n BẮT ĐẦU suy nghĩ: "Đây là vài ngày KHÔNG viết mã cho sản phẩm thực tế của tôi"
2. DỪNG suy nghĩ: "Tôi có thể xây dựng điều này một cách đơn giản" \n BẮT ĐẦU suy nghĩ: "Tôi có thể giải quyết điều này một cách đơn giản bằng cách không xây dựng"
3. DỪNG suy nghĩ: "Dịch vụ bên thứ ba thêm độ phức tạp" \n BẮT ĐẦU suy nghĩ: "Dịch vụ bên thứ ba hấp thụ độ phức tạp"

\

\

Mô hình tư duy #3 - Lựa chọn thoải mái

Chúng tôi chọn Angular vì kỹ sư sáng lập của chúng tôi biết nó sâu sắc. Quyết định thông minh, phải không? Sử dụng điểm mạnh của bạn, phát hành mã chất lượng. Framework là tốt, NHƯNG vấn đề là hệ sinh thái của nó.

Cái bẫy hệ sinh thái

Angular rất xuất sắc và kỹ sư của chúng tôi có thể xây dựng bất cứ thứ gì với nó.

Nhưng "bất cứ thứ gì" cũng mất thời gian chỉ để bắt đầu. Thiết lập triển khai, xác thực, và các thành phần UI cơ bản có nghĩa là cấu hình vô tận trước khi viết một tính năng duy nhất. Trong khi chúng tôi gỡ lỗi chủ đề Angular Material, đối thủ cạnh tranh có thể (và sẽ) sử dụng Next.js + Vercel đã đưa người dùng vào hệ thống.

Chỉ cần so sánh điều đó với con đường Next.js + Vercel: triển khai ứng dụng khung với npx create-next-app vào ngày đầu tiên, thêm xác thực Clerk và các thành phần shadcn/ui, phát hành các tính năng thực tế vào ngày đầu tiên. Cùng một đích đến, hành trình hoàn toàn khác nhau.

Tại sao điều này xảy ra?

Sự khác biệt không phải là chất lượng framework, mà là tối ưu hóa hệ sinh thái. Next.js/React được bao quanh bởi các công ty khởi nghiệp được hỗ trợ bởi các nhà đầu tư mạo hiểm xây dựng công cụ cho các công ty khởi nghiệp khác:

• UI: shadcn/ui - sao chép, dán, phát hành
• Xác thực: Clerk/Supabase - cấu hình trong vài phút
• Triển khai: Vercel - git push tương đương với sản phẩm
• Mọi thứ khác: Nếu các công ty khởi nghiệp cần nó, ai đó đã xây dựng một dịch vụ

Hệ sinh thái của Angular phục vụ doanh nghiệp: mạnh mẽ, linh hoạt, có thể tùy chỉnh vô hạn. Hoàn hảo(?) cho các đội 50 người và là chất độc cho các đội 3 người.

\

Mô hình tư duy #4 - Xây dựng Cốt lõi, Thuê Ngữ cảnh

Nhưng ngay cả với các công cụ đúng đắn, vẫn còn một cái bẫy cuối cùng: sự thôi thúc xây dựng mọi thứ vì bạn có thể, không phải vì bạn nên. Cái bẫy này giết chết các đội kỹ thuật mạnh và nhiều công ty khởi nghiệp hơn chúng ta có thể tưởng tượng: xây dựng những thứ không ai yêu cầu vì bạn có thể, không phải vì bạn nên.

Chúng tôi đã dành ít nhất một tháng tổng cộng cho các tính năng không ai cần. OAuth tùy chỉnh khi Auth0 đã tồn tại. Một hàng đợi công việc dựa trên Postgres khi Redis + Celery đã tồn tại. Terraform từ ngày đầu tiên, khi bảng điều khiển hoạt động tốt. Mỗi quyết định cảm thấy hiệu quả, nhưng mỗi quyết định là tự phá hoại để đối mặt với những thách thức thực sự như nói chuyện với khách hàng hoặc thực hiện phát triển khách hàng khác.

Mô hình rất đơn giản: nếu khách hàng sẽ không chọn bạn vì nó, đừng xây dựng nó.

Quy tắc 50$ của tôi

Nếu một SaaS có giá dưới 50$/tháng, bạn không thể đủ khả năng để xây dựng nó. Thời gian của bạn quá đắt.

Xây dựng OAuth tùy chỉnh mất 1-2 tuần tổng cộng bảo trì và thêm các nhà cung cấp OAuth khác nhau. Với tốc độ đốt tiền của công ty khởi nghiệp, đó là 5,000-15,000$ thời gian kỹ thuật, hoặc trong thời gian mất cơ hội. Auth0 miễn phí cho đến 25,000 người dùng hoạt động, sau đó là 35$/tháng. Bạn có thể trả tiền cho Auth0 trong 35 năm với chi phí để xây dựng nó một lần.

Vì vậy, đây không phải là về tiền mà về ưu tiên và chi phí cơ hội.

Ngoại lệ

Theo ý kiến của tôi, chỉ xây dựng nếu bạn không thể tìm hiểu về người dùng mà không có nó.  Một ví dụ đơn giản là khi bạn cần kiểm tra xem người dùng có sẵn sàng trả tiền cho báo cáo được tạo bởi AI hay không. Xây dựng phiên bản đơn giản nhất chứng minh nhu cầu. Và mọi thứ khác cố gắng trượt qua. Vâng, bỏ qua cơ sở hạ tầng, bỏ qua "làm đúng", bỏ qua các thực hành tốt nhất không phát hành tính năng, bỏ qua kiểm tra. Một lần nữa, hãy lười biếng nhất có thể trong việc viết mã.

Những gì tôi thực sự sử dụng

• Xác thực: Clerk (React-native, DX tốt hơn) hoặc Auth0 (tập trung vào B2B, sẵn sàng cho doanh nghiệp)
• Email: Resend (ưu tiên nhà phát triển) hoặc SendGrid (đã được kiểm chứng)
• Phân tích: PostHog (miễn phí cho đến khi mở rộng)
• Giám sát: Sentry (không thể đánh bại cho lỗi)
• Lưu trữ: Cloudflare hoặc Vercel (nếu hoàn toàn sử dụng Next.js)

Đây không phải là sự chứng thực mà là lựa chọn của riêng tôi được tối ưu hóa cho tốc độ. Tôi đoán ngăn xếp của bạn sẽ khác nhưng nguyên tắc này sẽ không.

\

\

Kết luận

LLM đã biến việc xây dựng thành hàng hóa. Bất kỳ junior nào với Claude cũng có thể tạo ra hệ thống xác thực tùy chỉnh mà bạn tự hào. Giá trị của bạn không còn nằm ở những gì bạn có thể xây dựng nữa, MÀ là ở việc biết những gì không nên xây dựng.

Lãnh đạo là khả năng tách biệt tín hiệu từ tiếng ồn. Sự thâm niên thực sự có nghĩa là có kỷ luật để bỏ qua 90% những gì bạn biết và phát hành giải pháp của ngày hôm nay, không phải kiến trúc của ngày mai.