Solo necesitas 3 días y 400 dólares para aprender paso a paso cómo construir una plataforma Launchpad.

Título original: I Built a Launchpad in 3 Days for $400 (and so can you)
Autor original: ultra

Traducción: Luffy, Foresight News

El pasado fin de semana, trabajé horas extra para lanzar el proyecto Blind, simplemente para demostrar que crear un producto significativo no requiere millones de dólares en financiación, meses de trabajo ni siquiera un equipo.

Blind es una plataforma de lanzamiento de tokens desarrollada sobre la cadena Base, que funciona gracias a la infraestructura de Flaunch. Intenta un mecanismo completamente nuevo: permite a los creadores de tokens elegir qué información personal desean hacer pública al emitir un token.

De esta manera, los creadores pueden aprovechar su reputación o credenciales sin necesidad de revelar completamente su identidad real, ni asumir los problemas que suelen acarrear los "embajadores de tokens". Además, los creadores pueden establecer requisitos de acceso, permitiendo solo la participación de usuarios que cumplan ciertos mínimos.

Propósito de este artículo

El objetivo de este artículo es compartir mi marco general para pasar de una "idea" a un "producto".

Como suelo decir, los próximos 6-12 meses son el "período dorado para materializar ideas". Gracias a las herramientas de IA, convertir una idea en realidad es más fácil que nunca, pero pocos son conscientes de ello. Para quienes estén dispuestos a invertir tiempo, sin duda es una gran oportunidad de arbitraje.

Espero que este artículo inspire a más personas a intentar el vibecoding, convirtiendo sus ideas en realidad y devolviendo a Web3 a ese espacio dominado por desarrolladores independientes y pequeños equipos, donde la innovación surge a diario.

Este artículo asume que los lectores ya tienen cierta base técnica y están familiarizados con herramientas de desarrollo, gestión de repositorios de código y componentes comunes.

Fase 0: Fuente de inspiración

La idea del control de acceso mediante capital social llevaba meses gestándose en mi mente. Al usar frecuentemente herramientas como Kaito, Ethos, fantasy.top, time.fun y al investigar métricas de SocialFi, surgía repetidamente una pregunta en las discusiones: ¿por qué nadie ha creado un panel que integre los perfiles de usuario de todas estas plataformas y evalúe sus credenciales mediante puntuaciones y datos?

En los últimos 6 meses aproximadamente, el campo de las "métricas de creadores" ha crecido rápidamente, y ahora la gente puede evaluar el valor de una persona o cuenta a través de múltiples dimensiones de datos.

Entonces, ¿por qué no usar estas métricas para establecer "requisitos de participación" (por ejemplo, condiciones de acceso para la emisión de tokens)? ¿Y por qué no permitir que los creadores decidan qué métricas revelar al público mientras ocultan su identidad real?

Lo que realmente me impulsó a desarrollar fue ver que Pump.fun recaudó 500 millones de dólares y que recientemente heaven también alcanzó una financiación de 20 millones de dólares. En mi opinión, la dificultad de desarrollo de estos dos productos no es alta, ¿por qué sus valoraciones son tan exageradas? Además, hay muchas otras plataformas de lanzamiento exitosas que también han recaudado enormes sumas.

Siendo justos, en este campo, para mantener la racionalidad, ya no nos preocupamos por la "lógica de valoración de tokens"; muchas veces, la valoración en sí carece de sentido.

Pero, en cualquier caso, esto me llevó a un reto personal: ¿podría crear un producto de nivel similar en un fin de semana, con un coste muy bajo y sin ayuda externa?

Mi objetivo no es crear un producto comercial, emitir tokens ni siquiera ganar dinero, sino demostrar que "esto se puede hacer" y animar a más personas a seguir este camino.

Fase 1: Desglose del problema

Una vez que tienes la idea, el primer paso es descomponerla en componentes clave y tomar decisiones para cada uno. Para una "plataforma de lanzamiento con control de acceso social", identifiqué los siguientes subproblemas:

Elección del stack tecnológico on-chain

