Producto web, automatización y herramientas internas, construidos con criterio técnico.
SYS/--Aplicación
inicio
dungeon terminal / canal principal
Software a medida, pero con más magia visual.
Producto web, automatización de procesos y herramientas internas.
Construimos software que resuelve un problema concreto de tu operación,
con criterio técnico, IA donde acelera y bastante imaginación.
claro · creativo · útil
qué hacemos
módulos disponibles
Construimos software para trabajo real.
Producto, automatización, software interno y sistemas heredados.
Cada módulo abre con la situación, no con la oferta: si te reconoces
en la primera línea, esa es la tuya.
00
Producto web
Tienes la idea clara y no existe en ninguna parte.
De una necesidad concreta a una primera versión usable.
Nuestros criterios de ingeniería están por escrito y se aplican en
todos los proyectos. Estos son los que más se notan desde fuera.
acuerdoplan + pruebasentrega
00
Lo que se decide, se escribe
Antes de tocar código, el trabajo acordado queda como plan en el repositorio. El estado vive en un solo sitio, y si el plan y lo hablado se contradicen te lo decimos en vez de resolverlo por nuestra cuenta.
01
Empezar por lo útil
Antes de ampliar alcance, preferimos conseguir una versión pequeña que ya demuestre valor. Lo que nadie pidió por escrito no se construye.
02
Toda regla de negocio lleva prueba
Y cada defecto corregido lleva la suya, escrita antes de la corrección. El porcentaje de cobertura no es la meta; una regla sin prueba sí es un defecto.
03
Cada dependencia se justifica
Antes de añadir una librería revisamos si ya lo hace el lenguaje, la plataforma o unas pocas líneas. Menos piezas de terceros es menos que actualizar dentro de tres años.
04
Los atajos se marcan, no se esconden
Cuando simplificamos a conciencia queda comentado en el código, con su límite y con lo que justificaría cambiarlo. Así se lee como decisión y no como descuido, y se puede encontrar después.
05
IA donde acelera, no donde estorba
Nos ayuda a explorar, implementar y verificar. No sustituye las decisiones técnicas, no aparece como línea aparte en el presupuesto, y la responsabilidad de lo entregado sigue siendo nuestra.
Las reglas que seguimos cuando construimos algo tuyo. No es material de
venta: está aquí para que puedas leerlo antes de contratarnos y para que
puedas señalarlo si algún día no lo cumplimos.
✦Estándares de entrega
El piso de seguridad e ingeniería que cumple todo lo que entregamos.
✦Sistemas heredados
El procedimiento para cambiar código sin pruebas y sin documentación, y lo que cuesta hacerlo bien.
✦Metodologías
Cómo se entrega el trabajo: cadencia, despliegue y las ceremonias que no usamos.
piso de entrega
Lo que cumple todo lo que entregamos.
No es un certificado ni un programa de cumplimiento: es el mínimo
que superan todos nuestros proyectos antes de entregarse. Está
escrito para que puedas exigírnoslo.
estándares de entrega
Seguridad
✦Todo lo que entra se valida en el servidor
Con lista de permitidos: tipo, longitud, rango y formato. Lo que valida el navegador es comodidad para el usuario, no un control.
✦Cada petición se autoriza contra el registro, no solo contra el rol
Tener permiso de hacer algo no es tenerlo sobre ese dato en concreto. Comprobar el rol y olvidar el registro está detrás de la mayoría de las fugas.
✦Las contraseñas se guardan con Argon2id, scrypt o bcrypt
Nunca con un hash de propósito general, nunca cifradas, nunca en forma reversible.
✦Ningún secreto vive en el repositorio, en los registros ni en el navegador
Vienen del entorno o de un gestor de secretos. Si falta uno, la aplicación no arranca en vez de arrancar a medias.
✦Los datos personales se identifican, se minimizan y no se registran en crudo
Queda escrito qué campos son, dónde viven, cuánto se guardan y cómo se borran. Lo que no se guarda no se puede filtrar.
✦Las dependencias se fijan y se escanean
Una vulnerabilidad crítica con parche disponible se corrige antes de entregar. «Viene de otra librería» no es una razón para dejarla.
✦Los controles fallan cerrados
Si el sistema no puede decidir si tienes permiso, la respuesta es no. Un error que concede acceso es un agujero.
estándares de entrega
Ingeniería y pruebas
✦Fallar rápido dentro, vigilar en los bordes
La validación va donde el dato cruza la frontera. Dentro, el código confía en sus entradas en lugar de llenarse de comprobaciones que esconden el error real.
✦Las pruebas no tocan la red ni el reloj
El tiempo se inyecta y lo que sale del proceso se sustituye. Una prueba que depende de la hora falla sola cualquier martes.
✦Un commit, un cambio, con la build en verde
Sin estados intermedios rotos, y sin limpieza mezclada con comportamiento en el mismo cambio.
estándares de entrega
Las dos advertencias honestas
✦Lo que no se pueda cumplir, se dice
Cuando algo de esta lista no aplica o no se sostiene en tu caso, queda registrado y te lo decimos. No se salta en silencio.
✦Datos regulados necesitan más que esto
Expedientes clínicos, medios de pago o cualquier régimen de cumplimiento piden trabajo adicional. Se planea y se cotiza aparte, no se da por incluido.
código sin mapa
Cambiar algo sin romperlo.
Un sistema que lleva años funcionando, sin pruebas y sin documentación,
no se toca a ojo. Este es el procedimiento que seguimos, y explica por qué
el primer paso nunca es cambiar el código.
sistemas heredados
La pregunta que decide
✦La pregunta no es si el sistema es viejo
Es si lo que hay que tocar está cubierto por una prueba que fallaría si lo rompo. Un sistema de quince años tiene partes bien cubiertas, y uno de seis meses tiene rincones que nadie mira.
✦Cuando no se puede saber, se trata como si no tuviera pruebas
Asegurar comportamiento que ya estaba cubierto cuesta un rato. Cambiarlo sin asegurarlo es como se rompe un sistema de años por un sitio que nadie relaciona con el cambio.
sistemas heredados
El procedimiento
01
Primero, qué hace hoy
Antes de cambiar nada dejamos por escrito el comportamiento actual y cómo lo sabemos: leyendo el código, ejecutándolo, y revisando el historial, que a veces explica por qué está hecho así. Si no se puede decir qué hace, no seguimos adelante: te lo reportamos.
02
Pruebas que fijan la realidad, no el ideal
Registran lo que el código hace, no lo que debería hacer. Se escriben afirmando lo esperado y, cuando fallan, se corrige la expectativa y no el código. Quedan marcadas como lo que son, para que nadie las confunda después con una especificación.
03
Lo que parece un error se fija tal cual y se reporta
Si un cálculo redondea distinto al resto del sistema, lo dejamos como está y te lo decimos. Lleva años en producción y algo puede depender de ello. Corregirlo es una decisión tuya y aparte, no un efecto secundario de nuestro cambio.
04
Añadir al lado antes que editar dentro
El comportamiento nuevo se escribe aparte y con pruebas completas, y el código viejo solo lo llama. Así lo que no tiene pruebas se queda sin tocar y lo nuevo nace cubierto, que es la dirección en la que un sistema así necesita moverse.
05
Nunca el código y sus pruebas en el mismo paso
Primero se asegura el comportamiento, después se cambia. Si las dos cosas se mueven a la vez, nada te dice cuál rompió qué, y la seguridad que las pruebas debían darte nunca llegó a existir.
06
Se ordena lo que se tocó, no todo lo demás
Solo el código que el propio cambio obligó a entender. Un sistema de quince años no se arregla en un cambio, e intentarlo produce algo que ya nadie puede revisar.
sistemas heredados
Lo que esto cuesta
✦Asegurar el comportamiento va en línea aparte
No queda escondido dentro del precio del cambio. Es trabajo real, lo ves separado, y sabes por qué está ahí.
✦Un cambio de un día, en código sin pruebas, suele ser dos
Te lo decimos al estimar, no cuando ya vamos tarde. Lo que no tiene pruebas se estima con confianza baja y así queda dicho desde el principio.
cómo se entrega
Ves algo funcionando desde la primera semana.
No vendemos un método con nombre propio. Estas son las prácticas que
usamos y por qué cada una existe: todas están para reducir un riesgo
concreto tuyo, y las que no reducen ninguno no se usan.
metodologías
Cadencia
✦Cada semana ves lo construido, no un informe de avance
Software corriendo, sobre el que puedes hacer clic. Es la única forma de que corregir el rumbo cueste una semana en vez de un proyecto.
✦Lo que más dudas genera se construye primero
El alcance se ordena por riesgo, no por comodidad. Lo incierto se resuelve mientras todavía queda presupuesto para cambiar de opinión.
✦Un cambio de alcance se cotiza, no se absorbe en silencio
Te decimos qué cuesta y qué desplaza antes de tocarlo. Un «sí» que se paga con la fecha de entrega no es un sí.
metodologías
Entrega continua
✦Cada cambio pasa por la misma tubería
Pruebas, revisión y despliegue automáticos. Nada llega a producción por un camino que no esté escrito, incluido lo urgente.
✦Desplegar es aburrido a propósito
Si soltar una versión da miedo, se suelta poco, y cada versión acumula más riesgo del que nadie puede revisar. Un despliegue debe ser un botón.
✦Volver atrás es parte del plan, no una emergencia
Toda entrega sabe cómo deshacerse. La pregunta no es si algo va a salir mal alguna vez, sino cuánto va a durar cuando pase.
metodologías
Lo que no hacemos
✦No vendemos ceremonias
Ninguna reunión existe porque venga en el manual de alguien. Si una práctica no reduce un riesgo de tu proyecto, no se hace y no se te cobra.
✦Un encargo de una semana no lleva todo esto
La maquinaria se dimensiona al trabajo. Montar entrega continua para un cambio de dos días es cobrarte la instalación en vez del resultado.
archivo
decisiones
Las decisiones que costó pensar quedan escritas. Estas son de este mismo sitio, con lo que salió mal incluido.
Buena parte de estos diecisiete años es trabajo para empleadores que no
se puede publicar. Aquí está lo que sí: proyectos propios, y decisiones
técnicas que puedes leer enteras.
Casi todas las apps de finanzas personales piden registro, correo y suben
tus movimientos a un servidor. Auspex no.
INTERFACE / 03
Auspex en uso
captura 01 / 03
Panel generalLiquidez, flujo, gasto y alertas del periodo.abrir original ↗
01
El problema
Ordenar tus finanzas no debería costar entregar el detalle de tu vida: dónde compras, cuánto ganas, a quién le debes.
02
Qué construimos
Cuentas, transacciones, presupuestos, metas y deudas, con reportes y un módulo de asesoría. Sin registro, sin correo y sin nube: corre en tu equipo.
03
La decisión que más cambió el diseño
Una base de datos por espacio de trabajo, más una del sistema. Cada espacio es un archivo: copiarlo es respaldarlo, borrarlo es borrarlo. No hay que pedir una exportación porque el archivo ya es tuyo.
04
Dónde está hoy
En uso diario propio. Se publicará gratuita y completa; los extras, como los temas, serán un pago único, nunca una suscripción.
❖ASP.NET Core · Dapper · SQLite · Vue 3 · TypeScript
Un solo puerto: el front compilado lo sirve el propio backend.
stack
❖Terminal retro
Con aire de las computadoras de nave de la ciencia ficción de los setenta.
interfaz
seshat
caso 02 · archivo abierto
Un punto de venta que cabe en un archivo.
Para un negocio que vende tres cosas a la vez: artículos de mostrador,
trabajos personalizados y trámites. Casi ningún punto de venta asume esa mezcla.
01
El problema
Un punto de venta normal supone que vendes cosas de estante. Este negocio vende además tazas y playeras personalizadas, que se encargan un día y se entregan otro, y servicios como la impresión de documentos oficiales. Tres flujos distintos en el mismo mostrador.
02
Qué construimos
Catálogo de productos, servicios e insumos; pedidos personalizados con su ciclo de vida; venta con impresión de ticket; inventario con aviso de stock bajo; gastos y reportes. En español, y pensado para que lo use el dueño, que además es quien cobra.
03
La decisión que más cambió el diseño
Un solo ejecutable. Sin instalador, sin base de datos que administrar y sin necesidad de tener nada más instalado: se copia el archivo, doble clic, y se abre en el navegador. Los datos se quedan en la máquina del negocio, así que no hay mensualidad ni dependencia de internet.
04
Dónde está hoy
En fase final, antes de entrar a operar en el negocio para el que se construyó.
❖ASP.NET Core · SQLite · Vue 3 · TypeScript
Compilado como un único ejecutable de Windows, sin runtime que instalar.
stack
❖Sin correo y sin nube
La contraseña se recupera con un código que se muestra una sola vez, para anotarlo en papel.
acceso
quién
registro del operador
OmniPug, por Víctor González.
OmniPug es la marca; detrás hay un equipo con diferentes especialidades.
00
17 años
experiencia
Backend, aplicaciones web y aplicaciones de escritorio.
01
Financiero, salud, servicios y responsabilidad social
sectores
Dominios con reglas estrictas, datos sensibles y poco margen de error.
Proyectos acotados y asesorías, no plazas de jornada completa.
✦Zona Metropolitana de Guadalajara
remoto, con opción de vernos en persona
dónde
cómo empezamos
antes de comprometer nada
Dos formas de trabajar juntos.
Trabajamos por proyecto, no por plaza. Sabrás el alcance, el plazo y
el precio por escrito antes de decidir.
00
Asesoría
Una o varias sesiones para decidir algo concreto: qué construir, con qué stack, o por qué el sistema actual duele. Terminas con una recomendación, no con una venta.
01
Proyecto cerrado
Alcance y entrega definidos de antemano. De una semana a tres meses. Sirve igual para construir algo nuevo que para arreglar o ampliar algo que ya funciona. Si el alcance cambia, se renegocia antes de tocar el código.
FLOW/00
Así avanza un proyecto
00
Nos escribes
Un correo con el problema basta. Si no somos el proveedor indicado, te lo decimos en la primera respuesta y te ahorramos la reunión.
01
Media hora para entender el contexto
Llamada o café. Salimos de ahí sabiendo qué se necesita, para cuándo, y qué hay construido.
02
Propuesta por escrito
Alcance, entregables, plazo y precio en un documento que puedes leer entero. El precio sale de partir el trabajo en módulos y estimar cada uno, no de un número al tanteo. Sin cifras que cambian al firmar.
03
Entregas que puedes probar
Trabajamos en incrementos revisables. No desaparecemos un mes para volver con un archivo comprimido.
✦Precio cerrado
si el trabajo lleva más de lo estimado, lo absorbemos nosotros; si cambia el alcance, se cotiza aparte antes de hacerlo
✦Pagos por hitos
en proyectos de varias semanas, contra funcionalidad que puedes probar; no contra fechas del calendario
✦Garantía después de la entrega
corregimos lo que no se comporte según lo acordado; las funciones nuevas se cotizan aparte, y la propuesta dice cuánto dura
Cinta perforada del archivo. Cada fila es una cifra: suma las columnas marcadas.
● perforado, cuenta · ○ liso, no cuenta
cerradura
refugio
Lo que hay dentro
Un ordenador que ya no arranca, una guitarra sin encordar y una pila de discos. La bóveda no guarda oro: guarda las cosas que explican por qué alguien acaba dedicándose a esto.
Si has llegado hasta aquí leyendo cinta perforada, probablemente nos vamos a entender bien.