Experiencia · Software a medida

Un sistema construido para la forma en que trabaja tu organización, no para el caso general.

Construimos sistemas desde cero, cuando ningún producto del mercado encaja: plataformas con varias aplicaciones y una base de datos común, conectores hacia sistemas que no tienen API, conductos que leen documentos y movimientos de dinero, y programas cuyo resultado no es una pantalla, sino un dossier de fabricación. Al final entregamos el repositorio, el documento de puesta en marcha y los accesos.

Habla de un proyecto

Ya construidoHe elegido cuatro sistemas propios de disciplinas diferentes, precisamente para que no parezcan cuatro variantes del mismo sitio, y he ejecutado hoy las pruebas de cada uno. Un monorepo con 3 aplicaciones y 12 paquetes, 486 archivos TypeScript y 68 archivos de prueba, 151 commits, árbol de trabajo limpio. Un sistema de consulta de dos portales B2B sin API pública: 38 pruebas aprobadas en 0,52 s, sobre respuestas reales guardadas como fixturas. Una canalización que lee notificaciones bancarias de e-mail y PDF y las escribe en Postgres con deduplicación por huella digital. Y un generador de documentación de ingeniería, en Python, con 44 pruebas aprobadas en 0,50 s. Las cifras son de mis ejecuciones del 6 de septiembre de 2026, no de README.

„A medida” significa que el sistema se escribe según la forma en que ya trabaja tu gente, no al revés. Tiene un coste que es honesto decir antes: alguien tiene que mantenerlo, y ese alguien somos nosotros o tu equipo. Por eso la primera pregunta que te hacemos no es qué quieres construir, sino si existe un producto que ya hace el 80% del trabajo. Si existe, lo decimos, aunque eso signifique que no nos das a nosotros el trabajo. Lo que queda después de esa pregunta — la parte que no se compra — es exactamente lo que construimos bien.

La amplitud se ve más clara en cuatro sistemas distintos que en una lista de tecnologías. El primero es una plataforma para una institución de espectáculos: un monorepo con tres aplicaciones (sitio público, gabinete administrativo, API) y doce paquetes comunes — entradas, comercio, contenido, notificaciones, devoluciones, seguridad. El segundo consulta, a demanda, los portales B2B de unos turoperadores que no publican ninguna API: autenticación programática, retorno al login cuando la sesión expira, y un analizador probado con respuestas reales capturadas en archivos. El tercero lee notificaciones bancarias de correo electrónico y extractos en PDF y las coloca en Postgres. El cuarto no tiene pantalla en absoluto: es el programa que genera el modelo, la lista de materiales y los planos de una máquina industrial.

Lo que mantiene en pie un sistema así no es la pila, sino las reglas escritas antes de la primera pantalla. En la plataforma para la institución de espectáculos, el contrato de implementación fija en texto cosas que de otro modo se negocian en cada reunión: el dinero se mantiene en unidades menores enteras, con la moneda al lado; la disponibilidad de un asiento solo la da una reserva duradera en la base de datos, nunca la memoria intermedia; los pedidos críticos tienen claves de idempotencia; las vías P0 y P1 fallan en cerrado, no en abierto; los datos de tarjeta nunca se almacenan. Estas reglas se escriben al inicio porque, escritas al final, significarían reescribir el sistema.

Al final se entregan tres cosas, no una: el repositorio con todo su historial, el documento que dice cómo ponerlo en funcionamiento en un servidor vacío, y los accesos. Bajo nuestro directorio de proyectos hay 150 repositorios git, 103 archivos README y 19 documentos de puesta en funcionamiento o de entrega — contados hoy, no estimados. La regla de propiedad la escribimos en el contrato antes del inicio y es simple: el código escrito especialmente para ti es tuyo, las bibliotecas de terceros permanecen bajo su licencia, y nuestros componentes reutilizables y nuestros productos se licencian, no se ceden. Si una parte del trabajo se resuelve mejor con un producto nuestro, te lo decimos exactamente así, para que sepas desde el principio qué compras y qué recibes.

Qué incluye

El trabajo, por componentes

Escribimos las reglas del dominio antes de la primera pantalla