La decisión principal es "en qué cadena desplegar", ya que esto afecta a todas las fases posteriores. En ese momento, tenía dos opciones claras: Solana y Base.

Solana

Ventajas:

· La cadena con mayor volumen de trading de memecoins;

· Efecto foco: cualquier proyecto desplegado aquí tiende a recibir cierta atención.

Desventajas:

· Menor flexibilidad de implementación, se deben seguir los estándares de tokens existentes;

· Mayor complejidad de desarrollo, requiere muchas soluciones alternativas;

· Ciclo de desarrollo más largo;

· Coste de infraestructura alto e inestable.

Base

Ventajas:

· Mayor volumen de trading de memecoins entre las cadenas EVM;

· Excelente soporte para desarrolladores;

· Experiencia de desarrollo EVM sobresaliente;

· Posibilidad de reutilizar infraestructura existente.

Desventajas:

· El volumen de trading de memecoins es menor que en Solana.

Dado que Blind no es un proyecto comercial, sino una práctica de fin de semana, no necesitamos considerar "retornos financieros potenciales", solo elegir la opción que haga el desarrollo menos doloroso. Finalmente, elegimos EVM. Al desarrollar aplicaciones blockchain, EVM es la infraestructura más madura y con mejor experiencia, lo que nos permite avanzar de forma rápida, eficiente e inteligente.

Infraestructura existente reutilizable

Una vez elegida la cadena, el siguiente paso es buscar SDKs o contratos existentes reutilizables, para evitar escribir código desde cero. Especialmente en la parte de smart contracts, priorizar contratos auditados reduce mucho los riesgos de seguridad.

Por suerte, el ecosistema EVM tiene muchos recursos reutilizables, y básicamente teníamos dos opciones:

·Desarrollar sobre DEXs como Uniswap, construyendo toda la lógica de control de acceso sobre Uniswap V4;

· Desarrollar sobre la infraestructura de plataformas de lanzamiento existentes (como el SDK de Flaunch), que ya incluye indexación, subida de metadatos, configuración de curvas de emisión, gestión de fases, etc.

De nuevo, elegimos "el camino de menor resistencia": desarrollar sobre Flaunch. Así, podemos centrarnos en los aspectos sociales de la plataforma y la interfaz, sin perder tiempo ni dinero en funciones básicas como configuración de pools, indexación, contratos de reparto de ingresos, etc.

"Si alguien más inteligente ya ha hecho el trabajo, ¿para qué reinventar la rueda?"

Método de despliegue de tokens

Una vez elegido el SDK, hay que decidir "quién ejecuta realmente el despliegue del token", con dos opciones:

Opción 1: El usuario inicia la transacción para desplegar el token

· Requiere desarrollar un contrato proxy para asegurar que los parámetros elegidos por el usuario cumplen los requisitos de la plataforma;

· Hay que encontrar la forma de rastrear todos los tokens desplegados en el subgrafo de Flaunch.

Opción 2: El usuario envía una "solicitud de despliegue" al backend, y un bot de la plataforma ejecuta el despliegue

· Todos los tokens son desplegados por una EOA (cuenta externa) de la plataforma, facilitando el rastreo de todos los tokens lanzados por la plataforma en el indexador;

· Se asegura que todas las emisiones sigan parámetros estandarizados.

Elegimos la opción de "despliegue por backend": esto facilita el rastreo de tokens y permite un control más estricto sobre el "contenido y forma del despliegue", además de dejar margen para mejoras futuras.

Todos los tokens serán desplegados por una wallet controlada por el backend.

En esencia, es como "simplificar el SDK de Flaunch", eliminando todo lo innecesario y dejando solo lo que puede ser llamado por el backend.

Recopilación de datos sociales

Ahora nos centramos en la función social. Debemos determinar qué dimensiones de datos son valiosas para la plataforma de lanzamiento. La combinación ideal debe reflejar tanto el "estado de la cuenta de usuario" como su "reputación".

Finalmente, elegí las siguientes dimensiones de datos:

