Si acabas de empezar a trabajar con nosotros —como freelance o dentro del equipo—, este capítulo es lo que necesitas interiorizar. No va tanto de qué herramientas tocamos, sino de cómo nos relacionamos con el cliente. Nuestra forma de trabajar es bastante particular, y las veces que nos hemos saltado el proceso es cuando peor ha salido.
La idea de fondo es la del capítulo de cultura: trabajamos en proyectos de alta incertidumbre y nos comportamos como una extensión del equipo de producto del cliente, no como un proveedor más. De ahí sale casi todo lo que viene abajo: ser rápidos, cercanos, transparentes y muy abiertos a que las cosas cambien por el camino.
Cinco fases, un mismo principio
Todo proyecto pasa por cinco fases. No es un guion rígido, son etapas por las que conviene pasar siempre:
- Preventa — entender al cliente y decidir si el proyecto es para nosotros.
- Kickoff — la parte administrativa y de arranque (contrato, cuentas, canales).
- Definición — aterrizar cómo vamos a construirlo.
- Construcción — sprints semanales hasta tener el producto.
- Entrega — mostrarlo, documentarlo y traspasarlo.
El principio que las atraviesa: reduce la incertidumbre y enseña cuanto antes. Todo lo demás son detalles.
La preventa es donde se gana el proyecto
El 90% del éxito de un proyecto se decide antes de escribir una línea. La mayoría de clientes nos llegan de forma inbound (por posicionamiento y comunidad, no porque salgamos a vender). Recibimos un lead, hacemos un triaje y tenemos una reunión de entendimiento de 15–30 minutos. Ahí se gana o se pierde el proyecto.
Aprender a decir que no es parte del trabajo. A veces la mejor respuesta es "no soy la persona adecuada para tu proyecto". Cómo distinguir:
- Huye del cliente que lidera con el precio. El que ha pedido su MVP a un estudio de desarrollo, le han dicho 40–60k€ y busca hacer "lo mismo" por 5k. En el 98% de los casos no es tu cliente: viene con mentalidad de proveedor tradicional —tiempos fijos, scope cerrado— y no encaja.
- Busca al que entiende el valor del no-code. No la ganga, sino la velocidad: definimos mejor el producto y creamos una primera versión más rápida y barata. Somos fuertes en primeras versiones y MVPs, en la incertidumbre. Somos débiles cuando el negocio ya sabe exactamente lo que quiere y compite contra equipos de desarrollo de 20 personas.
- Las vibes cuentan. Si en esa primera media hora no hay feeling con la persona, para nosotros es un no. Si no os entendéis ahora, no os vais a entender durante el proyecto.
Y una cosa que dejamos clara desde el minuto uno: el no-code casi siempre tiene un trade-off. No significa que no podamos hacer algo; significa que el cliente tiene que estar abierto a hacerlo un poco distinto si por el camino aparece una limitación. El cliente que no es flexible con el "cómo" no es un buen cliente para no-code.
Para decir que no, transparencia: "no me encaja, y te recomiendo a esta persona porque va a ser mejor fit para ti". Es lo ideal, y deja buena relación.
La reunión de entendimiento
No tenemos un guion cerrado, pero sí un orden que funciona:
- Escuchar primero. Siempre, aunque nos hayan mandado documentación. Queremos oír de su boca qué quieren hacer.
- Comprobar que le hemos entendido. Abrimos un FigJam y le pintamos los flujos ("entiendo que quieres un marketplace con estos usuarios que hacen esto…"). Si dibujándolo se ve que no lo teníamos claro, mejor una segunda reunión que lanzarse a la piscina.
- Sacar presupuesto y tiempos. ¿Hay fecha límite? ¿Cuánto presupuesto hay para esto? Intenta siempre sacarles un número; si lo dices tú primero, pierdes.
- Integraciones y límites técnicos. Si hay que conectar con un sistema, que te pasen la API; que levanten la mano con cualquier riesgo legal.
El objetivo de fondo es separar qué pide de qué necesita. Muchas veces el cliente no sabe lo que necesita porque no conoce las alternativas que conocemos nosotros. Esta reunión es casi una consultoría —gratis— en la que aportamos ese criterio.
La prueba de concepto
De esa reunión podemos salir con tres niveles de entendimiento: lo entendemos del todo (adelante), lo entendemos pero hay riesgos, o incertidumbre total. Cuando hay una duda técnica de "¿seré capaz de hacer esto?", no adivinamos: hacemos una prueba de concepto antes de comprometernos.
Con IA hoy esto es rapidísimo. Coges lo que sacaste de la reunión, montas un prototipo en unas horas y se lo enseñas con un Loom junto a la propuesta. Cuando lo haces bien, el ratio de aceptación es altísimo: el cliente percibe en un día un valor que por otro lado le habría costado meses. Lo ideal es que te paguen esa prueba de concepto (startups con ronda, corporaciones); cuando no, se hace gratis y también nos sirve a nosotros para elegir herramienta y validar los flujos clave.
Un ejemplo real: una landing en Framer con un carrusel muy concreto que nativamente no se podía hacer. Como el cliente lo quería exactamente así y no había flexibilidad, dijimos que no. En otro caso parecido —un efecto de sello— sí nos lanzamos con código (el plugin Workshop de Framer) y ayuda de un colaborador. La diferencia siempre es la misma: cuánta flexibilidad tiene el cliente y cuánto riesgo podemos asumir.
La propuesta y el precio
Lo bajamos todo a una propuesta con un roadmap por semanas. Calculamos en sprints semanales: el precio del proyecto es nº de semanas × precio por semana.
- Con equipo: coste de los perfiles por semana + tu margen.
- Como freelance: tu tarifa por hora × las horas, con un buffer encima (si crees que son 4 semanas, véndelo a 5). Es fácil equivocarse en la estimación, y esa estimación la vas afinando con experiencia.
- Muchas veces el cálculo es al revés: el cliente tiene 8.000€ y el proyecto pasa a costar 8.000€.
Como referencia de mercado: un MVP suele moverse entre 5–15k€ y una web entre 100€ y 10k€, según complejidad, marca y posicionamiento. El cobro: 50/50 (mitad al empezar, mitad al terminar) en proyectos cortos, o mensual en proyectos largos. En no-code no vendemos "mantenimiento" como tal —el cliente paga su suscripción—; lo ofrecemos como bolsa de horas o, en proyectos tipo Lovable, como mantenimiento mensual.
Kickoff: arranque y herramientas
Cuando aceptan la propuesta viene la parte administrativa: contrato, NDA, crear las cuentas y los espacios de trabajo, y una reunión de kickoff donde repasamos el alcance y los pagos. Nuestras herramientas:
- Slack para hablar con el cliente. Creamos un canal compartido con él y, además, un canal interno del equipo para lo que el cliente no tiene por qué ver. Nunca trabajamos por email —nunca es buena idea—.
- Linear para las tareas. Gestionamos el proyecto a alto nivel: no hace falta bajar a muchísimo detalle, solo mantener las tareas actualizadas para saber en todo momento en qué estamos.
- Cuentas: que las cree el cliente y nos dé acceso con email y contraseña, nunca con login de Google. Si no, acabas necesitando su código de verificación a las 11 de la noche.
Comunicación y cadencia semanal
La comunicación pasa por Slack. La validación con el cliente la hacemos, cuando se puede, con una reunión semanal ya prefijada; y si no, de forma asíncrona en el canal, mencionando al cliente. Las reuniones de "estado" que no aportan nada las evitamos.
La semana tiene un ritmo:
- Lunes: planificamos qué haremos esa semana y se lo contamos al cliente ("esta semana nos centramos en esto, esto y esto").
- Miércoles/jueves: el objetivo es tener algo que enseñar. Le grabamos un Loom y le pedimos feedback.
- Viernes: decidimos la semana siguiente.
Todo esto persigue una sola cosa: acelerar el ciclo de feedback. Cuanto antes vea el cliente algo tangible, menos nos equivocamos.
Cómo construimos: dos máximas
1. Reduce la incertidumbre primero. Lo que más dudas te genera es lo primero que haces. Si lo más crítico del proyecto es una integración que no sabes si saldrá, atácala en el primer sprint —no la dejes para la semana cuatro y descubras entonces que no era viable—. En un proyecto con verificación de identidad, lo primero fue una demo de esa integración, no las pantallas bonitas.
2. Enseña algo tangible cuanto antes. No le digas al cliente "confía, lo probé y funciona": haz que lo pruebe él. Por muy bien que creamos que le entendemos, lo que quiere suele diferir de lo que imaginamos. Enseñar pronto acerca su visión y la nuestra.
Enseñar cosas al cliente lo antes posible es, con diferencia, nuestro mayor aprendizaje de estos años.
Los cambios: aceptar primero, gestionar después
Trabajamos en alta incertidumbre, así que damos por hecho que el roadmap va a cambiar. Nuestra actitud por defecto ante una petición de cambio es proactiva y muy abierta: primero la acogemos —con un mensaje explicando bien qué vamos a hacer— y luego la gestionamos. Solo si es un cambio grande de scope paramos a renegociar la propuesta.
Damos mucho al cliente, porque esa cercanía y esa flexibilidad son parte de por qué trabajan con nosotros. Lo que sí dejamos claro desde el principio (ver preventa) es que un cambio de scope grande puede mover tiempos y presupuesto.
La entrega
Cuando terminamos, se lo enseñamos en una reunión, y si el producto es complejo le dejamos documentación (Looms o Notion) y algo de formación. Traspasamos lo que haya que traspasar —aunque lo ideal es haber trabajado ya directamente en las cuentas del cliente— y cerramos.
Si te quedas con dos cosas de este capítulo, que sean estas: la preventa (entender bien al cliente, reducir incertidumbre y saber si es buen cliente) y enseñar cuanto antes. Suenan a obviedad hasta que te la pegas en un proyecto — y ahí es donde se aprenden de verdad.