TerraCore | Campo Inteligente
Ecosistema de TerraCore | Campo Inteligente, la plataforma de gestión agropecuaria para fincas colombianas. Reúne la app que funciona también sin señal, la página de presentación y la documentación oficial del producto.
Por Valentina Ramírez
Publicado: 16 de junio de 2026 · Actualizado: 5 de octubre de 2026
Cotizar un proyecto así
- Problema
- Las fincas colombianas llevan animales, cultivos y cuentas entre cuadernos, hojas de cálculo y WhatsApp, y los sistemas que existen son demasiado complejos.
- Solución
- Una sola plataforma para gestionar animales, cultivos, producción, salud y finanzas, que funciona también sin señal.
- Resultado
- En validación con clientes reales en Colombia. Producto funcional en producción.
01 App
PWA multiusuario y offline-first: backend en Django y frontend en React. Ver detalleOcultar
- Django
- DRF
- PostgreSQL
- Celery
- Redis
- JWT
- React
- TypeScript
- Dexie
- Tailwind CSS
El problema
Los productores agropecuarios en Colombia no contaban con software diseñado para ellos: los ERPs existentes eran demasiado complejos, y Excel con login no alcanzaba para gestionar animales, sanidad y producción al mismo tiempo. La operación terminaba repartida entre cuadernos, hojas de cálculo y grupos de WhatsApp.
Sin trazabilidad
¿Cuándo se vacunó ese animal? Nadie lo sabe con certeza.
Stock invisible
El concentrado se acaba y nadie lo vio venir.
Sin señal, sin datos
En el corral no hay internet. El registro queda para después, y después nunca llega.
Datos desconectados
El cuaderno dice que se vacunó, pero no cuánto insumo gastó ni cuánto costó.
Resultados
- Producto funcional en producción.
- En validación con clientes en Antioquia, Colombia.
Ver detalle técnico AbrirOcultar detalle técnico
Qué construí
- 01
Backend en Django y DRF sobre PostgreSQL. Celery con Redis ejecuta las tareas programadas (cobros y alertas). Autenticación con tokens de corta duración y rotación.
- 02
Aislamiento estricto de datos entre empresas: cada consulta se limita a la empresa de quien la hace antes de responder.
- 03
Lógica de negocio en servicios con transacciones y bloqueo de filas. Cada endpoint valida rol, plan y sede, y los errores siguen un contrato uniforme.
- 04
Frontend en React, TypeScript, Vite y Tailwind, con una carpeta por módulo y un hook de estado por módulo.
- 05
PWA instalable en Android e iOS sin pasar por tiendas. El Service Worker cachea la app y las lecturas; los datos viven en una base local (IndexedDB con Dexie) y cada escritura entra a una cola de salida (outbox).
- 06
Sincronización única para diez modelos: envío en orden de dependencias, lectura paginada y versión por registro. El servidor responde aceptado, conflicto o rechazo con motivo, y revalida igual que la API REST.
- 07
Offline más allá de los registros: una cola de acciones diferidas (invitar usuarios, cambiar roles) y lecturas guardadas para abrir cada pantalla sin red. Solo pagar con tarjeta exige conexión.
- 08
Importación CSV para el onboarding y exportación CSV con aprobación de un administrador.
- 09
Seguridad: documentación de la API de acceso restringido y revisiones de seguridad periódicas sobre las funciones críticas.
- 10
Infraestructura contenerizada con un entorno de pruebas aislado y revisión antes de producción. Escaneo de vulnerabilidades y despliegue reproducible en cada entrega. Más de 1.000 pruebas automatizadas en cada repositorio.
Panel
Métricas calculadas desde el dispositivo: vacunas vencidas y próximas, stock bajo y actividad pendiente.
Animales
Código único, estado de salud, sede y detalle con historial de vacunación.
Cultivos
Tipo, estado, área y fecha de siembra, con búsqueda y filtros.
Insumos
Stock, mínimo, costo unitario e historial de movimientos con su razón.
Herramientas
Equipo, costo de compra y mantenimiento.
Producción
Lotes con insumos usados, precio de venta y margen.
Salud animal
Vacunas con insumo aplicado, costo y fecha de refuerzo.
Finanzas
Resumen, histórico, rentabilidad por lote, proveedores, compras y pérdidas, según el plan.
Sedes y permisos
Cada usuario ve solo las sedes que le corresponden.
Usuarios y roles
Administrador, Operario y Colaborador (solo lectura, según el plan), con invitaciones y topes por plan.
Suscripción
Plan, pago, historial y cancelación.
Actividad
Notificaciones por módulo y bandeja de rechazos de sincronización.
Registras una vacuna y pasa esto solo
- 01 Vacuna aplicada a un animal, con insumo, cantidad, costo y fecha de refuerzo.
- 02 El insumo se descuenta en la misma transacción. Si no hay stock, el registro tampoco se crea.
- 03 El historial de Insumos deja un movimiento "Vacuna registrada".
- 04 El detalle del animal muestra la vacuna en su historial.
- 05 El Panel cuenta las vacunas vencidas o próximas a vencer (30 días).
- 06 El costo del tratamiento suma al gasto en salud del P&L del período.
- 07 Si el stock cae bajo el mínimo, se alerta al equipo.
- 08 Si el registro se borra, el insumo vuelve al stock.
Registras un lote de producción
- 01 Cada insumo usado se descuenta, validando el stock agrupado por insumo (todo o nada).
- 02 El lote deja el movimiento "Producción registrada".
- 03 Se calcula el costo del lote (cantidad por costo unitario) contra su ingreso (cantidad por precio de venta).
- 04 Si el costo supera el ingreso, se alerta al administrador.
- 05 El ingreso entra al P&L del período.
Cambias la sede activa
- 01 Todas las pantallas se recortan a esa sede.
- 02 Una etiqueta de alcance indica si ves una sede o todas.
- 03 La vacuna hereda la sede de su animal.
Todo esto sin señal
- 01 El mismo flujo se guarda en el dispositivo.
- 02 Al volver la red se aplica en el servidor con las mismas reglas: stock, roles, plan y sede.
Diseño
- 01
El producto nace de un diseño propio en Claude Design, con un prototipo navegable (botón Ver diseño).
- 02
Verde profundo como color primario y ámbar como acento sobre neutros cálidos. Inter para texto y Poppins para títulos.
- 03
Atomic design con tokens CSS compartidos con la landing: átomos, moléculas y organismos de layout.
- 04
Navegación responsive: panel lateral desde 1024 px y barra inferior con hoja Más en móvil. Ambas salen de la misma fuente y una prueba falla si se desalinean.
- 05
El estado offline siempre es visible: banner, contador de pendientes, marca Pendiente en cada fila y bandeja de rechazos.
- 06
Con una sede activa, una etiqueta de alcance dice siempre si la pantalla muestra esa sede o todas.
- 07
Formularios pensados para Colombia: teléfono con indicativo y banderas en SVG, y documento CC o CE. URLs en español y tour guiado en el primer uso.
Decisiones de arquitectura
01 Offline-first con PWA VerCerrar
- Contexto
- En corrales y potreros la señal es intermitente o inexistente, y el registro queda para después.
- Trade-off
- Una web tradicional falla sin red. Una app nativa exige tiendas y doble mantenimiento.
- Decisión
- PWA instalable con base local en IndexedDB (Dexie). Cada escritura va a una cola y se sincroniza al volver la red. El Service Worker cachea la app y las lecturas.
02 Módulos integrados con reglas en el servidor VerCerrar
- Contexto
- Una acción de campo toca varios registros: vacuna, insumo, animal y costo.
- Trade-off
- Módulos aislados son simples, pero obligan a registrar lo mismo varias veces. Conectarlos obliga a decidir quién es dueño de cada dato.
- Decisión
- La lógica vive en servicios con transacciones y bloqueo de filas. El animal es dueño de la sede de sus vacunas y los módulos se importan en una sola dirección.
03 Multiusuario con roles y sedes VerCerrar
- Contexto
- Una finca la opera un equipo de 2 a 10 personas con funciones distintas, en una o varias sedes.
- Trade-off
- Un solo rol expone todo. Demasiados roles se vuelven inmanejables.
- Decisión
- Tres roles, permisos por sede, topes de usuarios y sedes por plan e invitaciones con clave temporal.
04 Multitenancy estricta VerCerrar
- Contexto
- Varias empresas comparten una sola instancia y los datos de una nunca deben llegar a otra.
- Trade-off
- Instancias separadas aíslan mejor pero multiplican la operación y el costo.
- Decisión
- El aislamiento por empresa se resuelve en el servidor y nunca depende de datos que envía el cliente. Toda consulta se limita a la empresa antes de responder.
05 Sincronización sin pisar datos VerCerrar
- Contexto
- Dos dispositivos pueden editar el mismo registro o mover el mismo stock sin conexión.
- Trade-off
- Última escritura gana es simple pero pierde datos. Resolver conflictos exige versionado y más código.
- Decisión
- Cada registro lleva versión y el servidor responde aceptado, conflicto o rechazo con motivo. El stock offline viaja como diferencia, no como valor absoluto.
06 Portabilidad de datos VerCerrar
- Contexto
- Los productores desconfían de plataformas que retienen sus datos o dificultan la salida.
- Trade-off
- Exportar sin control facilita fugas. Bloquear la salida destruye la confianza.
- Decisión
- Importación y exportación CSV disponibles, y la exportación pasa por la aprobación de un administrador.
Aprendizajes
Definir temprano el aislamiento de datos entre empresas evita reescrituras: condiciona cada decisión de modelado.
El sync no puede saltarse validaciones: se corrigió para validar igual que la API REST (roles, plan y sede).
Conectar módulos obliga a decidir quién es dueño de cada dato: la sede de una vacuna es la de su animal.
Roadmap
Ahora
- Producto en producción, en validación con clientes reales en Colombia.
Siguiente
- Eliminar el subsistema viejo de vacunación.
- Llevar el histórico de Finanzas a nivel de sede.
Después
- Mano de obra y costos fijos y variables (hoy en cero).
- Reportes a medida, API de integraciones y base DIAN y NIIF.
Fuera del alcance del MVP
- Forecasting financiero, facturación electrónica completa, multimoneda y reportes PDF automáticos.
02 Landing
Landing de conversión en Astro con planes y formulario de diagnóstico. Ver detalleOcultar
- Astro
- TypeScript
- Tailwind CSS
- Vercel Functions
- Supabase
- Brevo
- Playwright
- GA4
- SEO
- A11y
El problema
Una plataforma SaaS sin una landing de conversión pierde el tráfico antes de que el productor llegue a la app. Hay que explicarle qué cambia frente a Excel, cuadernos y WhatsApp, enseñarle el producto, decirle qué incluye cada plan y darle una forma simple de pedir una demo.
Planes poco claros
Si no se ve qué incluye cada plan, el productor duda antes de empezar. Los límites y el alcance tienen que estar a la vista.
El valor diferencial es invisible
Que los módulos se hablan entre sí no es obvio. Sin demostrarlo antes de los planes, la landing pierde la conversión.
Desconfianza en los datos
El productor no quiere que sus costos y su producción salgan de la finca. Sin una sección de privacidad explícita, la confianza no se gana.
Poca señal en el campo
Si el producto funciona sin internet, la landing tiene que decirlo desde el primer pantallazo y sin letra pequeña.
Resultados
- Landing en producción, con el formulario de diagnóstico guardando solicitudes y avisando por correo.
- Tres planes publicados con límites claros por plan y condiciones de cancelación visibles.
Ver detalle técnico AbrirOcultar detalle técnico
Qué construí
- 01
Astro con salida estática, sin adaptador ni framework de interfaz: el JavaScript es vanilla, en un script por componente. Se despliega en Vercel.
- 02
Atomic design con alias de importación por capa (átomos, moléculas, organismos y plantilla). Los tokens de color, tipografía y espacio viven en un solo archivo CSS y Tailwind los extiende. Inter, Poppins y JetBrains Mono van autoalojadas, sin pedir fuentes a terceros.
- 03
Embudo de conversión en 13 secciones: Hero, Impacto, franja de confianza, Módulos, Producto, Beneficios, Seguridad, Planes, Preguntas y cierre. Métricas, casos de éxito y testimonios están construidos pero ocultos hasta tener datos reales.
- 04
Los datos de cada sección son TypeScript tipado en un solo archivo (planes, impacto, beneficios y preguntas). Las preguntas alimentan el acordeón visible y el JSON-LD FAQPage desde la misma fuente.
- 05
Tres planes: Semilla (1 sede, 5 usuarios), Profesional (hasta 5 sedes, 10 usuarios) y Enterprise (sedes y usuarios ilimitados). Cada botón de plan abre el formulario con el tamaño de operación ya elegido. Lo que se vende coincide con lo que el backend hace cumplir: topes de sedes y usuarios, rol Colaborador, Herramientas y exportación CSV desde Profesional, y pérdidas en Finanzas solo en Enterprise.
- 06
Formulario de diagnóstico que envía JSON a una función de servidor. Valida y normaliza los datos, guarda el lead en Supabase y avisa por correo con Brevo. Un correo repetido no crea otra fila y la notificación nunca bloquea el guardado.
- 07
Antispam sin captcha, con comprobaciones en el cliente y en el servidor. Solo guarda en producción.
- 08
Analítica: GA4 opcional, con eventos en cada CTA (Hero, planes, WhatsApp y formulario), más Vercel Web Analytics y Speed Insights. Botón flotante de WhatsApp en todas las páginas.
- 09
SEO técnico: title, description, canonical, Open Graph y Twitter, sitemap, robots.txt y llms.txt. JSON-LD con Organization, WebSite, SoftwareApplication con sus ofertas y FAQPage.
- 10
Seguridad en cabeceras: CSP restrictiva y cabeceras anti-framing y de permisos.
- 11
Calidad: Vitest para la lógica, Playwright para el flujo (landing, formulario, planes, FAQ y menú móvil) y Lighthouse en cada PR con accesibilidad como umbral que bloquea. Una prueba ata los límites de la landing a lo que el producto hace de verdad.
Hero con promesa y demo
Titular 'Reemplaza Excel y WhatsApp', chip de que funciona sin internet, botón al diagnóstico y demo en video en un lightbox.
Módulos contados desde el dolor
Animales, insumos, herramientas (desde el plan Profesional), producción y salud animal, cada uno en un bento que empieza por el problema que resuelve y no por la función.
Integración en cascada
Flujo visual: vacuna aplicada, insumo descontado y fecha de vencimiento con alerta. Y stock mínimo, alerta al administrador. Es lo que el producto hace y demuestra el valor diferencial antes de los planes.
Capturas reales del producto
Pestañas de Dashboard, Animales, Insumos, Producción y Salud Animal con capturas de la app, rotación automática y botón de pausa.
Privacidad y seguridad
Cinco compromisos: cifrado en tránsito, roles y permisos, exportación CSV con aprobación de un administrador, sin minería de datos y respaldo nocturno.
Planes y formulario
Tres planes en un carrusel con límites y alcance, preguntas frecuentes y un formulario de diagnóstico gratuito con WhatsApp como alternativa.
Diseño
- 01
El diseño parte de un prototipo navegable, accesible desde el botón Ver diseño.
- 02
Verde profundo como color primario y ámbar como acento sobre neutros cálidos, en la misma familia visual que la PWA.
- 03
Poppins para titulares, Inter para texto y JetBrains Mono para cifras y detalles. Las tres van autoalojadas.
- 04
Secciones numeradas con un eyebrow editorial y un ritmo que alterna fondos claros y oscuros para separar cada paso del embudo.
- 05
Módulos en bento con minivistas del producto (tablas y tarjetas de métricas) en vez de ilustraciones genéricas.
- 06
Capturas reales en pestañas con rotación automática y pausa, y planes en un carrusel con flechas y pausa.
- 07
Menú de hamburguesa bajo 1000 px, botón flotante de WhatsApp y skip link en todas las páginas.
Decisiones de arquitectura
01 Copy al dolor, no al producto VerCerrar
- Contexto
- El productor agropecuario no busca 'SaaS agroindustrial'. Busca dejar de usar Excel, cuadernos y grupos de WhatsApp.
- Trade-off
- Un copy técnico no conecta con el campo. Un copy de dolor sí, pero exige conocer la operación real.
- Decisión
- Hero sin una sola mención al stack: 'Reemplaza Excel y WhatsApp en tu operación agrícola' y 'No se trata de ganar más, sino de dejar de perder'. Una tabla de antes y después refuerza el contraste.
02 Integración antes de los planes VerCerrar
- Contexto
- La diferencia de TerraCore frente a Excel es que los módulos se hablan entre sí. Eso no es obvio para el productor.
- Trade-off
- Ir directo a los planes antes de demostrar el valor diferencial baja la conversión.
- Decisión
- El bloque de integración ('Una acción. Todo el sistema al día.') va dentro de Módulos, antes de la sección de planes. El usuario entiende el valor antes de ver los planes.
03 Confianza antes de los planes VerCerrar
- Contexto
- Los datos de producción y costos son sensibles para el productor, y la desconfianza bloquea la compra.
- Trade-off
- Omitir la privacidad asume una confianza que en el agro hay que ganar de forma explícita. Ponerla antes de los planes alarga la página.
- Decisión
- La sección de seguridad va justo antes de Planes, con compromisos concretos: sin minería de datos ni entrenamiento de IA y exportación CSV con aprobación de un administrador.
04 Un solo embudo hacia el formulario VerCerrar
- Contexto
- Tres planes con tres destinos dispersan los leads y dificultan saber qué pidió cada visitante.
- Trade-off
- Un destino único pierde la compra directa del plan. A cambio, cada solicitud llega completa y con contexto.
- Decisión
- Los tres botones de plan llevan al mismo formulario y preseleccionan el tamaño de operación del plan. Primero un diagnóstico de 30 minutos y, si encaja, 14 días de prueba sin tarjeta.
05 GA4 para iterar con datos reales VerCerrar
- Contexto
- Sin métricas de comportamiento, el diseño de la landing es intuición: no se sabe qué secciones se leen ni qué botón convierte.
- Trade-off
- GA4 añade un script de terceros con implicaciones de privacidad, y hay que declararlo y poder apagarlo.
- Decisión
- GA4 se activa solo cuando está configurado y registra eventos en cada CTA (Hero, planes, WhatsApp y formulario). La política de privacidad lo declara junto con Vercel Web Analytics.
06 Estática, con una sola función de servidor VerCerrar
- Contexto
- Una landing no necesita un backend propio, pero el formulario tiene que guardar leads sin exponer llaves.
- Trade-off
- Una función serverless no corre bajo el servidor de desarrollo de Astro, y el entorno de pruebas no tiene base de datos.
- Decisión
- El sitio es estático y el formulario habla con una función de servidor que guarda los datos en Supabase. Fuera de producción valida y no guarda.
07 Sin prueba social inventada VerCerrar
- Contexto
- Una landing de un producto en validación está tentada a llenar métricas, casos y testimonios de relleno.
- Trade-off
- Esas secciones aportan confianza, pero con datos falsos la restan. Dejarlas fuera hoy cuesta conversión.
- Decisión
- Las tres secciones están construidas y ocultas hasta tener datos reales. Además, una prueba automática compara los límites de la landing con lo que hace el producto.
Aprendizajes
Una landing para un nicho no tecnológico tiene que hablar el idioma del cliente: cada sección se redactó con vocabulario de la finca, no del software.
Separar la demostración del valor de la sección de planes baja la barrera: el productor llega a los planes habiendo entendido ya qué diferencia a TerraCore de Excel.
Es más barato dejar una sección de prueba social oculta hasta tener datos reales que retirar cifras inventadas.
Roadmap
Ahora
- Landing en producción captando solicitudes de diagnóstico.
Siguiente
- Activar métricas, casos de éxito y testimonios cuando existan datos reales.
03 Documentación
Documentación oficial del producto: uso, características, primeros pasos y soporte. Ver detalleOcultar
- Astro
- MDX
- TypeScript
- Lucide
- Vitest
- Playwright
- Vercel
El problema
La guía es para el cliente final: dueño, administrador u operario de una finca en Colombia, que no es técnico. Necesita aprender el producto sin depender de una llamada de soporte: cómo empezar, qué hace cada módulo, qué hacer cuando algo no sale como espera y a quién escribir.
Ver detalle técnico AbrirOcultar detalle técnico
Qué construí
- 01
Astro con salida estática, sin React ni adaptador, desplegado en Vercel. El JavaScript es TypeScript vanilla: búsqueda, estado del menú lateral y tabla de contenido.
- 02
Contenido en MDX con colecciones de contenido de Astro: una página por archivo, con título, resumen e ícono tipados por el esquema de la colección. 34 páginas en 8 grupos: Empezar, Tu equipo, Tu finca, Tus números, Datos y conexión, Tu suscripción, Flujos de la app y Referencia.
- 03
Una sola fuente de verdad para la navegación: la lista de grupos y páginas define el menú lateral, la hoja de navegación móvil, la portada y el paginador anterior y siguiente, en orden de lectura. Una prueba falla si una página de la lista no tiene archivo, o al revés.
- 04
Bloques de redacción propios, disponibles en cada página sin importarlos: avisos, pasos numerados, campos, capturas, tarjetas, insignias y tablas.
- 05
Diseño atómico con alias de importación por capa (átomos, moléculas, organismos, plantillas y layouts), con los componentes del sistema de diseño de TerraCore recreados en Astro.
- 06
Búsqueda del lado del cliente: el índice se genera en el build como un archivo JSON estático y el navegador lo consulta, sin servidor ni servicios de terceros. Ignora tildes y mayúsculas.
- 07
Navegación en menús agrupados que recuerdan si están abiertos, tabla de contenido por página y paginador entre páginas. Cada página muestra la fecha de su última revisión contra el producto, tomada de una sola constante.
- 08
SEO técnico: sitemap generado, robots.txt, manifest e idioma es-CO declarado en el documento.
- 09
Seguridad por cabeceras, con una CSP restrictiva sin orígenes de terceros y cabeceras anti-framing, anti-sniffing, de referrer y de permisos.
- 10
Calidad: ESLint, Prettier y verificación de tipos con astro check, pruebas unitarias con Vitest y pruebas de punta a punta con Playwright (la guía y la navegación móvil), con CI en cada PR.
Diseño
- 01
Los tokens de color, espacio, radio y sombra son una copia fiel de los del sistema de diseño de TerraCore: no se inventan ni se redefinen en el sitio.
- 02
Íconos Lucide con un trazo uniforme, a través de un único componente.
- 03
Textos en español de Colombia, en tuteo, con fechas largas y números en formato es-CO, sin emojis.
- 04
Barra lateral en escritorio; en móvil, barra superior con una hoja inferior para navegar.