Solo necesitás 3 días y 400 dólares para que te enseñen paso a paso cómo crear 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 fin de semana pasado, trabajé horas extra para crear Blind, un proyecto que busca demostrar que para construir un producto significativo no se necesitan millones de dólares en financiamiento, meses de trabajo ni siquiera un equipo.

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

De esta manera, los creadores pueden aprovechar su reputación o credenciales como respaldo, sin necesidad de revelar completamente su identidad real ni asumir los problemas que suelen acarrear quienes se convierten en “embajadores” de tokens. Además, los creadores pueden establecer requisitos de acceso, permitiendo que solo usuarios que cumplan ciertos mínimos participen.

Objetivo de este artículo

El objetivo de este artículo es compartir el marco general que utilicé para pasar de una “idea” a un “producto”.

Como suelo decir, estos 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, aunque pocos lo notan. 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 probar el vibecoding, a convertir sus ideas en realidad y a devolverle a Web3 ese espíritu de innovación diaria liderado por desarrolladores independientes y pequeños equipos.

Este artículo asume que el lector ya tiene cierta base técnica y está familiarizado con herramientas de desarrollo, gestión de repositorios de código y componentes comunes.

Fase 0: Origen de la inspiración

La idea de controlar el acceso mediante capital social llevaba meses rondando mi cabeza. Usando frecuentemente herramientas como Kaito, Ethos, fantasy.top, time.fun y estudiando métricas de SocialFi, surgía una pregunta recurrente en las discusiones: ¿por qué nadie ha hecho un dashboard que integre los perfiles de usuario en todas estas plataformas y evalúe sus credenciales con puntajes y datos?

En los últimos 6 meses, el campo de las “métricas de creadores” ha crecido rápidamente, y hoy es posible evaluar el valor de una persona o cuenta desde múltiples dimensiones de datos.

Entonces, ¿podemos usar estas métricas para establecer “requisitos de participación” (por ejemplo, condiciones de acceso para emitir tokens)? ¿Y permitir que los creadores decidan qué métricas hacer públicas mientras mantienen oculta su identidad real?

Lo que realmente me impulsó a desarrollar fue ver que Pump.fun recaudó 500 millones de dólares y que heaven recientemente levantó 20 millones de dólares. En mi opinión, el desarrollo de estos dos productos no es tan complejo, ¿por qué entonces tienen valoraciones tan altas? Además, hay muchas otras plataformas de emisión exitosas que también han recaudado grandes sumas.

Siendo justos, en este sector, para mantener la racionalidad, ya no nos preocupamos tanto por la “lógica de valoración de tokens”; muchas veces, la valoración simplemente no tiene sentido.

Pero, de todos modos, esto me planteó un desafío personal: ¿podría yo, en un solo fin de semana, con un costo bajísimo y sin ayuda externa, crear un producto de nivel similar?

Mi objetivo no era crear un producto comercial, emitir un token 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 emisión con control de acceso social”, identifiqué los siguientes subproblemas:

Elección del stack tecnológico on-chain

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

Solana

Ventajas:

· Es la cadena con mayor volumen de trading de memecoins;

· Efecto spotlight: cualquier proyecto desplegado aquí recibe cierta atención.

Desventajas:

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

· Alta complejidad de desarrollo, requiere muchas soluciones alternativas;

· Ciclo de desarrollo largo;

· Costos de infraestructura altos e inestables.

Base

Ventajas:

· Es la cadena EVM con mayor volumen de trading de memecoins;

· Excelente soporte para desarrolladores;

· Gran experiencia de desarrollo EVM;

· Se puede reutilizar infraestructura existente.

Desventajas:

· El volumen de trading de memecoins no supera al de Solana.

Como Blind no es un proyecto comercial, sino un experimento 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, permitiendo avanzar rápido, eficiente e inteligentemente.

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 el riesgo de seguridad.

Por suerte, en el ecosistema EVM hay muchos recursos reutilizables, y teníamos dos opciones principales:

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

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

De nuevo elegimos “el camino de menor resistencia”: desarrollar sobre Flaunch. Así, podemos enfocarnos 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 revenue sharing, etc.

“Si alguien más inteligente ya hizo el trabajo, ¿para qué reinventar la rueda?”

