Sharing my general framework from "idea" to "product."
Written by: ultra
Compiled by: Luffy, Foresight News
Last weekend, I worked overtime to create the Blind project, just to prove that building meaningful products doesn't require millions of dollars in funding, months of work, or even a team.
Blind is a token issuance platform (Launchpad) developed on the Base chain, operating on the infrastructure of Flaunch. It attempts a brand new mechanism: allowing token creators to choose which personal information to disclose when issuing tokens.
This way, creators can leverage their reputation or qualifications for endorsement without fully revealing their true identity, nor do they have to bear the troubles that typically come with being a "token spokesperson." Additionally, creators can set pre-sale entry thresholds, allowing only users who meet minimum conditions to participate.
Purpose of this article
This article aims to share my general framework from "idea" to "product."
As I often say, the next 6-12 months are the "golden period for ideas to take shape." With the help of AI tools, turning ideas into reality is exceptionally easy, but few people realize this. For those willing to invest time, this is undoubtedly a huge arbitrage opportunity.
I hope this article can inspire more people to try vibecoding, turning their ideas into reality and bringing Web3 back to a domain led 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 component knowledge.
Stage 0: Source of Inspiration
The idea of social capital gating has been brewing in my mind for several months. While frequently using tools like Kaito, Ethos, fantasy.top, time.fun, and researching SocialFi metrics, a recurring question in discussions was: why is there no dashboard that integrates and displays user profiles across all these platforms, using scores and data to evaluate user qualifications?
In the past six months, the field of "creator metrics" has rapidly risen, and now people can evaluate the value of a person or an account through various data dimensions.
So, can we use these metrics to set "participation thresholds" (such as entry conditions for token issuance)? And can we allow creators to decide which metrics to disclose to the public while hiding their true identity?
What really prompted me to start development was seeing Pump.fun's ICO raise $500 million, and recently heaven's ICO also raised $20 million. In my view, the development difficulty of these two products is not high; why are their valuations so exaggerated? Moreover, there are many similar successful issuance platforms that have raised huge amounts of funding.
Fairly speaking, in this field, to maintain rationality, we have actually stopped entangling ourselves in "token valuation logic"; many times, the valuation itself is completely unreasonable.
But in any case, this sparked my personal challenge: can I create a product of comparable quality over a weekend, at a very low cost, without relying on external help?
My goal is not to create a commercial product, issue tokens, or even make money, but to prove that "this can be done" and hope that more people will follow this path.
Stage 1: Problem Breakdown
Once I had the idea, the first step was to break it down into core components and make decisions for each component. For the "issuance platform with social access control," I identified the following sub-questions:
On-chain Technology Stack Selection
The primary decision is "which chain to deploy on," as this choice will affect all subsequent implementation steps. At that time, there were two clear options: Solana and Base.
Solana
Advantages:
The chain with the highest trading volume for meme coins;
Spotlight effect: any project deployed here easily gains some attention.
Disadvantages:
Low implementation flexibility; must adhere to existing token standards;
High development complexity, requiring many workarounds;
Long development cycle;
High and unstable infrastructure costs.
Base
Advantages:
The highest trading volume for meme coins among EVM chains;
Comprehensive support for developers;
Excellent EVM development experience;
Can directly reuse existing infrastructure.
Disadvantages:
- Trading volume for meme coins is not as high as Solana.
Since Blind is not a commercial project, just a weekend practice piece, we do not need to consider decisions related to "potential financial returns," but only need to choose a solution that "does not make the development process too painful."
Ultimately, we chose EVM. When developing blockchain applications, EVM is the most mature and best-experienced blockchain infrastructure, allowing us to advance development quickly, efficiently, and wisely.
Reusable Existing Infrastructure
After determining the 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 the smart contract part, prioritizing the use of audited contracts can significantly reduce security risks.
Fortunately, there are many reusable resources in the EVM ecosystem, and we mainly had two choices:
Develop based on DEXs like Uniswap, building all access control logic on top of Uniswap V4;
Develop based on the existing infrastructure of issuance platforms (like Flaunch's SDK), which already includes features like indexing, metadata upload, issuance curve configuration, and pre-sale phase management.
We again chose the "path of least resistance": developing based on Flaunch. This way, we can focus on "the social attributes of the issuance platform + front-end display," without wasting time and money on basic functionalities like liquidity pool configuration, indexing infrastructure, and revenue-sharing contracts.
"Since smarter people have already done the work, why reinvent the wheel?"
Token Deployment Method
After determining the SDK, we need to decide "who will actually execute the token deployment," with two options available:
Option 1: Users initiate transactions to deploy tokens
Need to develop a proxy contract to ensure that the issuance parameters chosen by users meet platform requirements;
Need to find a way to track all deployed tokens in Flaunch's existing subgraph indexer.
Option 2: Users submit "deployment requests" to the backend, executed by platform bots
All tokens are deployed by the platform's own EOA (Externally Owned Account), making it easier to track all tokens issued by the platform in the indexer;
Ensures that all issuances adhere to standardized parameters.
We chose the "backend service deployment" option: this simplifies token tracking and allows for stricter control over "deployment content and methods," with future upgrade potential.
All tokens will be deployed by a wallet controlled by the backend.
Essentially, we streamlined the Flaunch SDK, removing all unnecessary features and retaining only the parts callable by backend requests.
Social Data Collection
Next, we focus on social features. We need to determine which data dimensions are valuable for the issuance platform. The ideal data combination should reflect both "user account status" and "user reputation."
Ultimately, I selected the following data dimensions:
Number of followers (X platform API)
Number of followings (X platform API)
Account registration duration (X platform API)
Number of likes (X platform API)
Number of high-value followers (Moni API)
Number of core interaction users (Moni API)
Reputation score (Ethos API)
Content dissemination score (Kaito API)
This combination allows creators to prove their qualifications through multidimensional data without fully exposing their identity, helping them stand out.
Social Data Processing and Privacy Protection
When users register, we will collect all the above data, but how should we design privacy aspects?
Our principle is "default privacy first": all data is not public by default to avoid leaks; users can decide whether to make each data dimension public. Additionally, users should be allowed to "obfuscate displayed data" (for example, if they actually have 43,000 followers, they can choose to display "40,000+"), providing semi-anonymous data references.
Furthermore, should data processing rely on "centralized backend + HTTPS requests," or should we adopt complex zero-knowledge proof technology?
Our solution is a combination of both:
All data is stored in a Postgres database, with the frontend directly retrieving information from the database via HTTPS API. The pre-sale access control follows this process:
User wants to participate in the pre-sale → requests "access proof" from the platform backend;
Backend verifies whether the user meets the thresholds set by the creator;
Backend returns a signed message containing "user wallet address + expiration timestamp";
Smart contract verifies the validity of the signature.
Stage 2: Development Implementation
Before starting development, I first listed the required "tool list":
Railway (backend hosting): $20/month
Vercel (frontend hosting): $15/month
Cursor (development tool, including Claude 4 MAX mode): $200/month + $100 credits
Website domain: $30/year
X Premium+ (account membership for increased exposure + publishing long articles): $40/month
ChatGPT: used for designing logo + brand visuals, can also be replaced with other familiar tools
Total cost is approximately $405 (assuming Vercel does not exceed subscription limits).
Note: To speed up development, I actually used more Cursor credits than expected (enabling MAX model). If speed is not a priority, a cheaper model can be chosen.
Architecture Design
Most projects require four 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.
In simple terms, Vercel handles all frontend-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 (that's right, the data exists in a "sphere").
Development Order
I always recommend developing core functionalities first and then focusing on frontend display.
For this project, the most critical function (and the one that needs to be tested for compatibility first) is token issuance.
Since we have determined that "the token deployment will be executed by the backend EOA," we can create a new git repository for the backend and start delving into the Flaunch SDK documentation.
This documentation outlines all feasible functionalities regarding launch configuration and even provides some code snippets for easier integration. It also offers some API endpoints for data retrieval and a subgraph that automatically indexes everything happening on Flaunch (including tokens launched from the Blind frontend).
1) Testing Token Issuance Functionality
In the new backend repository, the first step is to set up a local environment to test whether we can successfully issue tokens through the SDK. We can start by writing a simple Node script, which we can later transform into an Express server interface that calls this interface and passes in the specified parameters to complete the token deployment.
This step is actually quite simple and likely only requires one prompt + a little debugging to get it done.
Moreover, the gas fee for token deployment is less than $0.01! This means we can offer users a completely free token deployment service.
2) Pulling Social Data
The second step is to develop another core function: 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 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 progress on the frontend repository. We chose Next.js as the frontend framework because it has the best support for Vercel and supports middleware for authentication.
In the registration process, we want users to first link their wallets, then authenticate via X, and finally register by calling our endpoint.
We first look at the X authentication API documentation, implement a simple registration page on the frontend, and create 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, adding an additional wallet address entry. All requests sent to the registration endpoint should undergo both X key authentication and wallet signature authentication to prevent identity impersonation.
Once everything is functioning correctly, we also need to add authentication to the token deployment endpoint so that only registered users can deploy tokens. For any endpoints outside of the registration endpoint, we decided to authenticate solely through wallet-signed messages to avoid requiring X login each 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 settings table in the database (defaulting all data to private);
Develop a privacy settings modification interface callable by authenticated users;
Write helper functions to support users in choosing to obfuscate displayed data;
Develop a frontend privacy settings editing component.
5) Interface Checks and Optimization
Once the core services are ready, the following optimizations are needed:
All core functionalities of the server are prepared, and now we need to ensure that all endpoints use authentication when necessary and do not leak any personal information during public access. We can also use Redis caching to optimize some APIs to avoid unnecessary server load. Finally, we added several APIs to retrieve user public profiles, token owners and their data, currency data, etc.
6) Frontend Development
Now it's time to create an attractive website. We first determine the theme, the pages to display, and start removing the "private" sections. For displaying custom-sorted token lists and other data, we can rely on Flaunch's subgraph and filter based on the deployer's address, using this as our EOA. For the token detail page, a quick way to display charts is to embed a simple DexScreener iframe.
7) Testing
Everything is finally ready. Test the user flow, deploy everything to Vercel and Railway, and share access with friends for feedback. The goal is to create an environment that is 1:1 consistent with the production environment.
8) Optimize Based on Feedback
This is the last step before going live.
Stage 3: Public Launch
The public launch consists of two steps: first, brand building, and then market promotion.
Brand Building
I didn't mention brand building earlier because it can be done at any time, but it's best to complete it before frontend development. The core elements of the brand (name, logo, color scheme, domain name) should adhere to the principles of "simplicity and recognizability."
One approach I personally like is "single-word naming + domain name combination play":
The project name is "Blind" (meaning "blind investment," hinting at users purchasing tokens with limited information);
The domain name is goblind.xyz, cleverly merging the meanings of "go blind" (blind investment), "goblin" (a bit of fun), and "goblin'd" (goblinized);
The color scheme is intentionally chosen to be glaringly bright in a light mode, paired with a "beast style" design, evoking the image of Braille documents, echoing the theme of "Blind";
Logo design: generated using ChatGPT (with existing themes as background prompts);
Market Promotion
It's time to let the world know about our MVP (Minimum Viable Product)! Generally speaking, the best way to inform others is not to be straightforward but to create confusion.
Confusion Marketing
Before the official promotion, it's advisable to ensure that the MVP's functionalities are complete. It's best to start marketing a week before the launch, as this can concentrate public attention within that week, making it easier to occupy social platform trending topics.
The core goals for this week are:
To get more people to follow the project's X account and turn on notifications;
To release vague teasers and playful content, but never directly reveal the project's functionalities;
To leave "clues" for netizens to guess in the comments section, allowing them to generate buzz for you.
Vanity Metrics: Making Users No Longer Alone
An effective means to complement "confusion marketing" is "leaderboards"! People want to "get ahead" but don't want to "enter too early." Your task is to "make the platform 'live' before it goes online."
The "registration + leaderboard" activity has the following benefits:
It guides users to register early, dispersing website traffic and testing system stability;
It keeps users continuously engaged with the project: "Are there benefits for early registration?" thus prompting them to turn on account notifications;
People enjoy the feeling of "being better than others": leaderboard rankings are easy to share and allow users to discover interesting data about their accounts;
It facilitates the team's external promotion of "growth data."
Before Blind went live, pre-registered users exceeded 40,000!
Note: If an "invitation link" mechanism is added, the growth rate will be even faster.
24-Hour Countdown Announcement
It's time to reveal the core functionalities of Blind! When the article is published, please inform them so they have a specific time to look forward to. The last 24 hours should lock in your guesses about Blind's content. The 24 hours allow people in all time zones to prepare.
Release Launch Article
At this point, users are refreshing your X account homepage, and it's time to publish the article! The article should detail:
The core functionalities of Blind;
The official launch time;
No need to be overly technical or list all functionalities; focus on conveying the "development motivation," "core idea," and "project appeal";
If technical details need to be supplemented, a separate document can be provided outside the article.
Stage 4: Official Launch!
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 just waiting for token deployment. Next, we need to:
Switch all environments to production mode;
Switch the deployer EOA account;
Be on standby to address any errors that may occur during the launch (errors will always happen).
Alright, we are officially live!
Summary
When developing an MVP, always choose the "path of least resistance." There is no need to pursue a perfect solution all at once; you can iteratively optimize in the production environment. Seizing the opportunity is often more important than "waiting for everything to be ready."
But also note: first impressions are crucial. The experience users have when they first visit the platform will directly determine their long-term perception of it; don't expect most users to continuously pay attention to "function updates."
The development process of this side project was very interesting; I learned a lot and created a tool that "people might use to issue tokens."
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
