Từ app thành sản phẩm

Định giá, hợp đồng, bàn giao, hỗ trợ. Những thứ quyết định bạn có sống được bằng nghề này không — và chúng không phải là kỹ thuật.

Bạn đã có app chạy được. Bài này nói về khoảng cách giữa một app và một sản phẩm có người trả tiền và bạn không kiệt sức vì nó.

Bốn câu hỏi phải trả lời trước khi làm

Trả lời được bốn câu này thì làm; không thì đừng bắt đầu:

1. Ai đang làm việc này bằng tay, và mất bao lâu mỗi ngày? Không trả lời được bằng con số cụ thể thì bạn chưa có vấn đề thật.
2. Nếu app biến mất ngày mai, họ có khổ không? Không khổ → đó là đồ chơi, không phải sản phẩm.
3. Ai là người ký duyệt chi tiền? Người dùng và người trả tiền thường là hai người khác nhau. Người thứ hai quan tâm thứ khác.
4. Hỏng lúc 11 giờ đêm thì ai sửa? Nếu câu trả lời chỉ có thể là "tôi", hãy định giá theo đúng điều đó.

Định giá — ba hiểu lầm

Hiểu lầm 1: "Tôi làm 3 ngày nên lấy tiền 3 ngày." Khách không mua số ngày. Khách mua việc họ hết phải làm bằng tay. Nếu app thay cho 2 giờ nhập liệu mỗi ngày của một nhân viên, giá trị một năm của nó là vài chục triệu — bất kể bạn làm trong bao lâu.

Hiểu lầm 2: "Tôi báo giá thấp để lấy khách đầu." Giá đầu tiên trở thành cái neo. Khách thứ hai sẽ nghe về giá của khách thứ nhất. Và khách trả rẻ thường đòi hỏi nhiều hơn — vì họ cảm thấy mình đang được "làm ơn" nên không ngại nhờ thêm.

Nếu muốn giảm giá cho khách đầu, hãy ghi rõ: "giá triển khai thí điểm, áp dụng cho hợp đồng ký trong tháng 10". Giữ được giá niêm yết.

Hiểu lầm 3: Quên phí duy trì. Đây là hiểu lầm làm người mới lỗ. Bạn báo giá dựng app, rồi sáu tháng sau vẫn đang sửa lỗi miễn phí vì "khách nhờ chút thôi".

Cấu trúc báo giá nên có ba dòng, luôn luôn:

1. Triển khai ban đầu        : X đồng (một lần)
2. Hạ tầng                   : Y đồng/năm (hoặc "nằm trong gói miễn phí")
3. Duy trì & hỗ trợ          : Z đồng/năm — gồm: sửa lỗi, sao lưu,
                               cập nhật, và N giờ thay đổi nhỏ

Dòng 3 kể cả khi bằng 0 cho năm đầu — vẫn phải ghi ra. Để năm sau không thành phát sinh.

Phạm vi — nơi mọi dự án chết

Dự án hỏng không phải vì kỹ thuật, mà vì phạm vi trôi: mỗi tuần thêm một chút, không ai thấy là nhiều, sáu tháng sau bạn làm gấp ba việc với cùng một khoản tiền.

Hai công cụ chống trôi:

1. Danh sách "KHÔNG bao gồm" trong báo giá. Quan trọng hơn danh sách "bao gồm":

KHÔNG bao gồm trong phạm vi này:
- Kết nối với phần mềm kế toán
- Ứng dụng cài trên điện thoại (bản này chạy trên trình duyệt)
- Nhập dữ liệu lịch sử từ Excel cũ
- Đào tạo nhân viên (có thể làm thêm, báo giá riêng)

2. Câu trả lời chuẩn cho mọi yêu cầu mới:

"Việc này em làm được, nằm ngoài phạm vi đã chốt. Khoảng N giờ. Anh muốn em làm thêm (báo giá riêng), hay thay vào một việc đang có trong danh sách?"

