ToolTasted: Học xây và vận hành một sản phẩm của riêng mình

Mình bắt đầu ToolTasted vào tháng 9/2026 để học cách xây dựng và vận hành một sản phẩm của riêng mình. Mình muốn đi xa hơn việc làm cho một website chạy được: chọn vấn đề để giải quyết, viết nội dung có ích, đưa nó đến người đọc và chịu trách nhiệm cập nhật sau khi xuất bản.

Sản phẩm mình chọn là một website hướng dẫn lựa chọn công cụ AI và SaaS. Phạm vi đủ nhỏ để mình tự làm toàn bộ, nhưng có những câu hỏi mà chỉ viết code thì chưa trả lời được: ai cần đọc, họ đang muốn quyết định điều gì, và vì sao họ nên tin vào một khuyến nghị?

ToolTasted là gì?

ToolTasted là nơi mình viết hướng dẫn và so sánh công cụ theo nhu cầu sử dụng cụ thể. Thay vì dừng ở danh sách tính năng, mình muốn làm rõ công cụ phù hợp với ai, có giới hạn gì và khi nào nên cân nhắc lựa chọn khác.

Nội dung hiện tập trung vào công cụ giọng nói và các tình huống làm việc của developer: nhập prompt bằng giọng nói, viết commit message, xử lý ghi chú hoặc chọn giữa nhận dạng trên thiết bị và trên đám mây.

Ví dụ, khi cân nhắc một công cụ dictation, câu hỏi không chỉ là “có hỗ trợ tiếng Việt không?”. Người dùng còn cần biết nó chạy trên thiết bị nào, audio và văn bản được xử lý ở đâu, gói miễn phí có đủ không, và phải sửa bao nhiêu trước khi dùng được đầu ra.

Đó là kiểu quyết định mình muốn ToolTasted hỗ trợ. Một công cụ có nhiều tính năng hơn chưa chắc là lựa chọn phù hợp hơn cho việc đang làm.

Vì sao mình chọn xây một website nội dung?

Động lực chính của mình là học cách làm sản phẩm từ đầu đến khâu vận hành. Với ToolTasted, mình tự phụ trách toàn bộ dự án, từ định hướng, giao diện và hệ thống xuất bản đến nội dung.

Một website nội dung khiến mình phải quan tâm đến những việc dễ bị bỏ qua nếu chỉ tập trung vào phần mềm. Một trang có thể hiển thị đúng nhưng vẫn không giúp người đọc chọn được gì. Một bài viết có thể đầy đủ lúc xuất bản nhưng trở nên sai khi nhà cung cấp đổi giá hoặc giới hạn gói.

Mình chọn AI và SaaS vì đây là chủ đề gần với công việc xây dựng workflow và automation. Góc nhìn mình muốn mang vào bài viết là: công cụ này giải quyết được bước nào trong công việc, cần điều kiện gì để dùng, và phần việc nào vẫn còn lại cho người dùng?

ToolTasted cũng là nơi mình học cách phân phối nội dung. SEO và khả năng được tìm thấy qua công cụ tìm kiếm AI là những hướng mình muốn tìm hiểu trên một sản phẩm cụ thể. Có cấu trúc kỹ thuật hỗ trợ việc thu thập nội dung không đồng nghĩa website sẽ có thứ hạng hay được AI trích dẫn. Mình xem đó là nền tảng để thử và đo tiếp, không phải kết quả đã đạt được.

Khuyến nghị cần nói rõ dựa vào đâu

Tên ToolTasted gợi ý việc “nếm thử” công cụ trước khi đưa ra nhận xét. Nhưng cái tên không thể thay thế bằng chứng. Mình không muốn người đọc hiểu rằng mọi bài đều là kết quả sử dụng trực tiếp trong thời gian dài.

Các bài hiện tại trong loạt Wispr Flow chủ yếu phân tích tài liệu sản phẩm được dẫn nguồn. Ngày kiểm tra nguồn cho biết lúc mình đối chiếu thông tin, không phải ngày hoàn thành một thử nghiệm thực tế.

Trong phương pháp biên tập của ToolTasted, mình phân biệt:

• Thông tin nhà cung cấp công bố: tính năng, giá, thiết bị hỗ trợ và điều kiện sử dụng, kèm nguồn để người đọc kiểm tra.
• Nhận định biên tập: cách mình diễn giải các thông tin đó cho một tình huống cụ thể.
• Kết quả tự thử: cần có thiết lập, ngày thử, đầu vào, đầu ra và giới hạn của phép thử.

