¿Ayuda una lista de stack más larga a lanzar más rápido?
Depende de lo que la lista deje fuera. Una lista de stack nombra herramientas; no instala sus límites — webhooks verificados, delimitado de tenants, firma de releases — y esas uniones son donde los proyectos se atascan. Una lista copiada reproduce las herramientas sin nada de la integración. Las listas sirven como carta de cosas que investigar, pero el camino a un producto lanzable es fontanería probada, la consigas como la consigas. La pregunta honesta es cuánto valen tus tardes.
La trampa de los favoritos
Hace unos días respondí a un hilo en X con el stack que uso de verdad — mi «stack indie dev 2026», una docena de herramientas en una sola respuesta. La respuesta reunió más de cien favoritos y envió más de cien clics a este sitio.
Las analíticas fueron menos halagüeñas: la mayoría de los visitantes ojeó una página y se marchó. Una lista de stack se lee como un plan terminado; una lista copiada no lanza nada. Cada herramienta sigue teniendo que instalarse, conectarse con sus vecinas y probarse — las uniones entre ellas son donde se van las semanas.
Este es el post que esos favoritos buscaban: no qué herramientas uso, sino qué fontanería ya era estructural — y qué me permitió lanzar en cuarenta y ocho horas.
Dónde mueren de verdad los proyectos
La mayoría de los proyectos indie no muere en su función central. Muere en la primera semana, en infraestructura que no tiene nada que ver con la idea. La motivación tiene una vida media de unas cuarenta y ocho horas — cada hora lejos del producto quema el recurso más escaso que tiene un build en solitario.
La forma de la semana es sorprendentemente constante:
- Día uno: estructura de monorepo, ESLint, rutas de
tsconfig, migraciones de base de datos. - Día tres: todavía en la documentación del proveedor de pagos, afinando la idempotencia de los webhooks.
- Día cinco: un compañero de escritorio o móvil — un pipeline de build nuevo, una superficie de auth nueva, actualizaciones automáticas desde cero.
Un build de 48 horas, de principio a fin
La semana pasada lancé SpinShare, una utilidad de escritorio nativa de Windows: arrastra un archivo en el Explorador, pulsa Shift y un menú radial se abre bajo el cursor; suelta para ejecutar una conversión u operación local. Sin ventanas emergentes, nada se sube — el archivo nunca sale de la máquina.
La cronología es la parte que merece examen: repositorio nuevo, lógica central en Rust, un flujo de licencias offline sobre mis rieles de facturación existentes y un envío a la Microsoft Store — cuarenta y ocho horas de desarrollo central, programando en pareja con un agente y casi sin afinar prompts. El agente no descarriló por una razón poco glamurosa: las fronteras de arquitectura donde alucina ya estaban selladas dentro de supastack, mi propio kit.
Lo que sigue es la contabilidad: la fontanería que no hubo que construir en esos dos días.
Configuración y barandillas
pnpm setup colapsa el arranque en un solo comando: comprobaciones previas, alineación de variables de entorno, instalación de dependencias, migraciones de base de datos. No hay una primera tarde montando un entorno de trabajo — el repositorio o supera su propia checklist o nombra lo que falta.
Los documentos espejo de .ai/, AGENTS.md y .agents/skills/ son un contrato escrito para el agente más que para el humano — la frontera de responsabilidad de cada paquete, sus reglas de test, sus líneas rojas (la app de escritorio es un shell de una sola webview que nunca bifurca la UI del producto). La guía de estructura de proyecto muestra la disposición que lee; el post sobre el flujo con agentes cubre el ritmo de trabajo.
Las fronteras que quedan escritas son fronteras que un agente no puede cruzar por descuido.
Facturación y releases ya montadas
Ocho adaptadores de facturación conviven detrás de un solo contrato — Stripe, Creem, Polar, Dodo, Lemon Squeezy, Paddle, Whop y PayPal — y un registro webhook_event hace que cada liquidación llegue con firma verificada e idempotente antes de convertirse en licencia o en correo. Mi trabajo empezó aguas abajo: niveles Early-Bird que cambian según el número de pedidos y claves de licencia offline firmadas con Ed25519 — una herramienta de escritorio tiene que activarse sin llamada de red. La guía del módulo de facturación documenta el flujo que extendí.
El lado de los releases fue igual de poco interesante, que es justo la idea. El pipeline de Tauri 2 — desktop-release.yml — construye bundles firmados y genera latest.json con minisign para los canales estable y beta en Windows (NSIS y msi), macOS (dmg) y Linux (AppImage). El único empaquetado que hice yo fue un build MSIX para la Microsoft Store; el quickstart de escritorio cubre el resto.
El diez por ciento que los usuarios sí notan
Esta es la aritmética que una lista de stack esconde. Aproximadamente el noventa por ciento de lo que un producto necesita es fontanería que el usuario nunca ve. La fontanería invisible es el trabajo que una base debería cargar — es la parte que se puede cargar. El resto es el producto.
Como la mía ya era estructural, casi todas mis cuarenta y ocho horas fueron al diez por ciento que los usuarios sí notan — trabajo que nunca cabe en un comentario de stack y que nunca ocurre mientras la semana se va en webhooks y firmas:
- Hooks de arrastre OLE de Windows en Rust, para que el menú solo se active mientras se mantiene un arrastre real de archivo con Shift — nunca al escribir.
- Un flujo de bandeja con varias ventanas, para que la herramienta quede a una tecla de distancia sin ventana en la barra de tareas.
- La animación del menú radial, afinada hasta que el menú se percibe instantáneo en lugar de animado.
- Más de treinta conversores de formato locales, cada uno con sus propios tests unitarios.
La parte práctica: precio y transparencia
La objeción razonable: «Tengo Cursor — ¿por qué pagar por una lista de stack?» Se sostiene hasta que tu propio tiempo tiene precio. Dos tardes de idempotencia de webhooks te cuestan una función que no lanzaste.
Sobre la transparencia: la documentación es pública por completo — estructura de directorios, dos motores web, sincronización multiplataforma, los ocho adaptadores de facturación, enrutamiento de IA. Prefiero que un escéptico la lea de principio a fin y se marche a que compre por un titular; ¿starter kit o desde cero? es la versión honesta de la decisión.
Dos notas prácticas: los precios mostrados ya incluyen 100 USD de ahorro de lanzamiento y el checkout acepta Alipay. Y un cashback del 50 % para builders — lanza un producto real en sesenta días, comparte la historia del build en público (5.000 visualizaciones orgánicas o 50 Me gusta orgánicos en X, Reddit, YouTube o similar) y envíame el enlace por correo: la mitad vuelve y la licencia sigue siendo tuya. Las reglas están en los términos del cashback de lanzamiento.
Preguntas frecuentes sobre listas de stack
Las mismas objeciones salen a la superficie cada vez que aparece el kit. Merecen respuestas directas.
- ¿No puede un agente montar todo esto por mí? — Puede producir algo plausible; no puede verificar las uniones en una sola pasada. Un webhook idempotente se prueba, no se genera — el scaffolding te devuelve la misma lista otra vez.
- ¿No hace un boilerplate que los productos sean genéricos? — La fontanería es compartida; el producto no. Los hooks de arrastre, el comportamiento de bandeja y los conversores de SpinShare no existen en ninguna parte del kit — el diez por ciento que ven los clientes sigue siendo tuyo.
- ¿Y si solo necesito una app web? — El kit es la compra en cualquier caso; móvil y escritorio son superficies que adoptar o ignorar, no requisitos. SpinShare existe porque la superficie de escritorio ya estaba construida.
- ¿Es una utilidad de escritorio realmente la historia del comprador? — Es el ejemplo honesto más corto que tengo: dos días de un repositorio vacío a un envío a la tienda. La misma fontanería sirve a un SaaS — la checklist de lanzamiento es la versión larga.
- ¿Por qué no publicar simplemente la lista de stack? — Hecho: la guía de stack tecnológico nombra cada elección y su razón. Una lista es una carta, no un plan — el argumento aquí es comprar el plan ya construido.