Arranque: por qué fundamos una empresa de software centrada en la infraestructura

Esta es la primera entrada del blog de ProCat Solutions Kft. Somos una microempresa de Budapest, un equipo de pocas personas, y desarrollamos software. Eso, por sí solo, no tiene nada de especial: en la ciudad hay cientos de empresas parecidas. Aquello en lo que queremos diferenciarnos es el enfoque: no partimos de la lista de funcionalidades, sino de la infraestructura sobre la que el sistema va a correr en producción.

¿Por qué no “feature-first”?

En los últimos años hemos visto de cerca varios proyectos que arrancaron rápido y de forma vistosa, y que a la primera carga seria o al primer incidente de seguridad dejaron a la vista que les faltaban los cimientos. Los síntomas típicos resultan familiares:

• un único servidor en el que corre todo, sin copias de seguridad,
• claves de API en el código fuente, sin gestión de permisos,
• una base de datos que nadie indexó porque en la máquina del desarrollador iba rápida,
• despliegue a mano, por SSH, un viernes por la tarde.

No son errores exóticos, sino la consecuencia de que el sistema se construyó en el estado “funciona si pulso el botón”, y no en el estado “funciona si mil personas pulsan el botón a la vez y, mientras tanto, se cae un disco”.

Nosotros lo pensamos al revés. Primero aclaramos dónde va a correr el sistema, qué carga tiene que aguantar, qué pasa en caso de fallo, cómo sale la nueva versión y quién accede a los datos. Las funcionalidades se construyen sobre esa base. Esto no significa que sobredimensionemos todos los proyectos; significa que tomamos las decisiones de forma consciente, y no a posteriori y a la fuerza.

¿Qué entendemos por desarrollo centrado en la infraestructura?

Algunos principios concretos que seguimos en todos nuestros proyectos:

Arquitectura lista para producción desde el primer día. El entorno de desarrollo corre en Docker igual que el de producción. La misma configuración de Nginx, las mismas variables de entorno, la misma versión de PostgreSQL. Así, el fenómeno del “en mi máquina funciona” no llega ni a aparecer.

Estructura de API segura. Diseñamos todas las API como si fueran públicas: autenticación, gestión de permisos, validación de entrada, rate limiting. Esto ahorra más adelante el trabajo de cuando una API interna se convierte de repente en una API expuesta a socios.

Alta disponibilidad. No todos los proyectos necesitan redundancia multizona, pero todos necesitan copias de seguridad automáticas, health checks, reinicio en caso de fallo y un procedimiento de recuperación documentado.

Infraestructura gestionada por nosotros. Trabajamos sobre VPS y servidores dedicados, con Linux, Docker y Nginx. Esto no es un rechazo a los proveedores cloud, sino una elección consciente: la mayoría de nuestros clientes necesita costes predecibles y control total, no una factura que escala en minutos pero que resulta difícil de seguir.

¿Con qué tecnologías trabajamos?

Nuestro stack es deliberadamente estrecho. En el backend, Node.js (NestJS y Express) y Laravel; como base de datos, PostgreSQL; como caché y cola de mensajes, Redis. Para contenerización, Docker; como reverse proxy, Nginx, y debajo, Linux. En el lado frontend y móvil, React, Angular y React Native.

No elegimos estas tecnologías porque estén de moda, sino porque llevamos años conociendo también sus defectos. Solo podemos llevar una tecnología a producción de forma responsable si sabemos cómo se comporta cuando escasea la memoria, qué hace si se corta la conexión con la base de datos y cómo se puede actualizar con seguridad.

También nos interesa el mundo de las telecomunicaciones (SIP, VoIP, integración con la PSTN), y seguimos lo que ocurre en blockchain y en aprendizaje automático, pero de eso escribiremos cuando tengamos experiencia real detrás.

¿De qué va a tratar este blog?

Ni de presentaciones de producto ni de notas de prensa. Queremos escribir sobre lo que aprendemos trabajando:

• decisiones de arquitectura concretas y sus consecuencias,
• errores que hemos cometido y que a otros les convendría evitar,
• experiencias de operación: monitorización, copias de seguridad, pruebas de carga,
• territorios nuevos en los que entramos y en los que documentamos los primeros pasos.

El público al que nos dirigimos son desarrolladores como nosotros y aquellos responsables de decisión que quieren entender qué ocurre bajo el capó de su sistema. Intentamos ser concretos: si una solución no nos ha funcionado, también lo contamos.

¿Cómo seguimos?

En los primeros meses tenemos previsto escribir sobre el diseño de API REST de alta carga y sobre las arquitecturas SaaS multi-tenant, porque son las áreas en las que ahora mismo tenemos más trabajo. Si quieres comentar alguno de estos temas, o estás trabajando en un problema parecido, puedes localizarnos en info@procats.hu.

Gracias por leer la primera entrada. En la siguiente ya habrá código y configuración.