Desarrollo a medida
Hay problemas que no encajan en un sitio web. Cuando el trabajo es una herramienta, una app, una integración o un proceso que ya no debería hacerse a mano, construimos eso en su lugar.
Pequeños, sénior y honestos con el alcance. Si un producto ya existente resuelve tu problema, te lo diremos en lugar de cobrarte por reconstruirlo.
Registro
El tipo de trabajo que aceptamos
Una forma útil de describir el software a medida es por el problema que elimina. Estos son los patrones que más se repiten, y lo que solemos terminar construyendo.
| El problema | Qué construimos |
|---|---|
| La misma tarea manual, todos los días, hecha por alguien demasiado sénior para eso | Una herramienta interna con los pasos codificados una sola vez: un formulario, una cola, un rastro de auditoría claro y permisos que reflejan cómo trabaja realmente el equipo. |
| Dos sistemas que no se comunican entre sí | Una integración que gestiona el mapeo entre ambos, reintenta con seguridad cuando uno de los lados falla, y avisa cuando algo necesita intervención humana. |
| El negocio funcionando sobre una hoja de cálculo que nadie se atreve a tocar | Una pequeña aplicación web con un modelo de datos real detrás, para que dos personas puedan trabajar a la vez y las cifras del trimestre pasado no se sobrescriban por accidente. |
| Un informe que alguien arma a mano cada semana | Una tarea programada que reúne los datos, los verifica y entrega el informe a quienes lo necesitan, con un registro de cada ejecución. |
| Trabajo que ocurre lejos de un escritorio: en un teléfono, en una furgoneta, en el piso de una tienda | Una aplicación móvil sobre los mismos cimientos que el resto del sistema, que comparte su modelo de datos, su estándar de revisión y sus verificaciones automatizadas, para que el teléfono y el escritorio nunca discrepen sobre los hechos. |
| Un flujo de cliente añadido a un sitio de marketing hasta que dejó de funcionar | Una aplicación propiamente dicha en su propia dirección, que comparte el sistema de diseño del sitio para que siga sintiéndose como una sola empresa. |
| Algo que nadie puede cotizar porque nadie lo ha definido | Una breve etapa de descubrimiento: la versión mínima funcional definida por escrito, con las partes que no construiríamos señaladas con la misma claridad. |
Criterio
Cómo decidimos qué construir
- Primero, lo mínimo que funcione. Una herramienta acotada en producción enseña más en dos semanas que una especificación completa en un trimestre, y puede ampliarse una vez que sabes qué partes importan.
- Tecnología aburrida, a propósito. Elegimos la opción probada por encima de la interesante. El software a medida se juzga el día en que alguien tiene que modificarlo, no el día en que se lanza.
- El modelo de datos se define bien desde el principio. Rediseñar interfaces es barato y reestructurar datos es caro, así que la forma de los datos se define antes que las pantallas.
- Comprar antes que construir. Si un producto con licencia cubre tu caso, la recomendación honesta es usarlo. Preferimos construir la pequeña pieza que lo conecta antes que cobrarte por reinventarlo.
- Diseñado para el segundo desarrollador. Código legible, configuración documentada, pruebas que explican la intención. La medida del trabajo es si otra persona puede modificarlo con seguridad.
Stack
La tecnología que realmente usamos
Nombrarla es parte de ser honestos sobre el alcance. Alguien técnico debería poder saber en una pantalla si somos el estudio adecuado, y alguien no técnico debería poder pasarle esta sección a su propio desarrollador y obtener una respuesta clara.
TypeScript, de principio a fin
Astro, HTML y CSS puros, React donde una aplicación lo necesita, además de apps móviles
Node y Cloudflare Workers
Bases de datos compatibles con Postgres, migraciones SQL versionadas
Cloudflare Pages, Workers, almacenamiento de objetos, tareas programadas
Playwright, Vitest, tipado estático, auditorías de accesibilidad automatizadas
- Un solo lenguaje en todo el sistema. TypeScript para la interfaz, la API, las tareas programadas y las pruebas, con los tipos verificados en cada cambio. Un solo lenguaje significa una sola cadena de herramientas y un solo estándar de revisión, y ninguna capa de traducción entre el navegador y el servicio que hay detrás.
- Renderizado elegido según el trabajo. El contenido se compila a HTML estático. Una interfaz que de verdad necesita estado en el cliente recibe un framework de componentes, limitado a la parte de la pantalla que lo necesita, en lugar de un framework envolviendo contenido que nunca cambia.
- Apps móviles, con la misma disciplina. Cuando el trabajo pertenece a la mano de alguien y no a una pestaña del navegador, construimos la app con el mismo estándar que todo lo demás: la misma cadena de herramientas basada en TypeScript, el mismo estándar de revisión, las mismas verificaciones automatizadas y el mismo modelo de datos que el servicio detrás de ella, en vez de una segunda versión de la verdad. Qué stack debe usar una app en particular es una decisión que tomamos contigo mientras se redacta el alcance, no una preferencia de la casa aplicada a todos los proyectos.
- Una base de datos relacional, no una sopa de documentos. Una base de datos compatible con Postgres con una capa de consultas tipada, y cambios de esquema que se revisan, se aplican en orden y son reversibles. Nadie edita un esquema de producción a mano.
- Sin servidor por defecto, porque no hay ningún servidor que olvidar. El código corre en la plataforma de borde de Cloudflare, con almacenamiento de objetos para archivos y workers programados para todo lo que tenga que ocurrir en un horario. Ninguna máquina tuya que parchear a medianoche y ninguna capacidad que adivinar.
- Integraciones sobre interfaces documentadas. Otros sistemas se alcanzan a través de sus API y webhooks, con reintentos, idempotencia y un registro de cada llamada. Cuando un proveedor no ofrece API, una carga de archivo o de datos programada es el respaldo deliberado, nunca hacer scraping de una pantalla que se romperá el próximo trimestre.
- Entornos y secretos como configuración, nunca como tradición oral. La infraestructura se declara en el repositorio, las credenciales viven en un almacén de secretos y llegan al servicio en ejecución como variables de entorno, y una máquina nueva tiene el proyecto funcionando esa misma tarde.
- Tu propio stack, cuando ya tienes uno. Si tu equipo mantiene algo razonable, lo correcto suele ser trabajar dentro de él en lugar de introducir una segunda forma de hacer todo. Y si lo que tienes es de verdad el problema, también te lo diremos.
Estándares
El mismo piso de ingeniería que los sitios web
El piso no cambia entre las dos líneas de servicio, porque una herramienta interna la usa durante años gente que no puede elegir otra. Código estándar en un repositorio con su historial completo, verificaciones automatizadas que detienen un despliegue en rojo, publicaciones de un solo comando que se revierten en un paso, interfaces accesibles (el equipo merece el mismo estándar que los clientes), secretos fuera del código, y ninguna plataforma propietaria debajo de nada de esto. Está detallado en sitios web corporativos en lugar de repetirlo aquí.
Dos cosas pesan más en el software que en un sitio web, y merece la pena nombrarlas por separado.
Los datos sobreviven al código
Las interfaces se reemplazan; los registros permanecen. Por eso los cambios de esquema son migraciones en el repositorio, aplicadas en orden y reversibles, las copias de seguridad son responsabilidad de la plataforma y no de un script que alguien escribió una vez, y tus datos pueden exportarse en un formato que puedas cargar en cualquier otro sitio.
Un sistema en marcha tiene que ser observable
Todo lo que ocurre sin que nadie lo vigile deja un registro: qué se ejecutó, cuándo, qué tocó y en qué falló. Una tarea programada que deja de funcionar en silencio nos avisa a nosotros, en lugar de que la descubra un mes después quien se preguntaba dónde quedó su informe.
Alcance
Dónde nos detenemos
Ser claros sobre los límites es parte de ser confiables. Somos un equipo pequeño y sénior, así que aceptamos el trabajo que podemos hacer bien y decimos que no al que no podemos.
No revendemos plataformas con licencia, no asignamos personal a un proyecto que no estamos construyendo, y no daremos una cifra para un problema que no se ha definido. Cuando una parte del trabajo le corresponde a un especialista, te lo diremos con claridad en lugar de que lo descubras a tu costa.
Los límites técnicos son igual de concretos:
- Usar un modelo sí, ciencia de datos no. Llamamos a un modelo alojado o a un servicio existente desde tu aplicación y construimos la interfaz y la mecánica alrededor. Entrenar modelos, el análisis estadístico y los pipelines de datos a escala de almacén no son lo nuestro.
- Plataformas gestionadas sí, tus propios servidores no. Desplegamos en plataformas gestionadas de borde y sin servidor. Si el trabajo tiene que correr en tu centro de datos, en máquinas que tú administras o en un sistema operativo que alguien tiene que mantener parcheado, somos el estudio equivocado y lo sabrás en la primera llamada.
- Los regímenes certificados necesitan un especialista a nuestro lado. Aplicamos ingeniería de seguridad real como cuestión de rutina, pero una auditoría formal contra un régimen determinado es una especialidad que no vendemos. Si tu proyecto necesita una, te lo decimos antes de que firmes nada, no después.
- Firmware, y reventa. El firmware embebido no es nuestra disciplina, y tampoco lo es nada cuyo valor sería una licencia que revendimos en vez de trabajo que hicimos.
Funcionamiento
Quién lo mantiene funcionando después
El software a medida no está terminado cuando se lanza. Se usa, y luego hay que cambiarlo. Quién lo mantiene en marcha y quién lo cambia debe formar parte del alcance desde el principio, no de un correo incómodo seis meses después.
Lo alojamos y lo mantenemos en marcha
Ese es el acuerdo por defecto: alojamos y operamos el sistema por una cuota mensual, y los cambios después del lanzamiento siguen el mismo ciclo que la construcción, es decir, una rama, una vista previa, todo el conjunto de verificaciones y un despliegue que se revierte en un paso. Las mismas personas que lo escribieron son las que lo vigilan en producción, lo que suele marcar la diferencia entre una corrección tranquila y un hilo largo sobre de quién es el problema.
Ser un equipo pequeño y sénior tiene un costo y preferimos decirlo con claridad: no operamos una guardia de disponibilidad de 24 horas ni vendemos un tiempo de respuesta garantizado en minutos. Si lo que estás construyendo de verdad lo necesita, dínoslo pronto y te diremos con honestidad si podemos cumplirlo.
O tu propia gente se hace cargo
Cuando tu contrato lo incluye, el software puede pasar a tu propio hospedaje y a tus propios desarrolladores: código estándar, las pruebas, la configuración documentada y un despliegue de un solo comando. Para eso sirve, precisamente, diseñar para el segundo desarrollador. Es una opción que dejamos por escrito cuando la quieres, no el acuerdo por defecto.
La plataforma también ayuda aquí. Un sitio estático y un servicio sin servidor no tienen ningún servidor que parchear ni sistema operativo que mantener al día, así que lo que queda son actualizaciones de dependencias y de plataforma: un cambio programado y revisable, no una emergencia.
No necesitas una especificación para empezar. Escríbenos por el formulario de contacto o a [email protected] y cuéntanos el trabajo en lenguaje sencillo.