
Build vs Buy: Guía práctica para indie hackers
¿Deberías desarrollar esa funcionalidad tú mismo o pagar por una herramienta? Un framework para tomar decisiones build-vs-buy cuando tú eres todo el equipo técnico.
Eres una persona. Quizás dos. Tienes un producto que lanzar, clientes que atender, y una landing page que todavía dice "Coming Soon" en tres lugares. Y ahora tienes que decidir: ¿desarrollo esta funcionalidad yo mismo o pago por una herramienta?
Esta decisión es el mayor error de gestión del tiempo que cometen los indie hackers. Desarrolla lo incorrecto y pierdes semanas. Compra lo incorrecto y gastas dinero añadiendo una dependencia que no controlas.
Aquí tienes un framework que realmente funciona cuando eres un equipo de uno.
La respuesta por defecto debería ser "Comprar"
Es contraintuitivo para la mayoría de desarrolladores. Nos hicimos indie hackers porque nos gusta construir. Pero construir es lo más caro que puedes hacer. Tu tiempo es tu único recurso, y cada hora construyendo infraestructura es una hora menos en tu producto principal.
Las matemáticas son simples. Si una herramienta cuesta $20/mes y te ahorra 40 horas de desarrollo más 2 horas/mes de mantenimiento, tendrías que valorar tu tiempo en menos de $0,50/hora para justificar hacerlo tú mismo.
Cuándo construir
Hay exactamente cuatro situaciones donde construir tiene más sentido:
1. Es tu diferenciador principal
Si la funcionalidad es la razón por la que los clientes te eligen, debes ser dueño de ella. Stripe construyó su propio procesamiento de pagos porque los pagos SON su producto. Tú no deberías construir tu propio sistema de pagos.
2. No existe una buena herramienta
A veces el mercado no ha llegado ahí. Quizás necesitas una integración muy específica. En ese caso, construir está bien — pero pon un límite de tiempo. Si no puedes tener una versión funcional en una semana, el alcance está mal.
3. La herramienta crea un lock-in inaceptable
Si cambiar de herramienta requeriría reescribir una parte central de tu app, piénsalo bien. Hosting de base de datos? Ok — tus datos son portables. Un motor de workflows propietario que guarda toda tu lógica de negocio? Peligroso.
4. El coste escala mal
Algunas herramientas cobran por usuario, por evento o por llamada API. Si puedes ver un futuro donde la herramienta cuesta más que tus ingresos, es un problema real.
Ejemplo real: recolección de feedback
Supongamos que quieres añadir un widget de feedback a tu SaaS. Tres opciones:
Opción A: Construirlo. Formulario, endpoint API, tabla en base de datos, dashboard. Luego notificaciones. Luego los usuarios quieren análisis de sentimiento. Luego una roadmap pública. Mínimo 3-4 semanas, más mantenimiento eterno.
Opción B: Herramienta enterprise compleja. $79/mes por una plataforma con 200 funcionalidades que no necesitas. Una semana configurando. $948/año para algo sobredimensionado.
Opción C: Herramienta enfocada. Dos líneas de código y el feedback empieza a llegar. La herramienta cuesta $0-20/mes y gestiona widget, dashboard, sentimiento, roadmap y changelog. 5 minutos en vez de 4 semanas.
La opción C es casi siempre la respuesta correcta. Herramientas como Palmframe existen precisamente para esto — instalación en dos líneas, plan gratuito para empezar, y funcionalidades enfocadas.
El coste oculto de construir
Cuando construyes algo, no solo pagas el coste inicial. Te comprometes a:
- Corrección de bugs — los usuarios encontrarán casos que no pensaste
- Parches de seguridad — especialmente para todo lo que expones al usuario
- Peticiones de funcionalidades — "¿el formulario también puede hacer X?"
- Costes de infraestructura — hosting, monitorización, backups
- Coste de oportunidad — cada hora de mantenimiento es una hora no invertida en crecimiento
El stack indie hacker
Lista práctica de qué comprar vs construir para un SaaS típico:
Comprar (casi siempre):
- Autenticación (Clerk, Auth0, o nativo del framework)
- Pagos (Stripe, Lemon Squeezy)
- Email (Resend, Postmark)
- Recolección de feedback (Palmframe)
- Monitorización de errores (Sentry)
- Analytics (Plausible, PostHog)
Construir (es tu producto):
- Tu funcionalidad principal — aquello por lo que los usuarios pagan
- Workflows personalizados específicos de tu dominio
La regla única
En caso de duda, pregúntate: "Si paso esta semana construyendo esto, ¿lo notarán mis clientes?"
Si la respuesta es no — si estás construyendo infraestructura, herramientas internas o funcionalidades que ya existen — cómpralo y dedica esa semana a algo por lo que los clientes pagarán.
Tu ventaja competitiva no es tu widget de feedback, tu sistema de auth ni tu pipeline de emails. Es esa cosa que solo tú puedes construir. Invierte tu tiempo ahí.
Want to start collecting feedback? Try Palmframe for free — takes 2 minutes to set up.