Chỉ cần 3 ngày và 400 đô la, hướng dẫn từng bước để xây dựng một nền tảng Launchpad

Tiêu đề gốc: Tôi đã xây dựng một Launchpad trong 3 ngày với 400 đô la (và bạn cũng có thể làm được)
Tác giả gốc: ultra

Biên dịch: Luffy, Foresight News

Cuối tuần trước, tôi đã làm thêm giờ để hoàn thành dự án Blind, chỉ để chứng minh rằng: xây dựng một sản phẩm có ý nghĩa không cần phải huy động hàng triệu đô la, không cần hàng tháng trời làm việc, thậm chí không cần một đội ngũ.

Blind là một nền tảng phát hành token được phát triển trên chuỗi Base, vận hành dựa trên hạ tầng của Flaunch. Nó thử nghiệm một cơ chế hoàn toàn mới: cho phép người tạo token tự chọn công khai những thông tin cá nhân nào khi phát hành token.

Như vậy, người tạo vừa có thể tận dụng danh tiếng hoặc năng lực của mình để bảo chứng, vừa không cần hoàn toàn công khai danh tính thật, cũng không phải chịu những rắc rối thường gặp khi trở thành “người đại diện token”. Ngoài ra, người tạo còn có thể thiết lập điều kiện tham gia, chỉ cho phép người dùng đáp ứng tiêu chí tối thiểu tham gia.

Mục đích bài viết

Bài viết này nhằm chia sẻ khung tư duy chung từ “ý tưởng” đến “sản phẩm” của tôi.

Như tôi thường nói, 6-12 tháng hiện tại là “thời kỳ vàng để hiện thực hóa ý tưởng”, nhờ các công cụ AI, việc biến ý tưởng thành hiện thực trở nên cực kỳ dễ dàng, nhưng rất ít người nhận ra điều này. Đối với những ai sẵn sàng đầu tư thời gian, đây chắc chắn là cơ hội arbitrage lớn.

Tôi hy vọng bài viết này sẽ truyền cảm hứng cho nhiều người thử vibecoding, biến ý tưởng của mình thành hiện thực, đưa Web3 trở lại thời kỳ do các lập trình viên độc lập và nhóm nhỏ dẫn dắt, nơi mỗi ngày đều có đổi mới ra đời.

Bài viết mặc định độc giả đã có nền tảng kỹ thuật nhất định, quen thuộc với công cụ phát triển, quản lý kho mã nguồn và các kiến thức về thành phần phổ biến.

Giai đoạn 0: Nguồn cảm hứng

Ý tưởng kiểm soát truy cập bằng vốn xã hội thực ra đã ấp ủ trong đầu tôi vài tháng. Trong quá trình sử dụng thường xuyên các công cụ như Kaito, Ethos, fantasy.top, time.fun và nghiên cứu các chỉ số SocialFi, một vấn đề lặp đi lặp lại trong các cuộc thảo luận: Tại sao không ai làm một dashboard tổng hợp hồ sơ người dùng trên tất cả các nền tảng này, dùng điểm số và dữ liệu để đánh giá năng lực người dùng?

Khoảng 6 tháng trở lại đây, lĩnh vực “chỉ số người tạo” phát triển nhanh chóng, giờ đây mọi người có thể đánh giá giá trị của một người hoặc một tài khoản qua nhiều chiều dữ liệu khác nhau.

Vậy, liệu có thể dùng các chỉ số này để thiết lập “điều kiện tham gia” (ví dụ điều kiện phát hành token)? Và liệu có thể để người tạo tự quyết định công khai chỉ số nào, đồng thời ẩn danh tính thật?

Điều thực sự thúc đẩy tôi bắt tay vào làm là khi thấy Pump.fun huy động được 500 millions đô la, gần đây heaven cũng gọi vốn tới 20 millions đô la. Theo tôi, hai sản phẩm này không quá khó phát triển, vậy tại sao định giá lại cao đến vậy? Và còn nhiều nền tảng phát hành thành công khác cũng huy động được số vốn khổng lồ.

Công bằng mà nói, trong lĩnh vực này, để giữ lý trí, chúng ta thực ra không còn bận tâm tới “logic định giá token”; nhiều khi, bản thân định giá đã vô lý rồi.