Un contrato de implementación, en texto, que fija el vocabulario y los invariantes: qué significa un asiento reservado, qué significa un pago cobrado, qué falla en cerrado cuando un servicio no responde. En la plataforma para la institución de espectáculos las reglas son explícitas — el dinero en unidades menores enteras más la moneda, la disponibilidad solo a partir de reservas duraderas en la base de datos, claves de idempotencia en los pedidos críticos, la memoria intermedia nunca como fuente de verdad para el stock, los datos de tarjeta nunca almacenados. Son reglas que se verifican en el código, no principios.

Construimos el núcleo sobre pruebas que se ejecutan sin el sistema vivo

Las respuestas reales de los sistemas externos se guardan como fixtures y el analizador se prueba sobre ellas, no sobre el portal que puede estar caído justo el día en que trabajas. En el sistema de consulta de portales de vuelos, la suite se ejecuta en 0,52 segundos y pasa íntegramente; las pruebas que realmente tocan los portales se marcan aparte y se piden explícitamente. La misma separación existe en los cuatro sistemas: lo que se puede verificar en la mesa se verifica en la mesa.

Entregamos el repositorio, la puesta en funcionamiento y los accesos

No un archivo zip. El repositorio con el historial de commits, un documento que describe cómo se levanta el sistema en una máquina vacía — base de datos, variables de entorno, servicio del sistema, servidor web delante — y los accesos que lo hacen tuyo. Bajo nuestro directorio de proyectos existen hoy 150 repositorios git, 103 README y 19 documentos de tipo DEPLOY o HANDOVER; esa forma de entrega es la costumbre, no la excepción.

Cuando el sistema del otro no tiene API, te decimos qué riesgo asumes

Los portales B2B que consultamos no publican interfaz programática, así que la autenticación se hace como la de un usuario, con cookie de sesión y clave de conexión, y se rehace automáticamente al expirar. El riesgo está escrito en el README del proyecto, no descubierto después: la autenticación programática es una zona gris frente a las condiciones de uso del portal, y para un volumen de producción intenso la solución correcta es pedir al operador su API oficial. Un cliente tiene derecho a saberlo antes de firmar, no después.

Los documentos entran una sola vez, aunque los leamos diez veces

Cada transacción extraída de una notificación bancaria o de un extracto PDF recibe un identificador externo calculado como fingerprint SHA-256 sobre sus campos, y la inserción en Postgres se hace con `ON CONFLICT (external_id) DO NOTHING`. La consecuencia práctica: el buzón puede releerse tantas veces como quieras, y el saldo no se duplica. Sin esta regla, cualquier canal de ingestión acaba produciendo duplicados, es decir, un problema de contabilidad.

La clasificación con modelo se hace mediante herramientas, no mediante texto libre

El modelo no escribe una frase que luego adivinamos nosotros: recibe siete herramientas — pago de cliente, salario, impuesto, pago a acreedor, gasto de explotación, desconocido — y debe elegir una, con un puntaje de confianza entre 0 y 1. Para la coincidencia aproximada de nombres de contrapartida existe una reserva separada, basada en similitud de vectores. «Desconocido» es una salida legítima, con motivo, no un fallo oculto.

A veces el resultado no es una pantalla, sino un dossier

Un sistema propio en Python genera el modelo tridimensional de una máquina industrial, la lista de materiales con estado de liberación en cada posición, el plan de verificación, el esquema de cables y las láminas PDF — con un solo comando, para que nada del paquete pueda quedarse detrás del modelo. Tiene 44 pruebas que pasan en medio segundo y que verifican reglas de ingeniería, no solo código: que el dominio activo sea exactamente un metro cúbico, que ninguna posición de la lista de materiales quede sin línea de verificación, que la máquina nunca extruya en reposo.

La medición continua es otra disciplina que la consulta bajo demanda

Un sistema propio capta simultáneamente varias emisoras de radio con `ffmpeg`, transcribe localmente con un modelo de código abierto, luego busca anuncios con una puntuación transparente por grupos de señales en rumano y ruso, con umbral configurable, y agrupa el mismo anuncio emitido en distintas emisoras mediante una huella de audio de tipo chromaprint — porque las transcripciones divergen, pero el sonido es idéntico. Tiene 81 pruebas que pasan en 1,14 segundos. Un sistema que funciona sin supervisión necesita contadores de cobertura, reintentos con alquiler de tarea y un autotest; de lo contrario, calla cuando se rompe.

