Construimos productos de
software completos, y la capa que queda por debajo.
Llevamos ideas de producto difíciles desde el alcance hasta el software entregado: interfaz, backend, IA, infraestructura, seguridad y entrega. Cuando lo difícil está por debajo de la capa de aplicación, trabajamos ahí también.
Ver los ejemplos de entregables
Dos ramas, y el ciclo entre ellas.
El trabajo de producto para clientes es la oferta. El software que poseemos mantiene la ingeniería lo bastante profunda como para que valga la pena contratarla. Es un único oficio, no dos, y el mismo estándar se aplica a ambas.
Lo que construimos para clientes
Ingeniería de producto completa para empresas que necesitan profundidad real y no una plantilla: alcance, interfaz, backend, IA, infraestructura y seguridad, asumidos de principio a fin. Es el trabajo que puedes contratar hoy, con la misma ingeniería y los mismos estándares que todo lo que sigue.
Lo que asumimosLo que poseemos
Software de sistemas diseñado desde los primeros principios en lugar de montado sobre el producto de otro: un sistema operativo propio basado en Linux, plataformas para desarrolladores y herramientas asistidas por IA. I+D propia y no algo que vendamos hoy, y la razón por la que el criterio en infraestructura y seguridad de un desarrollo para un cliente vale lo que cuesta. Cada pieza lleva su etapa real.
Ver el banco de trabajoLo que compartimos
Escribimos sobre las entrañas: cómo funcionan de verdad los sistemas, lo que aprendemos construyendo un sistema operativo, las decisiones detrás de las herramientas. No es marketing disfrazado de entradas de blog. Es escritura técnica de verdad para gente que construye cosas.
Leer lo último
Tres proyectos propios.
Tres tipos de sistema distintos: una superficie de producto, un sistema de datos y una capa de sistema operativo. Juntos muestran amplitud, no una especialidad.
- / 01
Mantener de acuerdo un modelo de edición y su resultado
Una plataforma de contenido multiinquilino. Lo que edita el usuario y lo que sirve un navegador son dos artefactos distintos, y mantenerlos de acuerdo es todo el problema, que se repite en permisos, dominios y facturación.
- / 02
Convertir una pregunta en una consulta que puedas comprobar
Un sistema de análisis en lenguaje natural. El SQL generado es código no confiable dirigido a una base de datos real, así que se valida antes de ejecutarse y se muestra junto a su resultado en lugar de ocultarse.
- / 03
Tener root sin cederlo
Un gestor de pantalla, el nivel más bajo al que llega un proyecto. Autentica, tiene root y arranca una sesión que nunca debe heredar esa autoridad, en una máquina donde un fallo no deja ninguna pantalla desde la que depurar.
Productos completos, con profundidad por debajo.
La ingeniería de producto es la oferta. Las tres categorías de debajo son la profundidad a la que recurre un producto difícil, y la razón por la que el trabajo no se detiene en la capa de aplicación.
Ingeniería de producto
Un desarrollo completo: alcance, interfaz, backend, integraciones, despliegue y entrega. Todo, o la parte que bloquea al resto.
IA y automatización
Sistemas de agentes y automatización que resisten el uso real: límites en las herramientas, contexto controlado, evaluación antes de que un cambio salga.
Plataforma e infraestructura
El entorno de ejecución donde vive un producto: aprovisionamiento como código, CI, despliegue y reversión, y fallos que salen a la superficie en lugar de esconderse.
Seguridad y profundidad de sistemas
Límites de acceso, mínimo privilegio, endurecimiento y la depuración de bajo nivel que empieza donde se acaban los registros de la aplicación.
Diseñado para la carga, el fallo y la reversión.
El vocabulario con el que se construye el trabajo, y los tres modos de fallo en torno a los que se diseña desde el principio.
Pensamiento de sistemas
Procesos, servicios, límites de recursos y modos de fallo son el vocabulario de trabajo, no ideas de última hora. Un sistema se razona a partir de las piezas móviles que de verdad tiene.
Seguridad por defecto
Se asume una entrada hostil, el sistema falla en modo cerrado y el mínimo privilegio rige desde el primer commit. La seguridad es la posición de partida, no una pasada de endurecimiento antes del lanzamiento.
Fallo y recuperación
El diseño contempla qué ocurre cuando una pieza se rompe y cómo vuelve. La recuperación se planifica, no se improvisa cuando todo ya está caído.
- interfazlo que la gente toca
- servicioslas piezas móviles
- datosestado y flujo
- ejecuciónprocesos y límites
- infraestructurasobre lo que se ejecuta todo
Los tres en torno a los que se diseña
Diseñado para aguantar la carga
Los presupuestos de latencia y de coste se fijan antes de construir, de modo que la carga tiene un techo conocido desde el diseño en lugar de convertirse en una sorpresa en producción.
Diseñado para contener un fallo
Cada pieza recibe un radio de impacto acotado, así que la rotura de una pieza no puede arrastrar consigo al resto del sistema.
Diseñado para poder deshacerse
Los despliegues se construyen para ser reversibles y los entornos para reconstruirse desde el código fuente, de modo que recuperarse es una reversión y no un rescate.
Del primer contacto al lanzamiento, un solo camino.
Todo el arco desde tu lado: qué ocurre antes de que se comprometa nada, y cómo se desarrolla la entrega una vez que sí.
- 01
Una llamada o un brief por escrito
Empiezas con una llamada si el problema aún está tomando forma, o con un brief si el alcance y las restricciones ya están definidos. En ambos casos llegas a la misma persona.
- 02
Un documento de alcance
La conversación se convierte en un documento breve: el problema tal como se entiende, lo que se construirá, lo que no, y qué cuenta como terminado.
- 03acordado
Acordado antes de que empiece nada
Lees el alcance y lo aceptas. No se factura nada hasta que ese documento esté cerrado, así que el compromiso es tuyo.
- 04
Construido en incrementos revisables
La entrega avanza por etapas, según ese alcance. Cada incremento es algo que puedes inspeccionar, así que el progreso se ve en lugar de prometerse.
- 05
Lanzado con su razonamiento
El sistema sale a producción con su runbook y las decisiones que hay detrás. Recibes algo que puedes operar y pasar al siguiente ingeniero sin hacer arqueología.
Líneas que no cruzaremos.
Cuatro negativas, dichas desde el principio para que no tengas que descubrirlas después.
No entregaremos una demo que no pueda sobrevivir en producción
Si solo se sostiene en el camino feliz, no está terminada. El listón es un sistema que sigue funcionando con carga real y entradas reales.
No ocultaremos el razonamiento detrás de una decisión
Toda decisión no evidente se entrega con el porqué. Nunca tendrás que hacer ingeniería inversa de una elección que alguien tomó y no dejó escrita.
No pasaremos tu sistema a un subcontratista anónimo
El trabajo no se traspasa a una agencia ni a un freelance de una plataforma a tus espaldas. Si una parte necesita a un especialista, lo sabrás durante la definición del alcance y decidirás tú.
No añadiremos una pieza móvil que no pueda justificarse
Cada componente se gana su sitio o sale. Nada se queda en el sistema porque quitarlo resulte incómodo.
Hablas con las personas que de verdad entienden lo que estás construyendo.
Comunicación directa con los ingenieros que hacen el trabajo, sin una capa de gestores de cuenta de por medio. Un único responsable se mantiene cerca del alcance, la arquitectura, la implementación y la entrega.
Cuéntanos lo que estás construyendo.
Un producto entero, o la parte que bloquea al resto. Sirve igual un brief por escrito que una llamada: empieza por la restricción que de verdad es difícil.