Método de despliegue de tokens

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

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

· Se debe desarrollar un contrato proxy para asegurar que los parámetros elegidos por el usuario cumplan con los requisitos de la plataforma;

· Hay que encontrar la forma de rastrear todos los tokens desplegados en el subgraph 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 en el indexador de todos los tokens emitidos por la plataforma;

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

Elegimos la opción de “despliegue por backend”: esto facilita el rastreo de tokens y permite controlar estrictamente el “contenido y forma del despliegue”, además de dejar margen para futuras mejoras.

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

En esencia, es como “simplificar el SDK de Flaunch”, eliminando funciones innecesarias y dejando solo lo que puede ser llamado por el backend.

Recolección de datos sociales

Ahora nos enfocamos en la función social. Hay que definir qué dimensiones de datos son valiosas para la plataforma de emisión. La combinación ideal debe reflejar tanto el “estado de la cuenta” como la “reputación del usuario”.

Finalmente elegí estas dimensiones:

· 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 (Moni API)

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

· Puntaje de reputación (Ethos API)

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

Esta combinación permite que los creadores demuestren sus credenciales con datos multidimensionales sin exponer completamente su identidad, destacándose entre los demás.

Procesamiento de datos sociales y protección de la privacidad

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

Nuestro principio es “privacidad por defecto”: 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 elegir mostrar “más de 40,000”), brindando referencias semi-anónimas.

Por otro lado, ¿el procesamiento de datos debe depender de un “backend centralizado + solicitudes HTTPS” o usar complejas 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 vía API HTTPS. El control de acceso sigue este flujo:

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

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

· El backend devuelve un mensaje firmado con “dirección de 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, hago una lista de “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 + publicar textos largos): 40 USD/mes

· ChatGPT: para diseñar logo + visual de marca, o cualquier otra herramienta que prefieras

· Costo total aproximado: 405 USD (asumiendo que Vercel no excede 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 te importa la velocidad, puedes elegir modelos más baratos.

Diseño de arquitectura

La mayoría de los proyectos necesitan 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 al 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 los backends tienen una arquitectura como la siguiente (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 importante (y la que primero debe probarse por compatibilidad) es la emisión de tokens.

Como ya decidimos que el backend EOA ejecuta el despliegue, 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 inicial, incluso ofrece fragmentos de código para facilitar la integración. También proveen endpoints API para obtener datos y un subgraph 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 usando el SDK. Podemos escribir un simple script en Node, que luego convertiremos en un endpoint de servidor Express; llamando a ese endpoint con los parámetros adecuados, se despliega el token.

Este paso es bastante sencillo, probablemente solo requiera un prompt y algo de debugging.

¡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 emisión de tokens completamente gratis.

2) Obtener datos sociales

El segundo paso es desarrollar otra función clave: el puntaje social. Para cada dimensión de datos elegida, revisamos la documentación de cada API y creamos un endpoint en el servidor Express que, dado un nombre de usuario, devuelve todos los datos. 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 con el frontend. Elegimos Next.js como framework porque es el que mejor soporta Vercel y permite autenticación con middleware.

En el 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 de la API de autenticación de X, implementamos una página de registro simple 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 guardamos en la base de datos, agregando la dirección de wallet. Todas las solicitudes al endpoint de registro deben autenticarse tanto con la clave de X como con la firma de la wallet, para evitar suplantaciones.

Una vez que todo funciona, también agregamos autenticación al endpoint de emisión de tokens, para que solo los usuarios registrados puedan emitir tokens. Para los demás endpoints, decidimos autenticar solo con la firma de la wallet, para evitar tener que iniciar sesión con 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, todo privado);

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

· Escribir funciones auxiliares para permitir mostrar datos de forma difusa;

· Desarrollar el componente frontend para editar la privacidad.

5) Revisión y optimización de endpoints

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

Todos los endpoints principales del servidor están listos; ahora hay que asegurar que todos usen autenticación cuando sea necesario y que no filtren información personal en endpoints públicos. Podemos usar Redis para cachear algunas APIs y evitar sobrecargar el servidor. Finalmente, agregamos APIs para obtener el perfil público del usuario, los dueños de tokens y sus datos, datos de monedas, etc.

