¿Alguna vez te han pedido que construyas un CRM personalizado desde cero y pensaste, "Bueno, eso es imposible"? Yo tuve ese momento hace dos años con un cliente que necesitaba su CRM listo en solo 14 semanas. No es la línea de tiempo típica. Pero aquí está la cosa: usando nuestro plan de 5 fases, no solo fue posible sino sorprendentemente fluido. Stack Overflow y Postman fueron mis compañeros diarios. Y sí, aprendí más de una lección en el camino.
Fase 1: Descubrimiento y definición del alcance (semanas 1-2)
La mayoría de los proyectos de CRM fracasan antes de que se escriba una sola línea de código. Lo digo en serio. El fracaso ocurre en una sala de conferencias, usualmente alrededor de una pizarra, cuando todos asientan a requisitos vagos y nadie hace las preguntas incómodas.
Con este proyecto en particular (una empresa de logística de tamaño medio en Birmingham, alrededor de 80 empleados), pasé las primeras dos semanas haciendo casi nada más que escuchar. Talleres, llamadas de Zoom grabadas, y un documento compartido en Notion donde los interesados podían volcar cada flujo de trabajo que querían que el CRM manejara. El documento creció a 47 páginas. Mucho de ello era contradictorio. Eso en realidad está bien, las contradicciones en un documento de descubrimiento son gratis; las contradicciones descubiertas en la semana 11 te cuestan un sprint y una relación con el cliente.
Qué estás realmente mapeando
El objetivo en la fase de descubrimiento no es capturar cada característica. Es mapear las relaciones de datos y los roles de usuario que van a determinar cada decisión arquitectónica que venga después. Uso Whimsical para diagramas de flujo en esta etapa. Rápido, compartible, y los clientes pueden comentar sin necesitar una cuenta.data relationships and the user roles that will shape every architectural decision downstream. I use Whimsical for flow diagrams at this stage. Quick, shareable, and clients can comment without needing an account.
Para el final de la semana 2, necesitas cuatro entregables confirmados:
- Una lista de características priorizada, dividida en buckets MVP y post-lanzamiento
- Un esquema de relaciones de entidades (no un esquema completo todavía, solo los sustantivos: contactos, deals, pipelines, tareas)
- Definiciones de roles de usuario con niveles de permisos escritos en inglés plano
- Una línea de tiempo aprobada con hitos nombrados, no fases vagas
Ese último es innegociable. "Phase 2 complete" no significa nada. "Contact import and role-based access live in staging by day 28" significa algo.
---
Fase 2: Decisiones de Arquitectura y Stack Tecnológico (Semana 3)
Una semana. Eso es todo lo que le doy a esta fase, porque he visto equipos desaparecer en debates de arquitectura durante un mes y no lanzar nada.
Para este proyecto, el stack fue: Node.js con Express en el backend, PostgreSQL para la base de datos, React en el frontend, y todo desplegado en Kubernetes administrado de DigitalOcean. Usamos Prisma como ORM porque el schema iba a evolucionar rápidamente y el workflow de migraciones de Prisma es genuinamente bueno para eso.Node.js with Express on the backend, PostgreSQL for the database, React on the front end, and the whole thing deployed on DigitalOcean managed Kubernetes. We used Prisma as the ORM because the schema was going to evolve quickly and Prisma's migration workflow is genuinely good for that.
Honestamente, el stack importa menos de lo que la gente cree. Lo que importa más es:
- ¿Todos los desarrolladores en este proyecto conocerán este stack sin una curva de aprendizaje pronunciada?
- ¿La arquitectura soporta el modelo de permisos que mapeaste en la Fase 1?
- ¿Puedes agregar un nuevo tipo de entidad (digamos, "proveedor") en la semana 10 sin reescribir la capa de autenticación?
Ese tercer punto es donde me han quemado antes. En 2021, Seahawk Media tuvo un proyecto SaaS donde agregamos multi-tenancy en la semana 9. Tomó cuatro días retrofit lo que debería haber sido una decisión del día uno. Nunca más.
Para autenticación, por defecto uso Auth0 a menos que haya una razón convincente para no hacerlo. Maneja los casos extremos (restablecimiento de contraseñas, MFA, login social) que devoran a los desarrolladores junior.Auth0 unless there's a compelling reason not to. It handles the edge cases (password resets, MFA, social login) that eat junior developers alive.
---
Fase 3: Sprint de Construcción Principal (Semanas 4-9)
Seis semanas. Este es el cuarto de máquinas. Y si tu scoping fue sólido, esta fase es en realidad la parte más directa de todo el proyecto.
Dividí esto en dos mini-sprints de tres semanas con una revisión interna rigurosa en el punto medio.
Sprint A: Capa de Datos y API (Semanas 4-6)
Nada toca el front end hasta que el contrato de API esté acordado. Sin excepciones. Documento cada endpoint en Postman antes de escribir un controlador, lo cual suena tedioso pero evita aproximadamente dos semanas de conversaciones "espera, ¿qué devuelve este endpoint?" después.Postman before writing a controller, which sounds tedious but saves about two weeks of "wait, what does this endpoint return?" conversations later.
El esquema de base de datos recibe su primer análisis real aquí. Para CRMs, las tablas que siempre se subestiman son la tabla de registro de actividades y la tabla de campos personalizados. Cada cliente quiere campos personalizados. Construir correctamente una tabla custom_field_definitions flexible desde el primer día son aproximadamente cuatro horas de trabajo. Improvisar esto en la semana 11 es una pesadilla.custom_field_definitions table properly from day one is about four hours of work. Improvising it in week 11 is a nightmare.
Sprint B: Front End y Flujos de Trabajo (Semanas 7-9)
React con TanStack Query para la gestión de estado del servidor. Intenté usar plain useEffect y estado local en un proyecto más pequeño en 2022. Nunca volvería a hacerme esto, TanStack Query maneja caché, refetching en segundo plano y actualizaciones optimistas de una manera que hace que las interfaces de CRM se sientan ágiles sin necesidad de soluciones heroicas.TanStack Query for server state management. I tried rolling with plain useEffect and local state on a smaller project in 2022. Never doing that to myself again, TanStack Query handles caching, background refetching, and optimistic updates in a way that makes CRM interfaces feel snappy without heroics.
Para la capa de componentes UI, usamos shadcn/ui en este proyecto. No es una librería de componentes en el sentido tradicional; eres propietario del código, lo que significa que realmente puedes personalizarlo sin pelear contra la librería. Para un CRM con una vista de pipeline, una tabla de contactos y un tablero de tareas, esa flexibilidad importa.shadcn/ui on this project. It's not a component library in the traditional sense; you own the code, which means you can actually customise it without fighting the library. For a CRM with a pipeline view, a contacts table, and a task board, that flexibility matters.
Una cosa que consistentemente se cuela en este sprint: los estados vacíos. Un CRM sin datos se ve roto si no has diseñado para pantallas en estado cero. Construyelos temprano. Los clientes hacen demostraciones a las partes interesadas con bases de datos vacías y las primeras impresiones perduran.empty states. A CRM with no data looks broken if you haven't designed for zero-state screens. Build them early. Clients demo to stakeholders with empty databases and first impressions stick.
---
Fase 4: Integraciones y Migración de Datos (Semanas 10-11)
Aquí es donde la mayoría de las agencias cotizan por debajo y planifican mal. Lo he visto cada vez.
El cliente de logística de Birmingham necesitaba integraciones con su configuración de contabilidad Xero existente y una instancia más antigua de Salesforce de la que se estaban alejando. Dos semanas suena ajustado. Lo fue, pero lo logramos porque habíamos definido los puntos de integración en la Fase 3.Xero accounting setup and an older Salesforce instance they were migrating away from. Two weeks sounds tight. It was, but we made it because we'd stubbed the integration points back in Phase 3.
Específicamente para la migración de Salesforce, usamos su Bulk API 2.0 para extraer los datos, luego los pasamos por un script de Node que mapeaba su estructura de campos a la nuestra. El script tardó un día en escribirse e tres días en iterarlo porque los datos de Salesforce casi nunca están tan limpios como los clientes creen. Presupuesta para la limpieza de datos. Siempre.Bulk API 2.0 to extract the data, then ran it through a Node script that mapped their field structure to ours. The script took a day to write and three days to iterate on because Salesforce data is almost never as clean as clients believe it is. Budget for data cleaning. Always.
Hay algunas cosas que verifico antes de dar una integración por "completada":
- Manejo de fallos: ¿qué pasa cuando la API de terceros se cae?
- Idempotencia de webhooks: ¿puedes procesar el mismo evento dos veces de forma segura sin duplicar registros?
- Límites de velocidad: ¿estás dentro de ellos bajo carga realista?
La documentación del desarrollador de Xero es realmente decente, para ser honesto. El flujo OAuth 2.0 está bien documentado y su entorno sandbox funciona de manera confiable.Xero developer docs are actually decent, for what it's worth. The OAuth 2.0 flow is well documented and their sandbox environment works reliably.
---
Fase 5: QA, Hardening y Handover (Semanas 12-14)
Tres semanas para QA suena generoso hasta que estás dentro.
La semana 12 es testing estructurado. Le doy al cliente un tablero de ClickUp con cada caso de prueba escrito como tarea, ellos prueban, lo marcan, adjuntan un Loom si algo se rompe. Esto logra que usuarios reales hagan clic en flujos reales, lo que siempre descubre cosas que una prueba ejecutada por desarrolladores no ve. Alguien intentará pegar 4.000 caracteres en un campo de "notas". Alguien importará un CSV con comillas inteligentes. Quieres encontrar esto ahora.ClickUp board with every test case written as a task, they test, they mark it, they attach a Loom if something breaks. This gets real users clicking real flows, which always uncovers things that a developer-run test misses. Someone will try to paste 4,000 characters into a "notes" field. Someone will import a CSV with smart quotes in it. You want to find this now.
La semana 13 es el sprint de correcciones. Sin nuevas funcionalidades. Solo fixes de bugs y trabajo de performance. Ejecuto Lighthouse contra cada página clave. También ejecuto pruebas de carga con k6 contra la API, no porque el cliente lo pidiera, sino porque encontrar una consulta lenta con 50 usuarios concurrentes en la semana 13 es mejor que encontrarla después del lanzamiento.Lighthouse against every key page. I also run k6 load tests against the API, not because the client asked for it, but because finding a slow query under 50 concurrent users in week 13 beats finding it after go-live.
La semana 14 es la entrega y preparación para ir en vivo.
La documentación de entrega que produzco cubre:
- Descripción general de infraestructura (qué está corriendo dónde, cómo escalarlo)
- Procedimiento de backup y restauración de base de datos, probado y verificado
- Cómo agregar un nuevo rol de usuario sin tocar código
- Limitaciones conocidas y los elementos del backlog que dejamos para después
Ese último es importante. Sé honesto sobre qué no logró pasar el corte. Los clientes lo respetan, y prepara la siguiente fase de trabajo de forma limpia en lugar de dejar deuda tácita colgando sobre la relación.
Una Última Cosa sobre el Go-Live
Escalonalo. Hicimos un lanzamiento suave a 10 usuarios el día 92, monitoreamos los logs durante 48 horas usando Datadog, y luego lo abrimos al equipo completo de 80 personas. Esa ventana de 48 horas atrapó dos casos extremos en las transiciones de etapa del pipeline que no habían aparecido en las pruebas. Nada catastrófico, pero el tipo de cosa que hubiera generado 15 tickets de soporte el día uno si hubiéramos ido a toda velocidad.Datadog, then opened it to the full 80-person team. That 48-hour window caught two edge cases in the pipeline stage transitions that hadn't shown up in testing. Nothing catastrophic, but the kind of thing that would have generated 15 support tickets on day one if we'd gone full-steam.
El go-live no es el final. Es solo cuando comienzan a llegar los datos reales del comportamiento del usuario.
---
FAQ
¿Cuánto cuesta típicamente un CRM personalizado como este?
Honestamente, varía enormemente, pero un proyecto de 14 semanas con este alcance y un equipo pequeño (dos desarrolladores back-end, un desarrollador front-end, un líder de proyecto) típicamente cuesta entre £60,000 y £120,000 dependiendo de la complejidad de las integraciones y la migración de datos. Si ves cotizaciones por debajo de £30,000 para una construcción completamente personalizada, presiona fuerte sobre qué se está realmente construyendo versus configurando a partir de una plantilla existente.
¿Puedes construir un CRM personalizado en WordPress?
Puedes, pero no lo haría para nada por encima de aproximadamente 500 registros o 20 usuarios concurrentes. La capa de datos de WordPress no está diseñada para cargas de trabajo de CRM relacional. En Seahawk hemos construido capas de gestión de contactos sobre WordPress para clientes más pequeños, pero para cualquier cosa seria, un back-end adecuado con una base de datos relacional es la opción correcta.
¿Cuál es el error más grande que cometen los equipos en construcciones de CRM?
No especificar bien el modelo de permisos. Todos se enfocan en features y olvidan que un CRM con 80 usuarios necesita una respuesta matizada a "¿quién puede ver qué deal?" antes de escribir una sola ruta API. Retrofittear control de acceso basado en roles en la semana 10 es doloroso de una forma que es difícil de describir hasta que lo haces una vez.
¿Siempre usas exactamente este stack tecnológico?
No. El stack que describí funcionó para el equipo y las restricciones de este proyecto. He lanzado CRMs en Laravel y Vue, en Django y React, y una vez en un setup full-stack de Next.js del que era escéptico pero que funcionó bien en realidad. Los principios de arquitectura se mantienen igual. Las herramientas son flexibles.
Al final, el proyecto custom de CRM fue no solo un desafío sino una revelación. ¿Esa ventana ajustada de 14 semanas? Nos obligó a innovar, adaptarnos y entregar. Resulta que las restricciones pueden ser un catalizador para la creatividad. ¿Quién sabía que los deadlines podían enseñarnos tanto sobre nuestro oficio? Son proyectos como estos los que me recuerdan por qué cofundé Seahawk Media en primer lugar.