Nhưng dù sao, điều này đã tạo cho tôi một thử thách cá nhân: Liệu tôi có thể trong một cuối tuần, với chi phí cực thấp, không cần sự trợ giúp bên ngoài, làm ra một sản phẩm ngang tầm?

Mục tiêu của tôi không phải xây dựng sản phẩm thương mại, phát hành token, thậm chí không phải kiếm tiền, mà là chứng minh “việc này hoàn toàn làm được”, và hy vọng nhiều người sẽ đi theo con đường này.

Giai đoạn 1: Phân tích vấn đề

Có ý tưởng rồi, bước đầu tiên là phân tách nó thành các thành phần cốt lõi và ra quyết định cho từng thành phần. Đối với “nền tảng phát hành có kiểm soát truy cập xã hội”, tôi đã xác định các vấn đề con sau:

Lựa chọn công nghệ chuỗi

Quyết định đầu tiên là “triển khai trên chuỗi nào”, lựa chọn này sẽ ảnh hưởng đến tất cả các bước tiếp theo. Khi đó có hai lựa chọn rõ ràng: Solana và Base.

Solana

Ưu điểm:

· Chuỗi có khối lượng giao dịch meme coin lớn nhất;

· Hiệu ứng spotlight: bất kỳ dự án nào triển khai ở đây đều dễ thu hút sự chú ý nhất định.

Nhược điểm:

· Tính linh hoạt thấp, phải tuân thủ tiêu chuẩn token hiện có;

· Độ phức tạp phát triển cao, cần nhiều giải pháp linh hoạt;

· Chu kỳ phát triển dài;

· Chi phí hạ tầng cao và không ổn định.

Base

Ưu điểm:

· Trong các chuỗi EVM, Base có khối lượng giao dịch meme coin lớn nhất;

· Hỗ trợ tốt cho nhà phát triển;

· Trải nghiệm phát triển EVM tuyệt vời;

· Có thể tận dụng trực tiếp hạ tầng hiện có.

Nhược điểm:

· Khối lượng giao dịch meme coin không bằng Solana.

Vì Blind không phải dự án thương mại, chỉ là sản phẩm luyện tay cuối tuần, chúng tôi không cần cân nhắc “lợi nhuận tài chính tiềm năng”, chỉ cần chọn phương án “không làm đau đầu khi phát triển”. Cuối cùng chúng tôi chọn EVM. Khi phát triển ứng dụng blockchain, EVM là hạ tầng trưởng thành và tốt nhất, giúp phát triển nhanh, hiệu quả và thông minh.

Tận dụng hạ tầng hiện có

Sau khi xác định chuỗi, bước tiếp theo là tìm SDK (bộ công cụ phát triển phần mềm) hoặc hợp đồng thông minh có sẵn để tránh viết lại từ đầu. Đặc biệt với hợp đồng thông minh, ưu tiên dùng hợp đồng đã được audit để giảm rủi ro bảo mật.

May mắn thay, hệ sinh thái EVM có rất nhiều tài nguyên tái sử dụng, chúng tôi có hai lựa chọn chính:

·Phát triển dựa trên các DEX như Uniswap, tự xây dựng logic kiểm soát truy cập trên nền tảng Uniswap V4;

· Phát triển dựa trên hạ tầng của nền tảng phát hành hiện có (như SDK của Flaunch), SDK này đã tích hợp sẵn các chức năng như index, upload metadata, cấu hình đường cong phát hành, quản lý giai đoạn, v.v.

Một lần nữa, chúng tôi chọn “con đường ít cản trở nhất”: phát triển dựa trên Flaunch. Như vậy, chúng tôi có thể tập trung vào “tính xã hội của nền tảng phát hành + giao diện frontend”, không phải tốn thời gian và tiền bạc cho các chức năng cơ bản như cấu hình pool, hạ tầng index, hợp đồng chia sẻ lợi nhuận, v.v.

“Nếu những người thông minh hơn bạn đã làm xong việc, tại sao phải phát minh lại bánh xe?”

Cách triển khai token

Sau khi xác định SDK, cần quyết định “ai sẽ thực hiện việc triển khai token”, có hai phương án:

Phương án 1: Người dùng tự gửi giao dịch triển khai token

· Cần phát triển hợp đồng proxy, đảm bảo các tham số phát hành do người dùng chọn đáp ứng yêu cầu nền tảng;

· Cần tìm cách theo dõi tất cả token đã triển khai trong subgraph indexer hiện có của Flaunch.

Phương án 2: Người dùng gửi “yêu cầu triển khai” lên backend, bot của nền tảng thực hiện triển khai

· Tất cả token đều do EOA (tài khoản sở hữu bên ngoài) của nền tảng triển khai, thuận tiện theo dõi tất cả token do nền tảng phát hành trong indexer;

· Đảm bảo mọi phát hành đều tuân thủ tham số chuẩn hóa thống nhất.

Chúng tôi chọn phương án “triển khai qua backend”: giúp việc theo dõi token đơn giản hơn, kiểm soát chặt chẽ hơn “nội dung và cách triển khai”, đồng thời có thể nâng cấp trong tương lai.

Tất cả token sẽ được triển khai bởi ví do backend kiểm soát.

Bản chất, chúng tôi “tối giản hóa SDK của Flaunch”, loại bỏ mọi chức năng không cần thiết, chỉ giữ lại phần backend có thể gọi.

Thu thập dữ liệu xã hội

Tiếp theo tập trung vào chức năng xã hội. Chúng tôi cần xác định những chiều dữ liệu nào có giá trị cho nền tảng phát hành. Bộ dữ liệu lý tưởng nên thể hiện đồng thời “trạng thái tài khoản người dùng” và “danh tiếng người dùng”.

Cuối cùng tôi chọn các chiều dữ liệu sau:

· Số lượng follower (API X)

· Số lượng following (API X)

· Thời gian đăng ký tài khoản (API X)

· Số lượt like (API X)

· Số follower giá trị cao (Moni API)

· Số người tương tác cốt lõi (Moni API)

· Điểm danh tiếng (Ethos API)

· Điểm lan tỏa nội dung (Kaito API)

Bộ dữ liệu này giúp người tạo chứng minh năng lực qua nhiều chiều dữ liệu mà không cần công khai hoàn toàn danh tính, nổi bật giữa đám đông.

Xử lý dữ liệu xã hội và bảo vệ quyền riêng tư

Khi người dùng đăng ký, chúng tôi sẽ thu thập tất cả dữ liệu trên, nhưng về quyền riêng tư thì thiết kế thế nào?

Nguyên tắc của chúng tôi là “ưu tiên riêng tư mặc định”: tất cả dữ liệu mặc định không công khai, tránh rò rỉ; người dùng có thể tự quyết định từng chiều dữ liệu có công khai hay không. Ngoài ra, nên cho phép người dùng “làm mờ dữ liệu” (ví dụ thực tế có 43.000 follower, có thể chọn hiển thị “40.000+”), cung cấp tham chiếu dữ liệu bán ẩn danh.

Thêm nữa, xử lý dữ liệu nên dựa vào “backend tập trung + yêu cầu HTTPS”, hay dùng công nghệ zero-knowledge proof phức tạp?

Phương án của chúng tôi là kết hợp cả hai:

· Tất cả dữ liệu lưu trong cơ sở dữ liệu Postgres, frontend truy xuất thông tin qua API HTTPS trực tiếp từ database. Kiểm soát truy cập thực hiện theo quy trình sau:

· Người dùng muốn tham gia → gửi yêu cầu “chứng nhận truy cập” lên backend;

· Backend xác thực người dùng có đáp ứng điều kiện do người tạo đặt ra hay không;

· Backend trả về thông điệp đã ký chứa “địa chỉ ví người dùng + timestamp hết hạn”;

· Hợp đồng thông minh xác thực tính hợp lệ của chữ ký.

Giai đoạn 2: Triển khai phát triển

Trước khi bắt đầu phát triển, hãy liệt kê “danh sách công cụ” cần thiết:

· Railway (lưu trữ backend): 20 đô la/tháng

· Vercel (lưu trữ frontend): 15 đô la/tháng

· Cursor (công cụ phát triển, bao gồm chế độ Claude 4 MAX): 200 đô la/tháng + 100 đô la credits

