Marketing
Un formulario prolijo para las siete preguntas que de verdad hacés.
Typeform cuesta US$29–99 / mes, o sea US$348–1.188 al año. Tenés dos caminos:
Opción 1 · Instalar
HeyForm es el formulario estilo Typeform, una pregunta por vez, pero que instalás en tu propio servidor. En el editor visual armás encuestas, quizzes, formularios de contacto o de pedido, con lógica condicional, temas, CSS propio, pagos con Stripe, subida de archivos y firmas. Las respuestas caen en una tabla de resultados con tasas de abandono, se exportan a CSV y llegan a tus herramientas por webhooks, Zapier, Make, Google Sheets, Airtable o Slack. Corre en tu servidor con Docker: la app, una base MongoDB y un Redis. Licencia AGPL-3.0, y existe una versión alojada desde €13 por mes. Lo importante: el proyecto tuvo una ola grande de avisos de seguridad en 2026 y reforzó su código en agosto. Así que instalá la última versión, no una más vieja.
| Criterio | HeyForm | Typeform |
|---|---|---|
| Precio | US$0, más un VPS chico por unos pocos euros al mes | US$29–99 al mes |
| Respuestas por mes | Sin tope, es tu base de datos | 100 en Basic, después hay que subir de plan |
| Dónde quedan las respuestas | En tu MongoDB, en tu servidor | En sus servidores |
| Sacar la marca | Incluido, con tu propio CSS | Plan Plus, desde €48 por mes |
| Usuarios | Tu equipo, sin costo extra | 1 usuario en Basic |
| Seguridad y actualizaciones | Depende de vos, y acá importa | Se encargan ellos |
Tres contenedores (la app, MongoDB y Redis) y un proxy HTTPS adelante. El prompt hace todo; vos ponés un servidor y un nombre de dominio. Calculá unos veinte minutos.
Despliega HeyForm desde el proyecto oficial con Docker Compose, configura las variables, pone un proxy HTTPS adelante y revisa tu primer formulario:
Instalá HeyForm en mi servidor (el creador de formularios open source estilo Typeform, repo de GitHub heyform/heyform) con Docker Compose, siguiendo la documentación oficial docs.heyform.net/open-source/self-hosting. Arrancá de cero: verificá que Docker y Docker Compose estén instalados y, si no, instalalos. Creá una carpeta heyform con un docker-compose.yml que levante tres servicios: la imagen heyform/community-edition con una versión etiquetada reciente (como mínimo v3.0.2, nunca más vieja que v3.0.1, que es la que trae los arreglos de seguridad), una base de datos MongoDB y un Redis (KeyDB), cada uno con un volumen para conservar los datos. Generá dos claves aleatorias largas para SESSION_KEY y FORM_ENCRYPTION_KEY, configurá APP_HOMEPAGE_URL con mi nombre de dominio en https, y poné TRUST_PROXY en 1 porque la aplicación va a estar detrás de un proxy. No publiques el puerto 9157 en internet: instalá un reverse proxy (preferentemente Caddy) que sirva mi dominio en HTTPS con certificado automático y redirija al contenedor de HeyForm. Levantá todo, abrí la dirección, creá mi cuenta de administrador, y después agregá APP_DISABLE_REGISTRATION=true y reiniciá para cerrar los registros. Verificá que se pueda crear un primer formulario, publicarlo y recibir una respuesta de prueba. Explicame cada paso de manera simple, soy principiante.
Revisá el repositorio de GitHub y fijate si es seguro instalarlo dado mi equipo y mi infraestructura. Hacime todas las preguntas que puedas, usando widgets, para aclarar mi pedido y ser lo más preciso posible.Una vez que existe tu cuenta, la instancia tiene que rechazar cuentas nuevas; si no, cualquiera puede registrarse en tu dominio. El prompt se ocupa con la variable pensada para eso. Comprobalo abriendo la página de registro en una ventana privada.
El proyecto corrigió 42 avisos de seguridad entre mayo y agosto de 2026. Instalá como mínimo la versión 3.0.2, suscribite a los releases en GitHub y volvé a bajar las imágenes con cada versión nueva. Un formulario público es una puerta abierta a tu servidor.
Un formulario de una pregunta por vez se completa más seguido que una pared de campos. Lo linkeás en una story o lo embebés en tu sitio, y cada respuesta te llega por email o por webhook a tu CRM.
Subida de archivos, firma, pago con Stripe, lógica condicional: juntás todo de una vez, y el archivo ya queda en tu base de datos en vez de perderse en una casilla de correo.
Le preguntás a tu comunidad qué quiere, ves dónde abandona la gente y exportás a CSV. Sin tope de respuestas, lo podés repetir en cada lanzamiento.
Hecho con: TypeScript 94.7% · SCSS 4.1% · HTML 0.7%
Datos públicos del repositorio en GitHub, tomados el 8 de octubre de 2026.
Opción 2 · Construir
Este desarrollo es para un negocio chico que junta consultas de clientes o datos de ingreso. El objetivo: crear y publicar formularios de una pregunta por vez que se vean excelentes en el celular. Si necesitás más que eso, seguí pagando: armarlo vos sirve para tener una herramienta hecha a la medida de tu forma de trabajar, no para rehacer el plan de una empresa con millones de inversión.
Mismo desarrollo, otro logo: esta v1 también reemplaza a Jotform y Youform, porque los tres resuelven el mismo trabajo de fondo.
El prompt de abajo arma una sola versión, con lo que de verdad se usa. Lo demás queda afuera a propósito.
| Lo que arma el prompt | formulario de una pregunta por vez, tabla de respuestas, saltos lógicos, temas visuales, exportación a csv, webhooks |
|---|---|
| Lo que queda afuera | editor visual, campos de pago, galería de integraciones |
Form, Question, LogicRule, Submission, Answer
email, webhook genérico
Astro, HTMX, D1
Validá y limitá la cantidad de envíos del lado del servidor; sumá un campo honeypot.
No armes un editor visual de flujos general ni campos de pago.
Elegí tu stack, copiá el prompt y pegáselo a tu agente de código (Claude Code, Cursor, Codex…).
Vas a construir un producto de software listo para producción llamado “Goodform”, una alternativa deliberadamente enfocada a Typeform. Construí un recorte completo y usable, no una landing page, ni una maqueta estática, ni un montón de componentes sueltos.
ACUERDO DE TRABAJO
Antes de escribir código de implementación, armá un plan técnico corto que nombre las rutas o páginas, las server actions o endpoints, las tablas de datos, las transiciones de estado importantes, los límites de autorización, los jobs en segundo plano y los adaptadores externos. Si algo se contradice, resolvelo a favor de la audiencia acotada y de los no-objetivos de abajo. Elegí una arquitectura chica y legible antes que abstracciones especulativas, pero no omitas persistencia, validación, manejo de errores ni tests.
DESCRIPCIÓN DEL PRODUCTO
Usuario principal: un negocio chico que junta consultas de clientes o datos de ingreso.
Resultado principal: crear y publicar formularios de una pregunta por vez que se vean excelentes en el celular.
Principio del producto: optimizá el flujo exacto de abajo en vez de copiar todo lo que hace Typeform. Alguien que lo usa por primera vez tiene que entender qué hacer desde la propia interfaz, sin tour ni documentación.
RECORRIDOS COMPLETOS DEL USUARIO
Implementá todos estos flujos usando la interfaz real y la capa de datos persistente:
1. El dueño crea un formulario desde cero, agrega y reordena preguntas, marca campos como obligatorios, lo previsualiza y publica una URL estable para compartir.
2. Quien responde completa el formulario de a una pregunta, sigue un salto condicional, revisa los mensajes de validación y ve la pantalla de agradecimiento personalizada.
3. El dueño recibe un aviso, revisa las respuestas normalizadas, busca entre los envíos y exporta a CSV el resultado actual.
PANTALLAS Y ARQUITECTURA DE INFORMACIÓN
Construí estas pantallas como vistas coherentes y responsive. Cada pantalla tiene que definir su acción principal, sus acciones secundarias, el estado visible, el feedback de validación, el estado vacío, el estado de carga o pendiente, la confirmación de éxito y un estado de error recuperable.
1. Lista de formularios: estado, cantidad de respuestas, hora de la última respuesta, y acciones de duplicar, archivar, editar, compartir y ver resultados.
2. Editor: riel ordenado de preguntas, ajustes de la pregunta seleccionada, ajustes de intro y cierre, controles de tema, resumen de lógica y vista previa en vivo.
3. Vista pública para responder: una pregunta por pantalla, progreso, botones de atrás y siguiente, atajos de teclado, validación y estado de sesión autoguardado.
4. Resultados: tabla de respuestas con búsqueda, detalle de cada respuesta, resumen de completados, exportación a CSV y estado de entrega de webhooks.
FUNCIONES PRINCIPALES
1. campos de texto, email, selección, selección múltiple, puntaje y respuesta larga
2. campos obligatorios, saltos condicionales simples e indicador de progreso
3. intro propia, mensaje de agradecimiento, colores y logo
4. tabla de respuestas con búsqueda y exportación a CSV
5. aviso por email y webhook después de cada envío
COMPORTAMIENTO DETALLADO Y REGLAS DE NEGOCIO
Tratá esto como requisitos del producto que se validan en el servidor, no como sugerencias de interfaz:
1. Los formularios publicados usan una versión inmutable, para que editar preguntas no pueda romper la forma ni el sentido de las respuestas históricas.
2. Las reglas condicionales pueden saltar hacia adelante o terminar el formulario, pero hay que validarlas para evitar bucles y referencias a preguntas borradas.
3. Creá como máximo un envío por cada token de envío, y hacé que los efectos de email y webhook se puedan reintentar y sean idempotentes.
4. Normalizá los emails, limitá el largo de los textos y el tamaño del payload (sin subida de archivos), escapá las fórmulas de planilla en el CSV y limitá la frecuencia de los envíos públicos.
MODELO DE DATOS Y CICLO DE VIDA
Diseñá un esquema relacional chico centrado en Form, Question, LogicRule, Submission, Answer. Antes de implementarlo, documentá:
1. El propósito de cada tabla, su clave primaria, el límite de propiedad o de tenant, timestamps, campos de estado y atributos importantes.
2. Claves foráneas, restricciones de unicidad, check constraints, los índices que necesitan las pantallas nombradas y los límites de transacción para cambios que tocan varios registros.
3. Las transiciones de estado o de ciclo de vida permitidas, quién puede disparar cada una, cuáles son terminales o reversibles y qué historial de auditoría tiene que quedar inmutable.
4. Cómo se archiva, se retiene y se borra, incluido qué pasa con los registros dependientes y los archivos externos.
5. La estrategia de idempotencia para envíos, jobs, importaciones, notificaciones, webhooks o reintentos, donde aplique.
Usá migraciones en lugar de crear el esquema a mano. Guardá los instantes de tiempo de forma consistente y conservá la zona horaria con nombre cada vez que importen horarios o fechas locales. Nunca dependas de un contador, un botón deshabilitado o una validación del lado del cliente para proteger una regla de negocio.
USUARIOS, AUTENTICACIÓN Y PERMISOS
Implementá solo los roles que necesita la audiencia indicada. Dejá explícito el modelo de propiedad y visibilidad antes de programar. Aplicá la autorización en cada consulta y mutación del servidor, incluidas búsquedas, exportaciones, adjuntos, actualizaciones en vivo y URLs adivinadas—no alcanza con ocultar botones. Usá sesiones seguras por defecto, protegé los requests que cambian estado y mostrá estados claros para sesión cerrada, sesión vencida y acceso prohibido. Si hacen falta varios roles, cargá usuarios distintos en los datos de prueba para poder mostrar y testear los permisos.
INTERACCIÓN Y DIRECCIÓN VISUAL
El producto tiene que sentirse rápido, tranquilo, enfocado y confiable, no como una plantilla genérica de panel de administración. Usá una jerarquía visual clara, color medido, tipografía legible, áreas de clic generosas y un lugar fijo para las acciones principales. Arrancá con HTML renderizado en el servidor y mejorá de forma progresiva solo las interacciones que lo necesiten. El flujo principal tiene que entenderse aunque esa mejora falle.
Arrancá con páginas de Astro renderizadas en el servidor y formularios HTML comunes. Usá HTMX para envíos de formularios, navegación parcial y actualizaciones que manda el servidor, y Alpine.js solo para estado local chico del navegador. El flujo principal tiene que entenderse aunque falle cualquiera de esas dos capas.
Diseñá las vistas de celular a propósito, no apilando los paneles de escritorio. Soportá navegación con teclado, foco visible, landmarks semánticos, labels explícitos, títulos de página útiles, la preferencia de movimiento reducido y anuncios para lectores de pantalla en resultados asincrónicos. Nunca uses solo el color para comunicar un estado. Las acciones destructivas necesitan un alcance claro y una confirmación; las acciones seguras que se repiten tienen que ser idempotentes.
Agregá un footer en todas las páginas con el texto «Creado por aurelioagency.com», donde «aurelioagency.com» es un link embebido a https://www.aurelioagency.com que se abre en una pestaña nueva. Tiene que quedar visible; no lo saques.
DIRECCIÓN TÉCNICA
Construí esta versión con el stack AHA: Astro para el ruteo, los layouts y las páginas renderizadas en el servidor; HTMX para las interacciones que se benefician de respuestas con fragmentos HTML; y Alpine.js para estado chico y local de la interfaz. Preferí Cloudflare D1 para la persistencia relacional, R2 para el almacenamiento de objetos, Workers para los endpoints del servidor y las tareas programadas, Durable Objects solo para estado en tiempo real coordinado, y Workflows o Queues para jobs en segundo plano durables—pero solo cuando los requisitos del producto lo pidan.
Mantené las reglas de dominio en módulos del servidor que se puedan testear, no en los route handlers ni en los componentes de UI. Separá la persistencia, los proveedores externos y el trabajo en segundo plano detrás de interfaces chicas, sin armar un framework. Preferí formularios HTML y URLs comunes para la navegación; usá interacción optimista solo cuando un error se pueda resolver con claridad.
El brief del producto identifica hoy Astro, HTMX, D1 como contexto técnico. Cualquier capacidad nativa, solo de navegador, de edge, de almacenamiento, de tiempo real o de procesamiento en segundo plano que haga falta, conservala a través de un adaptador acotado que corresponda al framework elegido. Si el flujo central realmente necesita APIs nativas o de navegador, mantené ese entorno como superficie principal de ejecución en vez de simular capacidades inaccesibles o inventar una superficie web innecesaria.
Integrá con email y webhook genérico. Para cada integración:
- Listá las variables de entorno necesarias en un .env.example sin secretos reales.
- Agregá un adaptador chico con timeouts, errores normalizados y una versión falsa local determinística o un modo de desarrollo.
- Verificá las firmas entrantes y deduplicá los eventos del proveedor cuando se pueda.
- Mantené las credenciales en el servidor, encriptá en reposo los tokens de larga duración y ocultá secretos y datos sensibles en los logs.
- Definí reintentos, backoff e idempotencia para cualquier efecto que se pueda repetir.
SEGURIDAD Y PRIVACIDAD
Validá y limitá la cantidad de envíos del lado del servidor; sumá un campo honeypot.
Validá, normalizá y limitá el largo de todo input no confiable en el servidor. Escapá el contenido renderizado por defecto, sanitizá cualquier markup que aceptes a propósito, poné rate limit a las acciones públicas o fáciles de abusar y usá almacenamiento de objetos privado con URLs autorizadas de corta duración para archivos sensibles. Juntá solo los datos personales que necesita el flujo indicado. Documentá cómo se retienen y se borran. Sumá protecciones específicas para las partes más riesgosas de esta app, como subidas de archivos, redirecciones, requests salientes, envío de emails, OAuth, webhooks, importación o exportación CSV y conexiones en tiempo real.
ESCENARIOS DE ACEPTACIÓN
Automatizá estos escenarios propios de la app en el nivel que corresponda:
1. Un formulario publicado con un email obligatorio rechaza datos mal formados, conserva lo que la persona escribió y pone el foco en la explicación del campo.
2. Una respuesta elegida dispara el salto configurado, saltea las preguntas obligatorias que ya no corresponden y guarda qué versión del formulario y qué camino se usaron.
3. Si un webhook se queda sin tiempo, no se pierde el envío: aparece como entrega fallida y se puede reintentar sin duplicar la respuesta.
TESTS
Agregá tests unitarios enfocados en transiciones de estado, reglas de autorización, normalización, cálculos de fechas o dinero y otras reglas de dominio riesgosas. Agregá tests de integración para las restricciones de persistencia y para los caminos de éxito, timeout, reintento y rechazo de cada adaptador externo. Agregá al menos un test de navegador para cada recorrido completo de arriba, incluido uno en pantalla chica. Los tests tienen que usar datos aislados y correr con un solo comando documentado.
OPERACIÓN Y RECUPERACIÓN DE ERRORES
Agregá logs estructurados en el servidor con IDs de correlación por request, job o evento, sin secretos ni datos sensibles de más. Hacé que los errores digan qué hacer, tanto en la interfaz como en los logs. El trabajo en segundo plano tiene que mostrar los estados pendiente, completado, fallido y reintentando cuando aplique; nunca te tragues errores en silencio. Incluí una guía segura de migración y rollback de la base, datos de prueba, notas de backup y restauración, qué pasa con los datos externos al limpiar y una ruta básica de salud o diagnóstico acorde al stack.
ENTREGABLES
Entregá la aplicación funcionando, las migraciones, datos de prueba representativos, los tests, el .env.example y un README corto. El README tiene que cubrir requisitos previos, instalación local, variables de entorno, migraciones, comandos de datos de prueba y tests, deploy, configuración de integraciones, backup y restauración, decisiones de seguridad y limitaciones conocidas. Los datos de prueba tienen que cubrir el camino feliz y al menos un estado vacío, fallido, vencido, expirado, archivado o con permisos restringidos que importe para el producto.
DEFINICIÓN DE TERMINADO
La app está terminada cuando alguien nuevo puede seguir el README, crear y migrar la base, levantar la app, entrar con cada rol relevante, completar cada recorrido nombrado con datos reales guardados, recargar sin perder el estado, recuperarse de los errores comunes y usar la interfaz principal en celular y escritorio. Todos los escenarios de aceptación pasan, los límites de permisos están cubiertos por tests, ninguna pantalla principal queda como placeholder y el crédito «Creado por aurelioagency.com» del footer se ve en todas las páginas.
NO-OBJETIVOS
No armes un editor visual de flujos general ni campos de pago.La app que armes con este prompt lleva en el footer «Creado por aurelioagency.com».
Prompts cortos para resolver la pieza más difícil sin construir todo.
Construí el validador de lógica condicional para un formulario de una pregunta por vez.
Cada regla dice: si la respuesta a la pregunta X cumple una condición, saltá a la pregunta Y o terminá el formulario. Modelá el formulario como un grafo dirigido (las preguntas son nodos; las reglas de salto y el orden normal de la pregunta siguiente son aristas) y validá en cada guardado: ninguna regla puede referirse a una pregunta borrada, ningún camino puede volver a pasar por una pregunta (los saltos van hacia adelante o terminan, así que rechazá cualquier arista que vuelva atrás), y toda pregunta tiene que ser alcanzable o quedar marcada como huérfana.
Lo delicado: una pregunta obligatoria que algún camino saltea legítimamente está bien, pero solo si el validador de envíos sabe qué camino siguió realmente quien respondió. Registrá el recorrido, de modo que obligatorio signifique obligatorio en tu camino, no obligatorio en general.
Dale al editor un aviso honesto: nombrá la regla exacta que crea un ciclo, listá las preguntas inalcanzables y negate a publicar mientras alguna regla quede colgada.
Terminado cuando: ningún formulario publicable pueda dejar a alguien atrapado en un bucle, borrar una pregunta muestre todas las reglas que la referenciaban, y una pregunta obligatoria salteada nunca bloquee el envío de un camino legítimo.Construí versionado inmutable para formularios publicados, de modo que editar nunca dañe las respuestas históricas.
Publicar congela el formulario: preguntas, orden, opciones y lógica se copian a una versión numerada de solo lectura. Quien responde contesta sobre una versión concreta, y cada envío registra cuál fue. El dueño sigue editando un borrador de trabajo; volver a publicar crea la versión n+1.
El problema que esto evita es real: si renombrás la opción A veces a Casi nunca, todas las respuestas viejas cambian de significado sin avisar; si borrás una pregunta, las exportaciones viejas pierden una columna. Por eso las respuestas referencian ids de pregunta propios de cada versión, y la vista de resultados muestra cada envío según su propia versión, con el texto exacto de la pregunta que vio quien respondió.
Diseñá a conciencia la tabla de resultados entre versiones: unificá las columnas de todas las versiones, marcá qué versiones hicieron qué preguntas y mantené estables las columnas del CSV atándolas al linaje de la pregunta; una pregunta que pasa de una versión a otra conserva su id de linaje.
Terminado cuando: editar y volver a publicar no cambie en nada cómo se muestran los envíos existentes, los resultados de versiones mezcladas nunca desalineen columnas, y cualquier respuesta se pueda rastrear hasta la redacción exacta a la que respondía.Construí el manejo de envíos para que aguante doble clics, reintentos y conexiones inestables sin crear duplicados.
Emití un token aleatorio de envío cuando carga el formulario. El endpoint de envío garantiza como máximo un envío por token con una restricción de unicidad, y un reintento del mismo token devuelve la respuesta de éxito original, sin error y sin una segunda fila.
Después hacé que los efectos secundarios se porten bien: el email de aviso y el webhook se disparan una vez confirmado el envío, desde una tabla outbox chica, nunca dentro del request. Cada entrega tiene su propio estado (pendiente, entregada, fallida), cantidad de intentos y último error. Los reintentos son seguros porque el payload del webhook lleva el id del envío para que quien lo recibe pueda deduplicar, y el que manda el email revisa el estado de entrega antes de enviar.
Un webhook que se queda sin tiempo nunca debe hacer perder ni duplicar el envío. Tiene que aparecer como entrega fallida, con un control para reintentar a mano.
Terminado cuando: apretar el botón de enviar sin parar produzca una sola fila, repetir el mismo request devuelva éxito sin insertar nada, y reintentar un webhook fallido nunca vuelva a disparar uno que ya salió bien.Construí la exportación a CSV de las respuestas de un formulario, que abra bien en Excel y que no pueda atacarlo.
Primero la defensa contra inyección: toda celda que empiece con =, +, - o @ (o con un tab o un retorno de carro) lleva adelante una comilla simple, para que las planillas la traten como texto y no como fórmula. Alguien va a escribir =HYPERLINK en tu cuadro de comentarios, seguro. Asumí mala intención.
Después las rarezas del formato: poné entre comillas los campos que tengan comas, comillas o saltos de línea; duplicá las comillas internas; usá CRLF como fin de fila; emití un BOM UTF-8 para que Excel no arruine los nombres con acento. Las respuestas largas conservan sus saltos de línea internos dentro de campos entre comillas.
Columnas: una por pregunta en el orden del formulario, más la fecha de envío y el id del envío. Las respuestas de selección múltiple se unen con un separador que no choque con el delimitador. Mandá la salida en streaming en vez de armar todo el archivo en memoria, y nombralo con el slug del formulario y la fecha de exportación.
Terminado cuando: una respuesta que contenga =2+2, una coma, un emoji y un salto de línea llegue a Excel como texto literal en una sola celda, y una exportación de 50.000 filas se mande en streaming sin picos de memoria.Typeform cuesta US$29–US$99 por mes en sus planes pagos públicos, o sea US$348–US$1188 por año. Un reemplazo propio y enfocado te cuesta el tiempo de armarlo más un hosting casi gratis.
El prompt de esta página viene en cuatro versiones: el stack AHA (Astro, HTMX, Alpine.js), Next.js, Laravel y Ruby on Rails. El contexto técnico de este producto es Astro, HTMX, D1. Elegí el stack que ya conocés: importa más el alcance que el framework.
Una v1 útil necesita: campos de texto, email, selección, selección múltiple, puntaje y respuesta larga; campos obligatorios, saltos condicionales simples e indicador de progreso; intro propia, mensaje de agradecimiento, colores y logo; tabla de respuestas con búsqueda y exportación a CSV; aviso por email y webhook después de cada envío. Todo lo demás es agrandar el alcance hasta que lo extrañes de verdad.
No armes un editor visual de flujos general ni campos de pago.
Sí. Typeform, Jotform y Youform resuelven el mismo trabajo de fondo: crear y publicar formularios de una pregunta por vez que se vean excelentes en el celular. La v1 de esta página cubre lo que casi todos usan de cualquiera de los tres, así que un solo desarrollo enfocado reemplaza al que pagues hoy.
HeyForm hace casi todo lo que hace Typeform, sin suscripción, y tus datos quedan con vos. La comparación punto por punto está en la página.
Sí. Con una herramienta de código abierto instalada de tu lado, tus archivos quedan en tu máquina o en tu servidor. Nadie puede cerrarte la cuenta ni cambiarte el precio.
¿Sin tiempo para hacerlo?
Si preferís que alguien lo instale, lo conecte a tus herramientas y lo deje andando, en Aurelio hacemos exactamente eso.
Pedir una auditoría de automatización