6) Desarrollo frontend

Ahora es momento de crear un sitio atractivo. Definimos el tema, las páginas a mostrar y comenzamos a eliminar las partes “privadas”. Para mostrar listas de tokens ordenadas y otros datos, podemos usar el subgraph de Flaunch y filtrar por 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 simple de DexScreener.

7) Pruebas

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

8) Mejoras 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, aunque lo ideal es antes del desarrollo frontend. Los elementos clave de la marca (nombre, logo, paleta de colores, dominio) deben ser “simples y fáciles de reconocer”.

Personalmente me gusta el juego de “nombre de una sola palabra + dominio creativo”:

· Elegí “Blind” como nombre (aludiendo a “inversión a ciegas”, es decir, comprar tokens con información limitada);

· La paleta de colores es intencionalmente brillante y de estilo “brutalista”, evocando documentos en braille y reforzando el tema “Blind”;

· El logo fue generado con ChatGPT (usando el tema como prompt);

Marketing

¡Es hora de que el mundo conozca nuestro MVP! Normalmente, la mejor forma de que otros se enteren no es decirlo directamente, sino generar confusión.

Marketing de confusión

Antes de promocionar, asegúrate de que el MVP esté completo. Lo ideal es empezar el marketing una semana antes del lanzamiento, así concentras la atención pública en esos días y es más fácil llegar a los trending topics.

Los objetivos clave de esa semana son:

· Conseguir que más personas sigan la cuenta de X del proyecto y activen notificaciones;

· Publicar teasers ambiguos y contenido con memes, pero nunca revelar directamente la función del proyecto;

· Dejar “pistas” para que la gente especule en los comentarios y así generen hype por sí mismos.

Métricas de vanidad: que los usuarios no se sientan solos

Un recurso eficaz junto al “marketing de confusión” es el “ranking”. La gente quiere “ser pionera”, pero no “entrar demasiado temprano”. Tu tarea es “hacer que la plataforma esté ‘viva’ antes de lanzarla”.

El evento “registro + ranking” tiene estos beneficios:

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

· Mantiene a los usuarios atentos al proyecto: “¿Habrá beneficios por registrarse temprano?” y así activan notificaciones;

· A la gente le gusta “ser mejor que otros”: el ranking es fácil de compartir y permite descubrir datos curiosos 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 agregás un sistema de “links de invitación”, el crecimiento será aún más rápido.

Cuenta regresiva de 24 horas

¡Es momento de revelar la función principal de Blind! Cuando publiques el artículo, avísales para que tengan una hora concreta para esperar. Las últimas 24 horas sirven para que todos los usuarios de todos los husos horarios se preparen.

Publicar el artículo de lanzamiento

Ahora todos están actualizando tu perfil de X, ¡es hora de publicar el artículo! En el artículo, explica en detalle:

· Las funciones principales de Blind;

· Fecha y hora de lanzamiento oficial;

· No hace falta ser demasiado técnico ni listar todas las funciones; lo importante es transmitir “la motivación”, “la idea central” y “el atractivo del proyecto”;

Si necesitas agregar detalles técnicos, podés hacerlo en un documento aparte.

Fase 4: ¡Lanzamiento oficial!

En el artículo, aclara que “el lanzamiento será 24 horas después de la publicación”. Los usuarios pre-registrados ya están listos, solo falta desplegar los tokens. Ahora debemos:

· Cambiar todos los entornos a modo producción;

· Cambiar la cuenta EOA del deployer;

· Estar atentos para resolver cualquier error que surja (siempre habrá alguno).

¡Listo, lanzamiento oficial!

Resumen

Al desarrollar un MVP, siempre elegí “el camino de menor resistencia”. No busques la perfección de entrada; podés iterar y mejorar en producción. Aprovechar el momento suele ser más importante que “esperar a que todo esté listo”.

Pero ojo: la primera impresión es clave. La experiencia del usuario en su primera visita determinará su percepción a largo plazo; no esperes que la mayoría siga las “actualizaciones de funciones”.

Este proyecto paralelo fue muy divertido de desarrollar, aprendí mucho y creé una herramienta que “la gente podría usar para emitir tokens”.