// proceso

Cómo trabajamos.

Cuatro pasos. Cada uno se gana su sitio. Aquí tienes lo que es cada uno en la práctica y lo que puedes esperar en cada entrega.

01

Descubrir

Escuchamos. Investigamos. Cuestionamos las hipótesis antes de escribir código. Lo que sale es un brief escrito que todo el mundo firma, y un no claro a lo que no vamos a construir.

// nos dais

  • Tiempo en agenda con las personas que van a usar el producto
  • Acceso a los sistemas que ya existen
  • Respuestas honestas sobre las restricciones

// recibís

  • Brief de descubrimiento por escrito
  • Límites del alcance — dentro, fuera y aparcado para después
  • Primera versión de la arquitectura técnica

// duración

Definido por proyecto

02

Diseñar

Primero el prototipo. Cada píxel justificado. Lo ves antes de que lo construyamos. Diseñamos en código cuando tiene sentido, en Figma cuando no, y publicamos un build navegable que puedes poner delante de usuarios.

// nos dais

  • Guía de marca si existe
  • Webs de referencia que te gustan (y las que no)
  • Decisiones que no puedes delegar (las marcamos claramente)

// recibís

  • Prototipo Next.js navegable en una URL de staging
  • Documento del sistema de diseño
  • Pantallas anotadas para la fase de build

// duración

Definido por proyecto

03

Construir

Demos semanales, progreso transparente. Sin sorpresas al final. La rama siempre se puede desplegar, la demo siempre es honesta, y los cambios se estiman antes de comprometerlos.

// nos dais

  • 30 minutos semanales de revisión
  • Decisiones en menos de 48 horas cuando las pidamos
  • Confianza para empujarnos atrás cuando algo está mal

// recibís

  • Código en producción con CI/CD
  • Entorno de staging vivo
  • Grabación de demo semanal + changelog escrito

// duración

Definido por proyecto

04

Publicar

Lanzamos, monitorizamos, mantenemos. Lo que viene después del lanzamiento no es un añadido. Coordinamos el lanzamiento, vigilamos las métricas y estamos disponibles mientras todo se asienta.

// nos dais

  • Acceso a DNS y credenciales
  • Una hora para que recorramos el código con el equipo
  • Feedback honesto durante la ventana de soporte

// recibís

  • Lanzamiento a producción + plan de rollback
  • Runbook operativo
  • Ventana de soporte tras lanzamiento con SLAs de respuesta

// duración

Lanzamiento + ventana de soporte

“El proceso no es una presentación. Es si la demo es honesta y la URL de staging funciona un martes por la tarde.”

— Antonio, fundador
Cómo se ve esto en la práctica
Ver lo que hemos publicado →

¿Tienes un problema difícil?

Respondemos en menos de 24 horas. Cuéntanos qué estás construyendo.

Hablemos →
o reserva una llamada directamente