De un vistazo
Rol. Founding Designer. Investigación, marca, UX, frontend, backend, lanzamiento y campañas. Dos fundadores trajeron la idea y llevan el negocio en el día a día: reclutan profesionales y validan los pagos.
Período. De febrero a septiembre de 2026. De la idea a producción en menos de seis meses.
Stack. Next.js 16, Supabase (Postgres con row-level security), Vercel, Resend, Sentry, GitHub Actions, Playwright, Vitest.
Estado. En línea en buscoservicio.com.ar. Más de 230 perfiles profesionales. El registro de clientes se abrió el 8 de septiembre de 2026.
El problema
En Argentina, contratar a un plomero, a un electricista o a alguien que limpie la casa depende de grupos de WhatsApp, de la recomendación de un vecino o de quien conteste primero. No hay un lugar único donde ver quién está disponible, cuánto cobra o si sus clientes anteriores quedaron conformes. Se paga en efectivo o por transferencia, y a cruzar los dedos.
Dos fundadores me acercaron una idea que nació de la ola de desempleo en el país: una plataforma donde las personas con un oficio pudieran generar ingresos por su cuenta con sus servicios, en la línea de las nuevas apps que estaban apareciendo en Argentina en ese momento. El primer mercado es el Gran Buenos Aires (AMBA).
En el fondo, el problema de diseño era la confianza. Un desconocido va a entrar a tu casa. El dinero cambia de manos antes del trabajo. Ninguna de las dos partes tiene pruebas de nada. Cada flujo del producto está pensado para ganar esa confianza paso a paso.
Restricciones
Una sola persona a cargo del producto. Diseño, frontend, backend, base de datos, despliegue, contenido y marketing de lanzamiento pasaron por mí, mientras los fundadores llevaban el negocio. Por eso la documentación es tan detallada: escribí los flujos de cliente, profesional y admin como documentos con diagramas de estados antes de desarrollarlos, porque mi única compañera de equipo eran mis propias notas de un mes atrás.
Sin pasarela de pago, por decisión propia. Los fundadores eligieron las transferencias bancarias manuales en lugar de Mercado Pago o Stripe, para no pagar comisiones de pasarela. El cliente transfiere a la cuenta de la plataforma, marca "Ya transferí" y un admin coteja el extracto bancario y confirma a mano. De esa decisión salió toda una cola de conciliación en el panel de admin. Hay una integración con Mercado Pago diseñada y lista, por si los fundadores cambian de opinión.
Ley argentina de protección de datos. Los usuarios tienen derecho a que se eliminen sus datos personales. Diseñé un flujo de baja de cuenta que anonimiza los datos personales pero conserva el historial de transacciones del que depende la otra parte.
Usuarios que viven en el teléfono. Las personas con oficios y los clientes que buscan una solución rápida usan el teléfono. Un modal que no entra en una pantalla pequeña, o un formulario que pierde lo cargado al recargar la página, no es un detalle de pulido. Es una reserva abandonada.
Proceso
Antes de escribir una sola línea de código, investigué marketplaces de servicios en Argentina y en otros países, armé un moodboard y publiqué una landing independiente para empezar a captar profesionales interesados mientras el producto todavía se estaba definiendo. Después el alcance creció, de un MVP pequeño a una plataforma completa (panel de admin, perfiles de profesional y de cliente, chat interno, reservas y pagos), a medida que los fundadores y yo entendíamos qué necesitaba el negocio.
Traté la documentación como una pieza de diseño más. Cada flujo se escribió primero como un documento con un diagrama de todas sus transiciones de estado: cómo una reserva pasa de pago pendiente a validación pendiente, luego a confirmada y por último a completada, quién dispara cada paso, qué email se envía en cada momento. Esos diagramas fueron la especificación sobre la que desarrollé.
Trabajé con un pull request por funcionalidad: 151 PRs fusionados en cinco meses, cada uno limitado a un solo cambio. Esa disciplina me permitió confiar en mi propio trabajo anterior sin que nadie más revisara el código.
Lo que más peso tuvo fue una revisión sistemática de UX del producto en producción, en junio de 2026, hecha con agentes de IA en Claude Code. Seis agentes mapearon los subsistemas del código, ocho buscaron problemas de UX, y cada hallazgo pasó por un verificador independiente cuyo trabajo era intentar refutarlo leyendo el código. El resultado: 121 hallazgos, 119 únicos, 80 sometidos a ese contraexamen, 79 confirmados y 1 refutado. Los 25 hallazgos más graves, agrupados en cuatro temas (un flujo de pago con huecos, estados de autenticación sin salida, profesionales trabajando a ciegas y modales que se rompían en el teléfono), pasaron de hallazgo a corrección publicada en cuestión de días.
Prefiero decirlo claro: esto se hizo con ayuda de IA. El valor no estuvo en que una IA encontrara bugs, sino en un proceso donde cada hallazgo tenía que resistir un intento de refutarlo antes de que yo hiciera algo al respecto.
Solución
Búsqueda y reserva con turnos de 1 hora
El cliente busca por categoría o con texto libre, filtra por zona, modalidad y calificación, entra a un perfil público y después elige un turno de 1 hora en un calendario, donde ve el precio antes de confirmar.
Decisión clave
Los turnos duran siempre una hora. Los trabajos reales no duran todos lo mismo, pero con un turno fijo el flujo fue abarcable para una sola persona y fácil de gestionar para cada profesional.
Contrapartida
Durante mucho tiempo, el calendario no bloqueaba el turno mientras se hacía el pago: un cliente podía verlo libre, transferir el dinero y perderlo porque otra persona lo reservaba en el medio. Lo señalé en la revisión de junio y lo resolví bloqueando el turno durante el pago y dando de baja las reservas sin pagar a las 24 horas.
Escritorio

