Web
La app web está construida con React y TanStack Router, buscando una navegación rápida, tipada y fácil de mantener mientras los módulos crecen.
Para desarrolladores
Una mirada técnica a cómo estamos construyendo Nottrix
Nottrix combina una app web, una experiencia móvil, una app de escritorio en exploración y una API compartida para mantener notas, finanzas, pizarras y recordatorios conectados sin convertir el producto en una colección de piezas sueltas.
Esta página comparte decisiones de alto nivel. Evitamos publicar detalles operativos, rutas internas, políticas exactas de infraestructura o configuraciones que puedan comprometer la seguridad del servicio.
Tecnologías principales
Stack moderno, compartido donde conviene y separado donde la experiencia de cada plataforma lo necesita.
Móvil
La app móvil usa React Native y Expo para llevar los módulos principales de Nottrix a una experiencia nativa, rápida y cómoda en el día a día.
Desktop
La app de escritorio se explorará con Wails y Go, buscando mejor consumo de memoria que Electron y un flujo más cercano para nosotros que alternativas basadas en Rust como Tauri.
Backend
La API corre sobre Node.js con Hono y oRPC para mantener contratos tipados entre cliente y servidor, con una superficie clara para crecer por módulos.
Datos y acceso
La capa de datos usa PostgreSQL y Drizzle ORM para mantener el modelo tipado. Redis nos ayuda donde el tiempo de respuesta y la coordinación importan.
UI
La interfaz se apoya en HeroUI v3 y HeroUI Native con Uniwind para una experiencia consistente. Conocemos y seguimos la evolución de esta biblioteca desde NextUI.
Decisiones de arquitectura
Estas decisiones buscan que el producto sea mantenible sin sacrificar velocidad de iteración.
Monorepo con límites claros
El código vive en un monorepo TypeScript para compartir tipos, UI, autenticación, datos y utilidades sin duplicar lógica entre web, móvil y servidor. También nos ayuda mucho a trabajar con agentes de código como Claude Code y Codex, porque mantienen contexto del proyecto completo y todos los plan.md viven en el mismo repositorio.
Módulos específicos, no lienzo vacío
Finanzas, documentos, pizarras, recordatorios y organización se diseñan como módulos concretos. Eso permite una experiencia más guiada y menos dependiente de plantillas.
Static-first para la landing
El sitio público se mantiene mayormente estático para mejorar rendimiento, SEO y confiabilidad. Las partes interactivas se hidratan solo cuando aportan valor visible.
Tipado end-to-end
La prioridad es que los cambios de dominio fallen temprano durante el desarrollo, no en producción. Por eso los contratos compartidos y las validaciones tienen un rol central.
Principios que guían la implementación
Compartir el dominio, no forzar la interfaz
Web, móvil y servidor comparten contratos, tipos y lógica cuando representan el mismo concepto del producto. La experiencia visual y de navegación se adapta a cada plataforma: compartir código no debe hacer que una app móvil se sienta como una web reducida ni que la web herede restricciones innecesarias.
Cambios pequeños, contratos explícitos
Cuando un módulo cambia, el objetivo es que sus efectos se detecten cerca del cambio. Los contratos tipados entre cliente y servidor, el esquema de datos y las validaciones son una forma de hacer visibles las incompatibilidades antes de que lleguen a una persona usando la app.
Complejidad solo cuando paga una deuda real
Una tecnología nueva no es una mejora automática. La elección se evalúa por mantenimiento, seguridad, rendimiento y claridad para quien usa el producto. Por eso la landing es estática por defecto y los componentes interactivos se limitan a los lugares donde cambian materialmente la experiencia.
Seguridad y privacidad
Trabajamos con buenas prácticas de autenticación, validación de entradas, separación de responsabilidades y control de acceso por organización. También evitamos documentar públicamente detalles que faciliten abuso, enumeración o ingeniería inversa de las apps desplegadas.
Cómo evoluciona el proyecto
- Primero se estabilizan los flujos de uso diario: documentos, finanzas, pizarras, recordatorios y navegación entre dispositivos.
- Después se amplían las integraciones y mejoras de colaboración donde aporten claridad real al usuario.
- Cada cambio técnico se evalúa por mantenimiento, seguridad, rendimiento y simplicidad de uso, no solo por novedad.
Qué se puede esperar del proyecto
El producto está en evolución y la arquitectura también. Algunas decisiones, como la exploración de una app de escritorio, siguen abiertas porque deben demostrar que resuelven una necesidad real antes de consolidarse. La prioridad no es publicar cada experimento; es mantener una base que permita mejorar documentos, finanzas, recordatorios y pizarras sin perder estabilidad ni contexto entre dispositivos.
¿Quieres conversar sobre la parte técnica?
Si tienes feedback, ideas o curiosidad por decisiones de producto e ingeniería, puedes escribir directamente.
Escribir sobre Nottrix