Las herramientas han cambiado. Nuestra forma de trabajar, no.
Hemos clarificado el posicionamiento de Capamoon y estrenado una nueva web. Te contamos por qué.

Hola:
Acabamos de cambiar bastantes cosas en Capamoon: nuestra oferta, nuestra web, nuestra forma de presentarnos. El objetivo: clarificar nuestra propuesta de valor, en un momento en el que la tecnología avanza a toda velocidad, y reflejar lo que está en el centro de lo que hacemos, es decir, cómo acompañamos de verdad a las empresas.
En dos años, nuestras herramientas y nuestra forma de ejecutar han cambiado de forma radical. Nuestra forma de pensar los proyectos, no. Hemos decidido reflejarlo con más claridad en nuestra comunicación.
Al principio nos presentábamos como una agencia no-code
Hace dos años nos lanzamos los dos, convencidos de que podíamos resolver problemas concretos para las pymes con no-code. Unas cuantas decenas de proyectos después, el no-code sigue siendo una tecnología pertinente, pero no es el centro de nuestra propuesta de valor.
El problema es que presentarse como «una agencia no-code» es definirse por una herramienta. Y la tecnología, aunque siga siendo una parte importante de lo que entregamos, al cliente le da igual (salvo a los más frikis). Lo que le interesa es el resultado final, es decir, el beneficio para su negocio.
Lo que dos años nos han enseñado
Nadie nos compra no-code. Ni IA, dicho sea de paso.
Lo que los clientes compran es otra cosa: tiempo ganado, menos errores, más fluidez y orden en sus procesos, una mejor experiencia para sus equipos y para sus clientes, la capacidad de crecer y, al final de la cadena, una reducción de costes o más ingresos.
Trabajamos para una empresa francesa de energías renovables. No nos pidieron «un bot». Su día a día consistía en declarar la producción de sus plantas solares ante EDF, una a una, en el portal del proveedor de energía. Cuenta 1 o 2 minutos por planta, decenas de plantas. Añade el seguimiento de cientos de facturas cada mes y los expedientes de conexión a la red de ENEDIS. Varios días al mes en tareas administrativas sin valor añadido.
Su verdadera pregunta, detrás de la automatización, era cómo crecer manteniendo bajo control su masa salarial y sus costes, para centrarse en su negocio principal en lugar de en rellenar formularios. Primero identificamos con ellos qué procesos automatizar para priorizar el mayor ahorro de tiempo, y luego pusimos en marcha un sistema de monitorización que controla que los bots se ejecuten bien y avisa cuando hace falta. Resultado: alrededor de un 80% menos de tiempo administrativo, errores de entrada de datos que se esfuman, equipos que vuelven a su verdadero trabajo (desarrollar proyectos solares) y un control total sobre la automatización implantada.
~80% menos de tiempo administrativo
Errores de entrada de datos que se esfuman, equipos que vuelven a su verdadero trabajo.
Primero buscamos entender
Los proyectos tecnológicos rara vez fracasan por la tecnología. Fracasan porque se construyó una solución que pasa por alto las necesidades reales y no resuelve el verdadero problema.
La mayoría de las agencias eligen las herramientas primero, los clientes a veces llegan con una solución ya decidida de facto, y al final es fácil pasar por alto los verdaderos requisitos del negocio si no te haces las preguntas correctas antes.
Un ejemplo. Una startup del sector salud nos contacta para gestionar sus pacientes, sus profesionales, sus citas y sus pagos. El reflejo fácil habría sido sacar las herramientas de inmediato. Solo que el verdadero reto no era técnico: hacía falta una solución que cumpliera las exigencias de confidencialidad del ámbito médico (los datos de salud son, evidentemente, muy sensibles) y que a la vez fuera usable a diario por equipos que no son ingenieros. Así que empezamos por definir los procesos objetivo, las obligaciones regulatorias (la solución debía cumplir con HIPAA en Estados Unidos) y cómo interactúa cada cual con quién. Una vez sentada esa base, construimos la solución eligiendo herramientas no-code para los bloques principales (CRM, formularios, automatizaciones) y Stripe para el pago. La IA nos permitió crear scripts para las automatizaciones allí donde el no-code encontraba sus límites, así como la integración entre el CRM y Stripe. Pero fueron la comprensión del negocio y las restricciones reales (costes, facilidad de uso, complejidad y cumplimiento normativo) las que marcaron las decisiones técnicas.
A veces el problema está en otra parte. Una fundación nos llama porque sus herramientas, apañadas a lo largo de los años, se han vuelto inmanejables. Barajábamos cambiar de herramientas no-code y «simplemente» modificar las automatizaciones existentes. Solo que el verdadero problema era más profundo. Su modelo de datos ya no se parecía a su forma de trabajar, y la solución técnica se había vuelto difícil de mantener, con las incoherencias propias de esa complejidad. Así que volvimos a poner los cimientos en su sitio, es decir, el modelo de datos, repensamos el recorrido de usuario (proceso interno y candidatura de las asociaciones) y rehicimos por completo los formularios y las automatizaciones. Mantuvimos las mismas herramientas no-code (Airtable, Jotform y Make), las que el equipo ya conocía. Y hoy gestionan la herramienta solos, sin nosotros. Una vez más, decisiones técnicas marcadas por necesidades de negocio.
La IA forma parte de nuestra cadena de producción
En nuestros proyectos usamos la IA de dos maneras. A veces, cuando es pertinente, como componente de la solución que entregamos (un chatbot, el análisis de documentos, respuestas generadas automáticamente), y siempre como parte de nuestra cadena de producción, lo que nos permite llegar más lejos y más rápido. Es esta segunda forma la que más ha cambiado nuestro trabajo.
Cuando una plataforma SaaS nos pidió un dashboard analítico para pilotar sus flujos de trabajo, combinamos el enfoque de producto clásico (discovery, diseño, construcción, pruebas, despliegue) con la IA, en cada fase del proyecto.
En concreto, seguimos una lógica de spec-driven development: antes de escribir una sola línea de código, generamos los documentos de especificaciones con la IA. Primero el PRD, el documento que define las necesidades funcionales y las reglas de negocio, luego la arquitectura y el plan de implementación. Los releemos, iteramos sobre ellos. Ahí es donde la reflexión humana resulta esencial, porque hay que tomar las decisiones correctas, tanto a nivel funcional como técnico. Suele ser intenso y siempre apasionante.
Una vez afinadas las especificaciones, la IA programa el dashboard apoyándose en ellas, respetando nuestras guidelines (identidad visual, buenas prácticas de código). También automatizamos las pruebas, para evitar cualquier regresión con cada nueva evolución.
Balance: un prototipo completo y probado en dos semanas, cuando este tipo de herramienta suele medirse en meses.
Un prototipo completo y probado en dos semanas
Cuando este tipo de herramienta suele medirse en meses.
Ojo, la IA no sustituye ni el juicio ni la reflexión. Tiene sus sesgos, alucina, puede tener una visión parcial del contexto en el que te mueves e ignora todo lo que hemos aprendido sobre el terreno en veinte años de oficio. Eso también es Product Thinking: cruzamos, verificamos, decidimos. En definitiva, hacemos la síntesis para producir el mejor producto posible. El product manager se convierte en el piloto y el controlador, en cada etapa de la construcción de la solución.
Nuestro nuevo posicionamiento
Product Thinking + AI-Powered Execution. Entender antes de construir, y luego ejecutar rápido gracias a la IA. Es lo que hacemos desde el primer día. Solo que al final lo hemos acabado diciendo con claridad, tanto en nuestra oferta como en nuestra nueva web.
“Product Thinking + AI-Powered Execution”
Y ya que estamos: este artículo es un buen ejemplo. La reflexión, la historia, las convicciones: escritas a mano, al 100%. La IA solo intervino después, para acelerar lo que se podía acelerar: las traducciones y la corrección de las faltas (¿quién ha dicho que cometemos alguna?). Te lo dijimos. La IA está en todas partes, menos en lo esencial.
Sobre los cofundadores

Julien Andrieu
20 años de experiencia en Product Management y desarrollo de productos digitales. Tras pasar por startups, editores de SaaS y grupos internacionales, hoy acompaña a las pymes en el diseño de soluciones digitales centradas en las necesidades del negocio.

Yahan Bermudez
Emprendedor y especialista en marketing 360 desde hace más de 10 años, lleva varios años acompañando a las pymes en su crecimiento y en la optimización de sus operaciones. Su enfoque combina visión de negocio, ejecución pragmática y resultados medibles.
¿Te apetece que hablemos? Escríbenos: hello@capamoon.com
O si estás en Barcelona, no dudes en escribirnos para tomar un café ☕ Un abrazo.