Móvil

Pago por transferencia bancaria con validación del admin
El cliente ve los datos bancarios de la plataforma, transfiere el precio más una comisión del 4% y marca "Ya transferí". Un admin coteja la transferencia con el extracto bancario y la confirma o la rechaza. En el momento de la confirmación se liberan los datos de contacto del profesional. Cuando el trabajo termina, el profesional ingresa un código de 6 dígitos que el cliente recibió por email. Con eso la reserva se completa y se genera la liquidación: el precio menos la comisión.
Decisión clave
El manejo del dinero es simple. La plataforma cobra todo, no hay pagos divididos ni cuentas conectadas, y después el admin transfiere el importe neto al profesional.
Qué cambié
Al principio, un cliente podía transferir antes de que existiera un registro de la reserva, así que otra persona podía quedarse con un turno ya pagado. Lo resolví con el bloqueo del turno y cerré los callejones sin salida que había alrededor: una reserva trabada en pago pendiente sin ninguna pantalla que mostrara los datos bancarios, y un email de pago rechazado que prometía un reembolso que el sistema no contemplaba.

Verificación de identidad opcional y la insignia "Verificado"
Un profesional puede presentar su documento de identidad y un certificado de antecedentes penales para obtener la insignia "Verificado". Sin ellos, de todos modos puede publicar servicios y recibir reservas: basta con una descripción y un servicio activo.
Qué cambié
La verificación empezó siendo obligatoria: sin documentos, el perfil no era visible. Lo cambié en agosto de 2026, después de ver cómo funcionaba en la práctica la campaña de activación: 27 de los primeros 30 profesionales que empezaron el registro abandonaron en el paso de subir documentos. Hice la verificación opcional y la convertí en una insignia que se gana. La idea: un marketplace con oferta les sirve más a los clientes que uno vacío detrás de una barrera que nadie logra cruzar. La migración que aplicó el cambio deja registrada la decisión y el motivo en el propio código.
Contrapartida
Ahora la insignia significa "eligió verificarse", no "profesional evaluado". El resto de la confianza lo aportan las reseñas y la moderación.
Escritorio

