Câu hỏi

Cứ gửi sang thứ bạn đang có: một ý tưởng còn thô, một file Figma, một sản phẩm dở dang, hay đơn giản là một vấn đề mãi chưa gỡ được. Chúng tôi đọc kỹ trước khi nói chuyện, rồi hẹn một buổi trao đổi để xác định bạn thực sự cần xây điều gì, và liệu chúng tôi có phải studio phù hợp hay không.

Nếu phù hợp, bạn nhận được một đề xuất bằng văn bản với đầy đủ phạm vi, thứ tự triển khai, chi phí và mốc thời gian. Còn nếu không phù hợp, chúng tôi sẽ nói thẳng và chỉ bạn tới một nơi tốt hơn.

Cả hai, tuỳ theo mức rủi ro. Giá trọn gói hợp với những phạm vi đã rõ ràng: một trang marketing, một tích hợp đã xác định, hay một design system. Bạn biết con số ngay từ đầu, còn rủi ro ước lượng thì chúng tôi gánh.

Tính theo thời gian hợp với những sản phẩm chắc chắn sẽ đổi khi va vào người dùng — tức là phần lớn sản phẩm. Bạn có một nhịp làm việc theo tuần, và có thể dừng, tạm hoãn hay đổi hướng ở cuối bất kỳ tuần nào.

Thứ duy nhất chúng tôi tránh là giá trọn gói cho một phạm vi còn mơ hồ. Kiểu thoả thuận ấy chỉ kết thúc theo một trong hai cách: hoặc chúng tôi độn giá, hoặc hai bên ngồi cãi nhau về phát sinh.

Có — đủ nhỏ để dự án đầu tiên không trở thành một canh bạc, và đủ lớn để chúng tôi làm được điều gì đó thực chất. EDIT: ghi mức tối thiểu của bạn ở đây (ví dụ hai tuần discovery, hoặc một đợt build bốn tuần).

Một giai đoạn discovery ngắn có trả phí thường là cách rẻ nhất để cả hai bên biết được có nên đi đường dài cùng nhau hay không.

Thường là có. Chúng tôi bắt đầu bằng một đợt rà soát có trả phí trên codebase và hạ tầng, để cả hai bên cùng biết mình đang nhận về thứ gì: cái nào chạy được, cái nào đang chịu lực, và cái nào rồi sẽ gây đau đầu.

Bạn nhận bản rà soát ấy dưới dạng tài liệu kèm chi phí, dù sau đó có làm tiếp với chúng tôi hay không. Chúng tôi thà đưa bạn một đánh giá thành thật, còn hơn lặng lẽ ôm vấn đề của người khác rồi tính tiền bạn cho phần bất ngờ đó.

Không, nhưng phần việc đầu tiên sẽ là định hình chứ chưa phải xây dựng. Chúng tôi giúp bạn quyết định sản phẩm thực chất là gì, phiên bản nhỏ nhất đáng ra mắt trông ra sao, và phiên bản ấy cần trả lời câu hỏi nào.

Xây thật tốt một thứ sai là kết cục tốn kém nhất có thể xảy ra, nên giai đoạn này hoàn toàn xứng đáng với chi phí của nó.

Tuỳ phạm vi — và studio nào báo giá trước khi hiểu phạm vi của bạn thì chỉ đang đoán. Điều chúng tôi nói được là con số ấy cấu thành từ đâu: quy mô đội ngũ, số tuần làm việc, và việc chúng tôi có gánh rủi ro ước lượng thay bạn hay không.

EDIT: bổ sung bảng giá hoặc khoảng chi phí điển hình ở đây (ví dụ một landing page, một MVP và một nền tảng hoàn chỉnh thường rơi vào mức nào). Thiếu phần này thì câu trả lời tuy thành thật nhưng chẳng giúp được ai.

Bạn luôn nhận được bản ước lượng bằng văn bản trước khi công việc bắt đầu, và chúng tôi báo ngay khi thấy sắp vượt, chứ không đợi tới lúc mọi thứ đã xong.

Công việc trọn gói được tính theo những mốc gắn với thứ bạn thực sự nhìn thấy được, chứ không theo các giai đoạn nội bộ. Công việc tính theo thời gian thì xuất hoá đơn hằng tháng, dựa trên nhật ký những gì đã làm.

EDIT: ghi mức đặt cọc, điều khoản hoá đơn và các hình thức thanh toán bạn nhận.

Nó sẽ thay đổi, và đó là chuyện bình thường. Với hình thức tính theo thời gian, chúng tôi chỉ việc sắp lại ưu tiên cho tuần kế tiếp. Với giá trọn gói, chúng tôi báo giá riêng cho thay đổi ấy, và bạn quyết định nó có đáng làm hay không trước khi chúng tôi bắt tay vào.

Không có gì bị âm thầm nuốt vào, cũng chẳng có gì bị âm thầm tính tiền. Nếu một yêu cầu làm dời ngày hoặc đổi con số, bạn sẽ biết ngay trong tuần đó.

Bạn sở hữu toàn bộ, ngay khi thanh toán nốt: mã nguồn, file thiết kế, định nghĩa hạ tầng và mọi tài khoản. Chúng tôi không giữ lại bất kỳ ràng buộc nào vào hosting, giấy phép hay tài khoản của riêng mình.

Thứ duy nhất chúng tôi giữ lại là những khối dựng sẵn mang tính dùng chung, không gắn với khách hàng cụ thể nào, và chúng được cấp phép vĩnh viễn cho bạn. EDIT: đối chiếu điều này với hợp đồng của bạn trước khi công bố.

