Xây dựng LoopSignal: Nền tảng quản lý Feedback tích hợp GitHub cho Indie Developer

Khi xây dựng một sản phẩm SaaS, phản hồi của người dùng thường nằm rải rác ở khắp mọi nơi, ngoại trừ nơi duy nhất mà chúng thực sự hữu ích.

Một số yêu cầu gửi qua email, số khác lại xuất hiện trong các cuộc trò chuyện hỗ trợ, vài ý kiện nằm trong GitHub Issues, và có những người dùng nhiệt tình gửi tin nhắn riêng (DM) dài dòng. Đến lúc lên lộ trình phát triển (roadmap), bạn mới nhận ra mình chủ yếu đang phán đoán.

Chính sự thất vọng này đã dẫn đến việc tôi xây dựng LoopSignal.

LoopSignal là một nền tảng phản hồi nhẹ nhàng dành cho các nhà phát triển độc lập (indie developers) và các nhóm nhỏ. Nó cung cấp cho mỗi sản phẩm một bảng công khai để người dùng gửi ý tưởng và bình chọn, một nhật ký thay đổi (changelog) công khai để hiển thị các tính năng đã ra mắt, một widget có thể nhúng vào ứng dụng, và tích hợp GitHub kết nối phản hồi trực tiếp với công việc phát triển.

Mục tiêu rất đơn giản:

1. Dễ dàng thu thập phản hồi.
2. Làm rõ mức độ ưu tiên.
3. Dễ dàng chứng minh với người dùng rằng phản hồi của họ có giá trị.

Phần cuối cùng chính là lý do cho cái tên này. Tôi không chỉ muốn một bảng yêu cầu tính năng, tôi muốn một công cụ có thể "đóng vòng tròn" (close the loop).

Vấn đề tôi muốn giải quyết

Hầu hết các công cụ phản hồi tôi xem đều rơi vào một trong hai nhóm:

• Chúng mạnh mẽ, bóng bẩy và được định giá cho các nhóm sản phẩm lớn.
• Chúng đơn giản, nhưng quá hạn chế hoặc quá tách biệt với quy trình làm việc của nhà phát triển.

Đối với các indie hackers và nhóm SaaS nhỏ, điều này tạo ra một khoảng trống khá khó xử. Bạn không cần một bộ sản phẩm doanh nghiệp chỉ để trả lời những câu hỏi như: Người dùng yêu cầu tính năng gì nhiều nhất? Tôi nên xây dựng tiếp theo cái gì? Làm sao để thông báo cho người dùng biết yêu cầu của họ đã được hoàn thành?

Bạn cần một hệ thống nhỏ gọn, nhanh chóng và có định hướng đúng đắn.

LoopSignal hoạt động như thế nào

Ở mức độ cao, mỗi dự án trong LoopSignal có quy trình phản hồi công khai riêng. Dưới đây là những tính năng chính:

• Bảng phản hồi công khai: Người dùng có thể gửi yêu cầu tính năng và bình chọn cho các yêu cầu hiện có.
• Tham gia ẩn danh: Người dùng cuối không cần tạo tài khoản để để lại phản hồi.
• Trạng thái quy trình làm việc: Mở (Open), Đã lên kế hoạch (Planned), Đang thực hiện (In Progress), Hoàn thành (Completed) và Đã đóng (Closed).
• Kiểm duyệt và chống spam: Giữ cho bảng luôn sạch sẽ.
• Tích hợp GitHub: Tạo Issues từ các phản hồi đã được duyệt.
• Đồng bộ Webhook GitHub: Khi đóng một Issue, yêu cầu phản hồi liên quan sẽ được đánh dấu là hoàn thành.
• Trang Changelog công khai: Được tạo từ các công việc đã hoàn thành.
• Widget nhúng: Hoạt động chỉ với một thẻ script.

Quy trình quan trọng nhất mà tôi hướng tới trông như sau:

1. Người dùng gửi phản hồi từ bảng công khai hoặc widget trong ứng dụng.
2. Những người dùng khác bình chọn cho ý tưởng đó.
3. Nhóm xem xét và phê duyệt nó.
4. LoopSignal tự động tạo GitHub Issue.
5. Issue được xử lý trong quy trình phát triển bình thường.
6. Khi Issue được đóng, mục phản hồi chuyển sang hoàn thành và hiển thị trên changelog công khai.

Đó là toàn bộ sản phẩm gói gọn trong một vòng tròn khép kín.

Tại sao tôi xây dựng hướng tới Nhà phát triển trước

Nhiều công cụ phản hồi được xây dựng như một phần mềm quản lý sản phẩm. Điều này hợp lý với các tổ chức lớn, nhưng lại tạo ra ma sát cho các nhóm nhỏ.

Các nhóm nhỏ không muốn một hệ thống cồng kềnh khác để bảo trì. Họ muốn thứ gì đó phù hợp với các công cụ họ đã đang sử dụng. Đó là lý do LoopSignal được thiết kế thân thiện với nhà phát triển:

• GitHub là một phần nhất quán trong quy trình làm việc.
• Widget chỉ là một thẻ script đơn giản.
• Sản phẩm cung cấp các điểm cuối API cơ bản.
• Bảng công khai đủ đơn giản để người dùng có thể bắt đầu đóng góp ngay lập tức.

Stack công nghệ đằng sau nó

Tôi xây dựng LoopSignal với một stack rất phù hợp cho các sản phẩm SaaS do chủ sở hữu tự vận hành:

• Next.js 15 cho ứng dụng, định tuyến, kết xuất phía máy chủ và server actions.
• React 19 cho lớp giao diện người dùng (UI).
• Supabase cho cơ sở dữ liệu Postgres, xác thực (auth) và quyền truy cập cơ sở dữ liệu.
• Cloudflare Workers để triển khai thông qua OpenNext.
• Paddle cho thanh toán.
• Resend cho email giao dịch.
• Tailwind CSS + shadcn/ui cho giao diện.

Stack này mang lại sự cân bằng tốt: vòng lặp lặp lại nhanh, cơ sở mã TypeScript duy nhất, không cần dịch vụ backend riêng để bảo trì.

Cách quy trình sản phẩm cốt lõi hoạt động

1. Gửi công khai mà không cần rào cản tài khoản

Một trong những cách dễ nhất để giết chết lượng phản hồi là yêu cầu người dùng tạo tài khoản trước khi gửi ý tưởng. LoopSignal tránh điều này bằng cách cho phép người dùng gửi phản hồi từ bảng công khai hoặc widget nhúng mà chỉ cần email tùy chọn nếu họ muốn nhận cập nhật.

Quy trình gửi sẽ thực hiện một số việc trước khi bài đăng được tạo:

• Xác thực tiêu đề và mô tả.
• Giới hạn tốc độ gửi (rate-limit).
• Chạy qua một quy trình chấm điểm spam đơn giản.
• Lưu bài đăng dưới trạng thái pending để kiểm duyệt.

Đây là đoạn code chính của server action đó:

const spam = checkSpam({ title, description, email, ip });
if (spam.isSpam) {
  await logSpam(ip, "spam_detected", spam.signals, spam.score, {
    title,
    description,
    email,
  });
  return { error: "Your submission was flagged." };
}

const { data: newPost } = await admin
  .from("posts")
  .insert({
    project_id: projectId,
    title,
    description,
    category,
    email: email || user?.email || null,
    ip,
    spam_score: spam.score,
    moderation_status: "pending",
    workflow_status: "open",
  })
  .select("id")
  .single();

2. Bình chọn để xác định mức độ ưu tiên

Khi một bài đăng được duyệt, nó xuất hiện trên bảng công khai nơi người dùng có thể bình chọn. Điều này quan trọng vì phản hồi thô thường rất ồn ào. Bình chọn chuyển các yêu cầu riêng lẻ thành nhu cầu có thể nhìn thấy được.

3. Tự động tạo GitHub Issue khi phê duyệt

