Producto propio · 2025 – actualidad
Verificación de arrendatarios para quien arrienda sin inmobiliaria en Colombia. Lo investigué, lo diseñé y lo estoy construyendo.
Product Designer & Design Engineer
Investigación, producto, diseño, arquitectura y construcción
MVP previsto octubre 2026
Arrendar directo le ahorra al propietario una comisión de alrededor del 10 % del canon, todos los meses. El costo de ese ahorro es que entrega su inmueble sin saber a quién se lo entrega.
No tiene forma de verificar identidad, antecedentes ni capacidad de pago. El contrato lo resuelve con una minuta descargada de internet que puede no ser exigible el día que la necesite.
El otro lado del problema es menos obvio, y es el que hace que el modelo funcione: el candidato honesto tampoco tiene cómo demostrar que lo es. Compite contra otros aspirantes sin ninguna manera de probar que paga a tiempo y que es quien dice ser. Esa asimetría define quién paga.
Primero, lo que no hice. El descubrimiento fue de escritorio más conversaciones informales con propietarios de mi red. No hubo protocolo ni muestra representativa. Lo aclaro porque la diferencia importa: lo que sigue son decisiones tomadas con evidencia parcial y declarada, no conclusiones de un estudio formal.
Lo que sí hice:
Un producto no es una suma de pantallas. Es una suma de decisiones que cuestan algo. Estas cuatro lo definieron.
¿Quién paga la verificación?
El propietario recibe el beneficio evidente, pero es también quien ya está evitando pagar una comisión. Cobrarle es cobrarle a alguien cuya motivación de entrada es no pagar.
Paga el candidato. El propietario usa el servicio sin costo.
El candidato también obtiene algo concreto: un certificado que lo diferencia de los otros aspirantes por el mismo inmueble. Y el volumen está de ese lado — un propietario genera una transacción al año; los candidatos que compiten por ese inmueble son varios. Cobrar del lado del volumen es lo que hace que el modelo escale.
Le cobro a quien tiene menos poder en la negociación. Eso obliga a que el precio sea bajo y a que el beneficio para el candidato sea explícito en cada pantalla. Si siente que paga por un trámite ajeno, no termina el flujo. Es una tensión permanente, no un problema resuelto.
¿La compuerta de pago va antes o después de la biometría?
Cada verificación consulta servicios externos que se cobran por uso. Si el pago va al final, cada abandono cuesta dinero real. Si va al principio, se pierden candidatos que habrían pagado después de entender qué recibían.
El pago va antes de disparar las consultas externas — pero después de que el candidato entienda qué obtiene y quién se lo pidió.
El costo de una consulta es real e inmediato; el de un abandono es una conversión que se recupera con mejor secuencia y mejor texto. Optimicé por el que no se puede recuperar.
La pantalla previa al pago no pide plata: explica que el propietario de ese inmueble específico solicitó la verificación, qué queda en el certificado y qué no. La legitimidad del pedido sostiene la conversión, no el descuento.
¿No-code o código propio?
El producto arrancó en Bubble. Funcionaba. Cambiar de plataforma a mitad de camino es tirar trabajo a la basura.
Migrar todo a Next.js y Supabase.
Tres razones, y solo una es técnica. El costo crecía de forma difícil de proyectar. El control sobre la interfaz tenía un techo que ya estaba tocando. Y la que realmente decidió: en un producto que maneja cédulas, selfies y datos de crédito de terceros, necesito poder demostrar exactamente quién puede leer qué fila de qué tabla. Eso se resuelve con políticas de acceso escritas y versionadas, no con el panel de permisos de una plataforma cerrada.
Semanas de reconstrucción, y asumir yo la responsabilidad técnica de decisiones que antes tomaba la plataforma por mí.
¿Qué pasa cuando el contrato sale mal?
El camino feliz es corto: se verifica, se generan los datos, se firma. Pero un contrato con un dato equivocado —una cédula, un canon, una fecha— es un documento que no sirve, y para cuando alguien lo nota ya está firmado electrónicamente.
Diseñar dos cosas antes del camino feliz: una pantalla de confirmación donde el propietario ve exactamente lo que va a quedar escrito, y un flujo de anulación y regeneración que invalida el documento anterior y emite uno nuevo sin romper la trazabilidad.
En un producto con firma electrónica, el camino del error no es un caso borde: es la diferencia entre una plataforma en la que se puede confiar y una que produce documentos que hay que arreglar por fuera.
Estilos de texto y color, botones en tres variantes, campos para correo, contraseña, texto y teléfono, cinco variantes de badge, indicador de progreso de cuatro pasos, tarjeta de candidato y navegación.
Lo que lo separa de un archivo bonito de Figma: está sincronizado con el código a través de Figma MCP. Los tokens de tipografía, color y espaciado que definen el diseño son los mismos que consume la aplicación. No hay una versión de la verdad en Figma y otra en producción — que es donde normalmente muere la intención del diseño.
El indicador de progreso lleva una decisión pequeña que vale nombrar: los tres primeros pasos se llenan en morado y el cuarto en verde. El cambio de color marca que el último paso no es «uno más», es el que cierra. Es el tipo de detalle que solo se decide cuando la misma persona diseña el componente y lo implementa.
Cuatro pasos: captura del documento de identidad, selfie para la prueba biométrica, pago y confirmación.
El problema de diseño aquí no es la interfaz, es la desconfianza. A un desconocido se le está pidiendo la cédula, una foto de su cara y dinero, a través de un enlace que le llegó por WhatsApp. Cada pantalla tiene que responder tres preguntas antes de pedir nada: quién solicita esto, para qué inmueble, y qué pasa con mis datos después.
La captura biométrica es donde más se juega el producto. Cada instrucción que falta es un intento fallido, y cada intento fallido acerca al candidato a abandonar. El equilibrio es entre fricción, tasa de éxito de la verificación y percepción de seguridad — y los tres se mueven en direcciones distintas: hacerlo más fácil puede hacerlo sentir menos serio.
Autenticación, creación del inmueble, envío del enlace al candidato y seguimiento del estado de las solicitudes.
Una decisión de alcance que tomé y sostengo: el dashboard del propietario se construye directamente en código desde el design system, sin diseñarlo pantalla por pantalla en Figma. El sistema ya define los componentes y sus estados; volver a dibujar composiciones de componentes existentes era duplicar trabajo sin agregar decisiones. Diseñar en Figma lo que ya está resuelto en el sistema es ceremonia, no diseño.
Esquema en PostgreSQL sobre Supabase, con políticas de seguridad a nivel de fila aplicadas y verificadas. La aplicación en Next.js consume tipos generados directamente desde la base, así que un cambio de esquema rompe la compilación en vez de romper la aplicación en producción.
Wompi para pagos, con llaves de producción aprobadas. DocuSign para firma electrónica. Tusdatos y Datacrédito para antecedentes y score crediticio. Cinco webhooks orquestados en n8n, incluido el de anulación y regeneración de documentos.
Uso inteligencia artificial como equipo de ejecución técnica. Yo defino la arquitectura, el modelo de datos, los criterios de seguridad y el alcance de cada bloque; la IA comprime el tiempo de implementación; yo reviso cada entrega. El repositorio es privado y la documentación de contexto del proyecto está versionada junto al código.
No vengo de programar. Lo que aporto no es sintaxis: es criterio de producto y de arquitectura, y la disciplina de no dar por bueno lo que no entiendo.
Autenticación del propietario, creación de inmuebles y envío del enlace al candidato
Pantallas de captura de cédula y selfie construidas
Wompi aprobado en producción · revisión legal completa
Go-Live de DocuSign
Integración definitiva del proveedor de verificación
Habría validado con propietarios antes de construir el design system. Tengo el sistema al 100 % y los flujos diseñados sobre supuestos razonables pero no probados. El orden correcto era el inverso: cinco conversaciones estructuradas antes de definir componentes me habrían costado una semana y habrían cambiado, sospecho, la pantalla de confirmación y la secuencia del pago.
Habría empezado en código. Los meses en no-code me enseñaron dónde estaban los límites, pero el mismo aprendizaje costaba menos leyendo con cuidado la letra pequeña de precios y permisos antes de construir encima.
Y habría medido desde el primer día. El producto va a lanzar sin línea base de nada: no sé cuánto tarda hoy un propietario en elegir arrendatario, ni cuántos candidatos abandonan un formulario de este tipo. Sin ese número antes, la mejora después no se puede demostrar. Es el error que menos me perdono, porque es el más barato de evitar.