Có. Cứ gửi bản của bạn sang và chúng tôi ký, hoặc chúng tôi đưa sẵn một bản song phương tiêu chuẩn.

Mặc định, chúng tôi cũng không công khai dự án của bạn khi chưa hỏi. Nếu bạn muốn nó xuất hiện trong portfolio, hai bên sẽ thống nhất trước những gì được phép hiển thị.

Ít hơn bạn lo, nhưng không thể bằng không. Chúng tôi cần một người phía bạn đủ thẩm quyền ra quyết định mà không phải triệu tập cả hội đồng, có mặt ở buổi review hằng tuần, và liên lạc được trong tuần khi có câu hỏi.

Dự án tắc lại vì những quyết định không ai trả lời, nhiều hơn hẳn so với vì các vấn đề kỹ thuật.

Một kênh chung cho những câu hỏi hằng ngày, và mỗi tuần một buổi review trên đường link chạy thật. Thứ bạn nhìn vào là phần mềm đang sống, không phải một bản báo cáo tiến độ.

Chúng tôi thà cho bạn xem một thứ còn dở dang ở tuần thứ hai, còn hơn một thứ bóng bẩy nhưng sai hướng ở tuần thứ tám.

Có. Phần lớn trao đổi được thiết kế theo hướng bất đồng bộ, kèm một buổi gọi cố định hằng tuần vào giờ phù hợp cho cả hai phía.

EDIT: ghi giờ làm việc, múi giờ gốc và khoảng thời gian trùng nhau mà bạn cam kết được.

Nói về hình dạng của tiến độ sẽ hữu ích hơn một con số đơn lẻ: discovery đo bằng ngày, bản phát hành đầu tiên đo bằng tuần, còn một sản phẩm đã ổn định thì chạy theo nhịp liên tục.

EDIT: thay đoạn này bằng thời lượng điển hình cho loại công việc bạn thực sự bán.

Nếu có một mốc thật sự cố định — ngày ra mắt, một sự kiện, một vòng gọi vốn — hãy nói ngay từ đầu. Chúng tôi sẽ giữ lấy mốc đó và cắt bớt phạm vi để kịp, bởi đây là cách đáng tin cậy duy nhất để về đích đúng hạn.

Chủ yếu là TypeScript xuyên suốt: React và Next.js cho web, React Native cho mobile, Node và Python ở phía server, PostgreSQL cho dữ liệu, Docker và AWS để vận hành.

Chúng tôi cố tình chọn những công cụ nhàm chán nhưng được hỗ trợ tốt. Bởi sau khi chúng tôi rời đi, bạn vẫn phải tuyển được người tiếp quản — và điều đó khó hơn nhiều nếu chúng tôi trót chọn một thứ đang thời thượng.

Mỗi trang dịch vụ đều liệt kê bộ công nghệ chúng tôi ưu tiên cho mảng đó.

Thường là được. Chỉ cần cho chúng tôi biết sớm: nếu gặp thứ mình không kham nổi một cách tử tế, chúng tôi sẽ nói thẳng, chứ không lấy ngân sách của bạn ra để học nghề.

Chúng tôi dùng công cụ AI ở những chỗ nó thực sự giúp ích, và rà soát lại mọi thứ trước khi phát hành. Thứ bạn mua là phán đoán kỹ thuật: cái gì nên tồn tại, nên được tổ chức ra sao, và sẽ hỏng theo cách nào — mà những điều ấy không đến từ một mô hình.

Chúng tôi không phát hành đoạn code nào do AI sinh ra mà chính mình không hiểu.

Có, và nhắm vào đúng những chỗ hỏng là mất tiền thật, chứ không chạy theo một con số phần trăm coverage. Mọi luồng người dùng quan trọng đều có test end-to-end chạy ở từng thay đổi.

Chúng tôi thà có một bộ test nhỏ, nhanh và đáng tin, còn hơn một bộ đồ sộ mà rồi ai cũng quen tay bỏ qua.

Sản phẩm đang chạy, repo còn nguyên lịch sử commit, hạ tầng viết bằng code, tài liệu về môi trường và cách triển khai, cùng một buổi hướng dẫn trực tiếp cho người tiếp nhận.

Đây là tiêu chuẩn chúng tôi tự đặt ra cho mình: một kỹ sư có nghề, chưa từng gặp chúng tôi, phải clone được repo, chạy được trên máy mình và triển khai được, chỉ bằng những gì chúng tôi để lại.

Có — cập nhật thư viện và vá bảo mật, giám sát, cùng một quy trình rõ ràng cho lúc có sự cố. Xem trang dịch vụ bảo trì để biết một thoả thuận dài hạn bao gồm những gì.

EDIT: ghi thời gian phản hồi và khung giờ hỗ trợ của bạn.

Đó là một kết cục bình thường, không phải thất bại. Bạn vốn đã sở hữu mọi thứ, và tài liệu bàn giao thì có từ ngày đầu chứ không phải viết vội vào phút chót.

Chúng tôi sẽ đồng hành một giai đoạn chuyển giao cùng đội mới của bạn, theo mức phí thông thường. Không phí thoát, cũng không giữ chân ai.

Chúng tôi làm sai thì chúng tôi sửa bằng tiền của mình. Đó là lỗi chứ không phải yêu cầu phát sinh, và chúng tôi không mất công câu nệ ranh giới ấy.

Còn những yêu cầu mới phát sinh sau khi ra mắt lại là chuyện khác, và chúng tôi sẽ nói thẳng với bạn rằng mình xếp nó vào loại nào.