Quyết định sản phẩm quan trọng nhất của tôi là kết nối phản hồi đã duyệt trực tiếp với GitHub. Khi một yêu cầu được phê duyệt, LoopSignal có thể tự động tạo GitHub Issue cho kho chứa được chọn. Phần thân của Issue bao gồm mô tả phản hồi và được gắn nhãn feedback.

Logic tạo Issue cốt lõi:

const body = [
  description || "",
  "",
  "---",
  "*Created from LoopSignal feedback*",
].join("\n");

await fetch(`https://api.github.com/repos/${owner}/${repo}/issues`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${githubToken}`,
    Accept: "application/vnd.github+json",
    "Content-Type": "application/json",
    "User-Agent": "LoopSignal",
  },
  body: JSON.stringify({ title, body, labels }),
});

4. Đóng vòng tròn với GitHub Webhooks

Tạo Issue chỉ là một nửa câu chuyện. Phần thú vị hơn là đồng bộ ngược. Khi một GitHub Issue được đóng, LoopSignal sẽ tra cứu bài đăng liên quan và cập nhật trạng thái quy trình thành completed. Nếu Issue được mở lại, bài đăng sẽ chuyển lại về open.

if (action === "closed") {
  workflowStatus = "completed";
} else if (action === "reopened") {
  workflowStatus = "open";
}

Điều này loại bỏ một bước thủ công. Các nhóm không cần phải nhớ cập nhật bảng phản hồi sau khi phát hành xong.

5. Widget nhúng với một thẻ script

Tôi cũng muốn sản phẩm hoạt động bên trong các ứng dụng hiện có mà không cần tích hợp sâu. Điều này dẫn đến một đoạn script nhúng đơn giản:

<script
  src="https://loopsignal.dev/embed.js"
  data-slug="your-project"
  defer
></script>

Điều quan trọng không phải là sự phức tạp về mặt kỹ thuật, mà là tốc độ thiết lập. Nếu ai đó có thể dán một script và bắt đầu thu thập phản hồi trong hai phút, họ có nhiều khả năng sẽ thực sự sử dụng tính năng đó.

Những khó khăn khi xây dựng

Không có bản dựng SaaS nào hoàn hảo mà không có một vài góc cạnh khó chịu.

1. Triển khai trên Cloudflare Workers: Chạy Next.js 15 trên Cloudflare Workers là khả thi nhưng không hoàn toàn suôn sẻ. OpenNext giúp đỡ rất nhiều, nhưng bạn vẫn phải cân nhắc kỹ về các giả định môi trường và các API Node còn thiếu.
2. Quyền hạn trở nên phức tạp nhanh chóng: Ngay khi sản phẩm hỗ trợ chủ sở hữu dự án, quản trị viên, thành viên, người dùng công khai và khách hàng API, mô hình quyền hạn của bạn sẽ trở nên rất phức tạp.
3. Logic thanh toán chạm vào nhiều phần của ứng dụng: Thanh toán ban đầu trông có vẻ tách biệt, nhưng cuối cùng lại ảnh hưởng đến hành vi sản phẩm: giới hạn dự án, giới hạn thành viên, phân tích chỉ số cao cấp...

Bài học rút ra

Bài học lớn nhất là phạm vi sản phẩm quan trọng hơn số lượng tính năng.

Rất dễ dàng để tiếp tục thêm các ý tưởng "tốt để có", nhưng sản phẩm sẽ mạnh mẽ hơn khi vòng lặp cốt lõi vẫn rõ ràng: thu thập phản hồi -> xác thực nhu cầu -> đồng bộ với phát triển -> hiển thị những gì đã ra mắt.

Mọi thứ trong LoopSignal đều ở đó để hỗ trợ vòng lặp đó.

Bài học lớn thứ hai là các sản phẩm phản hồi sống hay chết dựa trên ma sát. Nếu người dùng phải thực hiện quá nhiều bước để gửi phản hồi, họ sẽ không làm. Nếu không ai thấy những gì đã được chuyển giao, hệ thống sẽ không xây dựng được niềm tin.

Nếu bạn muốn xem thử, sản phẩm đang hoạt động tại loopsignal.dev.