Móvil

Panel de admin con historial de actividad, cola de pagos y moderación
Un solo panel con siete secciones: resumen, pagos, liquidaciones, profesionales, clientes, reseñas y admins. Cada acción pasa por una función de servidor que vuelve a comprobar el rol de admin, valida los datos y escribe en un registro de auditoría que no se puede modificar. Las reseñas entran sin aprobar y necesitan moderación manual antes de publicarse.
Decisión clave
Armé el registro de auditoría desde el primer día, porque el panel siempre iba a estar en manos de personas que no escribieron el código. Cada acción tenía que dejar un rastro que se pudiera entender después.
Contrapartida
Este panel es la única interfaz operativa de la plataforma, y cada pago, aprobación y reseña pasa a mano por los fundadores. A partir de cierto volumen, eso no escala. Fue la decisión correcta para salir rápido con un producto que funcionara, y es lo primero que va a cambiar cuando crezca el volumen.




Activación y comunicación
Los profesionales nuevos se registran con un asistente paso a paso, ven una pantalla de espera mientras se revisa su perfil y reciben 28 emails transaccionales que cubren cada cambio de estado: aprobación, rechazo, pago confirmado, código enviado, liquidación generada. Antes del lanzamiento precargué 214 perfiles a partir de las listas de contactos de los fundadores, en tres tandas, para que el primer cliente no llegara a un sitio vacío. Después vinieron tres campañas de activación: ocho envíos de email a los 214 a fines de julio; un email y un mensaje de WhatsApp a mediados de agosto, cuando la verificación pasó a ser opcional (se entregaron 186 de 198 mensajes de WhatsApp); y una campaña segmentada a fines de agosto con tres grupos: profesionales que nunca habían iniciado sesión (172), los que habían entrado pero dejaron el perfil incompleto (23) y los que tenían el perfil y los servicios completos (19). También grabé 20 tutoriales en video para YouTube, para profesionales y para clientes, y produje dos reels cortos con un flujo de generación con IA, a un costo casi nulo.
Decisión clave
Grabé los tutoriales ejecutando los tests end-to-end sobre la app real mientras capturaba la pantalla. La misma automatización que verifica los flujos produce también el material.
Un perfil precargado no es un registro, y mido la diferencia. De los 237 profesionales de hoy, 70 iniciaron sesión alguna vez: 47 que activaron una cuenta precargada y 23 que se registraron por su cuenta. 34 cargaron un servicio activo, que es lo que de verdad hace falta para poder recibir reservas, y 15 tienen la insignia de verificado. Las campañas movieron el número, de 30 perfiles activados después de los primeros envíos a 70, pero siendo honesta, una lista de nombres no es un marketplace. En eso estoy ahora: conseguir que los otros 167 entren, o reemplazarlos por gente que de verdad quiera estar.
Escritorio

Móvil

Sistema de diseño y marca
Escribí un manual de marca completo (logo, paleta violeta y ámbar, modo oscuro, tipografía, iconografía, componentes y espaciado) y lo publiqué dentro del propio producto. La app usa Tailwind 4 y un conjunto de componentes al estilo shadcn: las mismas tarjetas, modales y patrones de formulario se reutilizan en las vistas de cliente, profesional y admin.
En julio de 2026 rediseñé en cuatro etapas la home y la landing para reclutar profesionales: contadores con datos reales de la base de datos en lugar de estadísticas inventadas, preguntas frecuentes que responden las dudas reales del registro y un botón de acción fijo en móvil.
Escritorio

Móvil