Nguyên tắc này còn xuất hiện trong hệ thống xuất bản: bài khai báo ngày tự thử phải có trường bằng chứng đi kèm. Kiểm tra đó không tự chứng minh nội dung là đúng, nhưng tạo một điểm nhắc để mình không đánh đồng việc đọc tài liệu với việc đã dùng sản phẩm.

Mình muốn giữ ranh giới ấy ngay cả khi nó khiến một bài viết có ít kết luận hơn. Nói rõ điều chưa biết hữu ích hơn đưa ra một bảng xếp hạng chưa có cơ sở.

Từ bài viết đến thứ người đọc có thể dùng

Mình muốn ToolTasted có những tài nguyên giúp người đọc tự kiểm tra lựa chọn của mình, thay vì chỉ đọc nhận xét rồi tin theo.

Repo hiện có bộ câu tiếng Việt và Anh–Việt, mẫu prompt, checklist, workflow n8n và script tổng hợp kết quả dictation. Chúng tạo điểm bắt đầu cho một tác vụ hoặc phép thử cụ thể.

Chẳng hạn, bộ chuẩn bị benchmark dictation hướng dẫn ghi lại việc giữ đúng ý nghĩa, thuật ngữ và thời gian chỉnh sửa. Nó chưa phải kết quả thử nghiệm giữa các công cụ. Script tổng hợp dữ liệu người dùng nhập vào, không tự nghe audio hoặc xác định công cụ nào tốt nhất.

Với mình, đó là một hướng phát triển đáng theo đuổi: mỗi bài không nhất thiết phải đưa ra một người thắng, nhưng nên giúp người đọc biết bước tiếp theo cần làm.

Phần kỹ thuật phục vụ việc xuất bản

Mình xây ToolTasted bằng Next.js, TypeScript và Tailwind CSS. Bài viết được lưu bằng MDX trong Git; cấu hình triển khai sử dụng Cloudflare Workers qua OpenNext.

Nội dung được biên dịch trước khi chạy trên Workers. Bước chuẩn bị nội dung kiểm tra metadata, ngày tháng, bài nháp và các phiên bản ngôn ngữ được xuất bản. Website cũng có canonical, sitemap và structured data để mô tả nội dung rõ hơn cho công cụ tìm kiếm.

Mình chọn quản lý bài viết trong Git thay vì thêm CMS ở giai đoạn này. Cách đó phù hợp với một người tự viết và phát triển website, đồng thời giữ lịch sử thay đổi cạnh code. Đổi lại, chỉnh sửa nội dung gắn với quy trình build và xuất bản; nếu có thêm người viết không làm kỹ thuật, mình sẽ cần xem lại lựa chọn này.

Mình muốn đưa ToolTasted đến đâu?

Trước mắt, mình muốn làm tốt nhóm nội dung đang có, thay vì mở rộng thành một danh mục công cụ quá lớn. Điều mình hướng tới là các bài có phạm vi rõ, nguồn còn đúng và tài nguyên thực hành có thể sử dụng.

Với người đọc, mục tiêu là giúp họ xác định công cụ đáng thử và những điều cần kiểm tra trước khi trả phí. Khi phát triển thêm nội dung tự thử, mình muốn công bố đủ điều kiện và dữ liệu để người khác hiểu được kết quả, thay vì chỉ đọc một điểm số.

Với bản thân, mình muốn học cách duy trì sản phẩm sau lúc ra mắt: quyết định nội dung nào cần cập nhật, lắng nghe phản hồi, theo dõi khả năng được tìm thấy và lựa chọn việc nên làm tiếp. Mình muốn đánh giá dự án bằng những điều đó, không chỉ bằng số trang đã xây.

Affiliate là một phần mô hình mình muốn thử để hỗ trợ việc duy trì website. Một số liên kết có thể mang lại hoa hồng khi người đọc đăng ký. Quan hệ thương mại cần được công bố rõ và không nên quyết định khuyến nghị. Hiện tại, mình không kể ToolTasted như một câu chuyện thành công về doanh thu; đây vẫn là quá trình học xây dựng và vận hành sản phẩm.

Nếu bạn đang phân vân giữa các công cụ giọng nói, có thể bắt đầu từ các hướng dẫn trên ToolTasted. Nếu một bài chưa trả lời được tình huống của bạn, hãy gửi mình tình huống cụ thể: bạn đang làm việc gì, dùng thiết bị nào và vướng ở đâu. Đó là phản hồi mình muốn dùng để quyết định nên viết hoặc cải thiện điều gì tiếp theo.