· Número de seguidores (API de X)

· Número de seguidos (API de X)

· Antigüedad de la cuenta (API de X)

· Número de likes (API de X)

· Número de seguidores de alto valor (API de Moni)

· Número de usuarios con interacción clave (API de Moni)

· Puntuación de reputación (API de Ethos)

· Puntuación de difusión de contenido (API de Kaito)

Esta combinación permite a los creadores destacar demostrando sus credenciales con datos multidimensionales, sin exponer completamente su identidad.

Procesamiento de datos sociales y protección de la privacidad

Al registrar usuarios, recopilamos todos estos datos, pero ¿cómo diseñar la privacidad?

Nuestro principio es "prioridad por defecto a la privacidad": todos los datos son privados por defecto para evitar filtraciones; el usuario puede decidir qué datos hacer públicos. Además, debe poder "mostrar datos de forma difusa" (por ejemplo, si tiene 43,000 seguidores, puede mostrar "40,000+"), ofreciendo referencias semianónimas.

Por otro lado, ¿el procesamiento de datos debe depender de un "backend centralizado + peticiones HTTPS", o usar técnicas complejas de pruebas de conocimiento cero?

Nuestra solución combina ambos:

· Todos los datos se almacenan en una base de datos Postgres, y el frontend los obtiene mediante una API HTTPS. El control de acceso sigue este flujo:

· El usuario quiere participar → solicita al backend una "prueba de acceso";

· El backend verifica si el usuario cumple los requisitos establecidos por el creador;

· El backend devuelve un mensaje firmado con la "dirección de la wallet del usuario + timestamp de expiración";

· El smart contract verifica la validez de la firma.

Fase 2: Desarrollo e implementación

Antes de empezar a desarrollar, enumeramos las "herramientas necesarias":

· Railway (hosting backend): 20 USD/mes

· Vercel (hosting frontend): 15 USD/mes

· Cursor (herramienta de desarrollo, incluye modo Claude 4 MAX): 200 USD/mes + 100 USD en créditos

· Dominio web: 30 USD/año

· X Premium+ (membresía de cuenta, para mayor visibilidad + publicación de textos largos): 40 USD/mes

· ChatGPT: para diseñar el logo y la imagen de marca, aunque se puede usar cualquier otra herramienta conocida

· Coste total aproximado: 405 USD (suponiendo que Vercel no supere el límite de suscripción).

Nota: Para acelerar el desarrollo, usé más créditos de Cursor de lo previsto (activando el modelo MAX). Si no se busca velocidad, se puede optar por modelos más baratos.

Diseño de arquitectura

La mayoría de los proyectos requieren 4 componentes clave:

· Frontend: alojado en Vercel (repositorio GitHub separado);

· Backend: alojado en Railway (repositorio GitHub separado);

· Base de datos de almacenamiento: base de datos Postgres en Railway;

· Base de datos de caché: base de datos Redis en Railway.

En resumen, Vercel gestiona todo lo relacionado con el frontend; Railway aloja de forma segura los servicios centrales "invisibles para el usuario", como procesamiento de datos, despliegue de tokens, APIs, caché de información, etc.

La mayoría de las arquitecturas backend son así (sí, los datos están en la "bola").

Orden de desarrollo

Siempre recomiendo desarrollar primero las funciones clave y dejar la interfaz para el final.

En este proyecto, la función más esencial (y la que requiere probar compatibilidad primero) es la emisión de tokens.

Como ya decidimos que el despliegue de tokens lo ejecuta una EOA del backend, podemos crear un nuevo repositorio git para el backend y empezar a estudiar la documentación del SDK de Flaunch.

La documentación resume todas las funciones posibles para la configuración de lanzamiento, e incluso ofrece fragmentos de código para facilitar la integración. También proporciona endpoints API para recuperar datos y un subgrafo que indexa automáticamente todo lo que ocurre en Flaunch (incluyendo los tokens lanzados desde el frontend de Blind).

1) Probar la función de emisión de tokens