· Tên miền website: 30 đô la/năm

· X Premium+ (tài khoản thành viên, để tăng độ hiển thị + đăng bài dài): 40 đô la/tháng

· ChatGPT: dùng để thiết kế Logo + nhận diện thương hiệu, có thể thay bằng công cụ quen thuộc khác

· Tổng chi phí khoảng 405 đô la (giả sử Vercel không vượt hạn mức đăng ký).

Lưu ý: Để tăng tốc phát triển, tôi thực tế đã dùng nhiều credits Cursor hơn dự kiến (bật mô hình MAX). Nếu không cần tốc độ phát triển nhanh, có thể chọn mô hình rẻ hơn.

Thiết kế kiến trúc

Hầu hết các dự án đều cần 4 thành phần cốt lõi:

· Frontend: lưu trữ trên Vercel (repo GitHub riêng);

· Backend: lưu trữ trên Railway (repo GitHub riêng);

· Cơ sở dữ liệu lưu trữ: database Postgres trên Railway;

· Cơ sở dữ liệu cache: Redis trên Railway.

Nói đơn giản, Vercel chịu trách nhiệm mọi chức năng frontend; Railway lưu trữ an toàn các dịch vụ cốt lõi “người dùng không nhìn thấy” như xử lý dữ liệu, triển khai token, API, cache thông tin, v.v.

Kiến trúc backend của đa số dự án đều như hình dưới (đúng vậy, dữ liệu nằm trong “quả bóng”).

Thứ tự phát triển

Tôi luôn khuyên nên phát triển chức năng cốt lõi trước, cuối cùng mới làm giao diện frontend.

Với dự án này, chức năng cốt lõi nhất (cũng là chức năng cần kiểm tra tương thích trước) là phát hành token.

Vì chúng tôi đã xác định “triển khai token bằng EOA backend”, nên có thể tạo một repo git mới cho backend và bắt đầu nghiên cứu tài liệu SDK của Flaunch.

Tài liệu này tổng hợp tất cả chức năng cấu hình hiện có, thậm chí cung cấp một số đoạn mã dễ tích hợp. Họ còn cung cấp một số endpoint API để truy xuất dữ liệu, cùng một subgraph tự động index mọi hoạt động trên Flaunch (bao gồm token khởi tạo từ frontend của Blind).

1) Kiểm tra chức năng phát hành token

Trong repo backend mới, bước đầu là dựng môi trường local, kiểm tra có thể phát hành token thành công qua SDK không. Có thể viết một script Node đơn giản, sau này chuyển thành endpoint server Express, gọi endpoint này và truyền tham số là triển khai token xong.

Bước này thực ra rất đơn giản, khả năng cao chỉ cần một prompt + chút debug là xong.

Hơn nữa, phí gas triển khai token chưa đến 0,01 đô la! Điều này nghĩa là chúng tôi có thể cung cấp dịch vụ triển khai token hoàn toàn miễn phí cho người dùng.

2) Lấy dữ liệu xã hội

Bước thứ hai là phát triển chức năng cốt lõi khác: chấm điểm xã hội. Với tất cả chiều dữ liệu đã chọn trước đó, chúng tôi cần xem tài liệu của từng API, sau đó tạo một endpoint trên server Express, endpoint này trả về tất cả dữ liệu dựa trên username. Sau đó, có thể lưu dữ liệu này vào database Postgres trên Railway.

3) Quy trình đăng ký

Đến bước này, phát triển sẽ phức tạp hơn một chút, cần đồng thời phát triển repo frontend. Chúng tôi chọn Next.js làm framework frontend, vì nó hỗ trợ tốt nhất cho Vercel và hỗ trợ middleware xác thực danh tính.

Trong quy trình đăng ký, chúng tôi muốn người dùng liên kết ví trước, sau đó xác thực qua X, cuối cùng gọi endpoint của chúng tôi để đăng ký.

Đầu tiên, chúng tôi xem tài liệu API xác thực X, triển khai một trang đăng ký đơn giản trên frontend, đồng thời tạo endpoint đăng ký trên repo backend.

