Construir un producto digital no es escribir código. El código es la última etapa, la más visible, y casi nunca la que decide si el producto sale bien o sale mal. Las decisiones que importan se toman antes — y las que se toman mal después son las que matan proyectos.
Llevo 5 años construyendo sitios y productos digitales para empresas, y el proceso que uso hoy es el resultado de equivocarme caro varias veces: subestimar scope, descubrir el problema real demasiado tarde, entregar algo técnicamente perfecto que el cliente no usa. Lo que sigue es lo que termino aplicando en cada proyecto, sin importar si es una landing de 1 semana o una herramienta interna de 3 meses.
El principio que ordena todo
Antes del código va el problema. Antes del problema va la pregunta.
Cuando un cliente me dice "necesito una nueva web", la primera pregunta no es "qué stack querés" o "cuántas páginas". Es "¿qué pasa si no la hacés?". La respuesta a esa pregunta define el alcance, el budget, y qué entrego primero. Si la respuesta es "nada urgente, queremos que se vea más moderna", el proyecto es uno. Si la respuesta es "estamos perdiendo deals porque la competencia se ve más profesional", el proyecto es completamente otro.
Esto es lo que separa "construir lo que pidieron" de "resolver el problema". Lo primero llena agendas y vacía clientes. Lo segundo crea relaciones largas.
Etapa 1 · Discovery (días 0-3)
El discovery es la etapa más subestimada y la única que no se puede comprimir sin romper todo lo que viene después. Yo la hago así:
Una sola call de 30 minutos
Sin presentación de slides. Sin "metodología". Solo preguntas. Las que más sirven son las que parecen tontas: "¿cómo se enteran los clientes de ustedes hoy?", "¿qué hace que alguien diga sí o no?", "¿qué pasaría si no hicieran este proyecto?". La mayoría de los clientes no se hizo esas preguntas conscientemente, y la conversación las saca.
Auditoría rápida del estado actual
Mientras hablamos, abro su sitio (o su producto, o su flujo) en pantalla compartida. Voy anotando 5-10 cosas que cambiaría. No para mostrarme inteligente — para tener observaciones concretas con las que armar la propuesta. El cliente ve que entiendo el contexto antes de prometer nada.
Research silencioso
Después de la call, paso 1-2 horas mirando 3-5 competidores reales. No para copiar — para mapear el terreno. ¿Quién está haciendo SEO bien? ¿Quién está mostrando precios? ¿Quién tiene un proceso claro? Esto se traduce directamente en la sección "Entendimiento estratégico" de mi propuesta.
Etapa 2 · Propuesta (días 3-5)
La propuesta es el primer entregable real del proyecto. No un PDF genérico — una página web propia con 8 secciones, hecha específicamente para ese cliente, que ellos pueden revisar offline y compartir internamente.
La estructura que uso siempre:
- Lo que escuché. Los puntos del meet, en bullets, con sus palabras.
- Entendimiento estratégico. Lo que aprendí del research del sector.
- Alcance. Módulos concretos con tags de fase (F1, F2). Sin generalidades.
- Timeline. Semanas con milestones específicos.
- Inversión. Números claros en USD. Sin "depende".
- Lo que queda afuera. Transparencia total: si no incluye fotos profesionales o traducción, lo dice acá.
- Qué necesito para arrancar. Checklist de inputs del cliente.
- Por qué Huevsite. 4 diferenciales concretos.
La propuesta se manda con un mensaje corto y una invitación a una review call de 15 minutos a las 24-48 horas. Esa call cierra el 70% de los deals — la propuesta hizo el trabajo pesado, la call solo destraba dudas.
Etapa 3 · Kickoff (semana 1)
Kickoff = 50% inicial cobrado, acceso a un canal directo (email o Slack 1-a-1, sin intermediarios), y entrega de 3 cosas en la primera semana:
- Moodboard visual. 8-12 referencias específicas de cómo va a sentirse el producto. No moodboards genéricos de Pinterest — referencias reales que el cliente puede comparar.
- Paleta + tipografía. 2-3 colores principales, 1-2 fuentes, aplicadas a un mock real de la home. No "exploración tipográfica" — decisiones tomadas.
- Arquitectura de información. Qué páginas, qué secciones por página, qué CTA por sección. En texto plano, sin diseño todavía. Esto es el contrato de scope.
Al final de la semana 1, el cliente firma (literalmente o por aprobación escrita) el moodboard, la paleta y la arquitectura. Si no firman, no avanzo al diseño visual. Esto evita el clásico "ya lo veo terminado y no me gusta" en la semana 5.
Etapa 4 · Diseño + Dev (semanas 2-5)
Acá es donde la mayoría espera que entre el "código mágico". No es así. Lo que hago es:
- Diseño y dev en paralelo, no en serie. Diseño la home en alta fidelidad mientras desarrollo el sistema base (componentes, layout, dark mode si aplica). Cuando aprueban la home, el resto del sitio sale 5x más rápido porque ya está la base técnica.
- Reviews semanales con avance real. Todos los lunes una call de 30 minutos con un Vercel preview deploy del estado actual. Sin mockups eternos — el cliente clickea, navega, prueba.
- Decisiones rápidas. Cuando aparece una decisión que no estaba en el scope ("¿agregamos un FAQ?"), la conversamos en el momento, no la diferimos. Si suma scope, lo agregamos como adicional. Si reemplaza algo, ajustamos. Sin ambigüedad, sin "lo vemos al final".
Etapa 5 · Pre-deploy (semana 4-5)
La semana antes del deploy es la más importante técnicamente. Acá entran las cosas que el cliente no ve pero que decidirán si el sitio funciona:
- Performance. Lighthouse 95+ en mobile, LCP < 1.5s, CLS < 0.05. Si no llega, ajusto antes del deploy.
- SEO técnico. Sitemap.xml, robots.txt, canonical URLs, hreflang si aplica, schema.org en cada página relevante.
- AEO. llms.txt, llms-full.txt, structured data validada en Rich Results Test, contenido con jerarquía semántica clara.
- Analytics. GA4 con events de conversión específicos (no solo pageviews), Search Console verificado, eventos de form submission.
- Tests cross-browser y cross-device. Safari iOS, Chrome Android, Edge desktop, Firefox. Si algo se rompe, se arregla antes del deploy.
- Backup y rollback plan. Si algo falla en producción, tengo un rollback de 1 click.
Etapa 6 · Deploy + Handoff (semana 5)
El deploy es un evento, no un proceso largo. Una hora de trabajo coordinado: cambio de DNS, verificación de SSL, smoke tests, primera revisión del cliente. Después de confirmar que todo está bien, viene el handoff:
- Training del admin. Una call de 30-45 minutos donde le muestro al cliente cómo editar contenido, agregar productos, cambiar imágenes. Grabada para que la consulten después.
- Documentación operativa. Un documento corto con: cómo acceder al admin, cómo hacer cambios comunes, qué NO tocar, a quién contactar para qué.
- Credenciales y accesos. Vercel, dominio, GA4, Search Console, admin del CMS. Todo transferido al cliente.
- 50% restante cobrado. Una vez el cliente confirma que todo está OK.
Lo que viene después
Incluyo 30 días de soporte después del deploy para ajustes finos: typos, microajustes de copy, bugs que aparecen con uso real. Después de los 30 días, paso a un esquema de mantenimiento mensual opcional o trabajamos por proyecto puntual.
Lo que NO hago: contratos de mantenimiento obligatorios. El cliente debería poder no necesitarme. Si me llaman 6 meses después es porque el sitio les funcionó tan bien que están listos para la próxima fase.
El error más caro que me enseñó esto
En 2022 entregué un dashboard interno técnicamente perfecto. Performante, escalable, con tests, con docs. El cliente lo usó dos semanas y volvió a Excel. Cuando le pregunté por qué, me dijo: "está demasiado bien hecho, mi equipo no se anima a tocarlo".
Ahí entendí: el output técnico no es el producto. El producto es lo que el cliente puede usar todos los días, sin miedo, sin abrir tickets. Desde entonces, la última pregunta antes de cerrar cada proyecto es: "¿esto se va a usar el lunes a las 9 AM o no?". Si la respuesta no es un sí claro, falta trabajo.
¿Estás pensando en construir un producto digital? En 30 minutos te ayudo a separar el problema real del problema declarado. Agendar diagnóstico.