Last weekend, I worked overtime to create the Blind project, just to prove that you don’t need millions of dollars in financing, months of work, or even a team to build a meaningful product.
Blind is a token issuance platform (Launchpad) developed on the Base chain and running on the Flaunch infrastructure. It experiments with a novel mechanism: allowing token creators to choose which personal information to disclose when issuing tokens.
This allows creators to leverage their reputation or credentials without having to fully disclose their true identity or the hassles that typically come with being a “token spokesperson.” Furthermore, creators can set pre-sale entry thresholds, allowing only users who meet the minimum requirements to participate.
Purpose of this article
This article aims to share my general framework from "idea" to "product".
As I often say, the current 6-12 months are the "golden era for idea execution." AI tools make it incredibly easy to bring creative ideas to life, yet few people realize this. For those willing to invest the time, this presents a massive arbitrage opportunity.
I hope this article inspires more people to try vibecoding, turn their ideas into reality, and return Web3 to a field dominated by independent developers and small teams, where innovation is born every day.
This article assumes that readers have a certain technical foundation and are familiar with development tools, code repository management, and common components.
Phase 0: Source of Inspiration
The idea of social capital gating has been brewing in my mind for months. While frequently using tools like Kaito, Ethos, fantasy.top, and time.fun, and researching SocialFi metrics, a question kept coming up in discussions: Why hasn't anyone created a dashboard that consolidates a user's profile across all of these platforms, using scores and data to assess user qualifications?
In the past six months or so, the field of "creator indicators" has rapidly emerged, and people can now evaluate the value of a person or an account through various data dimensions.
So, can these metrics be used to set “participation thresholds” (such as entry requirements for token issuance)? Or can creators be allowed to independently decide which metrics to disclose to the public while keeping their true identities hidden?
What really motivated me to start developing was seeing Pump.fun's ICO raise $500 million, and Heaven's recent ICO also raised $20 million. In my opinion, the development difficulty of both products wasn't high, so why were the valuations so inflated? And there are many similarly successful launch platforms that have raised huge amounts of capital.
To be fair, in this space, in order to maintain rationality, we have actually stopped worrying about the "logic of token valuation"; many times, the valuation itself makes no sense.
Regardless, this sparked a personal challenge for me: could I create a comparable product in a weekend, at a fraction of the cost and with no outside help?
My goal is not to build a commercial product, issue tokens, or even make money, but to prove that "this thing can be done" and hope that more people will follow this path.
Phase 1: Problem Breakdown
Once I had an idea, the first step was to break it down into its core components and make decisions for each. For the "distribution platform with social access control," I identified the following sub-questions:
On-chain technology stack selection
The first decision was “which chain to deploy on”, a choice that would impact all subsequent implementation steps. There were two clear options: Solana and Base.
Solana
Advantages:
The chain with the highest On-Chain meme transaction volume;
Spotlight effect: Any project deployed here is likely to receive a certain amount of attention.
Disadvantages:
Low implementation flexibility, requiring adherence to existing token standards;
High development complexity, requiring numerous workarounds;
Long development cycle;
· Infrastructure costs are high and unstable.
Base
Advantages:
On-Chain meme has the highest transaction volume among EVM chains.
Improve support for developers;
· EVM development experience is excellent;
Existing infrastructure can be directly reused.
Disadvantages:
On-Chain meme’s transaction volume is lower than Solana’s.
Since Blind wasn't a commercial project, just a weekend experiment, we didn't need to consider potential financial returns; we simply chose an approach that minimized development pain. Ultimately, we chose the EVM. When developing blockchain applications, the EVM offers the most mature and proven blockchain infrastructure, enabling us to develop quickly, efficiently, and intelligently.
Reusable existing infrastructure
After deciding on a chain, the next step is to look for reusable SDKs (software development kits) or ready-made contracts to avoid writing code from scratch. Especially for smart contracts, prioritizing audited contracts can significantly reduce security risks.
Fortunately, there are a lot of reusable resources in the EVM ecosystem, and we have two main options:
Developed based on DEXs such as Uniswap, all access control logic is built independently on the basis of Uniswap V4;
· Developed based on the infrastructure of existing distribution platforms (such as Flaunch's SDK), which has built-in functions such as indexing, metadata upload, distribution curve configuration, and pre-sale stage management.
Once again, we chose the path of least resistance: developing on Flaunch. This allowed us to focus on the social aspects of the distribution platform and its front-end presentation, without wasting time and money on fundamental features like fund pool configuration, indexing infrastructure, and revenue sharing contracts.
"Why reinvent the wheel when someone smarter than you has already done the job?"
Token deployment method
After deciding on the SDK, you need to decide who will actually perform the token deployment. There are two options:
Solution 1: User initiates transaction to deploy tokens
· Develop a proxy contract to ensure that the issuance parameters selected by users meet the platform requirements;
Need to find a way to track all deployed tokens in Flaunch’s existing subgraph indexer.
Solution 2: The user submits a "deployment request" to the backend, and the platform robot performs the deployment
All tokens are deployed by the platform’s own EOA (Externally Owned Account), making it easy to track all tokens issued by the platform in the indexer;
Ensures that all issuances adhere to uniform, standardized parameters.
We chose the "backend service deployment" solution: this makes token tracking easier, allows for stricter control over "what and how" is deployed, and leaves room for future upgrades.
All tokens will be deployed from wallets controlled by the backend.
Essentially, we have "stripped down the Flaunch SDK" by removing all unnecessary functionality and keeping only the parts that can be called by backend requests.
Social data collection
Next, we'll focus on social features. We need to determine which data dimensions are valuable to the publishing platform. The ideal data combination should reflect both "user account status" and "user reputation."
I ultimately settled on the following data dimensions:
Number of followers (X platform API)
Number of followers (X platform API)
Account registration duration (X platform API)
Likes (X Platform API)
High-value followers (Moni API)
Core interactive users (Moni API)
Reputation score (Ethos API)
Content virality score (Kaito API)
This combination allows creators to prove their qualifications through multi-dimensional data without having to fully reveal their identity, allowing them to stand out.
Social data processing and privacy protection
When users register, we collect all the above data, but how should we design it at the privacy level?
Our principle is "privacy by default": all data is private by default to prevent leaks; users can independently decide whether to make each data dimension public. Furthermore, we should allow users to "obfuscate" data (for example, if a user actually has 43,000 followers, they can choose to display "40,000+"), providing semi-anonymous data for reference.
In addition, should data processing rely on "centralized backend + HTTPS requests" or adopt complex zero-knowledge proof technology?
Our solution is a combination of both:
All data is stored in a Postgres database, and the front-end directly obtains information from the database through an HTTPS API. Pre-sale admission control uses the following process:
The user wishes to participate in the pre-sale → Request an “Access Certificate” from the platform backend;
The backend verifies whether the user meets the threshold set by the creator;
The backend returns a signed message containing the user’s wallet address and expiration timestamp.
Smart contract verifies the validity of the signature.
Phase 2: Development and Implementation
Before starting development, make a list of the tools you need:
Railway (backend hosting): $20/month
Vercel (front-end hosting): $15/month
Cursor (development tool, including Claude 4 MAX mode): $200/month + $100 credits
Website domain name: $30/year
X Premium+ (account membership, for increased exposure and publishing long articles): $40/month
ChatGPT: used to design logos and brand visuals, and can also be replaced with other familiar tools
Total cost is approximately $405 (assuming Vercel doesn't exceed subscription limits).
Note: To speed up development, I actually used more Cursor credits than expected (using the MAX model). If you are not concerned about development speed, you can choose a cheaper model.
Architecture Design
Most projects require 4 core components:
Frontend: hosted on Vercel (separate GitHub repository);
Backend: hosted on Railway (separate GitHub repository);
Data storage database: Postgres database on Railway;
· Cache database: Redis database on Railway.
Simply put, Vercel is responsible for all front-end related functions; Railway securely hosts "user-invisible" core services such as data processing, token deployment, API interfaces, information caching, etc.
Most backend architectures look like this (yes, data is stored in "balls").
Development sequence
I always recommend developing the core functionality first and working on the front-end presentation last.
For this project, the most core function (and the function that needs to be tested for compatibility first) is token issuance.
Since we have determined that token deployment will be performed by the backend EOA, we can create a new git repository for the backend and start digging into the Flaunch SDK documentation.
The documentation outlines all the features currently available in terms of launch configurations and even provides some code snippets for easy integration. They also provide some API endpoints for retrieving data, and a subgraph that automatically indexes everything happening on Flaunch (including tokens launched from the Blind frontend).
1) Testing the token issuance function
In the new backend repository, the first step is to set up a local environment to test whether the SDK can successfully issue tokens. We can start by writing a simple Node script and then converting it into an Express server interface. Calling the interface and passing in the specified parameters will complete the token deployment.
This step is actually very simple, and it will probably be done with just one prompt word and a little debugging.
And the gas fee for token deployment is less than $0.01! This means we can provide users with completely free token deployment services.
2) Pulling social data
The second step is to develop another core feature: social scoring. For all the data dimensions previously selected, we need to review the documentation for each API and then create an endpoint in the Express server that returns all the data based on the username. We can then store this data in the Postgres database we created on Railway.
3) Registration Process
At this point, development becomes slightly more complex, requiring simultaneous development of the front-end repository. We chose Next.js as the front-end framework because it has the best support for Vercel and supports middleware for authentication.
In the registration flow, we want users to first link their wallet, then authenticate via X, and finally register by calling our endpoint.
We'll start by reviewing the X-Auth API documentation, implementing a simple registration page on the front end, and creating a registration endpoint on the backend repository.
During the registration process, we also need to extract all the data from step 2) and store it in the database, with an additional entry for the wallet address. All requests sent to the registration endpoint should be authenticated with both the X key and the wallet signature to prevent identity impersonation.
Once everything is working, we also need to add authentication to the token deployment endpoint so that only registered users can deploy tokens. For any endpoint other than the registration endpoint, we decided to only authenticate via a wallet signed message to avoid having to log in with X every time.
4) Privacy Settings
After completing the registration process and implementing data storage, the next step is to develop privacy settings:
Create a data visibility setting table in the database (all data is private by default);
· Develop a privacy setting modification interface that can be called by authenticated users;
Write auxiliary functions to support users to choose fuzzy display data;
· Developed front-end privacy settings editing component.
5) Interface inspection and optimization
After the core services are ready, the following optimizations are required:
With all the core server functionality in place, we now need to ensure that all endpoints use authentication where required and don't expose any personal information when publicly accessible. We can also optimize some APIs using Redis caching to avoid unnecessary server load. Finally, we'll add several APIs for retrieving user public profiles, token owners and their data, and currency data.
6) Front-end development
Now it's time to create a beautiful website. Let's first decide on the theme, the pages we want to display, and start removing the "private" sections. For displaying custom-ordered token lists and other data, we can rely on Flaunch's subgraphs, filtering by the deployer address as our EOA. For the token details page, a quick way to display the chart is to embed a simple DexScreener iframe.
7) Testing
Everything is finally ready. I tested the user flows, deployed everything to Vercel and Railway, and shared access with friends to get feedback. The goal is to have an environment that is 1:1 identical to the production environment.
8) Optimize based on feedback
This is the last step before going online.
Phase 3: Public Launch
The public launch is divided into two steps: first, brand building, and then market promotion.
Brand Building
I didn't mention branding before because it can be done at any time, but it's best done before front-end development. The core brand elements (name, logo, color scheme, domain name) must be simple and recognizable.
One of my personal favorite ways to play is to use a single word name + domain name combination to play with memes:
The project name was “Blind” (meaning “blind investment”, implying that users purchase tokens with limited information);
The domain name we chose was goblind.xyz, a clever fusion of the meanings of “go blind,” “goblin,” and “goblin’d.”
The color scheme is deliberately chosen to be a bright and dazzling light mode, combined with the "Brutalist" design style, reminiscent of Braille documents, echoing the theme of "Blind";
Logo design: generated using ChatGPT (using an existing theme as a background prompt);
Marketing
It’s time to let the world know about our MVP (minimum viable product)! Often, the best way to let others know is not to tell them directly, but to create confusion.
Confused Marketing
Before launching your product, it's recommended to ensure your MVP is fully functional. It's best to start marketing a week before the launch to focus public attention and increase your chances of becoming a hot topic on social media platforms.
The core goals for this week are:
Get more people to follow the project's X account and enable notifications.
Release vague teasers and memes, but never reveal the project's features directly;
Leave some clues and let netizens guess in the comments section to generate buzz for you.
Vanity metrics: making users feel less alone
An effective tool for "confusion marketing" is "rankings"! People want to "seize the opportunity" but don't want to "enter the market too early." Your mission is to "make the platform 'live' before it even launches."
The "Registration + Ranking" event has the following benefits:
Guide users to register in advance, disperse website traffic, and test system stability;
Keep users interested in the project: "Are there any benefits for early registration?" and enable account notifications;
People like to feel better than others: Leaderboard rankings are easy to share and allow users to discover interesting data about their accounts.
It makes it easier for the team to publicize “growth data” externally.
Before Blind went online, the number of pre-registered users exceeded 40,000!
Note: If the "invite link" mechanism is added, the growth rate will be faster.
24-hour countdown notice
It's time to reveal Blind's core features! Let them know when the article is published so they have a specific time to look forward to it. Last 24 hours to lock in your guesses about what Blind will contain. 24 hours for everyone in all time zones to get ready.
Publish online articles
Now that users are refreshing your X account's homepage, it's time to publish an article! The article should detail:
Blind's core functionality;
Official launch date;
Don't get too technical or list every feature; focus on conveying your motivation, core idea, and project appeal.
If additional technical details are required, separate documentation can be provided outside the article.
Phase 4: Officially launched!
The article should state that "the launch time is 24 hours after the article is published." At this point, pre-registered users are ready and waiting for the token to be deployed. Next, we need to:
Switch all environments to production mode;
Switch the deployer's EOA account;
Be on call at all times to handle any issues that might arise with the launch (and they will).
Okay, it’s officially online!
Summarize
When developing your MVP, always choose the path of least resistance. Don't aim for instant perfection; instead, iterate and optimize incrementally in production. Seizing the moment is often more important than waiting until everything is ready.
But be warned: first impressions are crucial. The user’s first experience with the platform will directly determine their long-term perception of the platform. Don’t expect most users to continue paying attention to “feature updates.”
This side project was a lot of fun to develop, I learned a lot, and built a tool that people might use to issue tokens.
Click here to learn about BlockBeats' BlockBeats job openings
Welcome to join the BlockBeats official community:
Telegram group: https://t.me/theblockbeats
Telegram group: https://t.me/BlockBeats_App
Official Twitter account: https://twitter.com/BlockBeatsAsia