En el nuevo repositorio backend, el primer paso es montar el entorno local y probar si se puede emitir un token con éxito usando el SDK. Podemos escribir primero un script sencillo en Node y luego convertirlo en un endpoint de servidor Express, que reciba parámetros y ejecute el despliegue del token.

Este paso es bastante simple, probablemente solo requiera un prompt y un poco de depuración.

¡Además, el gas para desplegar un token es menos de 0.01 USD! Esto significa que podemos ofrecer a los usuarios un servicio de despliegue de tokens completamente gratuito.

2) Obtener datos sociales

El segundo paso es desarrollar otra función clave: el scoring social. Para cada dimensión de datos elegida antes, revisamos la documentación de cada API y creamos un endpoint en el servidor Express que devuelva todos los datos según el nombre de usuario. Luego, almacenamos estos datos en la base de datos Postgres de Railway.

3) Proceso de registro

En este punto, el desarrollo se complica un poco y hay que avanzar también en el repositorio frontend. Elegimos Next.js como framework frontend porque tiene el mejor soporte en Vercel y permite autenticación mediante middleware.

En el proceso de registro, queremos que el usuario primero conecte su wallet, luego se autentique con X y finalmente se registre llamando a nuestro endpoint.

Primero revisamos la documentación del API de autenticación de X, implementamos una página de registro sencilla en el frontend y creamos un endpoint de registro en el backend.

Durante el registro, también extraemos todos los datos del paso 2) y los almacenamos en la base de datos, añadiendo un campo para la dirección de la wallet. Todas las peticiones al endpoint de registro deben requerir autenticación tanto con la clave de X como con la firma de la wallet, para evitar suplantaciones.

Una vez todo funciona, añadimos autenticación al endpoint de despliegue de tokens, de modo que solo los usuarios registrados puedan desplegar tokens. Para los demás endpoints, decidimos autenticar solo con firma de wallet, para evitar tener que iniciar sesión en X cada vez.

4) Configuración de privacidad

Tras completar el registro y el almacenamiento de datos, el siguiente paso es desarrollar la configuración de privacidad:

· Crear una tabla de configuración de visibilidad de datos en la base de datos (por defecto, todos los datos son privados);

· Desarrollar un endpoint para que los usuarios autenticados modifiquen la configuración de privacidad;

· Escribir funciones auxiliares para permitir la visualización difusa de datos;

· Desarrollar el componente frontend para editar la configuración de privacidad.

5) Revisión y optimización de endpoints

Con los servicios clave listos, hay que optimizar lo siguiente:

Todos los endpoints del servidor deben usar autenticación cuando sea necesario y no filtrar información personal en accesos públicos. Podemos usar Redis para cachear algunas APIs y evitar sobrecargar el servidor. Finalmente, añadimos APIs para obtener perfiles públicos de usuario, propietarios de tokens y sus datos, datos de monedas, etc.

6) Desarrollo frontend

Ahora toca crear un sitio web atractivo. Primero definimos el tema, las páginas a mostrar y empezamos a eliminar las partes "privadas". Para mostrar listas de tokens ordenadas y otros datos, podemos usar el subgrafo de Flaunch y filtrar por la dirección del deployer (nuestra EOA). Para la página de detalles del token, la forma más rápida de mostrar gráficos es incrustar un iframe sencillo de DexScreener.

7) Pruebas

Por fin todo está listo. Probamos el flujo de usuario, desplegamos todo en Vercel y Railway y compartimos el acceso con amigos para recibir feedback. El objetivo es crear un entorno idéntico al de producción.

8) Optimización según feedback

Este es el último paso antes del lanzamiento.

Fase 3: Lanzamiento público

El lanzamiento público tiene dos pasos: primero construir la marca, luego hacer marketing.

Construcción de marca

No mencioné antes la construcción de marca porque se puede hacer en cualquier momento, pero es mejor completarla antes de desarrollar el frontend. Los elementos clave de la marca (nombre, logo, paleta de colores, dominio) deben ser "simples y fáciles de reconocer".

