FindLeads — Generación de leads con CRM integrado
FindLeads convierte resultados de Google Places en un pipeline de outreach, usando “No se encontró sitio web en Google” como señal y no como afirmación absoluta.
Desplegado · piloto
Una cola de prospectos y un monitor de adquisición. La apertura al público depende de verificar la protección de endpoints y los límites de uso.
Estado documentado
Resumen
FindLeads es una consola de prospección para uso repetido construida sobre la API oficial de Google Places. Una búsqueda enfocada por categoría y ubicación puede recopilar hasta 60 resultados; el workspace de leads los convierte en una cola con métricas, búsqueda, filtros, enlaces telefónicos, cantidad de reseñas, estado de contacto, notas, exportación CSV y paginación de 25 filas. Next.js 16 y React 19 corren sobre Neon Postgres vía Drizzle, con Zod en cada límite y un worker asíncrono sin cola externa basado en filas de job, `after()` y polling con SWR.
El problema
La prospección local empieza con resultados ruidosos de directorios y termina rápido en una hoja de cálculo que no muestra qué se contactó, qué necesita atención ni qué búsqueda produjo cada lead. La restricción fue crear un flujo durable para una sola persona sin agregar autenticación ni infraestructura externa de colas.
Preguntas abordadas
- 01
¿Puede un job en background reanudable sobrevivir crashes y workers duplicados usando solo Postgres y updates atómicos?
- 02
¿Cómo debe coexistir estado CRM durable con snapshots de búsqueda re-ejecutables para que un re-scrape nunca borre tus notas?
- 03
¿Cómo pueden la capacidad, el progreso y los estados vacíos o fallidos seguir siendo legibles en el uso diario?
Metodología
Búsqueda Places y marcado tier-1
Los jobs de búsqueda llaman Google Places Text Search (New) por categoría + ubicación en texto libre. Cada respuesta se valida con Zod antes de tocar la base de datos, y negocios sin campo website se convierten en leads tier-1. Los resultados se almacenan como snapshots por job para que cada corrida de búsqueda sea reproducible.
Worker de jobs reanudable sin cola
En lugar de Redis o un servicio de cola, los jobs son filas de base de datos procesadas vía Next.js after() con polling cliente sobre SWR. El worker hace checkpoint de progreso y reclama trabajo mediante claims atómicos single-UPDATE, así un worker crasheado o duplicado nunca procesa dos veces — comportamiento fijado por tests de integración contra una base de datos de test Neon real.
Consola de prospección y estado CRM durable
El estado CRM durable (notas y estado de contacto) vive en una tabla businesses keyed por place_id, separado de los snapshots por job. La consola actual añade métricas de pipeline, búsqueda, cuatro filtros, teléfonos, reseñas, paginación de 25 filas, capacidad explícita de 3 páginas/60 resultados y feedback pendiente/exitoso/fallido para ediciones.
Resultados clave
Hallazgos clave
Postgres es una cola de jobs perfectamente válida a escala de un solo usuario: un claim atómico single-UPDATE te da crash-safety y duplicate-worker safety con cero infraestructura nueva.
Separar identidad durable (keyed por place_id) de snapshots de corrida es lo que hace un scraper re-ejecutable — el estado que te importa nunca debe vivir en estado que regeneras.
Usar `now()` de Postgres de forma consistente evita que los timestamps del CRM retrocedan cuando el reloj de la aplicación y el de la base de datos difieren.
Conclusión
FindLeads está en vivo como una herramienta intencionalmente acotada para prospección individual: adquirir un lote limitado, trabajar la cola, conservar estado CRM entre búsquedas y exportar cuando el outreach continúa fuera. La última revisión ejercitó el dataset real de Neon en desktop y móvil, dejando la paginación server-side como umbral futuro y no como infraestructura prematura.