Notas técnicas
Next.js 16 sobre Vercel, y Supabase para la base de datos y la autenticación. El esquema creció a lo largo de 59 migraciones, cada una probada en local antes de tocar producción. La seguridad a nivel de fila (row-level security) es la base del modelo de privacidad: un cliente no puede ver el teléfono ni la dirección de un profesional hasta que la propia base de datos los libera, y eso solo pasa cuando un admin confirma el pago. La regla se cumple aunque un bug del frontend intente mostrar esos datos antes de tiempo.
Las transiciones de estado de las reservas se controlan con triggers de Postgres, así que una reserva no puede saltar de pendiente a completada sin el rol correcto. Resend se encarga del email, y Sentry del monitoreo, incluidos los cron jobs diarios, para que ninguna falla silenciosa pase inadvertida. Los despliegues a producción salen de la rama main con GitHub Actions. Los tests se reparten entre Playwright para los flujos end-to-end y Vitest para los tests unitarios.
La decisión más difícil
Llegó un punto en que el producto estaba bien y yo quería seguir mejorándolo: más correcciones, más pulido, más funcionalidades. Pero la plataforma casi no tenía clientes y había pocos profesionales recibiendo reservas. No hacía falta más trabajo de producto. Hacía falta marketing: correr la voz, atraer clientes y profesionales, lograr que la plataforma generara dinero.
Se lo dije directamente a los fundadores: frenemos por un tiempo la inversión en producto y pongamos ese dinero y ese tiempo en marketing. No es fácil decirlo cuando lo que una quiere es seguir construyendo. Pero un marketplace sin gente de ninguno de los dos lados no tiene un problema de producto, tiene un problema de demanda, y eso no se arregla puliendo más. Estuvieron de acuerdo, y por eso dediqué las semanas siguientes a campañas, tutoriales y reels en lugar de a otra funcionalidad.
Impacto
Al 25 de septiembre de 2026: 237 perfiles profesionales, 234 visibles al público, 70 activados por sus titulares, 34 con un servicio activo y 15 con la insignia "Verificado". 76 servicios en 16 categorías. Sin adquisición pagada: cada número salió de la precarga inicial, de tres campañas por email y WhatsApp, y del boca a boca.
El registro de clientes estuvo detrás de una pantalla de "próximamente" hasta el 8 de septiembre de 2026. Mientras escribo esto, todavía no hay reservas completadas. Todas las transacciones de prueba se borraron de producción el 24 de julio, como limpieza previa al lanzamiento, así que el cero de hoy es un punto de partida limpio, no un producto roto. La tracción real, hoy, está en la oferta y en el sistema de activación. La demanda apenas está empezando, y voy a actualizar esta página a medida que avance.
En cuanto al proceso: 151 pull requests fusionados, 214 commits, 59 migraciones, 28 emails transaccionales, 20 tutoriales, 2 reels y una sola persona.
Qué haría distinto
Hacer la verificación opcional desde el primer día. El requisito obligatorio nos costó registros reales hasta que lo cambié. Parecía lo responsable para servicios que se hacen dentro de una casa, pero los datos de la campaña mostraron que una barrera estricta, sin un marketplace visible detrás, frena el registro en lugar de generar confianza.
Plantear antes cómo reducir la validación manual de pagos. Aun respetando la decisión de los fundadores de no usar pasarela, hubiera planteado el problema de escala antes de abrir el registro de clientes, no después. El plan con Mercado Pago está listo para cuando lo quieran usar.
Precargar menos, activar más. Precargar 214 perfiles hizo que el sitio se viera lleno el primer día, pero 167 de esas personas nunca iniciaron sesión. Una lista más corta de profesionales con ganas reales de estar, activados uno por uno, habría sido una base más sólida que una lista larga de nombres.
Separar desde el principio los datos de prueba del uso real. Tener que escribir un script de auditoría y borrado justo antes del lanzamiento, para confirmar que cada fila transaccional de producción era de prueba, me dejó claro que tendría que haber separado los dos entornos desde el primer día.
Equipo
Yo, como Founding Designer, a cargo del producto de punta a punta: investigación, marca, UX, frontend, backend, lanzamiento y campañas. Dos fundadores que llevan la operación, reclutan profesionales y validan los pagos.