Trong quá trình đăng ký, chúng tôi cũng cần lấy tất cả dữ liệu ở bước 2) và lưu vào database, đồng thời thêm một trường địa chỉ ví. Mọi request gửi tới endpoint đăng ký đều phải xác thực khóa X và chữ ký ví để ngăn giả mạo danh tính.

Sau khi mọi thứ ổn, chúng tôi cần thêm xác thực cho endpoint triển khai token, để chỉ người dùng đã đăng ký mới được triển khai token. Với các endpoint ngoài đăng ký, chúng tôi quyết định chỉ xác thực bằng chữ ký ví để tránh phải đăng nhập X mỗi lần.

4) Cài đặt quyền riêng tư

Sau khi hoàn thành quy trình đăng ký và lưu trữ dữ liệu, bước tiếp theo là phát triển cài đặt quyền riêng tư:

· Tạo bảng cài đặt hiển thị dữ liệu trong database (mặc định tất cả dữ liệu là riêng tư);

· Phát triển endpoint chỉnh sửa cài đặt quyền riêng tư cho người dùng đã xác thực;

· Viết hàm hỗ trợ người dùng chọn làm mờ dữ liệu khi hiển thị;

· Phát triển component frontend chỉnh sửa quyền riêng tư.

5) Kiểm tra và tối ưu endpoint

Sau khi dịch vụ cốt lõi đã sẵn sàng, cần tối ưu như sau:

Tất cả chức năng cốt lõi của server đã sẵn sàng, giờ cần đảm bảo mọi endpoint đều xác thực khi cần, và không rò rỉ thông tin cá nhân khi truy cập công khai. Có thể dùng Redis cache để tối ưu một số API, tránh server bị quá tải. Cuối cùng, thêm một số API để lấy hồ sơ công khai người dùng, chủ sở hữu token và dữ liệu của họ, dữ liệu coin, v.v.

6) Phát triển frontend

Giờ là lúc tạo một website đẹp mắt. Đầu tiên xác định chủ đề, các trang cần hiển thị, rồi loại bỏ phần “riêng tư”. Để hiển thị danh sách token sắp xếp tùy chỉnh và dữ liệu khác, có thể dựa vào subgraph của Flaunch, lọc theo địa chỉ deployer là EOA của chúng tôi. Với trang chi tiết token, cách nhanh nhất để hiển thị biểu đồ là nhúng một iframe DexScreener đơn giản.

7) Kiểm thử

Mọi thứ cuối cùng đã sẵn sàng. Kiểm thử quy trình người dùng, triển khai toàn bộ lên Vercel và Railway, chia sẻ quyền truy cập cho bạn bè để lấy phản hồi. Mục tiêu là tạo môi trường giống hệt production 1:1.

8) Tối ưu dựa trên phản hồi

Đây là bước cuối cùng trước khi ra mắt.

Giai đoạn 3: Ra mắt công khai

Ra mắt công khai gồm hai bước: xây dựng thương hiệu trước, sau đó quảng bá thị trường.

Xây dựng thương hiệu

Trước đó tôi chưa đề cập xây dựng thương hiệu, vì nó có thể làm bất cứ lúc nào, nhưng tốt nhất nên hoàn thành trước khi phát triển frontend. Các yếu tố cốt lõi của thương hiệu (tên, logo, phối màu, tên miền) cần đảm bảo “đơn giản, dễ nhận diện”.

Một kiểu đặt tên tôi rất thích là “tên một từ + chơi chữ với tên miền”:

· Tên dự án chọn “Blind” (nghĩa là “mua mù”, ám chỉ người dùng mua token khi thông tin hạn chế);

· Phối màu cố ý chọn chế độ sáng chói mắt, kết hợp phong cách thiết kế “dã thú”, gợi liên tưởng đến tài liệu chữ nổi, phù hợp chủ đề “Blind”;

· Thiết kế logo: dùng ChatGPT tạo (dựa trên chủ đề hiện có);

Quảng bá thị trường

Đã đến lúc cho cả thế giới biết về MVP (sản phẩm khả thi tối thiểu) của chúng ta! Thông thường, cách tốt nhất để người khác biết không phải là nói thẳng, mà là tạo sự tò mò.

Marketing gây tò mò

