--- title: "Caricalia · contenido completo" description: "Estudio de diseño e ingeniería de software en Barcelona. Trabajamos sobre sistemas que ya están en producción y de los que depende un negocio." canonical: https://caricalia.com/llms-full.txt last-updated: 2026-09-08 --- > Estudio de diseño e ingeniería de software en Barcelona. Trabajamos sobre sistemas que ya están en producción y de los que depende un negocio. - Qué hacemos: Diseño e ingeniería de producto sobre software en producción - Dónde: Barcelona, ES - Contacto: hola@caricalia.com - Índice corto: https://caricalia.com/llms.txt --- # Diseño e ingeniería para el software del que depende tu negocio. Las mismas personas diseñan y construyen. Trabajamos sobre sistemas en uso, donde cada cambio cuesta más que el anterior. ## Por qué nosotros y no otro. - **Diseña y construye el mismo equipo que responde.** El equipo que dibuja las pantallas es el que escribe el código y el que responde del proyecto de principio a fin. - **Operamos un producto propio.** BeeL, nuestra plataforma de facturación, está en producción bajo Verifactu. Antes, el equipo escribió código de pagos en Banco Santander y PagoNxt. - **Precio y fecha por escrito, y el diseño va dentro.** Cada fase se cierra antes de empezar. Si una condición de entrega falla, el último hito no se factura. Hemos escrito código en producción para: BeeL., Zernio, Banco Santander, PagoNxt, Inditex. ## Cuándo tiene sentido que hablemos. Casi siempre es una de estas cinco. - La web está cuidada, y la aplicación, los correos y las facturas no parecen de la misma empresa. - Cada pantalla nueva de tu aplicación sale distinta de la anterior. - Todo depende de una persona, o de un proveedor al que no puedes sustituir sin parar. - Un cliente grande, un inversor o una auditoría va a mirar por dentro y **no hay nada preparado**. - Quien lo escribió ya no está y nadie se atreve a tocarlo. El diagnóstico empieza por ahí: sentarse con quien usa el sistema y leer el código. ## Qué se puede encargar. Tres tipos de proyecto y una forma de empezar. - **Diagnóstico** (3 semanas · 2.900 € + IVA) Leemos tu código y hablamos con quien usa el sistema. Te entregamos qué falla, qué cuesta arreglarlo y en qué orden. — https://caricalia.com/diagnostico - **Software a medida** (12 a 16 semanas) Construimos o cambiamos la parte de tu sistema que se ha quedado corta: una herramienta interna, un módulo del ERP, la conexión entre dos programas. — https://caricalia.com/software-a-medida - **Marca y producto** (8 a 12 semanas) La identidad de tu producto aplicada a la web, la aplicación, los correos y los documentos. Diseñada y construida. — https://caricalia.com/marca-y-producto Un proyecto después se cierra por fases, con el precio de cada fase por escrito antes de empezar. Se paga por hitos; el primero, al empezar el diagnóstico. ## BeeL., producto propio, en producción. Plataforma de facturación. La construimos nosotros y la mantenemos para las empresas que facturan con ella. La parte de la que todo el mundo habla es Verifactu, y es una de las once cosas que hay que hacer bien para emitir una factura en España. Las otras diez son las que dan trabajo. Una numeración no puede saltarse un número ni cuando hay muchas facturas emitiéndose a la vez. 11 cosas que hay que hacer bien para emitir una factura en España. Las once están en BeeL. - Emisión - Numeración sin huecos - Series bloqueadas tras la primera emisión - PDF con validez legal - Envío y entrega - Rectificativas proporcionales - Facturas recurrentes - Multi-NIF - Clientes sin NIF - Registro en la AEAT - Verifactu ## Zernio: el último paso se hacía a mano. Ahora no. Zernio es una plataforma desde la que las marcas programan lo que publican en redes. Sus clientes ya automatizaban casi todo con flujos de n8n, y el último paso, publicar, seguía haciéndose a mano. Construimos el nodo de n8n de Zernio: el paso que falta para que una publicación se programe desde el propio flujo, con las credenciales del cliente, sin abrir otra herramienta. Está en el catálogo público de n8n y el código es abierto. - **Qué hicimos:** El nodo de n8n de Zernio, publicado en el catálogo - **Estado:** Publicada y en uso - **Qué cambia:** El cliente ya no sale de su herramienta para publicar > Desde el primer momento fue muy fácil la comunicación, y durante el proyecto muy amena y muy rápida. Esperamos seguir trabajando con el equipo de Caricalia. > > — Miki, fundador de Zernio ## Condiciones de entrega. Van en el contrato. Si alguna falla, el último hito no se factura. - **El código es tuyo desde el primer hito.** Repositorio, infraestructura y claves a tu nombre desde el principio, no al entregar. - **Cada fase tiene su precio antes de empezar.** Lo que cuesta cada fase se sabe antes de arrancarla, por escrito. Puedes parar al final de cualquiera con el sistema entero. - **Lo que mueve dinero se comprueba solo.** Las reglas que mueven dinero se ejecutan en cada cambio y se leen sin ser programador. En la demo de entrega eliges una y se comprueba. - **Antes de cerrar, alguien de fuera hace un cambio.** Con el repositorio y nada más, una persona que no ha visto el proyecto hace un cambio real que eliges tú. Si no puede, falta documentación, y se escribe antes del último hito. - **Las pantallas se entregan construidas.** En el mismo repositorio que el resto, no como archivo de diseño. Lo que apruebas en la maqueta es lo que se despliega. ## Empieza por el diagnóstico. Escribes, te contestamos con tres preguntas, y si encaja, veinte minutos y el diagnóstico. Se paga por hitos; el primero, al empezar el diagnóstico. Un proyecto después se cierra por fases, con el precio de cada fase por escrito antes de empezar. Después, si quieres, evolución mensual con el mismo equipo que lo construyó. Escribe a hola@caricalia.com o pide un diagnóstico en https://caricalia.com/diagnostico. --- # Qué se puede encargar. Tres tipos de proyecto y una forma de empezar. Todos son sobre software que ya tiene gente dentro usándolo. ## Los encargos - **Diagnóstico: por aquí se empieza** (3 semanas) Tres semanas. Leemos tu código, hablamos con quien usa el sistema y te damos un informe con qué falla, qué cuesta arreglarlo y en qué orden. Cuesta 2.900 € + IVA. Un proyecto después se cierra por fases, con el precio de cada fase por escrito antes de empezar. — https://caricalia.com/diagnostico - **Software a medida** (12 a 16 semanas) Construimos o cambiamos la parte de tu sistema que se ha quedado corta: una herramienta interna, un módulo del ERP, la conexión entre dos programas. — https://caricalia.com/software-a-medida - **Marca y producto** (8 a 12 semanas) La identidad de tu producto aplicada a la web, la aplicación, los correos y los documentos. Diseñada y construida. — https://caricalia.com/marca-y-producto - **De prototipo a producción** (12 a 16 semanas) Tienes algo hecho con IA o con no-code y ya lo usan clientes. Lo revisamos y lo convertimos en un sistema que aguanta, sin empezar de cero. — https://caricalia.com/de-prototipo-a-produccion ## Las otras opciones, comparadas Si no nos contratas, harás una de estas cuatro cosas. Dos de ellas a veces son la opción correcta, y el diagnóstico lo dice. - **Que lo haga tu equipo** A veces es lo correcto, y el diagnóstico lo dice. Lo habitual es que tu equipo aprenda en producción lo que nosotros ya hemos roto antes, y mientras tanto no está en lo que diferencia a tu empresa. - **Contratar a dos seniors** Cuatro a seis meses de búsqueda y un coste fijo que sigue cuando el proyecto acaba. Con nosotros el proyecto tiene fecha y precio cerrados, y el diseño va dentro. - **Una consultora grande** Te vende un socio y te manda un equipo que no conoces. Aquí diseña y construye el mismo equipo que responde del proyecto. - **No hacer nada este año** A veces es la respuesta buena. El diagnóstico existe para ponerle número: si sale pequeño, te decimos que no lo hagas. ## Antes de escribirnos **¿Cuánto cuesta?** El diagnóstico cuesta 2.900 € + IVA y dura tres semanas. Un proyecto después se cierra por fases, con el precio de cada fase por escrito antes de empezar. No trabajamos por horas ni ponemos gente dentro de tu equipo. **¿Cuánto dura?** Un proyecto de software a medida o de prototipo a producción, de doce a dieciséis semanas. Uno de marca y producto, de ocho a doce. El diagnóstico va antes y son tres semanas. **¿Y si mi equipo quiere hacerlo?** A veces es lo correcto, y el diagnóstico lo dice. Lo habitual es que tu equipo aprenda en producción lo que nosotros ya hemos roto antes, y que mientras tanto no esté en lo que diferencia a tu empresa. El informe sirve igual si al final lo hacéis dentro. **¿Trabajáis sobre código que ha escrito otro?** Es lo que hacemos casi siempre. Da igual quién lo escribiera: un proveedor que ya no está, tu equipo o un asistente de IA. Lo que hace falta es acceso al código y a alguien que use el sistema todos los días. **¿Qué pasa cuando escribo?** Te contestamos en un día laborable con tres preguntas sobre lo que tienes en marcha. Si encaja, hablamos veinte minutos por videollamada, que no se cobra. Después, si sigue teniendo sentido, el diagnóstico. ## Lo que no hacemos - **No hacemos** marca corporativa para empresas sin producto digital, ni logos sueltos, ni tiendas online sobre plantilla. - **No trabajamos** por horas ni ponemos gente dentro de tu equipo. - **No cogemos** proyectos que empiezan de cero sin usuarios: esa primera versión conviene montarla rápida y barata con otra herramienta. - **No entregamos** prototipos generados como si fueran producto. --- # Software a medida para lo que ya funciona. Trabajamos sobre sistemas que ya tienen clientes dentro, donde cada cambio cuesta más que el anterior. A medida casi nunca quiere decir empezar de cero. Lo normal es que haya un sistema en marcha con una parte que se ha vuelto cara de tocar, y lo que se paga es saber qué se puede tocar sin romper lo que ya cobra. ## Cuándo no tiene sentido Si lo que necesitas lo hace un producto estándar, cómpralo. Si nos preguntas, te diremos cuál, y esa respuesta no se factura. Un software a medida se justifica cuando lo que haces no lo hace nadie igual, o cuando la parte por la que pasa tu dinero no se parece a la de nadie. Fuera de esos dos casos, construir algo que ya existe se paga al hacerlo y cada año que hay que mantenerlo. ## Herramientas internas y paneles Las aplicaciones a medida que más veces tenemos delante no las ve ningún cliente: son las que usa el equipo para operar. - **Qué preguntamos primero** Qué decisión toma quien mira el panel cada mañana. Si no hay decisión, no hace falta un panel. - **Por dónde empezamos** Miramos trabajar a quien la usa, en su puesto y con sus datos. - **Qué sigue decidiendo una persona** Todo lo que aprueba dinero. [Qué es un dashboard, y cuándo sobra](https://caricalia.com/glosario/dashboard) ## ERP y CRM a medida: cuándo sí Lo normal es quedarse con el producto estándar y construir a medida el trozo que no cabe, conectado a él. Casi siempre ese trozo es la parte por la que pasa el dinero. - **Cuándo se defiende uno a medida** Cuando la forma en que cobras, produces o entregas es lo que te diferencia. - **El caso intermedio** La facturación o la conciliación construidas aparte y conectadas al estándar. - **Cómo se decide** Leyendo el código y hablando con quien lo usa, en la primera semana del diagnóstico. [Qué es un ERP y cuándo el estándar sobra](https://caricalia.com/glosario/erp) ## Integraciones entre sistemas que no se conocen Integrar dos sistemas es decidir qué pasa cuando uno de los dos no contesta. - **Qué se acuerda antes** Qué campos viajan, qué sistema manda sobre cada uno y qué ve el usuario mientras el otro lado está caído. - **Qué se rompe siempre** Reintentos que duplican un pedido, fechas en otra zona horaria y credenciales que caducan sin avisar. - **Cuando pasa dinero** Una operación que falla a medias se deshace entera o se completa entera, y se provoca el fallo delante de ti en la demo del hito. [El caso de Zernio: la integración vive en el flujo del cliente](https://caricalia.com/casos/zernio) ## Qué lo demuestra - **Operamos software propio por el que pasa dinero y que registra en la AEAT.** BeeL, nuestra plataforma de facturación, está en producción y la mantenemos nosotros. (Ver el caso de BeeL: https://caricalia.com/casos/beel) - **Lo que entregamos fuera se puede instalar sin pedirnos permiso.** La integración que construimos para Zernio está publicada en un catálogo público y en uso por sus clientes. (Ver el caso de Zernio: https://caricalia.com/casos/zernio) - **Quien lo hace ha escrito código de pagos en producción.** Antes de Caricalia, el equipo escribió código de pagos en Banco Santander y en PagoNxt. Con nombre y con la trayectoria completa, en la página del equipo. (Quién lo hace: https://caricalia.com/equipo) ## Qué incluye un proyecto - Una maqueta que se puede tocar antes de escribir código, probada con quien la va a usar. - Las decisiones de datos escritas antes de construir: qué sistema manda sobre cada dato y qué pasa cuando uno no contesta. - Formación con la gente que lo va a usar y con quien lo va a mantener. [Las condiciones de entrega van en el contrato](https://caricalia.com/terminos#entrega) ## Lo que no hacemos - **No hacemos** marca corporativa para empresas sin producto digital, ni logos sueltos, ni tiendas online sobre plantilla. - **No trabajamos** por horas ni ponemos gente dentro de tu equipo. - **No cogemos** proyectos que empiezan de cero sin usuarios: esa primera versión conviene montarla rápida y barata con otra herramienta. - **No entregamos** prototipos generados como si fueran producto. ## Preguntas **¿Por qué no lo hace mi equipo?** A veces debe hacerlo, y el diagnóstico lo dice si es así. Lo que suele pasar es que aprende en producción lo que ya está resuelto, y mientras tanto no está en lo que diferencia a tu empresa. Un proyecto cerrado tiene fecha y precio; una contratación, no. **¿Trabajáis sobre código que no habéis escrito vosotros?** Casi siempre. Leerlo es la primera parte del encargo y la que decide el precio. **¿Sois una empresa de desarrollo de software o un estudio de diseño?** Las dos cosas: las mismas personas diseñan y construyen. Quiénes somos está en la página del equipo. ## Ver también - https://caricalia.com/casos/beel - https://caricalia.com/casos/zernio - https://caricalia.com/notas/cuanto-cuesta-desarrollar-una-aplicacion - https://caricalia.com/notas/integrar-dos-sistemas --- # Marca y producto. La identidad de tu producto, aplicada en todos los sitios donde tu cliente lo ve: la web, la aplicación, los correos, los documentos y lo que publicáis. Una marca no es un logo y una tipografía. Es que tu empresa se comunique igual en cada punto de contacto, para llegar a la misma gente con el mismo mensaje. Eso incluye la web, la aplicación, los correos, las facturas y las propuestas, y también lo que la empresa publica en LinkedIn. Si la web dice una cosa y el resto dice otra, la marca no está funcionando. El objetivo es que se reconozca y se recuerde. ## Para quién Empresas con un producto digital en uso: una aplicación, una plataforma o un servicio que ya tiene clientes. Suele hacer falta cuando la web, la aplicación, los correos y los documentos no parecen de la misma empresa; cuando hay marca pero solo llegó al logo; o cuando el producto ha crecido y cada pantalla nueva sale distinta de la anterior. Marca corporativa sin producto detrás y logos sueltos quedan fuera. ## La identidad Marca, color, tipografía y tono, decididos con el producto delante. - **Qué se decide** Cómo se llama el producto y cómo se escribe, qué colores usa y para qué, qué tipografía lleva en pantalla y en papel, y cómo habla: a un cliente en un correo, a un usuario en un error, a un inversor en una propuesta. Todo eso queda decidido y escrito, para que nadie tenga que volver a discutirlo. - **Con qué se decide** Con el producto delante. Cada decisión se prueba sobre una pantalla, una factura o un correo reales de tu sistema antes de fijarla. Una identidad que solo funciona en una presentación no sirve. - **Qué se entrega** Los archivos de la identidad, las reglas de uso y los ejemplos aplicados, en tu repositorio junto al código. Los puede usar tu equipo, tu agencia o quien venga después. ## La identidad en la aplicación Los componentes de la interfaz con esa identidad, en código. - **Qué se construye** Los elementos con los que se hace cualquier pantalla: botones, campos, tablas, avisos, estados vacíos y de error, y los documentos que genera el sistema. Con la identidad ya aplicada, para que nadie tenga que interpretarla cada vez. - **Dónde queda** En tu repositorio, como los componentes con los que el equipo construye. No es una guía aparte que hay que consultar: es lo que se usa. - **Qué cambia** La siguiente pantalla la puede hacer cualquiera del equipo y sale de la misma empresa que las anteriores. La marca deja de depender de que el diseñador esté delante. [Un sistema de diseño no es una biblioteca de componentes](https://caricalia.com/notas/design-system-no-es-una-libreria) ## La identidad en lo que se envía La web del producto, los correos, las facturas, las propuestas y lo que publicáis. - **La web del producto** La que lo explica y lo vende, con la misma identidad que la aplicación que hay detrás. Diseñada y construida por nosotros, sin plantillas. - **Correos y documentos** Las plantillas de los correos que envía el sistema y de los que envía el equipo, y los dos documentos que más lee un cliente: la factura y la propuesta. Es donde la marca suele romperse y donde más se nota. - **Lo que se publica** Plantillas para LinkedIn y para presentaciones, para que un post o una diapositiva se reconozcan como vuestros antes de leer el nombre. [BeeL: cómo está diseñada y construida](https://caricalia.com/casos/beel) ## El trabajo - **BeeL, en 2025 y hoy.** Antes, una lista de espera sobre una plantilla. Hoy, una identidad propia de la que salen la web, la aplicación y las facturas. La diseñó y la construyó el mismo equipo. (Ver el caso de BeeL: https://caricalia.com/casos/beel) - **Como también construimos, la marca llega a producción tal como se diseñó.** Los componentes y las plantillas van en el mismo repositorio que el resto del sistema, y las condiciones de entrega van en el contrato. (Leer la cláusula de entrega: https://caricalia.com/terminos#entrega) - **Quién lo hace.** El mismo equipo diseña la identidad y escribe el código que la aplica. Los perfiles están en la página del equipo. (Ver el equipo: https://caricalia.com/equipo) ## Qué incluye un proyecto - La identidad con sus archivos y sus reglas de uso. - Los componentes de la interfaz en tu repositorio. - La web del producto, desplegada. - Las plantillas de correo, factura, propuesta y LinkedIn. - Una maqueta probada con tu equipo antes de escribir código. [Las condiciones de entrega van en el contrato](https://caricalia.com/terminos#entrega) ## Lo que no hacemos - **No hacemos** marca corporativa para empresas sin producto digital, ni logos sueltos, ni tiendas online sobre plantilla. - **No trabajamos** por horas ni ponemos gente dentro de tu equipo. - **No cogemos** proyectos que empiezan de cero sin usuarios: esa primera versión conviene montarla rápida y barata con otra herramienta. - **No entregamos** prototipos generados como si fueran producto. ## Preguntas **¿Ya tenemos marca?** Se respeta y se aplica donde no llegó. **¿Hacéis la web corporativa?** La del producto. Sin producto detrás, no. **¿Hacéis solo el logo?** No. Sin sistema detrás, un logo es lo que ya tienes. ## Ver también - https://caricalia.com/casos/beel - https://caricalia.com/notas/design-system-no-es-una-libreria - https://caricalia.com/notas/clientes-que-se-caen-en-el-alta --- # Lo montaste rápido. Ahora tiene clientes. Leemos lo que has montado, te decimos qué aguanta y qué no, y lo llevamos a producción. Una herramienta de IA te da un prototipo en una tarde, y las usamos todos los días. Lo que no te da es alguien que responda cuando el sistema falla con clientes dentro. ## Cuándo no tiene sentido Si todavía no tienes clientes, sigue con el prototipo. Es barato, se cambia en una tarde y estás aprendiendo cosas que ningún diagnóstico te va a decir. Entramos cuando aguantarlo empieza a costar dinero: alguien dedica horas a arreglar a mano lo que el sistema debería hacer solo, o ya hay clientes que dependen de él. ## Lo que suele romperse primero Estas cinco se miran antes que nada. - **La autenticación** La sesión no caduca y cualquiera con el enlace ve el panel de otro. - **Los datos duplicados** El cliente pulsa dos veces y hay dos pedidos. Nadie decidió qué pasaba entonces. - **Los pagos** Cobran, pero no registran. Se descubre cuadrando el mes. - **El correo** Sale de una cuenta personal hasta que un proveedor lo marca como masivo, y los avisos caen en spam. - **Las claves** Escritas dentro del código. Cambiarlas rompe cosas porque nadie sabe dónde se usan. [Síntoma, causa y qué se hace con cada una](https://caricalia.com/notas/vibe-coding-primer-cliente) ## Qué hacemos con lo que ya existe Primero se lee entero: la aplicación, la base de datos, lo que se hace a mano cada semana y lo que ya se ha roto alguna vez. Después se decide qué va en cada una de estas tres listas. - **Se conserva** El modelo de datos si aguanta, las reglas que ya sabes que son correctas y las pantallas que tu gente usa sin preguntar. - **Se cambia** Lo que toca el dinero, lo que toca las cuentas de usuario y lo que hoy depende de que alguien se acuerde. - **Se deja escrito** Lo que queda fuera del alcance, con lo que costaría y qué pasa si no se hace. [Cuándo dejar el no-code, con los números delante](https://caricalia.com/notas/cuando-dejar-el-no-code) ## Qué lo demuestra - **Sabemos lo que es que un sistema nuestro falle con clientes dentro.** BeeL, nuestra plataforma de facturación, la operamos nosotros. Cuando algo falla, contestamos nosotros. (El caso de BeeL: https://caricalia.com/casos/beel) - **Hemos llevado a producción piezas que instala gente que no conocemos.** La integración de Zernio se instala desde un catálogo público. Quien la instala no puede preguntarnos nada, así que tenía que aguantar sola. (El caso de Zernio: https://caricalia.com/casos/zernio) - **Publicamos un servidor para que un agente de IA emita facturas en BeeL con las mismas reglas que la interfaz.** Está publicado y se puede leer qué valida antes de emitir. (El servidor MCP de BeeL: https://caricalia.com/casos/beel) ## Qué incluye un proyecto - La lectura de lo que ya tienes, con lo que se conserva y lo que se cambia, dicho por escrito antes de tocar nada. - Cuentas de usuario y permisos rehechos para el número de clientes que esperas tener, no para el que tienes hoy. - Claves fuera del código, correo saliendo de un dominio tuyo y una copia de seguridad que alguien ha restaurado al menos una vez. - Diseño de las pantallas que cambian, hecho por quien las construye. [Las condiciones de entrega van en el contrato](https://caricalia.com/terminos#entrega) ## Lo que no hacemos [A quién decimos que no](https://caricalia.com/servicios#no-hacemos) ## Preguntas **¿Usáis IA para escribir código?** Sí, todos los días, como herramienta. De lo que falle en producción respondemos nosotros. **¿Cuánto tarda llevarlo a producción?** Depende de lo que aguante y de lo que no, y eso se sabe leyéndolo: para eso está el diagnóstico. Lo normal después son las mismas doce a dieciséis semanas de cualquier proyecto, cerrado por fases con el precio de cada una por escrito antes de empezar. **¿Podéis trabajar sobre lo que ya he montado con una herramienta de IA o de no-code?** Sí, sea cual sea la herramienta. Lo que cambia entre una y otra es cuánto se puede conservar, y eso lo dice el informe, no una demo. ## Ver también - https://caricalia.com/casos/beel - https://caricalia.com/casos/zernio - https://caricalia.com/notas/cuando-dejar-el-no-code - https://caricalia.com/notas/vibe-coding-primer-cliente --- # Tres semanas sobre el sistema que ya usas. Leemos el código y los datos, hablamos con quien lo usa y te entregamos un informe con qué falla, qué cuesta arreglar cada cosa y en qué orden tocarlo. ## Cómo va, semana a semana - **Semana 1 · Acceso y entrevistas** Nos das acceso de lectura al repositorio, a la base de datos y a la infraestructura. Hablamos una hora con quien usa el sistema, una con quien lo mantiene y una con quien lo paga. Por videollamada; no hay que preparar nada. - **Semana 2 · Leemos el código y los datos** Reproducimos los fallos que nos habéis contado y buscamos los que nadie ha contado: cobros que se quedan a medias, registros duplicados, reglas que solo están en la cabeza de una persona. - **Semana 3 · Informe y sesión** Escribimos el informe y lo repasamos contigo en una sesión de una hora, con la gente de tu equipo que quieras dentro. ## Qué recibes - **La lista de lo que falla, por orden de riesgo** Cada punto con el sitio exacto del sistema donde está y qué pasa si no se toca. - **Qué cuesta arreglar cada punto** En semanas y en euros, uno por uno, para que puedas dejar fuera lo que no quieras. - **Un plan por fases, con precio** En qué orden se toca, qué entra en cada fase y cuánto cuesta cada una. El precio de cada fase queda cerrado antes de arrancarla. El informe es tuyo: puedes llevarlo a otro proveedor y pedirle presupuesto sobre él. No incluye arreglar nada ni escribir código: eso es el proyecto, y se decide después. Si el problema es pequeño, el informe lo dice, y ahí puede acabar. ## Qué pasa después - **Contratas el proyecto con nosotros** Empieza la primera fase del plan, con el precio que ya has visto en el informe. Un proyecto son de doce a dieciséis semanas, cerrado por fases. Al acabar cada fase puedes parar, y el sistema sigue entero. - **Lo arregla tu equipo, u otro proveedor** El informe está escrito para eso: sitios exactos, orden y coste. No hay nada que solo sepamos nosotros. - **No haces nada este año** Si el informe dice que el riesgo es bajo, lo dice. Sabes lo que hay, y te ahorras un proyecto. ## Precio 2.900 € + IVA. Se paga al empezar, en una sola factura. Antes hay una videollamada de veinte minutos sin coste, y un acuerdo de confidencialidad firmado antes de ver nada. Un proyecto después, si lo hay: de doce a dieciséis semanas, cerrado por fases, con el precio de cada fase por escrito antes de empezar. ## Preguntas **¿Qué pasa cuando escribo?** Te contestamos en un día laborable con tres preguntas sobre lo que tienes en marcha. Si encaja, hablamos veinte minutos por videollamada, sin coste. Después, si tiene sentido, empieza el diagnóstico. **¿Y si el código lo hizo otra empresa y no tengo acceso?** Entonces el diagnóstico empieza por ahí. No poder entrar en tu propio sistema es lo primero que hay que arreglar, y sale en el informe con nombre. **¿Qué pasa con la confidencialidad y con los datos de mi sistema?** Firmamos confidencialidad antes de ver nada; vale el tuyo o mandamos el nuestro. Trabajamos con acceso de lectura y los datos no salen de tu infraestructura. El informe describe estructuras y volúmenes, nunca personas. **¿Se puede hacer en remoto?** Sí, y es lo normal. Las entrevistas son por videollamada. Estamos en Barcelona; si prefieres la sesión final en persona, se hace. ## Pedir un diagnóstico Te contestamos en un día laborable con tres preguntas. Si encaja, veinte minutos de videollamada sin coste y empezamos. Escribe a hola@caricalia.com o rellena el formulario en https://caricalia.com/diagnostico#pedir. --- # Contratar a dos seniors, o encargar el proyecto. Dos formas de resolver el mismo trabajo. Una deja capacidad dentro de tu empresa; la otra deja el trabajo hecho con fecha y precio. Si el sistema del que depende tu negocio se ha quedado corto, la decisión casi nunca es entre dos proveedores: es entre ampliar tu equipo y encargar el proyecto fuera. Esta página compara las dos por los criterios que se discuten en la reunión. ## Criterio a criterio Seis criterios. En cuatro gana el proyecto: cuándo empieza, qué pasa con el coste, el diseño y el riesgo. En dos gana contratar. | Criterio | Dos seniors en plantilla | Un proyecto con Caricalia | | --- | --- | --- | | Cuándo empieza el trabajo | Entre cuatro y seis meses habituales entre abrir la búsqueda y tener a las dos personas produciendo, contando la incorporación. | **Gana el proyecto.** El diagnóstico empieza en semanas y dura tres. | | Qué pasa con el coste al acabar | El coste sigue todos los meses, haya o no proyecto que justifique dos personas. | **Gana el proyecto.** El proyecto tiene fecha y precio cerrados por fases. El diagnóstico son 2.900 € + IVA; un proyecto después se cierra por fases, con el precio de cada fase por escrito antes de empezar. | | El diseño | Dos perfiles de ingeniería no cubren el diseño. O se contrata a una tercera persona, o las pantallas las decide quien las programa. | **Gana el proyecto.** Las mismas personas diseñan y construyen; el diseño va dentro del proyecto. | | Conocimiento de tu negocio | **Gana contratar.** Una persona dentro acumula contexto que ningún informe transmite, y ese contexto se queda cuando acaba el proyecto. | Lo aprendemos en las tres semanas del diagnóstico y lo dejamos escrito, que no es lo mismo que tenerlo dentro todos los días. | | Trabajo continuo, sin final | **Gana contratar.** Si lo que hay por delante es evolución indefinida del producto, un equipo propio sale más barato al segundo año. | Trabajamos por proyectos con principio y final, y después hay evolución mensual. | | Riesgo de que salga mal | Una contratación que no encaja se descubre a los meses y se corrige despacio. | **Gana el proyecto.** Las condiciones de entrega van en el contrato y el último hito no se factura si alguna falla. | ## Cuándo contratar es mejor Cuando el software es lo que vendes y va a cambiar cada semana durante años. Ahí lo que tienes por delante es una empresa de producto, y la capacidad tiene que estar dentro. Un estudio que entra y sale es caro para eso. Y cuando el conocimiento del dominio es la parte difícil. Si entender tu negocio cuesta seis meses y el código es lo de menos, alguien que se queda amortiza esa curva y un proveedor la paga cada vez. En ese caso lo útil que podemos hacer es un diagnóstico que deje escrito el sistema antes de que entren las personas nuevas. ## Preguntas **¿Podemos hacer las dos cosas?** Sí, y es lo más frecuente. Nosotros hacemos el proyecto con fecha mientras tu equipo sigue con lo suyo, y quien entra después encuentra el sistema documentado. **¿Nos quedamos con el código?** Sí. El código es tuyo desde el primer día, en tu repositorio y con tus cuentas. El entregable incluye las decisiones escritas y la prueba del relevo, que es enseñar a alguien de fuera del proyecto a cambiar algo y desplegarlo. **¿Y si contratamos y el proyecto sigue parado?** Es el riesgo real de esta opción: la búsqueda tarda y el sistema se sigue deteriorando mientras tanto. Si tienes una fecha externa, como una auditoría o un cliente grande, cuatro a seis meses de búsqueda no llegan a tiempo. ## Ver también - https://caricalia.com/casos/beel - https://caricalia.com/notas/auditoria-tecnica-antes-de-una-inversion --- # Una consultora grande, o Caricalia. Dos maneras de contratar el mismo trabajo. Cambian el tamaño del encargo que aceptan, quién lo hace y qué pasa cuando algo se tuerce. Comparar por precio por hora no sirve aquí: son dos formas distintas de organizar el trabajo. Esta página compara por lo que se nota durante el proyecto y por lo que queda cuando termina. ## Criterio a criterio Seis criterios. En cuatro gana Caricalia: quién hace el trabajo, diseño e ingeniería juntos, precio y fecha cerrados, y lo que queda al acabar. En dos gana la consultora. | Criterio | Consultora grande | Caricalia | | --- | --- | --- | | Quién hace el trabajo | Te vende un socio y el proyecto lo ejecuta un equipo que no conoces al empezar, con rotación entre fases. | **Gana Caricalia.** Las mismas personas de principio a fin, y son quienes diseñan y escriben el código. | | Diseño e ingeniería | Suelen ser dos áreas distintas, con su propio traspaso entre ellas y su propio presupuesto. | **Gana Caricalia.** Van juntos: lo que se decide en diseño es lo que llega a producción, sin volver a discutirlo. | | Tamaño de lo que se puede abarcar | **Gana la consultora.** Si hay que mover cincuenta personas durante dos años en varios países, la capacidad está ahí y nosotros no la tenemos. | Trabajamos sobre una parte acotada del sistema, la que se ha vuelto cara de tocar. | | Requisitos de compras y de riesgo | **Gana la consultora.** Certificaciones, seguros de gran importe, homologación como proveedor y un equipo de contratación al otro lado. En una empresa grande eso decide sin discusión. | Cumplimos lo que se firma y lo escribimos en el contrato, pero no pasamos todos los filtros de un proveedor homologado. | | Qué pasa cuando el proyecto acaba | El conocimiento se va con el equipo asignado, y la continuidad se contrata aparte. | **Gana Caricalia.** El entregable lo puede mantener quien venga después. Las condiciones de entrega van en el contrato y el último hito no se factura si alguna falla. | | Precio y fecha | Presupuesto por horas o por bolsa de días, y cada cambio de alcance abre una negociación. | **Gana Caricalia.** Cada fase tiene precio y fecha cerrados antes de empezar. Puedes parar al final de cualquiera con el sistema entero. | ## Cuándo la consultora es mejor Cuando el trabajo es grande de verdad y hay que sostenerlo mucho tiempo. Una implantación que toca a varios países, a cientos de personas y a procesos que dependen unos de otros necesita una estructura que nosotros no tenemos. Y cuando la decisión no la toma quien sufre el sistema. Si compras exige proveedor homologado, seguro de responsabilidad por un importe alto o certificaciones concretas, la conversación se acaba ahí y es razonable que se acabe. Si aun así quieres saber qué hay dentro de tu sistema antes de sacar el concurso, el diagnóstico sirve para escribir el pliego. ## Preguntas **¿Podéis trabajar junto a la consultora que ya tenemos?** Sí. Lo habitual es que nosotros llevemos la parte por la que pasa el dinero —cobros, facturación, conciliación— y ellos el resto. Lo que hace falta acordar antes es quién es dueño de cada dato y qué contrato hay entre los dos sistemas. **¿Qué pasa si el proyecto se hace más grande de lo previsto?** Se dice y se para. El diagnóstico existe para ponerle tamaño antes de firmar: si lo que sale es un programa de dos años con varios equipos, te diremos que ese trabajo no es nuestro y por qué. **¿Cómo sabemos que quien nos vende es quien va a trabajar?** El equipo tiene nombre y trayectoria comprobable en la página de equipo, y el diagnóstico lo hacen las mismas personas que harían el proyecto. ## Ver también - https://caricalia.com/casos/zernio - https://caricalia.com/notas/arquitectura-tres-decisiones --- # Escribes, y te contestamos. En un día laborable, con tres preguntas sobre lo que tienes en marcha. Si por las respuestas no encaja, también te lo decimos. Puedes escribir por correo o rellenar el formulario, que es el mismo mensaje con los datos que necesitamos para contestar algo útil a la primera. No hay comercial intermedio y no hay presupuesto sin haber leído nada. ## Qué pasa cuando escribes - **Escribes** Por correo o con el formulario. Con saber qué sistema tienes y quién lo usa hoy nos vale para empezar. - **Te contestamos en un día laborable** Con tres preguntas sobre lo que tienes en marcha. Las escribe quien haría el trabajo. - **Veinte minutos por videollamada** Si por tus respuestas encaja. No se cobra y no hay presentación: se habla de tu sistema y de qué te está costando. - **El diagnóstico** Tres semanas leyendo el código y hablando con quien usa el sistema. Cuesta 2.900 € + IVA. Un proyecto después se cierra por fases, con el precio de cada fase por escrito antes de empezar. ## Dónde estamos Trabajamos desde Barcelona, presencial cuando el proyecto lo pide. - Correo: hola@caricalia.com - Ciudad: Barcelona - Domicilio fiscal: carrer Josep M. Folch i Torres, 6, 43480 Vila-seca (Tarragona) Es la dirección que consta en el aviso legal, para facturación y notificaciones. No es una oficina de visita. ## Antes de escribir **¿Cuánto tardáis en contestar?** Un día laborable. Si escribes un viernes por la tarde, tienes respuesta el lunes. Si en dos días no has recibido nada, revisa la carpeta de correo no deseado y vuelve a escribirnos. **¿Hace falta tener el proyecto definido?** No. Lo que hace falta es que haya un sistema en marcha y alguien usándolo. Definir el proyecto es parte del trabajo del diagnóstico, y a menudo la parte que más cambia lo que se acaba haciendo. **¿Mandáis presupuesto por correo?** No sin haber leído nada. Un presupuesto escrito sobre una descripción de dos párrafos es un número inventado. Por eso la puerta de entrada es el diagnóstico, que sí lleva precio cerrado. ## Ver también - https://caricalia.com/diagnostico - https://caricalia.com/servicios - https://caricalia.com/equipo --- # Quién responde. De cada encargo responde una dirección técnica con nombre. Carlos Martínez dirige el diseño y el desarrollo de los proyectos y la operación de BeeL. Trabajamos desde Barcelona. ## Carlos Martínez — Dirección técnica Dirige el diseño y el desarrollo de los proyectos y responde de lo que se entrega, desde la primera conversación hasta el último hito. Antes construyó infraestructura de pagos en Banco Santander y en PagoNxt. Hoy el equipo mantiene BeeL, nuestra plataforma de facturación con Verifactu, en producción. - **Caricalia:** Dirección técnica. Diseño de BeeL y desarrollo de los encargos. - **BeeL:** Operación de la plataforma de facturación, en producción. - **PagoNxt:** Infraestructura de pagos. - **Banco Santander:** Infraestructura de pagos. ## Dónde ha escrito código el equipo Hemos escrito código en producción para: BeeL., Zernio, Banco Santander, PagoNxt, Inditex. ## Ver también - https://caricalia.com/casos/beel - https://caricalia.com/notas - https://caricalia.com/diagnostico --- # BeeL: facturar en España sin saltarse un número > Producto propio bajo normativa fiscal. Numeración sin huecos, series que se bloquean, rectificativas proporcionales y registro en la AEAT. Cliente: BeeL (https://beel.es) Publicado: 2026-09-08 - Comprobable: BeeL en producción — https://beel.es - Comprobable: Servidor MCP público en GitHub — https://github.com/beel-es/beel-mcp - Comprobable: Documentación pública de la API — https://docs.beel.es --- ## Contexto BeeL es una plataforma de facturación para empresas españolas que construimos desde cero y que opera el mismo equipo que la escribió. Emite facturas con validez legal y las registra en la AEAT bajo el sistema Verifactu. ## Qué había que resolver De Verifactu se habla mucho y es una de las once cosas que hay que hacer bien. Las otras diez son las que dan trabajo, y las que se rompen cuando el volumen sube o cuando entra un negocio con reglas distintas. Estas son las once, con la razón por la que cada una cuesta. | # | Qué es | Por qué cuesta | |---|---|---| | 01 | Emisión | Una factura emitida ya no se puede editar ni borrar. Todo lo que se valide después llega tarde | | 02 | Numeración sin huecos | El contador tiene que ser correlativo aunque dos peticiones lleguen a la vez y aunque una falle a mitad | | 03 | Series bloqueadas tras la primera emisión | Cambiar el formato de una serie que ya emitió reescribe el pasado. Hay que impedirlo desde el producto | | 04 | PDF con validez legal | Lleva el QR de verificación y los datos obligatorios, y tiene que salir igual dentro de un año | | 05 | Envío y entrega | Sin acuse de entrega no se sabe si el cliente ha recibido la factura | | 06 | Rectificativas proporcionales | Corregir en parte exige un registro nuevo con su tipo de rectificación y su motivo legal | | 07 | Facturas recurrentes | Se generan solas, y el problema es el mes que no salen | | 08 | Multi-NIF | Una gestoría lleva muchas empresas. Cada una con su NIF, sus series y sus permisos, sin mezclarse | | 09 | Clientes sin NIF | La factura simplificada tiene límites de importe y casos prohibidos por ley que el sistema debe conocer | | 10 | Registro en la AEAT | La factura solo está terminada cuando la Agencia la acepta, y eso ocurre después de guardarla | | 11 | Verifactu | Cada registro encadena al anterior con su huella. Un eslabón mal formado invalida los siguientes | ## Las decisiones **La numeración se reserva dentro de la misma transacción que crea el registro fiscal.** El contador vive en la serie y se incrementa con un bloqueo sobre esa fila, no con un `max(numero) + 1` calculado en memoria. Dos emisiones simultáneas de la misma serie se ponen en cola durante milisegundos y salen ordenadas. Si el proceso de emisión falla después de haber cogido número, la transacción se deshace entera y el número vuelve a estar libre. Esto obliga a que la petición a la AEAT no esté dentro de esa transacción, porque una llamada de red lenta bloquearía la serie para todos. Lo que hay es un estado intermedio: la factura queda emitida y con número, y su envío a la Agencia se reintenta hasta que responde. Un hueco en la numeración es una infracción. **Una serie se bloquea en cuanto emite su primera factura.** El formato, el prefijo y el modo en que se reinicia el contador se eligen al crearla y después dejan de ser editables. La razón: si alguien cambia el formato en octubre, las facturas de enero dejan de encajar con las de noviembre y no hay reconstrucción posible. Por eso la pantalla de creación pide el formato completo y enseña qué número saldrá. Quien migra desde otro programa puede fijar el número inicial para continuar su numeración anterior, y solo entonces. **Una rectificativa parcial recalcula, no resta.** Corregir una factura tiene dos ejes que el usuario tiene que decidir: si sustituye a la original o si aplica una diferencia, y por qué motivo legal se corrige. Un impago con procedimiento no es lo mismo que un descuento posterior, y a la AEAT llega distinto. La rectificativa parcial recalcula base e impuestos sobre el importe corregido y deja la original en estado rectificado, que admite otra corrección después. La total sustituye a la original y la deja anulada, sin más correcciones posibles. En el producto eso se traduce en que no se puede escribir a mano el importe de una rectificativa total: lo calcula el sistema desde la factura original. **Un cliente sin NIF es una factura simplificada.** La ley le pone límites que el software tiene que conocer antes de emitir. Por encima de tres mil euros con impuestos incluidos no es legal, y por encima de cuatrocientos hay que identificar al destinatario aunque sea simplificada. Además hay operaciones donde no se permite nunca, con independencia del importe. BeeL rechaza esas combinaciones en el borde de la API, con un error que dice cuál es la regla, en lugar de aceptarlas y dejar que el problema aparezca en una inspección. Quien integra no suele ser fiscalista, y un error de validación se lee mientras se programa. **Las recurrentes se diseñaron por el mes que fallan.** El caso difícil es el mes en que el cliente ya no existe, la serie está agotada o la AEAT no responde. Cada generación deja rastro, se marca como no emitida con su causa, y se avisa el mismo día por correo y por webhook. No hay reintento silencioso que acabe emitiendo dos facturas por el mismo periodo. ## Estado hoy BeeL está en producción y lo operamos nosotros. Registra cada emisión en la AEAT, soporta varias empresas con NIF distinto en una misma cuenta y emite recurrentes sin intervención. La API pública está documentada y hay un servidor MCP abierto para que un agente pueda emitir contra ella con las mismas reglas que aplica la interfaz. Cuando la Agencia cambia una especificación, la fecha no se negocia. Con ese punto de vista entramos en un proyecto de [software a medida](/software-a-medida). ## Qué puede comprobar un tercero - El producto está publicado y se puede probar en [beel.es](https://beel.es). - El servidor MCP es público en GitHub: [beel-es/beel-mcp](https://github.com/beel-es/beel-mcp). Ahí se leen las reglas fiscales que aplica antes de emitir, incluidas las de series, rectificativas y recargo de equivalencia. - La documentación de la API está abierta en [docs.beel.es](https://docs.beel.es), con el registro de cambios y las fechas de retirada de las rutas antiguas. --- # Zernio: el último paso se hacía a mano > Sus clientes programan publicaciones desde su propio flujo de n8n. Construimos el nodo, está en el catálogo y el código es abierto. Cliente: Zernio (https://zernio.com) Publicado: 2026-09-08 - Comprobable: Integración en el catálogo de n8n — https://n8n.io/integrations/zernio/ - Comprobable: Código del nodo en GitHub — https://github.com/zernio-dev/n8n-nodes-zernio - Comprobable: Zernio — https://zernio.com --- ## Contexto Zernio es una plataforma desde la que las marcas programan lo que publican en redes. Muchos de sus clientes automatizan el trabajo con n8n: un flujo redacta el texto, elige la imagen y decide el día. Y ahí se paraba, porque el último paso, programar la publicación en Zernio, había que hacerlo a mano. ## Qué había que resolver Un nodo de n8n para Zernio. Con él, el flujo que ya produce el contenido lo programa también, con las credenciales del cliente, sin que nadie tenga que copiar nada entre dos herramientas. Un nodo de catálogo lo instala gente que no conocemos y que no puede preguntarnos nada. Tiene que explicarse solo: qué campos pide, en qué orden, y qué dice cuando una publicación no se puede programar. ## Las decisiones **Los campos llevan los nombres que usa quien monta el flujo, no los de la API.** En cuanto hay flujos ajenos en producción, renombrar un campo los rompe, así que los nombres se cerraron antes de publicar. El código está publicado y ahí se ven los campos, las operaciones y los errores que devuelve. **Un error dice qué ha pasado y qué campo tocar**, y distingue entre lo que se puede reintentar y lo que no. Un nodo que reintenta un error de datos acaba publicando dos veces lo mismo. ## Estado hoy El nodo está publicado en el catálogo de n8n y en uso. Un cliente de Zernio programa desde su propio flujo, con sus credenciales, sin abrir otra herramienta. Se instala como cualquier nodo de la comunidad y el código es abierto. ## Qué puede comprobar un tercero - La integración figura en el catálogo de n8n: [n8n.io/integrations/zernio](https://n8n.io/integrations/zernio/). La página dice quién la mantiene y su estado de verificación. - El código del nodo está publicado en [zernio-dev/n8n-nodes-zernio](https://github.com/zernio-dev/n8n-nodes-zernio). - El producto al que se conecta está en [zernio.com](https://zernio.com). --- # Qué mira una auditoría técnica > Una due diligence técnica no puntúa tu código: mide qué riesgo compra quien entra. Estos son los sitios donde mira y lo que se puede preparar antes. Publicado: 2026-09-09 Autor: carlos Temas: arquitectura, diagnóstico --- ## Una auditoría mide el riesgo que compra quien entra Una auditoría técnica antes de una ronda, de una compra o de la firma de un cliente grande no existe para poner nota a tu sistema. Existe para responder a una pregunta: si esto sale mal, cuánto cuesta y quién lo paga. Las preguntas que se hacen durante la revisión cuelgan de ahí. Entenderlo cambia cómo te preparas. Un sistema con deuda técnica reconocida, documentada y con un plan de plazos pasa mejor que uno sin deuda conocida del que nadie sabe explicar cómo se despliega. Si un inversor, un comprador o un cliente grande va a mirar dentro y no hay nada preparado, esta es tu situación. Es una de las cinco por las que nos llaman, y suele llegar con fecha puesta. ## Los cinco sitios donde mira **Propiedad y procedencia del código.** Quién es dueño de lo que se ha construido. Si hubo proveedores externos, si el contrato cedía los derechos, si el repositorio está a nombre de la empresa o de la cuenta personal de alguien. Aquí también entra el inventario de licencias de las dependencias, porque una licencia contagiosa dentro de un producto que se vende cerrado es un problema legal, no técnico. Desde que parte del código se genera con asistentes, esta pregunta se ha vuelto más frecuente y más incómoda. Se responde con procedencia y con revisión, no negando que se use. **De cuántas personas depende esto.** Cuántas personas pueden desplegar. Cuántas entienden la parte por la que pasa el dinero. Qué pasa si mañana no está la que lleva más tiempo. Un sistema que solo una persona sabe tocar no es un activo estable, y quien invierte lo comprueba mirando quién ha escrito cada parte. Está contado en [un sistema legacy es código sin dueño](/notas/sistema-legacy-codigo-sin-dueno). **Los datos.** Dónde están, quién puede leerlos, qué se guarda de personas y con qué base legal, cuánto se conserva y qué pasa si alguien pide que se borren. Y la pregunta que más veces se queda sin respuesta buena: cuándo fue la última vez que se restauró una copia de seguridad de verdad, no cuándo se hizo. Una copia que nunca se ha restaurado no está comprobada. **El dinero, si pasa por tu sistema.** Si cobras, facturas o concilias con software propio, esa parte se mira aparte y con lupa. Que los ingresos declarados cuadren con el banco. Que las facturas no tengan huecos de numeración ni se puedan modificar después de emitidas. Que el cumplimiento fiscal esté donde tiene que estar, que en España pasa por lo que exige [Verifactu](/glosario/verifactu). Reconstruir dos años de [conciliación bancaria](/glosario/conciliacion-bancaria) durante una due diligence sale caro y llega tarde. **La capacidad de cambiar.** Se mide por lo que tarda un cambio pequeño en llegar a producción y por lo que se rompe cuando llega. Se mide con hechos: cómo se despliega, si vuelve atrás solo cuando falla, qué se comprueba de forma automática y qué se comprueba mirando. Un sistema donde cada cambio cuesta más que el anterior es un sistema cuyo plan de producto no se puede cumplir, y eso es lo que un inversor está comprando. ## Cómo se comporta la conversación Un auditor no te va a pedir el código y ya está. Va a pedir que alguien le cuente una decisión y luego va a ir a comprobarla. Las respuestas que sostienen esa comprobación son las escritas: por qué se eligió esta arquitectura, qué se descartó, qué se sabe que está mal y qué plazo tiene. Lo que complica una auditoría es la sorpresa: encontrar algo que el equipo no había mencionado. A partir de ahí se revisa con más detalle todo lo demás. Por eso conviene entregar tú mismo la lista de lo que está mal, con su tamaño y su orden. ## Qué se puede preparar antes, y en cuánto tiempo En dos o tres semanas se puede tener casi todo lo que se pide. Un documento corto de arquitectura con las tres o cuatro decisiones que explican el sistema, y lo que se descartó. El inventario de servicios, cuentas, dominios y licencias, con quién es el titular de cada uno. Una restauración de copia de seguridad hecha de verdad, con la fecha apuntada. La lista de accesos, con las bajas de gente que ya no está. Y el registro de deuda técnica conocida, con tamaño y prioridad. Eso mismo es lo que hace falta para que el sistema deje de depender de quien lleva más tiempo. Las decisiones y el marco de entrega están tratados en [tres decisiones de arquitectura](/notas/arquitectura-tres-decisiones). ## Si la fecha ya está puesta Cuando la auditoría tiene fecha y no hay nada preparado, la prioridad es saber qué van a encontrar antes de que lo encuentren. Eso es lo que hace un [diagnóstico](/diagnostico). Tres semanas leyendo el código y hablando con quien usa el sistema, y un informe con qué falla, qué cuesta arreglarlo y en qué orden. Cuesta 2.900 € + IVA; el proyecto que suele venir después se cierra por fases, con el precio de cada fase por escrito antes de empezar. El informe es tuyo, y sirve para llegar a la revisión con la lista escrita y también para decidir que este año no toca. Si el trabajo es reescribir la parte que no aguanta, eso es [software a medida](/software-a-medida). --- # Por qué tus clientes se caen en el alta > Quien abandona el alta ya había decidido pagarte. Se va por un dato que no tenía a mano, por una espera sin explicar o por un error que no sabe corregir. Publicado: 2026-09-09 Autor: carlos Temas: producto, diseño --- ## La gente que abandona el alta ya te había dicho que sí Quien se cae dándose de alta ya ha decidido usar tu producto y ha empezado. Por eso ese tramo es de los más rentables de arreglar: no hay que convencer a nadie, solo quitar de en medio lo que estorba. Si tienes un producto con clientes dentro y ves altas empezadas que no terminan, tickets de soporte de gente que no puede continuar y altas que acaba terminando el equipo comercial, estás en esta nota. Y conviene decir dónde acaba el alta de verdad. No acaba cuando existe la cuenta. Acaba cuando esa persona ha hecho por primera vez lo que venía a hacer: emitir la factura, importar el catálogo, cerrar el pedido. Todo lo que hay entre esos dos puntos es el [onboarding](/glosario/onboarding), y ahí es donde se pierde gente. ## Los cuatro sitios donde se rompe **Los datos que pides antes de tiempo.** Cada campo obligatorio es un encargo que le haces a quien se está dando de alta. Un CIF, un número de cuenta, un dato que está en otro departamento. Quien tiene que ir a buscarlo abandona la pantalla, y muchas veces no vuelve. La pregunta útil es cuántos de esos datos tiene la persona delante ahora mismo. Los que no, se piden después, cuando el producto ya ha demostrado algo, o los deduce el sistema. **Las esperas que no se explican.** Una verificación que tarda, una importación que corre en segundo plano, una comprobación que hace una persona de tu equipo por la mañana. Nada de eso está mal. Lo que rompe el alta es una pantalla que se queda quieta sin decir qué está pasando, cuánto falta y qué puede hacer mientras tanto. Decir «esto tarda dos minutos y te avisamos por correo cuando esté» deja que la persona se vaya sin perder el trabajo hecho. Decir solo «esto tarda dos minutos» la obliga a esperar delante. **Los errores que llegan al final.** El sistema acepta seis pasos y rechaza el séptimo por algo que se escribió en el primero. Ahí no pierdes a quien se equivoca: pierdes a quien ya no sabe qué corregir. Un mensaje que dice «datos inválidos» y no dice cuál, ni dónde, ni qué se esperaba, no permite corregir nada. Los errores que devuelve otro sistema son el caso peor. Si tu alta consulta un servicio externo y le enseñas al usuario el error literal de ese servicio, le estás enseñando el nombre interno de un campo de otro programa. Eso está tratado en [integrar dos sistemas que no se conocen](/notas/integrar-dos-sistemas): el mensaje que ve una persona es parte de la integración, no un detalle posterior. **El trabajo invisible que nadie asignó.** Muchas altas fallan porque hay un paso que depende de tu equipo —aprobar, verificar, cargar unos datos iniciales— y no está en ninguna cola visible. Funciona mientras hay pocas altas al mes. Cuando suben, quien lo hacía deja de dar abasto y las altas se quedan esperando sin que nadie lo sepa. ## Cómo encontrar el punto exacto en tu producto Sin estudios de sector y sin comparaciones con nadie. Con tus propios datos, que ya los tienes o los puedes tener en una semana. Primero, dos números. De cada cien cuentas creadas, cuántas llegan a hacer la acción que define tu producto. Y cuánto tiempo pasa entre una cosa y la otra. Con eso solo ya sabes si tienes un problema pequeño o uno grande. Segundo, el paso en el que se quedó cada persona que no llegó. Eso convierte la discusión en una lista ordenada: si una parte grande se detiene en la misma pantalla, no hace falta debatir por dónde empezar. Tercero, siéntate al lado de alguien que se dé de alta de verdad, con sus datos y sin ayuda, y no intervengas. Anota cada vez que abra otra pestaña, pregunte algo o se detenga, y qué estaba mirando en ese momento. ## Qué se arregla primero El orden importa, porque casi todo esto se puede tocar sin rehacer el producto. Se empieza quitando del camino los datos que no hacen falta todavía y guardando el trabajo a medias: quien vuelve mañana tiene que encontrar el alta donde la dejó. Después se explican las esperas y se ponen los errores donde ocurren, con el texto que dice qué corregir. Y al final se mira lo que depende de una persona de tu equipo y se le pone una cola con dueño y con aviso. Nada de esto es un rediseño. Es [marca y producto](/marca-y-producto) sobre un sistema que está funcionando y que no se puede parar, que es la situación normal cuando ya hay clientes dentro. ## Por dónde empezar Antes de pedir presupuesto a nadie, consigue dos cosas: el porcentaje de altas que llegan al primer resultado y la lista de pasos donde se queda la gente. Con esas dos, cualquier conversación con un proveedor deja de ser sobre estética y pasa a ser sobre qué se arregla primero y qué cuesta. Si no las tienes y el producto ya está en producción con clientes dentro, ese es exactamente el trabajo del [diagnóstico](/diagnostico): tres semanas leyendo el sistema y hablando con quien lo usa, y un informe con qué falla, qué cuesta arreglarlo y en qué orden. --- # Arquitectura de software: lo que no se deshace > La arquitectura que importa son tres decisiones caras de deshacer. Con ejemplos de nuestra plataforma de facturación, donde una la fija la ley. Publicado: 2026-09-08 Autor: carlos Temas: arquitectura, datos, pagos --- ## Las tres decisiones que cuesta deshacer En un sistema de software casi todo se puede rehacer más tarde con dinero y paciencia. Se puede cambiar el lenguaje, el proveedor de servidores o la interfaz entera. Tres cosas no: dónde vive cada dato y quién es su dueño, qué límites separan las partes del sistema, y cómo se comporta la parte por la que entra el dinero cuando algo falla a medias. Lo que no se rehace sin parar el negocio es un modelo de datos con años de historial dentro y muchas integraciones leyéndolo. Por eso estas tres se hablan antes de escribir una línea de código. ## Uno: dónde vive el dato y quién es su dueño Cada dato necesita un único sitio donde se decide su valor. Los demás lo leen de ahí y no lo tocan. En cuanto un mismo hecho se guarda en dos sistemas que ambos pueden escribirlo, has creado un trabajo manual permanente para alguien. El caso típico: el CRM guarda el correo del cliente y la herramienta de facturación también, porque lo necesita para enviar el PDF. Se copian a mano cada día, y con el tiempo hay trabajo fijo de cuadrar dos listas sin ninguna regla que diga cuál manda cuando no coinciden. Elegir el dueño es la parte fácil. La que se olvida es el historial: si guardas solo el estado actual, has decidido sin querer que la pregunta «cómo estaba esto en marzo» no tenga respuesta. Y esa pregunta la hace una auditoría, un cliente que reclama o la propia empresa cuando quiere saber por qué un pedido acabó como acabó. Por eso, en la parte del sistema donde el pasado importa, se guarda lo que pasó y no solo cómo está ahora. En vez de sobreescribir un precio, se registra quién lo cambió, cuándo y de qué valor a cuál. ## Dos: qué límites hay entre las partes Un límite bien puesto se reconoce por una cosa: puedes cambiar lo que hay dentro sin avisar a nadie de fuera. Si para tocar el cálculo de descuentos hay que revisar seis sitios que también lo calculan, ahí no hay límite. La pregunta útil es qué cambio previsible te obliga a tocar más de una parte. Coge los tres cambios que sabes que vas a pedir el año que viene y mira cuántas piezas toca cada uno. Si cada cambio normal atraviesa medio sistema, el reparto está mal. El error caro es partir el sistema por tecnología en lugar de por responsabilidad. Separar «la base de datos», «la lógica» y «la interfaz» no ayuda, porque cualquier funcionalidad nueva las cruza las tres. Separar «facturación» de «catálogo» sí, porque casi ningún cambio de catálogo debería tocar cómo se emite una factura. El otro error es partir demasiado pronto. Cada límite que pones es una conversación que hay que mantener después: contratos, versiones, qué pasa cuando una parte está caída. Los límites hacia fuera merecen el mismo cuidado. Cuando integras un sistema de terceros, lo que llega por su [API](/glosario/api) o por un [webhook](/glosario/webhook) no debería entrar tal cual en tu modelo. Se traduce en el borde, en un solo sitio, para que el día que ese proveedor cambie su formato haya un solo sitio que tocar. ## Tres: cómo se comporta la parte que cobra En la parte por la que pasa dinero, la pregunta que ordena el diseño es qué ocurre cuando la operación falla por la mitad. Una operación de cobro toca varias cosas seguidas. Se apunta el pedido, se pide el cargo al banco, se emite la factura, se avisa al cliente. Cualquiera de esos pasos puede fallar sin decirte si se hizo o no: un tiempo de espera agotado no significa que el cargo no se haya hecho, solo que no has recibido la respuesta. De ahí salen tres propiedades que esa parte necesita tener desde el primer día, porque añadirlas después obliga a revisar todo lo que ya se cobró. **Repetir tiene que ser inofensivo.** Si el mismo intento de cobro llega dos veces, se cobra una. Se consigue haciendo que quien pide la operación mande un identificador propio, y que el sistema recuerde qué identificadores ya atendió y con qué resultado. En el oficio esto se llama idempotencia. **El registro de lo intentado vale tanto como el resultado.** Hay que poder reconstruir qué se pidió, cuándo, qué contestó el banco y qué hizo el sistema a continuación. Sin ese registro, una reclamación se acaba respondiendo devolviendo el dinero por si acaso. **Hace falta un camino de vuelta escrito.** Un pedido no puede quedarse cobrado y sin factura, ni facturado y sin cobrar. Cuando los pasos no caben en una sola operación atómica, se decide por adelantado cómo se deshace cada uno y quién lo dispara. ## Un ejemplo real: la numeración de las facturas En [BeeL](/casos/beel) operamos nuestra propia plataforma de facturación con Verifactu. La numeración obliga a resolver ahí las tres decisiones a la vez, y no deja margen de opinión porque la fija la ley. La numeración de una serie tiene que ser correlativa y sin huecos. Eso descarta la forma cómoda de generar números cuando hay varios procesos a la vez, que es dejar que cada uno coja el siguiente disponible: si dos emiten a la vez y uno falla después de haber cogido su número, queda un hueco que hay que explicar delante de la Agencia Tributaria. Así que el número se asigna dentro de la misma operación que deja la factura emitida, con la serie bloqueada mientras tanto, y cada factura queda encadenada a la anterior. Si algo falla en mitad del proceso, no hay número gastado. La decisión de datos va pegada: una factura emitida no se edita nunca. Se corrige con una rectificativa, que es un documento nuevo que apunta al anterior. El historial está en el propio modelo de datos. Y el límite hacia fuera existe porque el registro en la AEAT es un sistema ajeno, con sus propios tiempos y sus propias caídas. El envío vive en su borde, con reintentos que no duplican registros, para que una incidencia allí no impida seguir emitiendo. ## Cómo se toman estas decisiones sin adivinar Mirando dos cosas que el propio negocio ya sabe: qué preguntas va a tener que responder sobre el pasado, y qué cambios sabe que va a pedir en los próximos doce meses. La primera lista dice qué historial hay que guardar. La segunda, dónde poner los límites. Las dos caben en un folio y ninguna requiere saber programar. Las escribimos en la primera semana de [cada diagnóstico](/diagnostico), delante de quien va a firmar, y ahí es también donde se mira si alguna de las tres se decidió mal en un sistema que ya está en marcha. Cómo trabajamos está en [software a medida](/software-a-medida). --- # Cuándo dejar el no-code, con números > El no-code se deja cuando hay cifras encima de la mesa: gente que depende del sistema, dinero que pasa por él, un cliente que pide contrato. Publicado: 2026-09-08 Autor: carlos Temas: no-code, producto --- ## La respuesta corta Deja el no-code cuando la herramienta te impida hacer algo que tu negocio ya necesita. Mientras puedas hacer lo que te piden tus clientes, cambiar de tecnología es gasto sin ingreso al otro lado. Lo difícil es saber cuándo has llegado a ese punto, porque llega despacio. Cada mes hay una cosa más que se hace a mano, hasta que son varias horas semanales de trabajo manual. Por eso los cuatro criterios de abajo son cosas que se cuentan. ## Criterio 1: cuánta gente depende Cuenta las personas que no pueden trabajar si eso se cae durante media jornada. Las de dentro y las de fuera, por separado. Con dos o tres personas dentro y ningún cliente, el no-code es la respuesta correcta y casi siempre la más barata. Cuando el número de fuera pasa de cero, ya no decides tú cuándo se arregla. El número que sirve es este: horas al mes que alguien dedica a mano a algo que el sistema debería hacer solo, multiplicadas por lo que cuesta esa hora. Ese coste anual es el que se compara con el presupuesto de arreglarlo. ## Criterio 2: si por ahí pasa dinero Si la herramienta cobra, factura o cuadra cuentas, el listón sube de golpe. En España, emitir una factura no es guardar un PDF. Hay numeración correlativa sin huecos, retenciones, IVA por tipo, rectificativas, y desde hace poco el registro en la AEAT. Operamos [BeeL](/casos/beel), nuestra propia plataforma de facturación, y son once cosas distintas las que hay que resolver para emitir una factura bien. Las herramientas genéricas no las traen puestas. El criterio contable es sencillo. Si un error en esa parte te obliga a devolver dinero, a corregir una factura o a explicárselo a la Agencia Tributaria, ha dejado de ser un problema de producto. ## Criterio 3: si hay un cliente que exige por contrato Este llega de golpe. Un cliente grande manda un cuestionario de seguridad, o un inversor pide una auditoría, y las preguntas se repiten: dónde están los datos, quién tiene acceso, qué pasa si os borran la cuenta, qué registro hay de quién ha entrado. Con una herramienta no-code puedes responder a algunas. A otras la respuesta honesta es «lo que diga el proveedor», y esa respuesta puede costar el contrato. El número aquí es cuánto vale ese contrato. Si vale más que el proyecto de sacarlo de ahí, ya sabes qué hacer. ## Criterio 4: los límites que la herramienta publica Este es el único que no depende de tu criterio, porque está escrito en la documentación del fabricante. Búscalo antes de montar nada encima. Airtable, por ejemplo, publica un tope de registros por base: 1.000 en el plan gratuito, 50.000 en Team y 125.000 en Business ([planes de Airtable](https://support.airtable.com/docs/airtable-plans)). Son límites acumulados entre todas las tablas de una misma base. Si tu producto guarda una fila por evento, esos números llegan antes de lo que parece. Haz la cuenta con tu propio crecimiento: filas nuevas al mes, dividido entre lo que te queda de tope. Si sale menos de doce meses, el problema ya está en el calendario. ## Lo que no es un motivo para dejarlo Que alguien diga que no es código de verdad, o que no escala, sin haber mirado lo que tienes. También conviene desconfiar del argumento contrario cuando llega desde alguien que vende desarrollo. Reescribir es la propuesta más fácil de justificar y la más cara de ejecutar, y quien la hace sin haber abierto lo que tienes te está vendiendo horas. ## Qué se conserva cuando por fin se sale Casi todo lo que importa, si se hace leyendo primero. Lo que montaste tiene dentro las decisiones reales de tu negocio: qué campos resultó que hacían falta, qué estados tiene un pedido en tu empresa y no en el manual, qué le dices al cliente cuando algo no se puede hacer. Eso no está escrito en ningún otro sitio, y es lo que se pierde cuando alguien empieza de cero con la excusa de la deuda técnica. Qué se conserva y qué se cambia está contado, con el orden en que se hace, en [de prototipo a producción](/de-prototipo-a-produccion). Si lo que tienes todavía es un [MVP](/glosario/mvp) sin clientes, la respuesta sigue siendo quedarse: el no-code es más barato que nosotros y para esa fase es mejor herramienta. ## Cómo se decide sin adivinar Los cuatro números de arriba se reúnen en una tarde: personas que dependen, horas de trabajo manual al mes, dinero que pasa por el sistema, y cuánto te queda de los topes que publica tu proveedor. Si prefieres que los saquemos nosotros con el sistema delante, eso es [un diagnóstico](/diagnostico). Y si la conclusión es que de momento no toques nada, también sale escrita. --- # Cuánto cuesta desarrollar una aplicación > Nadie puede darte un precio de mercado honesto. Sí se puede explicar de qué depende la cifra y cómo se compone un presupuesto por fases. Publicado: 2026-09-08 Autor: carlos Temas: precio, presupuesto, producto --- ## La respuesta corta, con nuestros números Aquí un diagnóstico de producto y arquitectura cuesta 2.900 € + IVA y dura tres semanas. Un proyecto de software en producción va de doce a dieciséis semanas y se cierra por fases, con el precio de cada fase por escrito antes de empezarla. Después existe una cuota mensual de evolución, para seguir con el sistema una vez entregado. Su importe se fija al cerrar el proyecto, según lo que se haya construido y cuánto se mueva. Esos son los únicos números que vas a leer aquí. No hay tabla de «una app sencilla cuesta X y una compleja cuesta Y»: quien te la enseñe no ha visto tu sistema, no sabe cuánta gente lo usa y no sabe qué hay ya construido. ## De qué depende de verdad la cifra Casi nunca del número de pantallas. Lo primero que miramos es **qué parte del sistema hay que tocar**. No cuesta lo mismo añadir una pantalla al margen que cambiar cómo se guarda un pedido; lo segundo obliga a revisar todo lo que lee ese pedido, y en un sistema con años encima eso alcanza a buena parte de la aplicación. Después viene la pregunta del dinero. Cobros, facturación, nóminas, conciliación: en cuanto una operación mueve dinero deja de valer que funcione casi siempre. Hay que decidir qué pasa cuando falla a medias, quién se entera y cómo se deshace. También cambia la cifra según cuánta gente dependa de que el sistema siga en pie. Con tres personas dentro y ningún cliente fuera, puedes arreglar en caliente lo que se rompa. Con clientes fuera, cada despliegue necesita poder deshacerse. Y queda el estado de lo ya construido. Un sistema con las reglas de negocio escritas como pruebas se puede tocar sin miedo. Uno donde nadie sabe qué pasa si cambias un campo obliga a averiguarlo primero, y averiguarlo son semanas antes de escribir una línea. ## Qué encarece y qué abarata Sin euros, porque los euros dependen de tu caso. Esta es la lista con la que calibramos cuando leemos un sistema. | Encarece | Abarata | |---|---| | Un fallo puede parar la operación o incumplir una norma | El peor caso es que alguien repita una tarea a mano ese día | | Hay que integrarse con sistemas de terceros que no controlas | Todo vive dentro de tu propia base de datos | | Nadie del equipo original sigue en la empresa | Quien lo escribió está y puede contestar en media hora | | Los datos históricos hay que migrarlos y cuadran mal | Se arranca con datos nuevos | | Arrancar con urgencia, desplazando trabajo ya comprometido | La fecha de inicio es flexible | | El alcance se define sobre la marcha | Hay un diagnóstico previo con el alcance escrito | | Varias personas tienen que aprobar cada decisión | Decide una persona con nombre | La fila que más mueve el número es la primera. Un proceso que te cuesta mucho al año justifica un proyecto grande; uno que te cuesta poco no justifica este servicio, y es mejor saberlo en la semana uno. ## Cómo se compone un presupuesto por fases | Qué es | Duración | Precio | |---|---|---| | Diagnóstico de producto y arquitectura | 3 semanas | Cerrado, al empezar | | Producto en producción | 12 a 16 semanas | Por fases, precio de cada fase antes de empezar | | Evolución | Mensual | Según lo entregado | El diagnóstico es la puerta. Leemos el código y hablamos con quien usa el sistema todos los días. Sales con qué se rompe primero, qué cuesta arreglarlo y el plan por fases con el precio de cada una. Si la conclusión es que este año no toca hacer nada, también sale escrita. De ahí en adelante se cobra por hitos. Cada fase se cierra con una demostración en vivo del software funcionando. Hasta que esa demostración no se hace, el hito no se factura. La razón de partirlo es que el precio de la fase cuatro se calcula con lo que se aprendió en la tres. Un número dado en la semana cero para la semana catorce es una apuesta, y esa apuesta la acaba pagando alguien: o tú con un cambio de alcance, o nosotros bajando la calidad para llegar. ## Qué pasa con los presupuestos que se dan sin leer el código Un presupuesto emitido a partir de una llamada de una hora y un documento de requisitos supone que el sistema por dentro es como lo cuenta quien lo pide. En un sistema con años encima esa suposición falla en la parte cara: el módulo del que nadie se acuerda, la integración que se reconcilia a mano cada mes, el campo que significa dos cosas distintas según quién lo rellenó. Cuando eso aparece a mitad de proyecto hay tres salidas y ninguna es buena. Se amplía el presupuesto, se recorta alcance por debajo de lo que hacía falta, o se entrega algo que funciona en la demo y se cae el primer mes. Por eso separamos el diagnóstico y lo cobramos. Tres semanas de leer el sistema antes de comprometer una cifra no se regalan, y regalarlas obliga a recuperarlas en el precio del proyecto o a hacerlas mal. Si prefieres empezar por ahí, [pide un diagnóstico](/diagnostico). ## Preguntas que sirven para cualquier proveedor Pídele que te nombre las dos cosas que más podrían mover el precio que acaba de darte. Quien lo ha calculado las nombra; quien lo ha estimado a ojo contesta con generalidades. Pregunta qué pasa si en mitad del proyecto aparece algo que nadie sabía. Busca una respuesta que describa un procedimiento. Pregunta a nombre de quién quedan el repositorio, la infraestructura y las claves, y desde qué momento. Aquí van a tu nombre desde el primer hito y está en el contrato. Pregunta qué se enseña al cerrar cada fase. Un documento de estado en lugar del software funcionando delante de ti significa que el riesgo de la última semana lo llevas tú. Y pregunta quién va a escribir el código, con nombre y apellido. Comprueba que la respuesta sea la misma en la venta y en el arranque. ## Si todavía no tienes clientes Si lo que tienes es una idea y ningún cliente pagando, lo que necesitas es un [MVP](/glosario/mvp) montado rápido y barato para descubrir si alguien lo quiere. Eso hoy se hace con herramientas que cuestan una fracción de un proyecto, y ese trabajo queda fuera de lo que hacemos. Donde sí trabajamos es más adelante: cuando el sistema ya está en uso, hay clientes dentro y cada cambio cuesta más que el anterior. Cómo se aborda eso está en [software a medida](/software-a-medida), y si quieres poner un número a lo que tienes entre manos, [el diagnóstico existe para eso](/diagnostico). --- # Un design system es una lista de decisiones > Los sistemas de diseño montados como catálogo se abandonan al año. Lo que aguanta es el acuerdo sobre qué se decide y quién lo cambia. Publicado: 2026-09-08 Autor: carlos Temas: diseño, sistema de diseño, producto --- ## Qué contiene de verdad un sistema de diseño Un sistema de diseño es el conjunto de decisiones que tu producto ya no vuelve a discutir, más el acuerdo sobre quién puede cambiarlas. Los componentes son el sitio donde esas decisiones quedan escritas en código. Las decisiones son cosas como cuántos tamaños de texto existen y para qué sirve cada uno. Qué significa exactamente el color de aviso. Qué se ve cuando una tabla no tiene datos. Cómo se llama la acción que borra algo. Cada una se responde una vez y se escribe. Si un sistema de diseño tiene muchas piezas dibujadas y ninguna línea que explique cuándo se usa cada una, lo que hay es un catálogo de imágenes ordenado. ## Cómo se nota la diferencia al año Se nota en el número de componentes que hacen casi lo mismo. Cuando el sistema solo es catálogo, cada equipo que necesita algo que no está se fabrica su versión y sigue. Con el tiempo hay varios botones de peligro con rojos distintos, varias formas de pedir confirmación y un calendario por producto. Nadie ha hecho nada mal: no había ninguna regla que dijera qué hacer cuando la pieza no existe. Brad Frost describe ese punto en [A Design System Governance Process](https://bradfrost.com/blog/post/a-design-system-governance-process/): si quien usa el sistema no puede hacer lo que necesita hacer, el sistema entero corre riesgo de quedarse obsoleto. Frost propone un procedimiento explícito para los casos en que el componente no existe o solo sirve a medias. Es de 2019. El segundo síntoma tarda más en aparecer y cuesta más. Los diseños dejan de parecerse al producto. Se aprueban pantallas en un fichero de diseño, se construyen aproximadamente, y como la diferencia es pequeña cada vez, nadie la corrige. Con el tiempo, lo que se enseña a un cliente y lo que ese cliente encuentra al entrar dejan de parecerse. ## Qué pasa cuando diseño y desarrollo son departamentos Las decisiones se toman dos veces, y la segunda gana. En el reparto habitual, diseño entrega un fichero con las pantallas y desarrollo lo construye. Pero un fichero de diseño no dice qué se ve cuando la carga tarda seis segundos, ni qué aparece si el usuario no tiene permiso, ni cómo se comporta la tabla con un nombre de cliente muy largo. Esas decisiones se toman igualmente, y las toma quien está escribiendo el código. El estado de error y el estado vacío son buena parte de la experiencia real de un producto de trabajo. El otro coste es la ida y vuelta. Diseño propone algo que por dentro cuesta semanas y nadie lo dice hasta la revisión. Ingeniería resuelve por su cuenta un caso raro de una forma que rompe una regla que sí estaba acordada. ## Cómo lo hacemos aquí Quien diseña una pantalla construye su componente, dentro del mismo equipo y sobre el mismo material desde el primer día. Cómo funciona el proceso por dentro y cómo lo vive quien lo usa se definen a la vez, en un solo documento, no en dos ficheros que se sincronizan después y acaban divergiendo. De ahí salen dos condiciones que van en el contrato. Una pantalla no se aprueba por correo sobre imágenes: se aprueba con el cliente haciendo clic en una maqueta navegable. Y las pantallas se entregan construidas, en el mismo repositorio que el resto, así que lo que se aprueba en la maqueta es lo que se despliega. Eso explica por qué el [wireframe](/glosario/wireframe) aquí dura días y no semanas. No hace falta perfeccionar un dibujo cuando la aprobación de verdad ocurre sobre algo que se puede tocar. ## Cuándo montar un sistema de diseño, y cuándo no Depende del número de personas que van a tomar decisiones sobre la interfaz sin hablar entre ellas. Con una persona diseñando y otra construyendo, un sistema formal es sobrecoste. Lo que hace falta es un puñado de decisiones escritas donde ambas las vean. En cuanto hay dos equipos trabajando en paralelo sobre el mismo producto, el sistema se paga solo: el coste de que cada equipo invente su versión sube por encima del de mantenerlo. Y si el producto tiene varios años y nadie sabe cuántos estilos de botón hay dentro, lo primero es contar lo que ya existe. Ese recuento es lo que cambia la conversación: la lista escrita de los estilos que ya existen ordena la discusión mejor que un argumento sobre consistencia. ## Qué preguntar antes de encargarlo Pregunta quién va a poder cambiar una decisión del sistema, y qué tiene que hacer para cambiarla. Si no hay respuesta, lo que te van a entregar es un catálogo sin mantenimiento. Pregunta qué pasa cuando un equipo necesita algo que no está. Ese caso aparece pronto. Y pregunta si lo entregado incluye los estados incómodos: error, vacío, sin permisos, carga lenta. Un sistema que solo cubre el camino feliz deja fuera un presupuesto que aparece después. Separar qué parte de una interfaz descosida es de diseño y qué parte viene de cómo está construido por dentro es de las primeras cosas que hace [un diagnóstico](/diagnostico). Cómo trabajamos está en [diseño de producto](/marca-y-producto). --- # Integrar dos sistemas que no se conocen > Una integración se juega en los acuerdos, no en el código: quién manda sobre cada dato y qué se hace cuando el otro lado no contesta. Publicado: 2026-09-08 Autor: carlos Temas: integraciones, arquitectura --- ## Los tres acuerdos que van antes del código Integrar dos sistemas es acordar por escrito qué datos viajan, quién manda sobre cada uno y qué ocurre cuando el otro lado no contesta. Escribir el código que hace la llamada es la parte pequeña, y casi nunca es la que se rompe seis meses después. **El contrato.** Qué campos se mandan, con qué nombre y qué tipo, qué se devuelve cuando sale bien y qué se devuelve cuando sale mal. Eso es lo que define una [API](/glosario/api). Da igual si el otro lado la publica documentada o si es un sistema interno antiguo al que hay que preguntarle probando: el contrato existe siempre. La diferencia es si está escrito o si vive en la cabeza de alguien. **Quién es dueño del dato.** Por cada cosa que viaja hay que decidir cuál de los dos sistemas la escribe y cuál solo la lee. Un cliente puede cambiar su correo en dos sitios; si los dos lo escriben, tarde o temprano habrá dos correos distintos y ninguna regla para elegir. Lo decidimos por campo y no por entidad: el precio lo manda el catálogo y el estado del pedido lo manda el sistema de cobro. Va escrito en una tabla que el cliente puede leer. **Qué pasa cuando uno cae o cambia.** El otro sistema se caerá alguna vez, y puede cambiar un campo sin avisarte. La pregunta que hay que responder antes de empezar es qué debe ver el usuario mientras tanto, y si la operación puede esperar o tiene que rechazarse en ese momento. ## Lo que se rompe siempre | Qué se rompe | Cómo se manifiesta | Qué hay que decidir antes | |---|---|---| | Reintentos | Falla la red a mitad, el sistema lo vuelve a intentar y la operación se ejecuta dos veces | Cada operación lleva una clave propia y el receptor la ignora si ya la vio | | Duplicados | El mismo cliente entra dos veces con el correo escrito distinto | Qué campo identifica de verdad a una entidad, y qué se hace cuando no coincide | | Fechas | Una publicación programada sale con horas de diferencia | En qué zona horaria se guarda, y quién convierte: el que manda o el que recibe | | Límites de peticiones | Funciona en pruebas con diez registros y se corta con dos mil | Cuántas llamadas por minuto admite el otro lado y qué se hace al llegar al tope | | Credenciales | Deja de funcionar sin aviso y nadie sabe por qué | Dónde se guardan, cuándo caducan y quién recibe el aviso antes de que caduquen | Los reintentos merecen un párrafo aparte porque están detrás de buena parte de lo que luego se llama «datos corruptos». Un sistema que reintenta se comporta bien. El problema aparece cuando el receptor no sabe distinguir el segundo intento del primero, y cobra dos veces, o crea dos pedidos. La solución cuesta poco al principio y cuesta un proyecto si hay que meterla cuando ya hay duplicados en producción. Con los [webhooks](/glosario/webhook) pasa lo mismo y peor, porque ahí no controlas tú cuándo llega el mensaje. Pueden llegar desordenados, repetidos o con retraso, cuando el pedido ya se dio por perdido. Un receptor que no guarda qué eventos ha procesado acaba duplicando trabajo o perdiéndolo. ## Los nombres de los campos son parte de la integración Quien configura una integración no lee tu documentación interna. Lee los nombres de los campos, el orden en que aparecen y el mensaje que sale cuando algo no se puede hacer. Si esos tres se deciden al final, acabas enseñando los nombres internos del otro sistema y el error literal que devolvió su servidor. Los estados intermedios son el otro sitio donde se nota. Una integración que responde al momento y otra que tarda son el mismo código y dos productos distintos: en la segunda hay que decidir si el usuario espera, si se va y recibe un aviso, o si el trabajo queda en una cola visible. ## Zernio: la integración vive en el flujo del cliente [Zernio](/casos/zernio) es una plataforma desde la que las marcas programan lo que publican en redes. Sus clientes ya automatizaban buena parte de su trabajo con flujos de n8n, y el último paso, programar la publicación, seguían haciéndolo a mano en otra herramienta. Construimos el nodo de n8n con el que un cliente de Zernio crea y programa publicaciones desde su propio flujo, con sus credenciales. Está publicado en el catálogo público de n8n y el código es abierto, con lo que cualquiera puede comprobar que existe sin pedirnos permiso. La decisión del encargo fue que la integración viviera donde ya trabaja el cliente, en lugar de pedirle que entrara en la herramienta de Zernio. Y que las credenciales sean del cliente y no pasen por nosotros, que es lo razonable cuando la integración la instala un tercero en su propia máquina. ## Por dónde empezar si tienes una integración pendiente Antes de pedir presupuesto, escribe dos cosas en un folio. La lista de datos que van a viajar y quién manda sobre cada uno. Y qué tiene que ver el usuario cuando el otro sistema no responde. Con esas dos respuestas, la conversación con cualquier proveedor pasa a ser sobre qué hace el sistema en el peor día. Si no están claras y el sistema ya está en producción con clientes dentro, ese es el trabajo del [diagnóstico](/diagnostico). --- # Un sistema legacy es código sin dueño > La edad del código importa poco. Un sistema es legacy cuando nadie puede explicar por qué está así ni cambiarlo sin miedo. Publicado: 2026-09-08 Autor: carlos Temas: legacy, arquitectura --- ## Qué convierte un sistema en legacy Un sistema es legacy cuando ya no hay nadie que responda de él. La edad del código apenas cuenta: hay sistemas con muchos años encima que se tocan sin sobresaltos, y aplicaciones del año pasado que ya da miedo mirar. La diferencia está en si queda alguien que sepa contestar, delante de un cambio, por qué el sistema está hecho así y qué se rompe al tocarlo. Y si hay manera de enterarse de que se ha roto algo sin esperar a que llame un cliente. Cuando esas respuestas viven solo en la memoria de una persona, el sistema depende de que esa persona siga disponible. El síntoma que buscamos es que haya partes que el equipo evita tocar y que esa decisión no la discuta nadie. ## Las cinco situaciones, contadas desde dentro **Hay una parte que nadie toca desde hace meses.** Suele ser la que calcula algo con dinero. El equipo ha aprendido a trabajar alrededor: se añaden funciones nuevas por fuera, se copian datos a otra tabla, se hace un ajuste manual al cierre de mes. Cada rodeo añade un sitio más donde el mismo número puede salir distinto. **Todo depende de una persona o de un proveedor.** El proveedor contesta, hace el cambio y factura. El problema aparece el día que quieres pedir presupuesto a otro: nadie más tiene acceso al servidor, o el repositorio está en la cuenta de la agencia. Ahí el precio deja de negociarse. **Alguien de fuera va a mirar por dentro.** Un cliente grande manda su cuestionario de seguridad, o entra un inversor, o toca una auditoría. Piden cosas que existen o no existen, sin término medio: quién tiene acceso a qué, qué se guarda de los usuarios, qué pasa si se pierde la base de datos. Preparar eso con dos semanas de aviso sale mal. **Hay muchos más clientes que cuando se hizo.** Ningún proceso se volvió manual por decisión: algo empezó a fallar de vez en cuando y se montó una hoja de cálculo para repasarlo. Con el tiempo esa hoja es parte del sistema y no está documentada en ninguna parte. **Quien lo escribió ya no está.** El código funciona, hace lo que tiene que hacer, y nadie sabe por qué toma buena parte de sus decisiones. Cada cambio empieza por averiguar por qué está así. ## Lo primero: acceso, lectura y reproducir el fallo El trabajo empieza consiguiendo acceso real, no una demo. Repositorio, base de datos de un entorno que no sea el de producción, registros de errores, y la lista de servicios externos con los que habla el sistema. Cuando conseguir eso cuesta más de una semana, ya sabemos algo del proyecto. Después se lee, y se lee por donde el negocio duele. Si el problema es la facturación, se sigue el camino de una factura desde que alguien pulsa el botón hasta que el cliente la recibe, anotando cada sitio donde el sistema toma una decisión que nadie ha documentado. Lo tercero es reproducir el fallo. Mientras un error solo pasa en producción y de vez en cuando, no se puede arreglar con criterio. Buena parte de las primeras semanas se va en conseguir que ocurra a voluntad en una máquina que no es la del cliente. Es también cuando aparecen los errores que nadie había reportado, porque el equipo había dejado de contarlos. Operamos [BeeL](/casos/beel), nuestra plataforma de facturación, así que los fallos raros de un sistema en producción los recibimos nosotros. ## Por qué reescribir de cero casi nunca es la respuesta El sistema que quieres tirar contiene años de reglas de negocio que nadie escribió en ningún sitio. La única copia de esas reglas es el código que quieres borrar. Mientras se escribe el sistema nuevo, el viejo tiene que seguir funcionando y recibiendo cambios. Durante meses hay dos sistemas que mantener con el mismo equipo, y el viejo gana siempre, porque es el que tiene clientes dentro. A eso se suman las reglas raras, las que se pusieron porque un cliente concreto lo pidió hace años. Van apareciendo de una en una, cuando alguien se queja de que el sistema nuevo ha dejado de hacer algo. Y una reescritura no entrega nada hasta el final, así que a mitad de camino alguien se plantea cancelarla. La alternativa que usamos: se elige la parte que más duele, se rodea de comprobaciones que se ejecutan solas, se sustituye por dentro y se entrega. El sistema sigue en producción todo el tiempo. Si el presupuesto se acaba a mitad, lo entregado ya está funcionando. Reescribir de cero tiene sentido cuando lo que el negocio necesita ahora se parece poco a lo que el sistema hace. Si un [ERP](/glosario/erp) montado para gestionar almacén tiene que pasar a vender por internet, el problema deja de ser el código y la conversación es de producto. ## Cómo se recupera un dueño Un sistema deja de ser legacy cuando alguien que no lo ha escrito puede cambiarlo. Esa es la prueba, y se puede hacer en directo. Nuestra cuarta condición de entrega dice justo eso y va en el contrato. Antes de cerrar, una persona que no ha visto nunca el proyecto hace un cambio real que elige el cliente, con el repositorio y nada más. Tiene que poder encontrar la decisión que explica por qué está así, hacer el cambio sin preguntarle a nadie y saber por las pruebas si ha roto algo. Si no sale, falta documentación y se escribe antes de facturar el último hito. Eso cambia qué se entiende por documentación. Sirve lo que permite a un extraño hacer un cambio concreto: las decisiones escritas junto al código, con su fecha y lo que se descartó, y las reglas de negocio convertidas en comprobaciones que se ejecutan en cada cambio y se leen sin ser programador. Al equipo del cliente le sirve el mismo día que se va el proveedor, y le sirve con la herramienta que use cada uno para programar. Lo que un modelo necesita para tocar un sistema sin romperlo es lo mismo que necesita una persona nueva: encontrar el porqué y tener algo que le avise del error. ## Por dónde se empieza Si al leer las cinco situaciones has reconocido tu sistema en dos o más, lo que falta antes de decidir nada es un número: cuánto cuesta arreglarlo, qué se rompe primero, y qué pasa si no se hace este año. Para eso existe [el diagnóstico](/diagnostico). Si sale pequeño, lo decimos y no hay proyecto. --- # Vibe coding: qué pasa con el primer cliente > Las aplicaciones generadas con IA no se caen a la vez. Se rompen en un orden predecible, y casi siempre por sitios que nadie decidió. Publicado: 2026-09-08 Autor: carlos Temas: vibe coding, producción --- ## Qué pasa el primer día Nada. El primer cliente entra, usa la aplicación y funciona, porque hace exactamente lo que hacía cuando la probaste tú. Lo que cambia ese día es que ya hay alguien que no puede esperar a mañana. Las cosas empiezan a romperse a las pocas semanas. Se rompen porque hay decisiones que nadie tomó, ni tú ni el modelo, y que solo aparecen cuando hay dos personas dentro a la vez. Esto no va de si generar código con IA está bien o mal. Nosotros lo usamos todos los días. Va de qué falta cuando lo único que has pedido es que funcione. Si buscas la definición del término, está en [vibe coding](/glosario/vibe-coding). ## El orden en que se rompe Se rompe antes lo que solo falla con más de un usuario, y después lo que solo falla con dinero de por medio. Lo que falla con el tiempo tarda más, y lo último en aparecer es lo que solo se nota cuando alguien mira desde fuera. ### 1. La autenticación va para uno y no para muchos Con un usuario, cualquier cosa parece una sesión. Con varios aparecen las preguntas que no se hicieron: cuánto dura la sesión, cómo se expulsa a alguien que se ha ido de la empresa, qué ve un usuario si escribe en la barra de direcciones el identificador de otro. Ese último caso es habitual: la pantalla comprueba qué te enseña, pero la consulta a la base de datos no comprueba de quién son los datos. Con una sola cuenta es invisible. ### 2. Los datos se guardan dos veces El cliente pulsa dos veces porque la primera tardó. Se crean dos pedidos. Nadie decidió qué debía pasar ahí. La versión cara es cuando la duplicación no se ve: dos registros idénticos con identificadores distintos, que luego se suman en un informe y cuadran mal por una cifra que nadie sabe de dónde sale. ### 3. Los pagos cobran pero no registran El cobro se hace fuera, en la pasarela, y funciona. Lo que falta es lo que pasa después: la pasarela avisa de que ha cobrado y ese aviso llega una vez, o llega tres veces, o llega cuando la aplicación estaba reiniciándose. Sin nada que reconcilie las dos partes, la cuenta de la pasarela y la de tu base de datos se separan despacio. Se descubre cuadrando el mes, cuando ya hay que devolverle dinero a alguien. ### 4. El correo sale de una cuenta personal Funciona hasta que el volumen sube y todos los envíos salen de la misma dirección personal. A partir de ahí, parte de los avisos acaba en spam sin que nadie lo vea, porque no se comprueba si el correo se entregó. ### 5. Las claves están en el código Las contraseñas de la base de datos y las llaves de la pasarela de pago, escritas dentro de los ficheros. Aguanta mientras el repositorio sea privado y lo abras solo tú. Deja de aguantar el día que entra una persona nueva, o que el repositorio deja de ser privado. Entonces hay que cambiarlas todas, y como nadie sabe cuántos sitios las usan, cambiarlas rompe cosas. ### Y una sexta que llega más tarde Nadie sabe qué había ayer. No hay copias de seguridad, o las hay y nunca se ha restaurado ninguna. Se descubre el día que hace falta. ## Síntoma, causa y qué se hace | Síntoma | Causa | Qué se hace | |---|---|---| | Un cliente ve datos de otro | La consulta filtra en la pantalla, no en la base de datos | Se mueve la comprobación de permisos al acceso a datos y se prueba con dos cuentas | | Pedidos repetidos | Sin clave única ni control de reintentos | Clave única de negocio y operaciones que se pueden repetir sin duplicar | | La pasarela y tu base de datos no cuadran | El aviso de cobro se procesa una vez, o ninguna, o tres | Registro de cada aviso recibido, reintentos y un cuadre que se ejecuta solo | | El cliente dice que no le avisaste | Envío desde cuenta personal, sin registro de entregas | Dominio propio con su configuración de envío y registro de qué se entregó | | Hay que cambiar una clave y da miedo | Credenciales escritas en el código | Claves fuera del código, rotables, y un inventario de dónde se usa cada una | | Nadie sabe qué había ayer | Sin copias de seguridad probadas | Copias automáticas y una restauración hecha delante del cliente | ## Por qué no es culpa de quien lo montó Porque nadie le pidió eso. Lo que pediste fue una aplicación que hiciera algo, y la tienes. Ninguna de las seis cosas de arriba aparece en la conversación con un modelo salvo que las nombres tú, y para nombrarlas hay que haberlas sufrido antes. La primera versión de un producto es hoy la parte barata. Lo caro sigue siendo el segundo año, cuando hay clientes que ya no se pueden perder. ## Qué hacemos con eso Leerlo primero. Antes de decir si sirve o no sirve, abrimos lo que hay: la aplicación, la base de datos, lo que alguien está arreglando a mano cada semana y lo que ya se rompió una vez. Casi nunca hay que tirarlo. Lo que montaste tiene dentro las decisiones reales de tu negocio, y eso no está escrito en ningún otro sitio. Qué se conserva y qué se cambia está contado, con el orden en que se hace, en [de prototipo a producción](/de-prototipo-a-produccion). Y si todavía no tienes clientes, quédate donde estás. ## Por dónde empezar mañana Coge tu aplicación y prueba las tres primeras a mano. Entra con dos cuentas distintas y cambia el identificador en la dirección. Pulsa dos veces el botón de pagar. Busca las claves con un buscador de texto en el repositorio. Si alguna te da un resultado que no te gusta, ya sabes por dónde va la conversación. Si prefieres que lo miremos con el sistema delante, eso es [un diagnóstico](/diagnostico). --- # Qué es una API > Interfaz que un sistema publica para que otros le pidan datos u operaciones. Lo caro de integrar dos sistemas es ponerlos de acuerdo sobre qué significa cada dato. Término: API Publicado: 2026-09-08 --- Una API es el conjunto de operaciones que un programa publica para que otros programas le pidan datos o le encarguen acciones, sin saber nada de cómo está hecho por dentro. Tu tienda pregunta al sistema de almacén cuántas unidades quedan. El almacén responde. La sigla es de *application programming interface*. La palabra que importa es interfaz: un contrato sobre qué se puede pedir, con qué datos y qué se devuelve. ## Para qué sirve Para que dos sistemas que no se conocen trabajen juntos. Ese es el caso normal en una empresa que lleva años funcionando: un [ERP](/glosario/erp) instalado hace años, un [CRM](/glosario/crm) que eligió el equipo comercial, una tienda montada aparte y una hoja de cálculo que alguien mantiene a mano. La API es la forma de conectarlos sin reescribir ninguno. También sirve para vender. Si tu producto expone una API, tus clientes lo integran en lo que ya usan. Nuestra plataforma de facturación [BeeL](https://beel.es) existe casi entera detrás de una API por esa razón, y su documentación es pública en [docs.beel.es](https://docs.beel.es). ## Lo que se rompe Lo que se rompe es el acuerdo sobre qué es un cliente. En el ERP tiene NIF obligatorio; en la tienda puede ser un correo electrónico sin más. Alguien tiene que decidir qué pasa con los pedidos de quien nunca dio su NIF, y esa decisión no la resuelve ningún conector. Después vienen tres cosas que aparecen en producción y no suelen estar en la documentación. - El otro sistema se cae, y hay que decidir si reintentas, si encolas o si pierdes el dato. - El mismo pedido llega dos veces, y si tu API no es idempotente acabas facturando dos veces. - Hay límites de peticiones por minuto, y el día que migras el histórico los alcanzas. Antes de escribir un conector, escribimos qué significa cada campo en cada sistema y quién manda cuando discrepan. Cómo se hace está en [integrar dos sistemas que no se conocen](/notas/integrar-dos-sistemas), ese trabajo entra en [software a medida](/software-a-medida) y la forma barata de empezar es un [diagnóstico](/diagnostico). Cuando la integración tiene que enterarse de algo en el momento en que ocurre, la pieza que falta es un [webhook](/glosario/webhook). --- # Qué es Claude Code > Herramienta agéntica de Anthropic que trabaja sobre el repositorio entero desde el terminal o el editor. La usamos a diario. No sustituye a quien responde del sistema. Término: Claude Code Publicado: 2026-09-08 --- Claude Code es la herramienta de programación con IA de Anthropic: lee tu código, edita ficheros, ejecuta comandos y se conecta con tus herramientas de desarrollo. Su [documentación oficial](https://code.claude.com/docs/en/overview) la define como una herramienta agéntica disponible en el terminal, en el editor, en una aplicación de escritorio y en el navegador. La diferencia con un autocompletado es el alcance: recibe un encargo en lenguaje normal, decide qué ficheros tocar, los cambia y comprueba el resultado. ## Cómo la usamos La usamos todos los días, con las reglas del estudio escritas en un fichero que la herramienta lee al empezar cada sesión. Se conecta a herramientas externas mediante MCP, un protocolo abierto. Nosotros publicamos uno: [beel-mcp](https://github.com/beel-es/beel-mcp) deja que un agente emita facturas contra BeeL aplicando las mismas reglas fiscales que la interfaz, con el código a la vista. Donde más ahorra es al entrar en código ajeno: le describes un síntoma y recorre el repositorio hasta el sitio donde se origina. Ese recorrido es buena parte del trabajo en [un sistema que escribió alguien que ya no está](/notas/sistema-legacy-codigo-sin-dueno). ## Qué no cubre No cubre a nadie que responda del sistema cuando algo falla. Un agente hace lo que le pides sobre el código que le enseñas. No sabe qué clientes dependen de una parte concreta del sistema, qué procesos no se pueden retrasar ni si un cambio en la numeración de facturas es legal en España. Esa información está en la cabeza de alguien del equipo o escrita junto al código. Y no cubre la comprobación. Lo que mueve dinero —cobros, facturas, descuentos— se prueba solo en cada cambio, y esa es una de las condiciones que llevamos al contrato. Un agente escribe esas pruebas; decidir cuáles hacen falta sigue siendo trabajo de quien conoce el negocio. Tampoco cubre la decisión de arquitectura. Si la pregunta está mal planteada, la respuesta será coherente y equivocada, y eso cuesta más de detectar que un error obvio. Sobre qué se rompe en un sistema construido así hemos escrito [qué pasa con el primer cliente](/notas/vibe-coding-primer-cliente). Si has llegado hasta aquí con algo construido así y quieres que aguante, eso es [llevar un prototipo a producción](/de-prototipo-a-produccion), y empieza por un [diagnóstico](/diagnostico). --- # Qué es la conciliación bancaria > Casar el extracto del banco con lo que tu sistema dice que debería haber pasado. Se rompe por los movimientos raros y se paga en horas de la persona más cara de administración. Término: conciliación bancaria Publicado: 2026-09-08 --- La conciliación bancaria es el trabajo de casar cada movimiento del extracto del banco con la operación de tu negocio que lo produjo. Este ingreso corresponde a una factura concreta; este cargo, a la comisión del mes. Cuando todo cuadra, el saldo del banco y el de tu contabilidad dicen lo mismo. En una empresa pequeña lo hace una persona a mano. En cuanto entran cientos de movimientos al mes, deja de poder hacerse así. ## Por qué se rompe Por los movimientos raros, no por los normales. Un cliente paga tres facturas en una sola transferencia. Otro paga de menos porque se descontó una nota de abono que nadie registró. La pasarela ingresa el neto de la semana en un único apunte, con las comisiones ya restadas. Un recibo domiciliado vuelve semanas después: con los plazos que publica el Banco de España puede ser hasta trece meses más tarde si el cargo no estaba autorizado, y ese detalle está en la entrada de [SEPA](/glosario/sepa). Cada caso es fácil de resolver una vez. Lo que rompe el sistema es que aparecen mezclados y ninguno se automatiza del todo sin decidir antes qué manda cuando el importe no coincide. ## Qué cuesta arreglarlo El síntoma visible es el cierre que se alarga. El invisible es que el número de caja deja de ser fiable, así que las decisiones se toman sin él. Un [dashboard](/glosario/dashboard) construido sobre datos que no conciliaron pinta números que no se pueden defender. Y hay un coste que solo aparece cuando llega alguien de fuera. Una due diligence, una auditoría o un inversor van a pedir que los ingresos declarados cuadren con el banco. Reconstruir dos años hacia atrás cuesta mucho más que haberlo hecho bien desde el principio. ## Cómo lo abordamos No empezamos por el algoritmo de casado, sino por escribir qué es un cobro en tu negocio, qué estados puede tener y quién decide cuando el importe baila. Después, el sistema tiene que ser capaz de explicar cada emparejamiento: si no puedes ver por qué casó dos apuntes, no puedes corregirlo. Lo hemos hecho del lado de la facturación en [BeeL](/casos/beel), donde la numeración no admite huecos y cada rectificativa tiene que cuadrar con lo que ya se declaró. Ese trabajo es [software a medida](/software-a-medida) y el primer paso es un [diagnóstico](/diagnostico). --- # Qué es un CRM > El sistema donde vive la relación con cada cliente. Casi siempre se compra; el problema suele estar en lo que hay alrededor. Término: CRM Publicado: 2026-09-08 --- Un CRM (gestión de la relación con clientes) es el sistema donde una empresa guarda sus contactos, sus oportunidades de venta en curso y el histórico de cada cliente. Sirve para que esa información no viva en la cabeza ni en el correo de una sola persona. Un CRM se compra. La funcionalidad es común a casi cualquier empresa y la oferta de producto lleva años madurando. Si alguien te propone construir uno desde cero, pídele que justifique qué parte de tu relación con los clientes es rara de verdad. ## Cuándo un CRM estándar no cabe No cabe cuando lo que vendes obliga a un proceso que el producto no sabe representar. Un contrato con hitos que dependen de una obra. Un precio que se calcula con variables propias. Una relación donde el cliente que firma no es el que consume. Ahí el CRM acaba lleno de campos libres, y un campo libre no se puede comprobar ni sumar. La señal es gente compensando a mano: comerciales que llevan su propia hoja porque el sistema no refleja su trabajo, y una dirección que pide informes que no cuadran con lo que hay dentro. Si el CRM está desactualizado, casi siempre es porque registrar la verdad cuesta más de lo que devuelve. ## Dónde entramos nosotros En los bordes. Una oportunidad ganada debería crear un cliente en facturación, con el mismo identificador fiscal y sin teclearlo dos veces. Cuando ese puente falla aparecen dos fichas del mismo cliente, un cobro que no encuentra su venta y un informe que no cuadra con contabilidad. Ese puente tiene sus reglas: qué sistema manda sobre cada dato, qué pasa cuando uno de los dos no responde, cómo se evita duplicar cuando un mensaje llega dos veces. Está contado en [integrar dos sistemas que no se conocen](/notas/integrar-dos-sistemas), y la pieza técnica es la [API](/glosario/api). Cuando construimos algo alrededor de un CRM es eso: la conexión con facturación o con cobros, y la pieza propia que calcula lo que el producto estándar no calcula. Lo cubre nuestro trabajo de [software a medida](/software-a-medida). Si dudas entre cambiar de CRM, implantar uno o dejarlo y arreglar lo que lo rodea, un [diagnóstico](/diagnostico) sirve para elegir con datos. --- # Qué es Cursor > Editor con IA que combina autocompletado predictivo y modo agente sobre todo el proyecto. Lo usamos a diario. Lo que no da es criterio sobre un sistema en producción. Término: Cursor Publicado: 2026-09-08 --- Cursor es un editor de código con IA integrada que sugiere, edita y trabaja como agente sobre tu repositorio. Su [documentación oficial](https://cursor.com/docs) lo presenta como un agente de programación para entender repositorios, construir funcionalidades, depurar errores y revisar cambios antes de fusionarlos. Se usa como cualquier editor. La diferencia está en dos sitios: lo que pasa mientras escribes y lo que pasa cuando le encargas algo entero. ## Las dos formas de usarlo Mientras escribes, la función que la documentación llama [Tab](https://cursor.com/docs/tab) sugiere código a partir de tus últimas ediciones y de los errores del linter, y predice dónde vas a editar a continuación, incluso en otro fichero. Cuando le encargas algo entero, el modo agente acota el cambio, lo planifica, toca los ficheros y ejecuta comprobaciones. En el estudio lo usamos así: le damos el contexto por escrito, revisamos el plan y solo entonces le dejamos tocar nada. ## Qué no hace No sabe qué parte de tu sistema no se puede parar. Un agente ve el repositorio. No ve los compromisos escritos con tus clientes, ni quién llama a cada integración desde fuera, ni por qué un cálculo está hecho de una forma concreta. Cuando el sistema está en producción y hay dinero pasando por él, esas cosas son el trabajo. Tampoco resuelve el problema de arriba: si la decisión de arquitectura está mal tomada, la herramienta la ejecutará igual, y el error se hereda en todo lo que venga después. ## Qué pedimos antes de dejarle tocar producción Que exista una comprobación automática de lo que mueve dinero, que el cambio se pueda deshacer y que quede escrito por qué se hizo. Con eso, un agente acelera el trabajo aburrido. Sin eso, acelera también el error. Es la misma condición que va en nuestros contratos de entrega: cobros, facturas y descuentos se comprueban solos en cada cambio. ## Dónde encaja Cursor es una herramienta que usamos, igual que [Claude Code](/glosario/claude-code). Lo que se contrata es quién responde del sistema cuando algo falla. Si has montado algo con una herramienta visual o con un agente y ya no aguanta, la frontera está en [cuándo dejar el no-code](/notas/cuando-dejar-el-no-code). El trabajo se llama [llevar un prototipo a producción](/de-prototipo-a-produccion) y empieza por un [diagnóstico](/diagnostico). --- # Qué es un dashboard > Reúne datos para que alguien decida. Sin una decisión detrás, es un adorno caro de mantener. Término: dashboard Publicado: 2026-09-08 --- Un dashboard es una pantalla que reúne los datos actualizados de uno o varios sistemas, para que una persona concreta tome una decisión concreta. Sin una decisión detrás es un adorno caro de mantener. La pregunta que hacemos antes de dibujar nada es qué vas a hacer distinto al mirarlo. Si la respuesta es «tener visibilidad», lo que hay que construir es un informe mensual que llega por correo. La prueba es fácil: coge cada número de la pantalla y di en voz alta qué harías si subiera de golpe. Los que no tienen respuesta no van en el panel. ## Cuándo importa Importa cuando alguien está tomando esa decisión hoy a mano, juntando datos de dos sitios en una hoja de cálculo cada lunes. También cuando la decisión es urgente y el dato llega tarde: un cobro que falla y se descubre a fin de mes es un problema distinto que uno que se ve el mismo día. No importa cuando la decisión es anual, ni cuando la toma alguien que ya conoce los datos de memoria. ## Lo que se subestima El coste está debajo de la pantalla. Los números salen de sitios que no fueron pensados para consultarse así, y cada uno tiene su propia idea de qué es un cliente y de cuándo cuenta una venta. Dos sistemas que dan cifras distintas para la misma pregunta son lo normal. Ahí se va el presupuesto: en acordar definiciones y en construir la vía por la que llegan los datos. Sobre cómo se reparte ese coste está la nota [cuánto cuesta desarrollar una aplicación](/notas/cuanto-cuesta-desarrollar-una-aplicacion). El segundo coste llega después. Un panel que muestra un número equivocado hace más daño que no tener panel, porque las decisiones ya se han tomado con él delante. Por eso en lo que mueve dinero ponemos comprobaciones automáticas sobre el propio dato, y es una de las condiciones que llevamos al contrato. ## Cómo lo abordamos En un proyecto de [software a medida](/software-a-medida) un panel empieza por la lista de decisiones y termina en la pantalla. Suele salir con menos gráficos de los que pedía el enunciado inicial y con más avisos, porque nadie garantiza que alguien mire la pantalla a tiempo. Si el problema es que los números de dos sistemas no cuadran, el punto de partida está más abajo: se parece a [conciliación bancaria](/glosario/conciliacion-bancaria). Un [diagnóstico](/diagnostico) separa qué parte es una pantalla y qué parte es un problema de datos. --- # Qué es un ERP > El sistema central de gestión de una empresa. La decisión real es comprarlo, y qué parte no cabe dentro. Término: ERP Publicado: 2026-09-08 --- Un ERP (sistema de planificación de recursos empresariales) es el software donde una empresa lleva compras, inventario, producción, facturación y contabilidad sobre una misma base de datos. Todos esos procesos comparten el mismo maestro de artículos y de proveedores. La pregunta útil es si el tuyo tiene que ser estándar. En la mayoría de los casos la respuesta es que sí, y lo decimos aunque nos reste proyectos: existen categorías consolidadas de producto, con décadas encima y con actualizaciones que siguen los cambios normativos. Un ERP estándar sobra cuando la empresa es pequeña y su operativa es común. Cinco personas facturando servicios no necesitan módulos de producción ni un proyecto de implantación. ## Cuándo un ERP estándar no cabe No cabe cuando lo que te hace ganar dinero es la parte que el producto trata como excepción. Un fabricante que decide sus lotes con un criterio propio. Un cálculo de coste que depende de variables que el módulo no contempla. Ahí aparece el patrón que buscamos: gente compensando el sistema a mano, con hojas de cálculo paralelas que se han vuelto la fuente de verdad. Esa señal es medible. Cuenta cuántas personas mueven datos cada semana entre el ERP y una hoja, y cuántas decisiones se toman mirando la hoja. Si la hoja manda, tienes dos sistemas de gestión y solo uno tiene soporte. Hay un segundo caso: el desarrollo que alguien hizo dentro del ERP hace años y que ya no entiende nadie. Un módulo a medida sin documentación dentro de un producto estándar bloquea las actualizaciones. Escribimos sobre eso en [un sistema legacy es código sin dueño](/notas/sistema-legacy-codigo-sin-dueno). ## Dónde se pone la frontera Lo que hacemos es sacar fuera la pieza que te diferencia y construirla como software propio conectado al ERP. Dentro se queda lo común: contabilidad, impuestos y obligaciones legales. Construir un motor de asientos contables propio casi nunca sale a cuenta. Esa frontera se dibuja con datos: qué dato es maestro en cada lado, en qué momento viaja y qué pasa cuando el ERP no está disponible. Es la parte del trabajo de [software a medida](/software-a-medida) donde se decide si el resultado será mantenible. El lado fiscal lo conocemos desde dentro, porque operamos [BeeL](/casos/beel), nuestra plataforma de facturación. Si dudas entre implantar, sustituir o rodear el ERP que ya tienes, un [diagnóstico](/diagnostico) pone esa frontera por escrito. Y si tu duda es más de clientes que de operaciones, sigue por [CRM](/glosario/crm). --- # Qué es un MVP > La versión mínima que un cliente puede usar en serio, con alguien que responde cuando falla. Término: MVP Publicado: 2026-09-08 --- Un MVP (producto mínimo viable) es la versión más pequeña de un producto que un cliente real puede usar para resolver su problema, y de la que se aprende algo que no se sabía antes de construirla. Buena parte de lo que se llama MVP es una demo. Se nota en una pregunta: ¿quién ha decidido qué pasa cuando falla? Si nadie sabe qué ocurre con un pago a medias o con un correo que no sale, lo que hay es una demostración. Puede estar bien hecha y ser suficiente para enseñarla en una reunión. La diferencia está en el borde. Un MVP tiene decidido qué se guarda, qué se pierde, quién se entera del error y en cuánto tiempo. Una demo cubre solo el camino en el que todo sale bien. ## Cuándo importa la distinción Importa el día que le das el acceso al primer cliente al que no conoces. En nuestros proyectos ese día se prepara antes: se elige qué parte se comprueba sola y qué parte se mira a mano. La regla que llevamos al contrato es que lo que mueve dinero se comprueba solo. Cobros, facturas y saldos no se validan mirando una pantalla, porque no siempre hay alguien mirando la pantalla. Lo segundo que importa es el coste de lo que viene después. Un MVP construido para enseñarlo suele reescribirse entero cuando llega el uso; uno construido para usarse crece por partes. La diferencia se paga en la segunda fase. ## Lo mínimo no es lo barato Mínimo se refiere al alcance, no a la calidad de lo que entra en ese alcance. Un MVP con dos pantallas y una integración puede estar bien construido. Uno con veinte pantallas y ninguna comprobación automática está mal construido, aunque haya costado más. Cuando alguien nos pide un MVP, la primera conversación va sobre qué se queda fuera: el panel de administración, el segundo idioma, los informes. Si esa lista no existe, el proyecto no tiene alcance. ## Qué hacemos y qué no Una idea sin clientes necesita una primera versión rápida y barata, y ese encargo queda fuera de lo que hacemos. Entramos cuando ya hay gente usando algo y cada cambio cuesta más que el anterior: eso es [software a medida](/software-a-medida). Si dudas de si lo tuyo es un MVP o una demo, y de qué costaría convertirlo, [pide un diagnóstico](/diagnostico). Sobre cómo se forma el precio de una primera versión está la nota [cuánto cuesta desarrollar una aplicación](/notas/cuanto-cuesta-desarrollar-una-aplicacion), y si todavía no lo usa nadie, la frontera está en [prototipo](/glosario/prototipo). --- # Qué es el onboarding de un producto > El tramo entre la decisión de usar tu producto y el primer resultado real. Casi nunca se cae por las pantallas: se cae por los datos que pides y por las esperas que no explicas. Término: onboarding Publicado: 2026-09-09 --- El onboarding es el recorrido que hace una persona entre que decide usar tu producto y el momento en que consigue por primera vez lo que venía a hacer. En un producto de gestión eso no es «ver el panel»: es emitir la primera factura, importar el primer catálogo, cerrar el primer pedido. Por eso el alta y el onboarding no son lo mismo. El alta acaba cuando existe una cuenta. El onboarding acaba cuando el producto ha servido para algo, y entre esos dos puntos es donde se pierde la gente que ya había decidido pagarte. ## Dónde se cae de verdad Casi nunca en el diseño de las pantallas. Se cae en tres sitios más aburridos. **En los datos que pides.** Cada campo obligatorio es una pregunta que alguien tiene que ir a buscar a otro sitio. Un número de cuenta, un CIF, un dato que está en el departamento de al lado. Quien se levanta a buscarlo muchas veces no vuelve. **En las esperas que no cuentas.** Una verificación que tarda, una importación que procesa en segundo plano, una comprobación manual que hace tu equipo. Nada de eso es un fallo, pero una pantalla que no dice qué está pasando ni cuánto falta se lee como un producto roto. **En los errores del final.** El sistema acepta seis pasos y rechaza el séptimo por un dato del primero. Ahí no se pierde a quien se equivoca: se pierde a quien ya no sabe qué corregir. ## Cómo se mide sin inventarse nada Con dos números que salen de tu propio sistema, no de un informe de sector. El primero: de cada cien cuentas creadas, cuántas llegan a hacer la acción que define el producto. El segundo: cuánto tiempo pasa entre lo uno y lo otro. Si además guardas en qué paso se quedó cada persona que no llegó, tienes la lista ordenada de qué arreglar, y deja de ser una discusión de opiniones. Ese instrumental es parte del trabajo. Un producto que no registra dónde se cae la gente obliga a rediseñar a ciegas, y un [dashboard](/glosario/dashboard) construido sobre esos datos incompletos pinta una curva que no se sostiene. ## Cómo lo abordamos Empezamos mirando a alguien darse de alta de verdad, con sus datos y sin ayuda, y anotando en qué momento se para. Después se decide qué se pregunta antes de entrar, qué se pregunta después y qué no se pregunta nunca porque el sistema lo puede deducir. La regla que aplicamos es que ningún dato se pide dos veces y ningún dato se pide antes de que haga falta. Un [wireframe](/glosario/wireframe) sirve para acordar ese orden en un rato, antes de construir nada. Esto es [marca y producto](/marca-y-producto) sobre un sistema que ya está funcionando, así que se hace sin parar la operación y sin pedirle a nadie que migre de golpe. Lo contamos con más detalle en [por qué tus clientes se caen en el alta](/notas/clientes-que-se-caen-en-el-alta), y si quieres el orden de los arreglos por escrito sobre tu propio producto, eso es un [diagnóstico](/diagnostico). --- # Qué es un prototipo > Sirve para decidir algo y luego se tira. En cuanto alguien depende de él, deja de ser un prototipo. Término: prototipo Publicado: 2026-09-08 --- Un prototipo es una versión de prueba de un producto, construida para responder una pregunta concreta y pensada para tirarse después. La frontera con lo demás no tiene que ver con el acabado: un prototipo no tiene a nadie que responda. Nadie está de guardia, nadie ha decidido cuánto puede estar caído, nadie recibe un aviso si deja de funcionar. Un prototipo con datos reales y con clientes entrando sigue siendo un prototipo mientras nadie haya decidido quién lo arregla y en cuánto tiempo cuando falla. El problema es el día en que deja de serlo sin que nadie lo declare. Empieza con un acceso dado a un cliente para que pruebe y termina con una operación entera funcionando sobre algo que se escribió para tirarse. ## Cuándo importa Importa cuando el prototipo empieza a guardar datos que no se pueden perder. Ahí cambia la naturaleza de lo que tienes, aunque el código sea el mismo. Un prototipo que guarda facturas emitidas ya no admite la respuesta «lo rehacemos si falla», porque hay una obligación detrás. Las herramientas de generación de código han hecho esta transición mucho más frecuente: se llega antes a algo que funciona, y funciona lo suficiente para enseñárselo a alguien que paga. Sobre ese momento va la nota [vibe coding y el primer cliente](/notas/vibe-coding-primer-cliente), y el término está en [vibe coding](/glosario/vibe-coding). ## Qué hay que decidir para dejar de tenerlo Cuatro preguntas, y ninguna es técnica del todo. Qué datos no se pueden perder. Qué parte mueve dinero y por tanto tiene que comprobarse sola. Quién se entera cuando algo falla, y por qué vía. Qué pasa si la persona que lo escribió no está disponible esa semana. Un prototipo puede tener las cuatro sin responder. Un sistema en producción no. Convertir lo uno en lo otro es [de prototipo a producción](/de-prototipo-a-produccion): decidir qué se conserva, qué se aísla y qué se sustituye, en ese orden. ## Un prototipo bien usado ahorra dinero Construir uno para responder una pregunta cara cuesta poco y evita decidir a ciegas. La condición es que la pregunta esté escrita antes de empezar y que haya una fecha para tirarlo. Nosotros los usamos así en la primera semana del [diagnóstico](/diagnostico), cuando hay una duda que no se resuelve discutiendo. Se monta algo pequeño, se mira el resultado y se descarta. Lo que queda es la decisión. --- # Qué es SaaS > Software por suscripción que mantiene otro. La decisión útil es cuándo deja de cubrir tu operativa. Término: SaaS Publicado: 2026-09-08 --- SaaS (software como servicio) es software al que accedes por internet y pagas por suscripción. Lo aloja y lo mantiene quien lo vende, así que tú no instalas nada ni actualizas nada. Nuestra posición sobre comprar o construir no es neutral: si existe un producto que hace lo que necesitas, cómpralo. Un producto consolidado cuesta menos y recibe más mantenimiento del que justifica un desarrollo propio. Decimos que no a proyectos por esta razón. El punto de ruptura tiene una forma reconocible. Tu operativa empieza a organizarse alrededor de las limitaciones de la herramienta, y hay gente cuyo trabajo consiste en compensarlas: exportar a una hoja, copiar entre dos pestañas, corregir a mano lo que el sistema entendió mal. ## Cuándo importa la decisión Importa cuando puedes contar las horas. Si dos personas dedican una mañana a la semana a arreglar lo que la herramienta no hace, eso es un coste anual con nombre, y se compara con el precio de construir esa pieza. Si nadie ha contado esas horas, la conversación es de opiniones. También importa cuando el dato que te diferencia vive fuera. Una empresa que se distingue por cómo calcula sus precios o por cómo prioriza sus pedidos tiene ahí su ventaja, y meterla en un producto genérico obliga a explicarla con campos libres, que no se pueden comprobar. Y hay un caso donde la respuesta es clara: cuando el proveedor no te deja sacar tus datos de forma razonable. Eso es un riesgo de continuidad. ## Lo que significa construir Sustituir una suscripción por software propio casi nunca quiere decir reemplazarla entera. Lo habitual es sacar la parte que duele, construirla bien y dejar el resto donde está, conectando ambos. Ese reparto es la mitad del trabajo en un proyecto de [software a medida](/software-a-medida). Sobre cuándo se llega a ese punto viniendo de herramientas sin código está la nota [cuándo dejar el no-code](/notas/cuando-dejar-el-no-code). Conocemos los dos lados. Operamos [BeeL](/casos/beel), nuestra plataforma de facturación por suscripción, donde cada cambio de normativa lo absorbe el proveedor y no el cliente: esa es la parte buena de comprar. Y construimos las piezas que un producto estándar no cubre. Si quieres poner esa duda en números antes de comprometer un año de licencias, para eso existe el [diagnóstico](/diagnostico). Y si el sistema del que hablas es de gestión interna, mira antes [ERP](/glosario/erp) y [CRM](/glosario/crm). --- # Qué es SEPA > Zona única de pagos en euros. Transferencia, adeudo directo e IBAN. Lo que cuesta dinero es lo que ocurre en tu sistema cuando un recibo se devuelve semanas después. Término: SEPA Publicado: 2026-09-08 --- SEPA es la zona única de pagos en euros: un espacio donde enviar y recibir euros funciona en las mismas condiciones sea la operación nacional o transfronteriza. El Banco de España lo describe así en su [ficha de la transferencia SEPA](https://clientebancario.bde.es/pcb/es/menu-horizontal/productosservici/serviciospago/traspasostransfe/guia-textual/tipos/Transferencia_SEPA.html) y sitúa dentro a los 27 estados de la UE más Islandia, Liechtenstein y Noruega. Antes de Caricalia, parte del equipo escribió código de infraestructura de pagos en producción en Banco Santander y en PagoNxt. ## Las tres piezas que vas a tocar **El IBAN.** Es el identificador de la cuenta y lo único que necesitas para mandar dinero a cualquier punto de la zona. Tiene dígitos de control, así que se puede validar en el formulario. Un IBAN mal tecleado que no se valida en el formulario acaba en una transferencia devuelta. **La transferencia SEPA.** Tú empujas el dinero. Según el Banco de España, en la ordinaria el importe llega el siguiente día hábil tras la recepción de los fondos por el banco receptor; en la inmediata, la cuenta del beneficiario se abona en un máximo de diez segundos, cualquier día del año. **El adeudo directo.** El acreedor tira del dinero de la cuenta del deudor con una autorización previa, el mandato. Es como cobra cualquier suscripción en España. ## Lo que rompe el sistema: la devolución Un recibo domiciliado se puede devolver, y el plazo depende de si estaba autorizado. El Banco de España lo publica en su [nota sobre devolución de recibos](https://clientebancario.bde.es/pcb/es/blog/devolucion-de-recibos-y-sus-consecuencias.html): ocho semanas cuando el cargo estaba previamente autorizado y trece meses cuando no lo estaba. Dentro de tu software eso significa que un cobro ya facturado y contabilizado puede revertirse meses después. Queda un ingreso que ya no existe, una factura emitida que no se puede borrar porque la numeración no admite huecos, y un cliente que sigue usando el servicio. Casi ningún sistema pensado solo para cobrar tiene respuesta a eso, y de ahí sale buena parte de los problemas de [conciliación bancaria](/glosario/conciliacion-bancaria). ## Qué hacemos nosotros Diseñamos el flujo al revés: primero qué pasa cuando el dinero vuelve, después cómo se cobra. La devolución deja de ser una incidencia y pasa a ser un estado más del cobro, con su factura rectificativa y su asiento. Cómo se sostiene eso con la AEAT delante está en [el caso de BeeL](/casos/beel). Si vendes por adeudo directo y tu sistema no sabe qué hacer con un impagado, eso es [software a medida](/software-a-medida) y empieza por un [diagnóstico](/diagnostico). --- # Qué es un TPV > Terminal de punto de venta: cobra, registra la venta y emite el documento. Lo que ha cambiado es que ese documento es una factura con obligaciones detrás. Término: TPV Publicado: 2026-09-08 --- Un TPV es el sistema con el que un comercio cobra una venta y la registra: terminal de punto de venta. En la caja de una tienda son el datáfono y el software que le dice cuánto cobrar. En un restaurante es también la comanda. En una web es la pasarela de pago. La parte de cobrar es la que se mira al comprarlo. La que da problemas es la otra: qué documento emite y qué pasa con él después. ## El ticket es una factura Lo que un TPV entrega al cliente es, casi siempre, una factura simplificada. El Reglamento de facturación permite expedirla cuando el importe no excede de 400 euros con IVA incluido, y el límite sube a 3.000 euros en operaciones como ventas al por menor, hostelería, transporte de personas, peluquería o aparcamiento ([artículo 4 del Real Decreto 1619/2012](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696)). Eso significa que tu TPV es un sistema de facturación, aunque nadie en la tienda lo llame así. Y a un sistema de facturación se le pide numeración correlativa sin huecos y la posibilidad de rectificar sin borrar nada. ## Y ahora habla con Hacienda La norma de sistemas informáticos de facturación obliga a que el software que emite facturas registre cada emisión de forma inalterable y encadenada. Verifactu es la modalidad en la que ese registro se envía a la AEAT, y un TPV que emite facturas simplificadas entra ahí. En la práctica esto rompe una costumbre extendida: dejar el ticket fuera del sistema contable y cuadrarlo a final de mes por el total de caja. Cuando cada documento queda registrado y encadenado, la caja ya no se cuadra por totales. Y aparece el segundo problema. El TPV liquida a través de la pasarela, que suele ingresar el neto de varios días en un solo apunte bancario. Cuadrar ese apunte con las ventas del período es el trabajo de la [conciliación bancaria](/glosario/conciliacion-bancaria), y con un TPV el volumen lo saca de lo que se puede hacer a mano. ## Dónde entramos nosotros No vendemos TPV. Trabajamos en lo que hay detrás: que lo que emite el punto de venta sea una factura válida, que quede registrada como exige la norma y que al final del mes cuadre con el banco. Lo conocemos desde dentro porque operamos [BeeL](/casos/beel), nuestra plataforma de facturación. Si tu punto de venta y tu facturación son dos sistemas que no se hablan, eso es [software a medida](/software-a-medida) y el primer paso es un [diagnóstico](/diagnostico). --- # Qué es Verifactu > El modo de facturar en el que cada factura se remite a la Agencia Tributaria al emitirse. Lo que cambia es lo que tu software tiene que garantizar sobre cada registro que emite. Término: Verifactu Publicado: 2026-09-09 --- Verifactu es el modo de funcionamiento en el que un sistema informático de facturación remite cada factura a la Agencia Tributaria en el mismo momento en que se expide. El nombre corto se refiere a los «sistemas de emisión de facturas verificables» que regula el Real Decreto 1007/2023. La norma tiene dos piezas. El [Real Decreto 1007/2023](https://www.boe.es/eli/es/rd/2023/12/05/1007) aprueba el reglamento que fija los requisitos de los sistemas y programas de facturación: integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros. La [Orden HAC/1177/2024](https://www.boe.es/eli/es/orden/2024/10/17/hac1177) desarrolla las especificaciones técnicas y funcionales: cómo es cada registro, cómo se encadena con el anterior y cómo se remite. Las fechas desde las que obliga a cada tipo de obligado tributario las fija el calendario de la propia norma, que se ha modificado después de su publicación: la referencia es el texto consolidado del BOE. ## Qué cambia dentro del software Lo que cambia no es el aspecto de la factura. Es lo que el programa tiene que poder demostrar sobre sí mismo. Cada registro de facturación se firma y se encadena con el anterior, de forma que borrar o retocar uno rompe la cadena y se nota. Anular una factura deja de ser un `DELETE`: se emite un registro de anulación que también se encadena y también se remite. Los huecos en la numeración dejan de ser un detalle de contabilidad y pasan a ser una diferencia entre lo que tú tienes y lo que la Agencia Tributaria ha recibido. Eso mueve la dificultad a sitios donde la mayoría de los sistemas no estaban preparados. Qué pasa cuando el envío falla y la factura ya se le ha entregado al cliente. Qué pasa cuando dos personas emiten a la vez desde dos dispositivos. Qué se hace con una rectificativa que corrige una factura de hace cuatro meses. Ninguna de esas tres se resuelve leyendo el reglamento: se resuelven decidiendo el comportamiento del sistema y dejándolo escrito. ## Lo que se nota en una empresa que ya factura Si facturas con un producto estándar y al día, esto lo resuelve tu proveedor y no tienes que hacer nada más que actualizar. El problema aparece cuando la facturación está dentro de tu propio sistema: un módulo del [ERP](/glosario/erp) que alguien escribió hace años, una integración que emite desde el panel de operaciones, un proceso que factura por lotes cada noche. Ahí la obligación no es de un proveedor: es tuya, y afecta a código que probablemente nadie ha tocado en mucho tiempo. La señal de que hay trabajo es sencilla de comprobar. Pregunta quién puede modificar una factura ya emitida en tu sistema y qué queda registrado cuando lo hace. Si la respuesta es «cualquiera con acceso a la base de datos» y «nada», ese es el tamaño del cambio. ## Lo que podemos decir nosotros Operamos [BeeL](/casos/beel), nuestra propia plataforma de facturación, bajo este sistema y en producción. No hemos leído el reglamento para escribir esta página: convivimos con él, con sus registros de anulación, con sus reenvíos y con las respuestas que devuelve la Agencia Tributaria cuando algo no cuadra. Por eso esos casos raros ya están resueltos en un sistema nuestro que está en producción. Cuando esa parte de un sistema hay que rehacerla, es trabajo de [software a medida](/software-a-medida) y empieza por un [diagnóstico](/diagnostico) que lee tu código y dice qué se conserva. --- # Qué es vibe coding > Programar por descripción, delegando el código en un modelo. Sirve para llegar a la primera versión y deja de aguantar cuando alguien depende de lo construido. Término: vibe coding Publicado: 2026-09-08 --- Vibe coding es construir software describiéndole a un modelo de IA lo que quieres, y aceptando el código que devuelve sin revisarlo línea a línea. El criterio de aceptación es ver si la pantalla hace lo que esperabas. En el estudio se trabaja así una parte del día: [Claude Code](/glosario/claude-code) y [Cursor](/glosario/cursor) forman parte del entorno de desarrollo habitual del equipo. ## Qué resuelve Resuelve el coste de la primera versión. Una idea que antes costaba semanas de trabajo caro ahora se prueba con mucho menos, y eso cambia quién puede llegar a tener algo funcionando: un responsable de operaciones, un fundador sin equipo técnico, un diseñador. También resuelve la exploración. Puedes probar cinco formas de resolver un flujo y tirar cuatro, cosa que antes no se hacía porque cada intento tenía un coste que había que justificar. ## En qué momento deja de aguantar El día que alguien que no eres tú depende de que aquello funcione. El código generado así suele ser correcto en el camino feliz. Lo que falta es lo otro: qué pasa cuando el pago se queda a medias, quién ve los datos de quién, qué ocurre si el mismo botón se pulsa dos veces. Un modelo no toma esas decisiones porque no se las has planteado, y tú no se las has planteado porque el flujo funcionaba. Los síntomas se repiten. Cada cambio nuevo rompe algo que ya estaba hecho. Nadie sabe explicar por qué existe un fichero. Hay dos sitios donde se calcula el mismo importe y dan resultados distintos. El momento exacto es fácil de reconocer: la primera factura, el primer cliente que llama enfadado o el primer dato que no se puede perder. Lo contamos en [la nota sobre el primer cliente](/notas/vibe-coding-primer-cliente). ## Qué se hace después Se decide qué se conserva. Las pantallas y el modelo de datos suelen valer. La capa donde pasa el dinero, los permisos y los procesos que corren solos hay que rehacerla con criterio. Ese trabajo se llama [llevar un prototipo a producción](/de-prototipo-a-produccion) y empieza por saber qué hay dentro: para eso existe el [diagnóstico](/diagnostico). Lo que se contrata en ese punto es que alguien responda del sistema cuando se cae, y sepa qué hacer con lo que ya está construido. --- # Qué es un webhook > Notificación que un sistema empuja a una URL tuya cuando ocurre un evento. El trabajo está en verificar la firma, deduplicar y responder a tiempo. Término: webhook Publicado: 2026-09-08 --- Un webhook es un aviso que un sistema envía por HTTP a una dirección tuya en cuanto ocurre algo, sin que tú tengas que preguntar. La pasarela cobra y avisa. La plataforma de facturación emite y avisa. Tu servidor recibe el aviso y actúa. Con una [API](/glosario/api) normal tú preguntas y el otro responde. Con un webhook el otro llama a tu puerta. ## Por qué se usa Porque preguntar cada minuto es caro y llega tarde. Si el cobro se confirma justo después de tu última consulta, tu cliente espera hasta la siguiente mirando una pantalla que no cambia. Y porque el que avisa sabe cuándo ha pasado algo y tú no. ## Qué pasa cuando se pierde uno Un webhook perdido es una factura que no se emitió, un pedido que no se preparó o un cobro que nadie apuntó. Y se pierden: tu servidor se reinicia, la red falla, tu receptor tarda demasiado y el emisor corta. Un receptor serio hace cuatro cosas. Lo describimos como lo hacemos en [BeeL](/casos/beel), nuestra plataforma de facturación, porque ahí somos los dos lados a la vez. **Verificar la firma.** BeeL manda una cabecera con un sello de tiempo y una firma calculada sobre el cuerpo original de la petición. Sin comprobarla, cualquiera puede enviarte un evento falso. El detalle que rompe más integraciones es que la firma cubre los bytes crudos: si tu código parsea el JSON antes de verificar, nunca cuadra. **Rechazar lo viejo.** Si el sello de tiempo se aleja más de unos minutos, se descarta. Sin eso, alguien puede grabar una petición legítima y reenviarla más tarde. **Deduplicar.** Cada entrega trae un identificador de evento. Guárdalo y, si vuelve, responde sin volver a procesar. Un conjunto en memoria no sirve, porque no sobrevive a un reinicio. **Responder rápido y con el código correcto.** Aceptas, encolas y contestas. Un emisor reintenta ante unos códigos de error y trata otros como definitivos, así que un receptor que responde 400 ante un evento que no reconoce pierde eventos sin dejar constancia de ello. Las reglas concretas de BeeL están publicadas en [docs.beel.es](https://docs.beel.es). ## Qué hacemos con esto Cuando integramos dos sistemas, el receptor de webhooks se escribe con esas cuatro cosas desde el primer día. Reconstruir eventos perdidos a mano un mes después cuesta más. Está contado entero en [integrar dos sistemas que no se conocen](/notas/integrar-dos-sistemas). Ese trabajo es [software a medida](/software-a-medida). Si ya tienes una integración que pierde eventos y no sabes cuántos, empieza por un [diagnóstico](/diagnostico). --- # Qué es un wireframe > Un esquema para acordar contenido y jerarquía. Si dura semanas, está haciendo el trabajo de otra cosa. Término: wireframe Publicado: 2026-09-08 --- Un wireframe es el esquema de una pantalla, dibujado sin color ni tipografía definitiva. Su único objetivo es acordar qué elementos hay, en qué orden y con qué importancia. Aquí no se aprueba una pantalla hasta que funciona, así que el wireframe dura días y es un paso de conversación, no un entregable que se firma. Las mismas personas que dibujan el esquema trabajan sobre lo que se construye después, así que nadie tiene que explicárselo a un equipo posterior. La consecuencia es que discutimos posiciones de botones sobre algo que ya responde al ratón. Un menú que parece razonable en un esquema deja de serlo cuando entran dentro todos sus elementos reales. ## Cuándo importa Importa al principio, para una cosa concreta: fijar qué información entra en la pantalla y cuál se va a otro sitio. Esa decisión es barata en un esquema y cara cuando ya hay código, porque arrastra consultas de datos y permisos. También importa cuando hay varias personas del lado del cliente con opiniones distintas. Un wireframe permite descubrir pronto que dos áreas del cliente esperan cosas incompatibles de la misma pantalla. Descubrirlo en la demostración final cuesta una fase entera. Donde no ayuda es en decidir si algo se entiende. Para eso hace falta que se pueda pulsar, y por eso pasamos pronto a una versión navegable aunque esté fea. ## Lo que viene después no es «maquetar» Cuando el diseño se piensa por pantallas sueltas, cada una acaba con su propio botón y su propia forma de mostrar un error. Con el tiempo hay muchas maneras de decir lo mismo y ningún sitio donde cambiarlas a la vez. Lo que sostiene la coherencia son las decisiones compartidas: va de eso la nota [un design system es una lista de decisiones](/notas/design-system-no-es-una-libreria). Donde antes se nota es en un panel de datos, así que conviene leer también [dashboard](/glosario/dashboard). ## Cómo lo usamos En un proyecto de [software a medida](/software-a-medida) los esquemas viven en la primera semana de cada fase y después no se tocan. A partir de ahí, lo que se revisa es la pantalla real, con datos reales, en el navegador. En el [diagnóstico](/diagnostico) aparecen menos todavía: tres semanas dan para mirar el sistema que ya existe y decidir por dónde se entra.