01 · 2 semanas
Scope
Definimos el límite del MVP: los must-have y los "esto no". El alcance se cierra antes de fijar el precio.
● MVP BUILD · ESPAÑA & LATAM
Production-grade
desde el día uno.
Para founders que empiezan de cero y quieren un MVP real, no un prototipo que rompe con el primer cliente que paga. Alcance fijo, precio fijo. Ingeniería senior más un pipeline de IA supervisado.
- Build
- 6–12 sem
- Por horas
- 0
Esto es para ti si…
Prefieres construirlo bien una vez que reconstruirlo dos.
- Empiezas de cero y tienes recursos para hacerlo bien.
- Ya has visto MVPs construidos con IA romperse con el primer cliente real.
- Quieres production-grade desde el inicio: auth real, CI real, tests reales, arquitectura real.
- Un timeline de 6–12 semanas te encaja: prefieres lo correcto a lo apresurado.
- Prefieres un ingeniero senior responsable a un equipo de agencia que rota.
Si tres o más encajan, el siguiente paso es la scoping call.
Con quién trabajarías
Un solo ingeniero senior, responsable de principio a fin.
Francisco Philip · France · UTC+1
+30 años de criterio senior. 10 con startups. Build hands-on, no delegado a un equipo que rota.
Defino la arquitectura antes del primer commit y la ejecuto con un pipeline de IA supervisado: la IA pone las teclas, el criterio es mío. Tratas con la persona que construye, no con un account manager.
Cómo sucede el trabajo
La arquitectura se decide antes del primer commit.
02
Arquitectura
Modelo de datos, auth, deploy y terceros: decididos y aprobados antes del primer commit.
03 · 6–10 semanas
Build
El pipeline supervisado ejecuta. Demos semanales, check-ins quincenales con stakeholders y updates async diarios.
04
Verify
Cobertura de tests, revisión de seguridad, load testing y usuarios reales en staging.
05
Ship
Deploy a producción con monitoring activo y handoff completo.
06
Hand off
Doc de arquitectura, runbooks, guía de deploy y 30 días de estabilización post-launch.
Qué significa production-grade de verdad
Lo que se rompe en el mes 3 si no lo construyes el día uno.
Auth
Email + magic link u OAuth, RBAC y row-level security donde el modelo de datos lo pida. Refresh de sesión sin race conditions.
CI/CD
GitHub Actions (o equivalente) en cada commit: lint, type-check, test, build y deploy preview. El build rojo bloquea el merge.
Tests
Unit en funciones puras, integración en el borde de la API, smoke en las rutas críticas. Umbrales de cobertura aplicados.
Datos
Postgres con constraints explícitas, foreign keys reales, índices en las queries que importan y migraciones versionadas y reversibles.
Observabilidad
Sentry o equivalente para errores. Logs estructurados. Dashboards de las tres métricas que te dicen que el sistema está vivo.
Runbooks
Los 5 modos de fallo más probables, documentados con sus pasos de diagnóstico.
Qué incluye
Un engagement. Alcance fijo, precio fijo.
Alcance fijo, precio fijo
6–12 semanas
Alcance fijo, precio fijo. Sin facturación por horas, sin markup de agencia.
- Auth, CI/CD, tests y monitoring reales — no maquetas.
- Documentación de arquitectura, runbooks y guía de deploy.
- 30 días de estabilización post-launch incluidos.
- Demos semanales, check-ins quincenales y updates async diarios.
- Propiedad del IP: el código vive en tu repo, sin vendor lock-in.
- Opción de graduar a un retainer de pipeline tras el launch.
Resultados
Preguntas
Respuestas directas.
¿Qué significa "production-grade" exactamente?
Production-grade significa que el sistema está preparado para usuarios reales desde el día 1: auth real (no maqueta), CI/CD que bloquea merges con build rojo, tests con cobertura aplicada, base de datos con constraints e índices reales, monitoring de errores (Sentry o equivalente) y runbooks para los 5 modos de fallo más probables. Es lo que evita que el sistema se rompa en el mes 3, cuando llegan los primeros 1.000 usuarios.
¿Puedes ir más rápido?
Depende del alcance, pero acelerar sin cerrar el scope es la causa número 1 de MVPs que hay que reescribir. El pipeline de IA supervisado ya acelera la ejecución significativamente — el límite no es la velocidad de código sino el tiempo de toma de decisiones de producto. Prefiero entregar lo correcto en 10 semanas que lo equivocado en 6.
¿Lo mantienes después del launch?
Los primeros 30 días de estabilización post-launch están incluidos: monitorizamos, corregimos bugs críticos y aseguramos que el sistema aguante la carga inicial. A partir del día 31, hay opción de graduar a un retainer de CTO externo o de salida limpia con handoff completo. Sin permanencia forzada.
¿Y si me quedo sin presupuesto a mitad del build?
El precio es fijo y se conoce antes del primer commit, por lo que la exposición financiera es predecible desde el inicio. Si el proyecto se interrumpe por cualquier motivo, el trabajo hecho es tuyo: el código vive en tu repo desde el día 1, con documentación del estado del sistema. No hay lock-in ni código retenido.
¿Puedes hacer white-label?
No. El trabajo es directo: tratas con el ingeniero que diseña y construye el sistema, sin intermediarios ni subcontratación a agencias. Esto elimina el overhead de comunicación y la dilución de criterio técnico que suele ocurrir en modelos de agencia.
¿Aceptas equity en vez de cash?
El default es cash con precio fijo. En casos muy concretos (early-stage con producto validado y runway suficiente) puede estructurarse un componente de equity parcial, nunca como sustituto completo del cash. La mayoría de proyectos funcionan mejor con cash: alinea incentivos sin complicar la cap table.
¿En qué stacks construyes?
Stacks web modernos: Next.js / Remix en frontend, Node.js / Python (FastAPI, Django) en backend, Postgres como base de datos principal, y deploy en Vercel, Render, Fly.io o AWS según el caso. El trabajo mobile nativo (iOS/Android) se deriva. La elección de stack siempre depende del problema, no de preferencias personales.