También decimos lo que no construimos

No construimos desde cero lo que se resuelve con un producto existente, nuestro o de otro, solo porque el trabajo sería mayor. No asumimos sistemas que no podamos ejecutar localmente, con datos de prueba, hasta el final de la primera etapa. Y no ponemos en marcha un sistema que dependa de un proveedor externo antes de verificar qué gate pública tiene ese proveedor — esa verificación es la primera, no la última.

Qué aspecto tiene

El recorrido, paso a paso.

Delimitamos el ámbito y escribimos las reglas

Una etapa de leer sistemas y hablar con las personas que hacen el trabajo hoy, cerrada con un documento corto con el vocabulario, las invariantes y qué queda cerrado. Entregamos este documento incluso si no se llega a la construcción: es útil también sin nosotros. En él entra también la lista de sistemas externos de los que depende el trabajo y la verificación de qué puerta pública tiene cada uno, porque de ahí vienen las sorpresas.

Construimos el núcleo, con sus pruebas, antes que las pantallas

Las reglas del dominio, los modelos de datos, los analizadores, los cálculos — más las pruebas que se ejecutan sin los sistemas vivos, sobre fixturas capturadas de respuestas reales. Entregamos la suite y su resultado, con el comando de ejecución, para que la puedas ejecutar tú. Un núcleo que no puede probarse sin el entorno de producción es un núcleo que no podemos reparar rápido más adelante.

Ponemos la interfaz y las integraciones sobre el núcleo

El gabinete administrativo, las pantallas públicas, los puntos de entrada para otros sistemas. Aquí se conectan los proveedores externos, cada uno con un adaptador propio y con una variante de simulación, para que el sistema pueda ejecutarse íntegramente sin cuentas reales. Entregamos también el modo de ejecución local, con base de datos y servicios levantados desde contenedores.

Ponemos en funcionamiento y entregamos

Instalación en la infraestructura acordada, servicio de sistema, servidor web delante, registros y su rotación, autotest. Luego la entrega: repositorio, documento de puesta en funcionamiento escrito para una máquina vacía, accesos y una revisión de lo que queda por hacer. Lo que no se haya llegado a incluir en el trabajo se escribe como lista, no se deja sin decir.

Tres pasos y su orden, que es la mitad del trabajo. Primero, las reglas del dominio escritas en texto — qué significa un lugar reservado, cómo se guardan los fondos, qué cae cerrado cuando un servicio calla. Luego, el núcleo con sus pruebas, que se ejecuta sobre respuestas reales guardadas como fixtures, sin los sistemas vivos. Al final, la puesta en marcha y la entrega: repositorio, el documento para una máquina vacía, accesos. La flecha de vuelta del paso tres al paso uno es real: lo que se descubre en la puesta en marcha cambia las reglas, no se oculta bajo ellas.

Los datos

Qué tocamos, dónde están y cuánto se quedan

Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.

Dónde se ejecuta y quién tiene la llave: El sistema se ejecuta en la infraestructura acordada por escrito al inicio: tu servidor, un servidor administrado por nosotros, o un proveedor de alojamiento elegido conjuntamente. Los cuatro sistemas de arriba se ejecutan de forma distinta entre sí — uno como servicio de sistema detrás de un servidor web, uno desde contenedores, uno como proceso programado en una máquina local, uno solo bajo demanda, en la estación de trabajo. La elección se toma por las restricciones de los datos, no por costumbre.
Las credenciales no están en el código y, donde se puede, tampoco en el disco: Las contraseñas y las claves se leen desde variables de entorno, y el archivo que las contiene se restringe al usuario actual. En un conector hacia un sistema externo, el token de sesión se guarda solo en memoria y se rehace al expirar o al primer rechazo — la contraseña y el token no se escriben en ningún archivo. La regla se verifica en la revisión: una clave que llega al repositorio es un incidente, no un descuido.
Datos que entran desde documentos: Cuando el sistema lee correos electrónicos o PDF, toca datos reales de negocio: importes, fechas de calendario, denominaciones de contrapartida, números de cuenta. Se almacenan en la base de datos del beneficiario, con un identificador propio, que no se puede repetir, por registro, y se puede reconstruir desde la fuente. Lo que sale hacia un modelo externo, si se usa uno, es la descripción de la transacción — no el documento entero ni el archivo adjunto.
Qué se conserva y durante cuánto tiempo: El plazo de conservación se establece por tipo de dato, no de forma global, y se escribe antes de la puesta en funcionamiento: los registros de negocio según las obligaciones legales del beneficiario, los registros técnicos en una ventana corta, los archivos intermedios —capturas de audio, adjuntos descargados— con limpieza automática. Un sistema que no tiene política de borrado termina, en seis meses, siendo un riesgo mayor que el problema que resolvía.
Qué queda con nosotros después de la entrega: Después de la entrega, nuestro acceso a tus sistemas existe solo si hay un contrato de mantenimiento que lo exija, y se retira cuando ese contrato termina. Las copias de trabajo en nuestras estaciones se borran a petición. Lo que conservamos en cualquier caso son los componentes genéricos que hemos escrito y que no contienen tus datos —y esos los declaramos desde el inicio, para que no haya una sorpresa al final.