Personalmente, me gusta mucho el juego de "nombre de una sola palabra + dominio creativo":

· El nombre elegido fue "Blind" (aludiendo a "inversión a ciegas", insinuando que los usuarios compran tokens con información limitada);

· La paleta de colores es intencionadamente clara y llamativa, con un diseño "brutalista" que recuerda a documentos en braille, reforzando el tema "Blind";

· Logo: generado con ChatGPT (usando el tema existente como prompt);

Marketing

¡Es hora de que el mundo conozca nuestro MVP! Normalmente, la mejor manera de darlo a conocer no es decirlo directamente, sino crear confusión.

Marketing de confusión

Antes de promocionar, asegúrate de que el MVP esté completo. Lo ideal es iniciar la campaña una semana antes del lanzamiento, así concentras la atención pública en ese periodo y es más fácil dominar los trending topics de las redes sociales.

Los objetivos clave de esa semana son:

· Conseguir que más gente siga la cuenta de X del proyecto y active las notificaciones;

· Publicar teasers ambiguos y contenido de broma, pero nunca revelar claramente la funcionalidad del proyecto;

· Dejar "pistas" para que los usuarios especulen en los comentarios y generen hype por ti.

Métricas de vanidad: que los usuarios no estén solos

Un recurso eficaz junto al "marketing de confusión" es el "ranking". La gente quiere "ser de los primeros", pero no "demasiado pronto". Tu tarea es "hacer que la plataforma parezca viva antes de lanzarla".

El evento "registro + ranking" tiene estas ventajas:

· Incentiva el registro anticipado, distribuye el tráfico y prueba la estabilidad del sistema;

· Mantiene a los usuarios atentos al proyecto: "¿Habrá recompensas por registrarse pronto?" y activa las notificaciones;

· A la gente le gusta "ser mejor que los demás": el ranking es fácil de compartir y permite descubrir datos interesantes de su cuenta;

· Facilita al equipo mostrar "datos de crecimiento".

Antes del lanzamiento de Blind, ¡los usuarios pre-registrados ya superaban los 40,000!

Nota: Si añades un sistema de "enlaces de invitación", el crecimiento será aún más rápido.

Cuenta atrás de 24 horas

¡Es hora de revelar la función principal de Blind! Cuando publiques el artículo, informa a los usuarios para que tengan una fecha concreta que esperar. Las últimas 24 horas, centra las especulaciones sobre Blind. Así, todos los usuarios de todos los husos horarios estarán preparados.

Publicar el artículo de lanzamiento

Ahora que todos los usuarios están refrescando tu perfil de X, ¡es el momento de publicar el artículo! Debe explicar en detalle:

· Las funciones principales de Blind;

· Fecha y hora del lanzamiento oficial;

· No hace falta ser demasiado técnico ni listar todas las funciones, céntrate en transmitir la "motivación de desarrollo", la "idea central" y el "atractivo del proyecto";

Si necesitas añadir detalles técnicos, puedes hacerlo en un documento aparte.

Fase 4: ¡Lanzamiento oficial!

En el artículo, indica que "el lanzamiento será 24 horas después de la publicación". Para entonces, los usuarios pre-registrados ya estarán listos para desplegar tokens. Ahora toca:

· Cambiar todos los entornos a modo producción;

· Cambiar la cuenta EOA del deployer;

· Estar atentos para solucionar cualquier error que surja durante el lanzamiento (los errores siempre ocurren).

¡Listo, lanzamiento oficial!

Resumen

Al desarrollar un MVP, elige siempre "el camino de menor resistencia". No busques la perfección de una sola vez, puedes iterar y mejorar en producción. Aprovechar el momento suele ser más importante que "esperar a que todo esté listo".

Pero también hay que tener en cuenta: la primera impresión es crucial. La experiencia del usuario en su primera visita determinará su percepción a largo plazo de la plataforma; no esperes que la mayoría siga las "actualizaciones de funciones".

El proceso de desarrollo de este side project fue muy divertido, aprendí mucho y creé una herramienta que "la gente podría usar para lanzar tokens".