"Necesitamos construir nuestro propio framework de testing. Las herramientas estándar no cubren nuestros casos de uso específicos."
Tu Tech Lead acaba de presentarte una propuesta de 6 semanas para desarrollar un framework de testing custom para tu aplicación SaaS. Argumentos sólidos: mayor flexibilidad, integración perfecta con tu stack, control total sobre features.
Pero antes de aprobar esas 6 semanas de desarrollo, deberías hacerte una pregunta: ¿Tu startup realmente necesita un framework custom, o estás cayendo en la trampa del "Not Invented Here"?
Esta es la guía completa de decisión build-vs-buy para frameworks de testing, basada en 17 implementaciones de QA en startups Serie A-B que hemos hecho en onext.
El síndrome "Not Invented Here" en testing
El síndrome NIH (Not Invented Here) es la tendencia de equipos técnicos a preferir soluciones desarrolladas internamente sobre soluciones externas probadas, incluso cuando las externas son objetivamente mejores.
En testing, se manifiesta así:
- "Nuestro caso de uso es único": Creemos que nuestra aplicación es tan especial que frameworks estándar (Jest, Cypress, Playwright) no pueden manejarla
- "Queremos control total": Preferimos escribir abstracciones propias sobre herramientas existentes para "mayor flexibilidad"
- "Es más rápido hacerlo nosotros": Subestimamos el esfuerzo de mantener infraestructura custom
- "Nuestros developers son mejores": Creemos que podemos construir algo superior a herramientas con millones de usuarios y años de madurez
Realidad dura: En 14 de 17 startups que auditamos, el framework de testing custom que construyeron en 4-8 semanas terminó siendo abandonado o reemplazado por herramientas estándar en menos de 12 meses. Costo: €30-60k en developer time sin ROI.
Framework de decisión: 4 criterios para Build vs Buy
Usa estos 4 criterios para decidir si deberías construir un framework de testing custom o adoptar herramientas estándar:
Criterio 1: ¿Tu caso de uso es realmente único?
Test de unicidad: Responde estas preguntas con honestidad.
- ¿Hay más de 100 empresas en el mundo haciendo algo similar a lo que hacés? → No eres único
- ¿Tu stack es Node/Python/Java + SQL/NoSQL + REST/GraphQL? → No eres único
- ¿Testeas UI web, APIs, o integración de servicios? → No eres único
- ¿Necesitas tests unitarios, integración, y e2e? → No eres único
Si respondiste "sí" a alguna, herramientas estándar ya cubren tu caso de uso.
Casos donde SÍ eres único (build puede tener sentido):
- Testeas hardware embebido con protocolos propietarios
- Testeas sistemas de tiempo real con restricciones de latencia <1ms
- Testeas algoritmos de trading de alta frecuencia donde timing es crítico
- Testeas sistemas legacy con protocolos binarios custom de los 90s
Regla de oro: Si Google, Facebook, Airbnb, y 10,000 startups más resolvieron el mismo problema de testing con herramientas open-source, probablemente vos también puedas.
Criterio 2: ¿Cuál es el TCO (Total Cost of Ownership)?
Comparemos el costo total de build vs buy en 3 años:
Escenario A: Build (framework custom)
Año 1:
- Desarrollo inicial: 6 semanas x 2 developers senior x €65/hora x 40h = €31,200
- Debugging y estabilización: 2 semanas adicionales = €10,400
- Documentación interna: 1 semana = €5,200
- Total año 1: €46,800
Año 2-3:
- Mantenimiento (bug fixes, compatibilidad con nuevas versiones de dependencias): 2 horas/semana x 52 semanas x €65/h = €6,760/año
- Nuevas features (soporte para nuevos tipos de tests): 3 semanas/año = €15,600/año
- Onboarding de nuevos developers: 4 horas por developer x 6 developers x €65/h = €1,560/año
- Total año 2-3: €23,920/año x 2 años = €47,840
Costo total 3 años: €94,640
Escenario B: Buy (herramientas estándar: Jest + Playwright + GitHub Actions)
Año 1:
- Setup inicial: 1 semana x 1 developer senior = €2,600
- Configuración custom (reporters, fixtures, helpers): 1 semana = €2,600
- Training del equipo: 4 horas = €260
- Licencias: €0 (herramientas open-source)
- CI runners (GitHub Actions): €50/mes x 12 = €600
- Total año 1: €6,060
Año 2-3:
- Mantenimiento: 0 (comunidad mantiene las herramientas)
- Actualizaciones: 2 horas/año x €65/h = €130/año
- CI runners: €600/año
- Onboarding: 0 (documentación oficial + Stack Overflow)
- Total año 2-3: €730/año x 2 años = €1,460
Costo total 3 años: €7,520
Criterio 3: ¿Tenés el expertise interno para mantenerlo?
Construir un framework de testing no es solo escribir código. Es:
- Diseñar APIs intuitivas para que el equipo las adopte
- Mantener compatibilidad con actualizaciones de tus dependencias (Node, browsers, librerías)
- Debuggear edge cases que solo aparecen en CI y no en local
- Documentar exhaustivamente para onboarding de nuevos developers
- Dar soporte interno cuando algo no funciona ("¿por qué este test es flaky?")
Pregunta crítica: ¿Tenés a alguien en el equipo que quiera ser "maintainer" de este framework durante los próximos 2-3 años?
Si la respuesta es "no", no construyas. Vas a tener un framework semi-abandonado que nadie entiende bien y nadie quiere tocar.
"Construimos un framework de testing custom en 2022. El developer que lo diseñó se fue de la empresa en 2023. Ahora nadie sabe cómo funciona internamente. Cada vez que algo se rompe, perdemos horas debuggeando. Deberíamos haberlo migrado a Playwright hace un año."
— CTO de SaaS B2B (Barcelona), 12 developers
Criterio 4: ¿Construir el framework te da ventaja competitiva?
La pregunta definitiva: ¿Tener un framework de testing mejor que tus competidores hace que tus clientes te elijan a vos en lugar de ellos?
Respuesta honesta: No. A tus clientes no les importa si usás Jest o un framework custom. Les importa que tu producto funcione sin bugs.
Tu ventaja competitiva está en:
- Features que tus competidores no tienen
- UX superior
- Performance mejor
- Integraciones que otros no ofrecen
- Pricing más inteligente
Tu framework de testing es infraestructura interna. No genera revenue directamente. Invierte developer time en lo que SÍ diferencia tu producto.
Regla de Bezos aplicada a testing: "Amazon construye internamente solo lo que genera ventaja competitiva directa. Todo lo demás se compra o usa open-source." Aplicá la misma regla a tu framework de testing.
Cuándo SÍ tiene sentido invertir en QA custom
No todo es blanco o negro. Hay escenarios donde invertir en infraestructura de QA propia tiene sentido. Pero el enfoque es diferente a "construir un framework desde cero".
Opción smart: Centro de Excelencia de QA (no framework custom)
En lugar de construir un framework, construís metodología, procesos, y expertise sobre herramientas estándar.
Un CoE de QA incluye:
- Testing strategy documentada
- Qué testear en cada nivel (unit, integration, e2e)
- Cobertura target por tipo de código (business logic: 80%, UI: 50%, utils: 95%)
- Cuándo usar mocks vs real dependencies
- Herramientas estándar configuradas con best practices
- Jest con custom reporters para métricas de cobertura
- Playwright con page object model para tests e2e mantenibles
- GitHub Actions con matrix testing (multi-browser, multi-OS)
- Visual regression testing con Percy o Chromatic
- Helpers y utilities custom (no framework completo)
- Factories para crear test data consistente
- Custom matchers para aserciones específicas de tu dominio
- Fixtures para setup/teardown de test environments
- CI/CD optimizado para testing rápido
- Parallelization de tests (correr 100 tests en 3 minutos en lugar de 20)
- Smart test selection (solo correr tests afectados por el changeset)
- Flaky test detection y auto-retry
- Cultura de quality ownership
- Developers escriben tests como parte del PR (no un QA team separado)
- Code review incluye review de tests
- Métricas de calidad visibles (coverage, flakiness, MTTR de bugs)
Resultado: Tenés testing de clase mundial sin mantener un framework custom.
Caso de éxito real: SaaS de eCommerce (Serie B, €2.5M ARR)
Contexto inicial (2024):
- Equipo de 14 developers, 0 QA engineers
- Coverage: 28% (principalmente tests escritos "por obligación", no por convicción)
- Tests e2e: 0 (testing manual antes de cada release)
- Bugs en producción: 12-15 por mes
- Tiempo de testing manual pre-release: 8 horas por developer
Transformación (8 semanas de CoE de QA con onext):
Semana 1-2: Auditoría + Testing strategy
- Identificamos 3 áreas críticas con 0 coverage que causaban el 70% de bugs en producción
- Diseñamos testing pyramid: 70% unit, 20% integration, 10% e2e
- Definimos coverage targets por tipo de código
Semana 3-4: Setup de herramientas + Quick wins
- Configuramos Jest con custom reporters para visualizar coverage por feature
- Implementamos Playwright para tests e2e de user flows críticos
- Agregamos 187 tests unitarios en áreas críticas (business logic de checkout y payments)
- Coverage subió de 28% a 54%
Semana 5-6: CI/CD optimization + Flaky tests elimination
- Configuramos GitHub Actions con matrix testing (3 browsers x 2 OS)
- Implementamos paralelización: tests bajaron de 18 minutos a 4 minutos
- Identificamos y arreglamos 12 tests flaky (de 14 totales)
Semana 7-8: Enablement + Handoff
- Training de 4 sesiones para todo el equipo de desarrollo
- Documentación interna: Testing playbook con ejemplos reales del codebase
- Definimos 2 "testing champions" internos para evangelizar
Resultados (6 meses post-implementación):
- Coverage: 76% (vs 28% inicial)
- Tests e2e: 42 tests covering 90% de user flows críticos
- Bugs en producción: 3-4 por mes (reducción de 75%)
- Tiempo de testing manual pre-release: 0 (todo automatizado)
- Confidence de equipo: "Ahora deployamos sin miedo"
Decision tree: Build vs Buy vs CoE
Usa este árbol de decisión para determinar tu estrategia:
¿Tu caso de uso es genuinamente único?
- Sí (hardware embebido, trading HFT, protocolos propietarios) → Consider BUILD framework custom
- No (web app, mobile app, APIs estándar) → Continuar análisis ↓
¿Tenés >€100k de developer time disponible para invertir en 3 años?
- No → BUY herramientas estándar (Jest, Cypress, Playwright)
- Sí → Continuar análisis ↓
¿Tenés expertise interno en testing frameworks y alguien committed a mantenerlo?
- No → BUY herramientas estándar
- Sí → Continuar análisis ↓
¿Un framework mejor te da ventaja competitiva directa?
- No → BUY herramientas estándar
- Sí (eres una empresa de testing-as-a-service) → BUILD puede tener sentido
¿Tu testing actual tiene cobertura <60% y bugs frecuentes en producción?
- Sí → Implementar CENTRO DE EXCELENCIA DE QA sobre herramientas estándar
- No → Mantener herramientas actuales y optimizar procesos
Errores comunes al decidir Build vs Buy
- Subestimar el costo de mantenimiento a largo plazo
El 80% del costo de un framework custom no es el desarrollo inicial, es el mantenimiento durante 3+ años. No lo olvides. - Overengineer la solución desde día 1
Si decidís build, empezá con un MVP súper simple. No construyas abstracciones para casos de uso que todavía no existen. - No medir ROI de la decisión
Define métricas antes de empezar: ¿Cuánto tiempo ahorrás? ¿Cuántos bugs menos? ¿Cuánto más rápido onboardeás developers? Si no mejorás esas métricas, la decisión fue incorrecta. - Ignorar el "time to market"
6 semanas construyendo un framework son 6 semanas no entregando features. ¿Vale la pena el trade-off? - No considerar la opción híbrida (CoE)
No es build o buy. Podés usar herramientas estándar + metodología de clase mundial. Eso es un Centro de Excelencia de QA.
¿Tu equipo está debatiendo build vs buy para testing?
Si tu equipo propuso construir un framework de testing custom, no lo apruebes inmediatamente ni lo rechaces de entrada.
Hacé una auditoría técnica de 2-3 días para evaluar:
- ¿El caso de uso es realmente único o ya existe una solución probada?
- ¿Cuál es el TCO real de build vs buy en 3 años?
- ¿Qué métricas de calidad estamos tratando de mejorar?
- ¿Un Centro de Excelencia de QA resolvería el problema sin build custom?
En onext implementamos Centros de Excelencia de QA en startups Serie A-B. En 6-8 semanas, transformamos tu testing de "coverage <40% con bugs frecuentes" a "coverage >70% con tests rápidos y confiables".
Sin construir frameworks custom. Sin mantener infraestructura propia. Sin paralizar entregas.