Un caso

Un sistema de consulta para dos portales que no tienen ninguna API

La situación

Una agencia de viajes necesitaba, a petición, la disponibilidad de plazas y las tarifas en los vuelos chárter de los portales B2B de dos turoperadores. Los portales están pensados para ojos humanos: te autenticas, buscas, lees una tabla. No existe una interfaz programática publicada, y la información se releía manualmente, varias veces al día, por una persona.

Qué construimos

Hemos escrito un cliente que se autentica programáticamente y rehace por sí solo la sesión cuando expira, un analizador que transforma las respuestas en objetos y una capa de identificadores para aeropuertos, donde el código está formado por ciudad y puerto, y algunas llamadas piden las dos partes por separado. Sobre ellos: un comando de línea que devuelve una ruta completa con disponibilidad y precio, un modo de solicitudes por lote con pausas entre ellas para que no se bloquee la cuenta, y dos puntos de entrada JSON para el caso en que otra plataforma quiera consumir el resultado. El analizador se prueba sobre respuestas reales, guardadas como fixtures en el repositorio, y las pruebas que realmente tocan los portales están marcadas por separado y no se ejecutan de forma predeterminada.

Qué salió

La suite pasa íntegramente: 38 verificaciones en 0,52 segundos, sin tocar los portales. Una solicitud devuelve, en una sola respuesta, la disponibilidad en los cuatro estados que usa el portal y la tarifa con clase y equipaje, en la moneda solicitada. El resultado se puede consumir desde la línea de comandos, como JSON, o a través de los dos puntos de entrada HTTP.

Qué no dice el caso

La autenticación programática sigue siendo una zona gris frente a las condiciones de uso de los portales, y eso está escrito en el README del proyecto, no descubierto después de la entrega. Para un volumen intenso de producción, nuestra recomendación es explícita: se pide la API oficial a los operadores. El sistema hace solicitudes puntuales y pone pausas entre ellas precisamente para no convertirse en una herramienta de extracción masiva.

Preguntas

Lo que nos pregunta la gente antes de llamar

¿Por qué no aparece ningún precio en esta página?

Porque no podríamos escribirlo con honestidad. El esfuerzo de un sistema a medida depende de tres cosas que no sabemos antes de mirar: cuántos sistemas externos hay que tocar y si alguno tiene API, cuántas reglas de negocio ya están escritas en alguna parte y cuántas hay que descubrir a partir de personas, y quién mantiene el sistema vivo después de la entrega. Un número dado antes de ver el sistema es una adivinanza con factura. Lo que sí podemos hacer rápido es la primera etapa —leer, delimitar, escribir las reglas—, que se estima correctamente y sigue siendo útil aunque te detengas ahí.

¿Quién posee el código al final?

El código escrito especialmente para ti es tuyo, con todo y repositorio e historial. Las bibliotecas de terceros siguen bajo sus licencias —no podemos cedértelas, porque no son nuestras. Nuestros componentes reutilizables y nuestros productos existentes se licencian para uso, no se transfieren; si tu trabajo se apoya en uno de ellos, te lo decimos en la oferta escrita, antes del inicio, no en la última reunión.