Không từ chối, không làm miễn phí. Đưa cái giá ra và để khách quyết.

Bàn giao — nghĩ từ ngày đầu

Ngày bạn và khách chia tay sẽ đến, dù vì lý do tốt hay xấu. Chuẩn bị trước thì nó là một buổi chiều; không chuẩn bị thì nó là một cuộc tranh cãi.

Bốn thứ phải rõ ngay trong hợp đồng:

Dòng cuối không có chỗ để thương lượng. Giữ dữ liệu của khách làm con tin là cách nhanh nhất để mất uy tín trong một ngành mà mọi người đều biết nhau.

Về tài khoản hạ tầng: cho khách sở hữu tài khoản Cloudflare của chính họ là lựa chọn sạch nhất. Nó giải quyết cả chuyện bàn giao, cả chuyện điều khoản bán lại hạ tầng (Chi phí), và nó làm khách yên tâm hơn — họ không bị phụ thuộc vào bạn.

Hỗ trợ — đặt ranh giới trước khi cần

Không đặt ranh giới thì bạn nhận tin nhắn lúc 10 giờ tối Chủ nhật, và bạn sẽ trả lời, và từ đó nó thành tiêu chuẩn.

Giờ hỗ trợ   : Thứ 2–7, 8h–17h30
Kênh         : nhóm Zalo chung (KHÔNG nhắn riêng)
Phản hồi     : trong 4 giờ làm việc
Sự cố nghiêm trọng (app không dùng được): xử lý ngay, kể cả ngoài giờ

Dòng "không nhắn riêng" là dòng quan trọng nhất về mặt vận hành: góp ý trong nhóm thì mọi người cùng thấy, không lặp lại, và có lịch sử. Góp ý trong tin nhắn riêng thì mất, và bạn phải nhớ bằng đầu.

Và định nghĩa rõ "nghiêm trọng", nếu không mọi thứ đều nghiêm trọng:

Nghiêm trọng = không đăng nhập được, không lưu được dữ liệu, hoặc dữ liệu sai lệch. Còn lại (giao diện, tính năng phụ, đề nghị mới) xử lý trong giờ làm việc.

Tài liệu — hai loại, viết khác nhau

Cho người dùng: ngắn, nhiều ảnh, theo việc chứ không theo màn hình.

❌ "Màn hình Đơn hàng"        (theo cấu trúc phần mềm)
✅ "Cách nhập một đơn mới"    (theo việc người ta cần làm)

Ba đến năm bài là đủ, mỗi bài một việc hay làm nhất. Đừng viết sách hướng dẫn 40 trang — không ai đọc.

Cho chính bạn (và người kế nhiệm): README.md, CLAUDE.md, HA-TANG.md, SU-CO.md. Bốn file này là tài sản thật của bạn.

Dựa trên project này, soạn giúp tôi 3 tài liệu:

1. BÁO GIÁ mẫu — ba dòng (triển khai ban đầu / hạ tầng / duy trì
   hằng năm), kèm mục "KHÔNG bao gồm" ít nhất 5 gạch đầu dòng.
   Để trống phần số tiền, tôi tự điền.

2. ĐIỀU KHOẢN HỖ TRỢ — giờ hỗ trợ, kênh, thời gian phản hồi,
   định nghĩa rõ thế nào là sự cố nghiêm trọng.

3. HƯỚNG DẪN NGƯỜI DÙNG — 5 bài, mỗi bài một VIỆC (không phải
   một màn hình), mỗi bài tối đa 10 dòng, viết cho người 45 tuổi
   đọc trên điện thoại.

Giọng văn: thẳng, không khoa trương, không tự thu nhỏ mình.
KHÔNG dùng các câu kiểu "chỉ là", "tuy nhỏ nhưng", "như các phần
mềm lớn". Không so sánh với sản phẩm khác.

Chỉ dựa trên tính năng CÓ THẬT trong mã. Đừng hứa thứ chưa có.