Trước khi quảng bá chính thức, nên đảm bảo MVP đã hoàn thiện chức năng. Tốt nhất bắt đầu marketing trước khi ra mắt một tuần, như vậy sẽ tập trung sự chú ý của công chúng trong một tuần, dễ lên top trending trên mạng xã hội.

Mục tiêu cốt lõi của tuần này là:

· Thu hút nhiều người theo dõi tài khoản X của dự án và bật thông báo;

· Đăng các teaser mơ hồ, nội dung chơi chữ, tuyệt đối không tiết lộ chức năng dự án;

· Để lại “manh mối”, để cộng đồng tự đoán trong phần bình luận, để họ tạo nhiệt thay bạn.

Chỉ số ảo: Để người dùng không đơn độc

Kết hợp với “marketing gây tò mò”, công cụ hiệu quả là “bảng xếp hạng”! Mọi người vừa muốn “đi trước”, vừa không muốn “vào quá sớm”. Nhiệm vụ của bạn là “làm cho nền tảng sống trước khi ra mắt”.

Hoạt động “đăng ký + bảng xếp hạng” có các lợi ích sau:

· Hướng dẫn người dùng đăng ký sớm, phân tán lưu lượng, kiểm tra độ ổn định hệ thống;

· Khiến người dùng liên tục chú ý dự án: “Đăng ký sớm có thưởng không?” rồi bật thông báo tài khoản;

· Mọi người thích cảm giác “hơn người khác”: thứ hạng dễ chia sẻ, còn giúp người dùng khám phá dữ liệu thú vị về tài khoản của mình;

· Dễ dàng cho đội ngũ truyền thông “số liệu tăng trưởng”.

Trước khi Blind ra mắt, số người đăng ký trước đã vượt 40.000!

Lưu ý: Nếu thêm cơ chế “link mời”, tốc độ tăng trưởng sẽ còn nhanh hơn.

Teaser đếm ngược 24 giờ

Đã đến lúc tiết lộ chức năng cốt lõi của Blind! Khi đăng bài, hãy cho họ biết để họ có thời gian mong đợi cụ thể. 24 giờ cuối cùng, khóa lại mọi dự đoán về Blind. 24 giờ để mọi múi giờ đều chuẩn bị kịp.

Đăng bài ra mắt

Lúc này người dùng đều đang F5 trang chủ tài khoản X của bạn, đã đến lúc đăng bài! Trong bài cần nêu rõ:

· Chức năng cốt lõi của Blind;

· Thời gian ra mắt chính thức;

· Không cần quá kỹ thuật, cũng không cần liệt kê mọi chức năng, tập trung truyền tải “động lực phát triển”, “ý tưởng cốt lõi” và “sức hút dự án”;

Nếu cần bổ sung chi tiết kỹ thuật, có thể cung cấp tài liệu riêng ngoài bài viết.

Giai đoạn 4: Chính thức ra mắt!

Trong bài cần nêu rõ “thời gian ra mắt là 24 giờ sau khi đăng bài”. Lúc này người dùng đăng ký trước đã sẵn sàng, chỉ chờ triển khai token. Tiếp theo, chúng ta cần:

· Chuyển tất cả môi trường sang chế độ production;

· Chuyển tài khoản EOA deployer;

· Luôn sẵn sàng xử lý lỗi có thể phát sinh khi ra mắt (lỗi luôn xảy ra).

Được rồi, chính thức ra mắt!

Tổng kết

Khi phát triển MVP, luôn chọn “con đường ít cản trở nhất”. Không cần hoàn hảo ngay từ đầu, có thể dần dần tối ưu trong môi trường production. Nắm bắt thời cơ thường quan trọng hơn “đợi mọi thứ sẵn sàng”.

Nhưng cũng cần lưu ý: ấn tượng đầu tiên cực kỳ quan trọng. Trải nghiệm lần đầu của người dùng sẽ quyết định nhận thức lâu dài của họ về nền tảng, đừng mong đa số người dùng sẽ liên tục theo dõi “cập nhật chức năng”.

Dự án phụ này rất thú vị, tôi đã học được nhiều điều, cũng làm ra một công cụ “có thể sẽ được dùng để phát hành token”.