Cómo Trabajamos
Un proceso construido en torno a la entrega,
no a las reuniones.
Nos movemos rápido, comunicamos con claridad y entregamos software que funciona. Cada cliente sabe exactamente dónde está su proyecto — desde el día uno hasta el lanzamiento y más allá.
Seis fases. Cada proyecto. Sin atajos.
Esto no es una diapositiva de metodología. Así es como hemos entregado más de 150 proyectos. Cada fase tiene una salida clara — algo que podéis leer, aprobar o en lo que podéis hacer clic.
Qué ocurre
Aprendemos vuestro negocio, no solo vuestros requisitos. Entrevistas con las partes interesadas, auditoría técnica de cualquier sistema existente, revisión de arquitectura. Hacemos las preguntas incómodas ahora para que no aparezcan como sorpresas en la semana diez.
Resultado
Documento de alcance, recomendación de stack tecnológico, cronograma del proyecto, propuesta de precio fijo o T&M. Aprobáis antes de que nada comience.
Qué ocurre
Diseño del sistema antes de escribir una línea de código. Definimos el esquema de base de datos, contratos de API, plan de infraestructura y wireframes de UX cuando es necesario. Aquí es donde las decisiones que cuestan 100.000 € deshacer después se toman correctamente por 5.000 €.
Resultado
Documento de arquitectura, especificación de API, prototipo UI en Figma. El cliente aprueba antes de que comience la construcción. Sin sorpresas durante el desarrollo.
Qué ocurre
Sprints de dos semanas. Cada sprint entrega funcionalidades probadas y operativas — no tickets "en progreso" ni actualizaciones de "casi listo". Tenéis acceso al entorno de staging desde el día uno y podéis navegar funcionalidad real cada semana.
Resultado
Funcionalidades probadas y operativas desplegadas en staging cada sprint. Resumen escrito semanal cada viernes. Llamada de sincronización de 30 minutos, no una reunión de 2 horas.
Qué ocurre
Las pruebas no son una fase al final — se ejecutan en paralelo con la construcción desde el primer sprint. Antes de cada lanzamiento hay una revisión de QA dedicada. La revisión de seguridad es estándar para sectores regulados y compromisos solicitados.
Resultado
Informe de cobertura de pruebas, suite de pruebas automatizadas, resultados de escaneo de vulnerabilidades. Los problemas se corrigen antes de que se conviertan en vuestro problema.
Qué ocurre
Pipeline de CI/CD, despliegue sin tiempo de inactividad, rollout blue-green o canary cuando corresponde. No hacemos despliegues manuales. Monitorización completa y alertas configuradas. Rollback listo antes del lanzamiento.
Resultado
Sistema en producción activo, cuadros de mando de monitorización activos, alertas configuradas, procedimiento de rollback documentado y probado.
Qué ocurre
Documentación completa escrita durante el proceso — no entregada al final de golpe. Transferencia de conocimiento a vuestro equipo o retención para desarrollo continuo. Ventana mínima de hypercare de 30 días en la que estamos disponibles para cualquier cosa que surja tras el lanzamiento.
Resultado
Documentación técnica completa, runbooks, guías de despliegue. Ya sea una entrega limpia a vuestro equipo o un compromiso de retención para desarrollo continuo.
Cuatro cosas que realmente importan a los clientes.
No son diagramas de proceso. No son certificaciones ISO. Son las cosas que los clientes mencionan cuando nos recomiendan a alguien.
Respondemos a los mensajes
Respuesta en horas, no en días. Cada cliente tiene un gestor de proyecto dedicado y un ingeniero sénior como puntos de contacto directos. Ningún cliente se pregunta nunca dónde estamos o cuál es el estado actual. Si algo bloquea el progreso, os enteráis por nosotros primero.
Staging desde el día uno
Podéis ver y hacer clic en vuestro producto desde la semana uno — no solo al final del proyecto. Cada sprint se despliega en staging. Dais feedback sobre funcionalidad real, no sobre wireframes o informes de estado. Esto elimina el problema de "eso no es lo que imaginaba" en el momento del lanzamiento.
Nos hacemos cargo del alcance
Si lo definimos en el alcance, lo entregamos. No facturamos extras por cosas que deberían haber estado incluidas. Si nos faltó algo durante la definición del alcance — ese es nuestro problema, no el vuestro. Definimos cuidadosamente el alcance desde el inicio para no acabar en esa conversación.
Documentación sobre la marcha
No un volcado al final cuando el contexto se ha enfriado. Cada decisión arquitectónica, cada elección de implementación no obvia, cada contrato de API — documentado en el sprint en que se construyó. Cuando tomáis la propiedad del sistema, tenéis algo que realmente podéis mantener.
Exactamente cómo nos comunicamos. Sin ambigüedad.
Cada compromiso funciona con la misma estructura de comunicación. Sabéis qué esperar y cuándo. Sin sorpresas, sin tener que perseguirnos.
Actualizaciones diarias de progreso en vuestro canal. Veis lo que se hizo, lo que está en progreso y si algo está bloqueado — cada día laboral.
No una reunión de estado de 2 horas. Una llamada concisa de 30 minutos: qué se entregó, qué sigue, alguna decisión pendiente. Grabada y compartible.
Un gestor de proyecto y un ingeniero sénior son vuestros puntos de contacto designados. No una cola de soporte. Personas directas que conocen vuestro proyecto.
Resumen escrito del resultado de la semana, plan del próximo sprint y cualquier pregunta abierta. Se envía a quien necesite estar informado — PM, CTO, inversores.
Si algo sale mal, sabéis exactamente a quién llamar y qué ocurre después. No hay que averiguar quién es responsable en una crisis.
Cronogramas reales, no estimaciones que asumen que todo sale bien.
Basado en más de 150 proyectos. Los rangos reflejan variación real de alcance — no relleno, no ilusiones.
Descubrimiento + arquitectura + construcción + QA + despliegue. El alcance define el rango. Un MVP enfocado con 4–6 flujos principales queda en 6–8 semanas. Una plataforma multirol con integraciones son 10–14 semanas.
Trabajo de funcionalidad definida en una base de código existente. Depende de la complejidad de la integración con el código existente y de si el sistema tiene cobertura de pruebas adecuada.
Auditamos el sistema, estabilizamos los fallos críticos y entregamos una hoja de ruta priorizada. El trabajo de rescate continúa en ciclos de sprint desde ahí — el alcance depende de lo que revele la auditoría.
Preguntas antes de cada compromiso — respondidas directamente.
Sin relleno. Las preguntas reales que los clientes nos hacen antes de firmar, y las respuestas reales.
¿Cómo gestionáis los cambios de requisitos a mitad del proyecto?
Los esperamos. Los requisitos evolucionan — eso es normal. Gestionamos los cambios a través de un proceso ligero de cambio de alcance: describís lo que queréis diferente, estimamos el impacto en el cronograma y el coste, aprobáis, y ajustamos. Nada se añade silenciosamente a la factura. Nada se ignora tampoco. Si un cambio es pequeño (menos de 2 horas), generalmente lo absorbemos. Si es material, somos transparentes sobre lo que cuesta.
¿Trabajáis a precio fijo o T&M?
Ambos, dependiendo de lo que tenga sentido para el proyecto. Para MVPs bien definidos y trabajo de funcionalidades concretas, preferimos precio fijo — alinea incentivos y elimina ambigüedad. Para desarrollo continuo, mantenimiento y proyectos donde el alcance es genuinamente exploratorio, T&M con tope mensual es más limpio. Recomendamos qué modelo es el adecuado después del Descubrimiento. Hemos utilizado ambos en más de 150 proyectos.
¿Cuántas horas a la semana necesitará invertir mi equipo?
Para la mayoría de los proyectos: 2–4 horas por semana. Eso incluye la sincronización de 30 minutos, revisión asíncrona de Figma o staging, y aprobaciones. Si no estáis disponibles durante períodos prolongados, estructuramos el sprint para poder avanzar en elementos no bloqueantes. No retenemos el progreso como rehén de vuestro calendario.
¿Puedo ver el progreso antes de que el proyecto esté terminado?
Sí — ese es precisamente el objetivo de staging desde el día uno. Desde el primer sprint, tenéis una URL que podéis visitar y navegar funcionalidad real y operativa. No un vídeo demo, no una presentación. Un entorno de staging en vivo que se actualiza cada sprint. La mayoría de los clientes lo revisan varias veces por semana.
¿Qué ocurre después del lanzamiento?
Comienza la ventana de hypercare de 30 días. Monitorizamos producción, respondemos a cualquier problema en horas y nos encargamos de cualquier cosa que surja tras el lanzamiento. Después del hypercare, vosotros decidís: entrega completa a vuestro equipo con la documentación que hemos escrito durante todo el proyecto, o un compromiso de retención donde continuamos como vuestro socio de desarrollo. Ambos caminos os dejan en una buena posición.
¿Firmáis acuerdos de confidencialidad (NDA)?
Sí, antes de cualquier llamada de Descubrimiento donde se traten detalles comerciales confidenciales. Utilizamos un NDA mutuo. Si tenéis vuestra propia plantilla estándar, la revisaremos — la mayoría de los NDAs estándar son sencillos. Nos tomamos la confidencialidad en serio: los detalles de proyectos de clientes, arquitecturas y lógica de negocio nunca se comparten ni se referencian públicamente sin permiso explícito.
Contadnos qué necesitáis construir.
Haremos las preguntas correctas, definiremos el alcance honestamente y os diremos cuánto cuesta y cuánto tiempo lleva. Sin presentaciones comerciales, sin rodeos.