¿Qué pasa si queremos continuar con otra persona?

La entrega debe hacer eso posible sin nosotros; de lo contrario, no hubo entrega. Por eso el documento de puesta en funcionamiento se escribe para una máquina vacía y no presupone nada de nuestra cabeza, y las pruebas permanecen en el repositorio para que el siguiente equipo sepa qué se rompe cuando modifica. Lo que no podemos prometer es que un sistema complejo se asuma sin esfuerzo —solo podemos prometer que no le falta nada de lo que hace falta para que sea asumido.

¿Puedo ver un sistema construido por vosotros, para juzgar la calidad?

Parcialmente, y es correcto decir dónde se detiene. Los sistemas construidos para clientes no son nuestros como para mostrarlos, y los internos contienen datos reales de negocio. Lo que podemos hacer delante de ti, en la pantalla, es otra cosa: abrimos el repositorio, te mostramos las reglas del dominio escritas en texto, ejecutamos las suites de pruebas — 38 en medio segundo en uno, 81 en poco más de un segundo en otro, 44 en el tercero — y leemos juntos el código que hace la afirmación que pones en duda. Este sitio es, a su vez, un sistema propio que puede inspeccionarse desde fuera.

Nuestro sistema antiguo no tiene API. ¿Se puede hacer algo?

Normalmente sí, pero con riesgo declarado. El orden es: primero preguntamos si el proveedor tiene una API oficial que simplemente no ha documentado públicamente — pasa a menudo. Si no la tiene, se puede trabajar mediante autenticación programática, exactamente como un usuario, con sesión renovada automáticamente; construimos así un sistema que consulta dos portales B2B. Entonces te escribimos con claridad que es una zona gris frente a las condiciones de uso del proveedor y que, para gran volumen, la solución duradera es pedir la API oficial. La decisión sigue siendo tuya, pero informada.

¿Usan inteligencia artificial para escribir el código?

Sí, y no lo ocultamos. Importan las reglas bajo las que se hace: cada parte del trabajo se cierra con pruebas que se ejecutan, con verificación de tipos y con una revisión de diferencias antes de confirmar, y los límites están escritos en el repositorio — sin publicaciones en producción desde dentro del trabajo, sin cambios en cuentas externas, adaptadores para proveedores solo con variante de simulación. Un código escrito rápido y no probado es más caro que uno escrito despacio. Lo que vende esto es la velocidad en la parte aburrida, no la ausencia de verificación.

¿Qué hacen cuando, a mitad de camino, se demuestra que la idea inicial era incorrecta?

Lo decimos. En un proyecto propio de ingeniería llegamos, después de la evaluación, a una segunda arquitectura completamente distinta para el mismo problema y la escribimos como alternativa documentada, con las puertas que hay que pasar antes de cualquier pedido, en lugar de seguir con la primera solo porque ya estaba empezada. El coste de un cambio de rumbo a mitad de camino es menor que el de un sistema entregado en la forma equivocada, y la diferencia la paga el beneficiario en ambos casos.

¿Qué tan grande puede ser el trabajo?

En un extremo, un sistema con tres aplicaciones y doce paquetes compartidos en un solo repositorio, 486 archivos TypeScript, 68 archivos de prueba y 151 commits, con base de datos relacional, coordinación efímera separada de la fuente de verdad y contratos comunes entre aplicaciones. En el otro extremo, un sistema con un solo proceso y veinte puntos de entrada, que es exactamente lo necesario. La amplitud no es una promesa sobre cualquier tamaño — es la observación de que hemos trabajado en ambos extremos.

¿También hacen mantenimiento después de la entrega?

Sí, pero como un acuerdo separado, no como algo implícito. Un sistema a medida necesita actualizaciones de seguridad, seguimiento de los cambios en los proveedores externos y a alguien que mire los registros. Si prefieres hacerlo con tu equipo, la entrega se construye para que sea posible. Si prefieres que lo hagamos nosotros, se escribe qué cubre y qué no — incluso qué significa «urgente», porque sin definición esa palabra no significa nada.

En qué se basan las afirmaciones anteriores (15 fuentes)

15 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.

Cómo trabajamos Todos los servicios

¿Qué te gustaría que funcionara mejor?

Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.

Vamos a hablar