Tu equipo tiene una hoja de cálculo que editan tres personas, una aprobación que vive en cadenas de correo y un informe que alguien rehace cada lunes. El desarrollo de herramientas internas a medida sustituye ese parche por una sola pantalla en la que tu equipo confía y que mantiene tus datos protegidos. La pregunta real es quién puede construirla y cómo contratarlo sin arrepentirte.
La respuesta corta: un desarrollador interno, un freelance, una agencia o un consultor low-code pueden hacerlo, y cada uno encaja con un tamaño de necesidad distinto. Lo que decide el resultado es el alcance que entregas, más que la etiqueta en la web del proveedor. Esta guía te muestra cómo redactar ese alcance, cómo elegir entre low-code y una versión a medida con Next.js, y cómo evaluar a un equipo.
No necesitas ser técnico para seguirla. Al terminar tendrás las piezas de un brief de una página que funciona con cualquier proveedor, werun.dev incluido.
Puntos clave
- Empieza por el flujo de trabajo que más horas cuesta a tu equipo y define solo ese para la primera versión.
- Elige low-code para necesidades de corta vida o equipos pequeños, y desarrollo a medida para herramientas de las que tu operación dependerá durante años.
- Incluye roles, inicios de sesión y registros de auditoría en el primer alcance, porque añadirlos después cuesta mucho más.
- Planifica una primera versión de 4 a 8 semanas, con pruebas de usuarios reales antes del lanzamiento.
- Pregunta quién es dueño del código, dónde se aloja y cómo es la entrega antes de firmar nada.
Quién puede encargarse del desarrollo de herramientas internas
Cuatro tipos de proveedor asumen este trabajo, y cada uno encaja con una necesidad distinta. Ajusta el proveedor al tamaño y a la vida útil de la herramienta y el proyecto arrancará sobre terreno firme.
Desarrollador interno, freelance o agencia
| Proveedor | Encaja mejor en | Pregunta por |
|---|---|---|
| Desarrollador interno | Una herramienta que cambia cada semana y está cerca del equipo | Cobertura en vacaciones y el día que se vaya |
| Freelance | Una herramienta pequeña y bien definida con un responsable claro | Persona de respaldo y documentos de entrega |
| Agencia o equipo de producto | Una herramienta central con inicios de sesión, integraciones y larga vida | Quién la mantiene tras el lanzamiento |
| Consultor low-code | Una necesidad de corta vida o un equipo de menos de unos 20 usuarios | Coste de licencias al crecer el equipo |
Un desarrollador interno conoce mejor tu negocio, pero una sola persona es un punto único de fallo cuando está de baja o se marcha. Un freelance sirve para una herramienta pequeña con un responsable claro, siempre que entregue código y documentos. Una agencia encaja con una herramienta que toca varios sistemas, necesita reglas de acceso estrictas y debe funcionar durante años. Un consultor low-code es el camino más rápido cuando la necesidad es breve o el equipo es pequeño.
Lo que aporta un buen socio además de código
El código es la parte visible. El valor está en lo que ocurre a su alrededor, y separa una herramienta que tu equipo usa de otra que abandona en silencio. Un buen socio te da:
- Preguntas sobre tu flujo de trabajo antes de dibujar ninguna pantalla, para que la herramienta refleje cómo se trabaja de verdad.
- Un mapa de accesos por escrito: quién ve qué y quién cambia qué.
- Un plan para los datos, incluido qué sistema es dueño de cada registro.
- Una entrega que puedas operar sin el proveedor, con el código en tu propio repositorio.
- Soporte tras el lanzamiento, porque el segundo mes de uso siempre genera las mejores peticiones de cambio.
Así trabajamos en werun.dev: tú pones el objetivo, nosotros construimos el camino y seguimos a tu lado después. Respondemos en menos de 2 horas en días laborables, algo que importa cuando falla una herramienta que tu equipo usa a diario.
Cuatro herramientas internas para construir primero
La mayoría de las herramientas internas se reduce a cuatro tipos. Nombrar el tuyo pronto acorta el alcance, porque cada tipo tiene una forma conocida y un conjunto de preguntas conocido.
Tipo 1
Panel de administración
Elimina la edición manual de registros en hojas de cálculo o en la base de datos.
Tipo 2
Flujo de aprobaciones
Elimina la persecución de visto buenos por correo y chat.
Tipo 3
Dashboard de informes
Elimina rehacer el mismo informe cada semana.
Tipo 4
Back office para clientes
Elimina las consultas rutinarias sobre pedidos, facturas y reservas.
Elige uno. Una herramienta que intenta ser las cuatro cosas en su primera versión suele superar el presupuesto y el plazo. La mejor primera versión es un solo tipo que resuelve un solo flujo para un solo equipo.
Paneles de administración para tus propios datos
Un panel de administración da a tu equipo una pantalla segura para ver y editar los registros que mueven el negocio: clientes, pedidos, productos, reservas. Por ejemplo, un agente de soporte corrige una dirección de entrega en un formulario en lugar de pedir a un desarrollador que cambie una fila de la base de datos. Obtienes menos interrupciones para el personal técnico y menos ediciones manuales arriesgadas.
Flujos de aprobación
Un flujo de aprobación envía una solicitud (un descuento, una compra, un reembolso por encima de un límite) a la persona correcta y registra la decisión. Por ejemplo, un comercial pide un descuento y el director lo aprueba desde el móvil en un minuto. Obtienes decisiones más rápidas y un rastro que muestra quién aceptó qué.
Dashboards de informes
Un dashboard de informes reúne cifras de tu CRM, tu tienda y tu contabilidad en una vista que se actualiza sola. Piensa en el informe del lunes que le lleva dos horas a alguien: pasa a ser una página que ya está al día cuando empieza la reunión. Recuperas horas y todos leen los números del mismo modo.
Back offices para clientes
Un back office para clientes permite que tus clientes o socios vean pedidos, facturas, reservas o documentos sin escribirte. Un distribuidor, por ejemplo, consulta el stock y repone por su cuenta. Reduce el correo rutinario y da a tus clientes una razón para quedarse.
Low-code o Next.js a medida: cómo decidir
Decide según la vida útil y el tamaño. Las plataformas low-code como Retool permiten montar pantallas rápido sobre tus datos. Un desarrollo a medida con Next.js, el framework de React descrito en la documentación oficial de Next.js, te da control total sobre pantallas, lógica y hosting. Ninguno gana siempre, así que la comparación siguiente usa criterios.
Arranque rápido
Low-code (estilo Retool)
- Velocidad: primeras pantallas en días
- Forma del coste: coste de construcción bajo, una licencia por usuario cada mes
- Límites: los componentes y los planes de precios de la plataforma
- Propiedad: la herramienta vive en la plataforma del proveedor
Nuestra opción para una herramienta central y duradera
Next.js a medida
- Velocidad: primera versión en 4 a 8 semanas
- Forma del coste: construcción más alta, luego hosting y mantenimiento fijos
- Límites: los que tú diseñes
- Propiedad: el código está en tu propio repositorio
Para la estrategia general más allá de las herramientas internas, nuestra guía sobre low-code y no-code frente a desarrollo a medida cubre el marco completo.
Cuándo low-code es la respuesta más rápida
Low-code encaja cuando se cumplen casi todas estas condiciones:
- La necesidad es temporal, como una migración o una campaña de temporada.
- El equipo tiene menos de unos 20 usuarios.
- Los datos viven en uno o dos sistemas a los que la plataforma se conecta.
- Las pantallas son tablas y formularios estándar.
En estos casos low-code suele ganar en tiempo y coste, y así se lo decimos a nuestros clientes. Una herramienta que puedes retirar el año próximo no merece un desarrollo a medida.
Cuándo un desarrollo a medida se amortiza
Un desarrollo a medida se amortiza cuando la herramienta pasa a formar parte de cómo operas. Las señales son muchos usuarios (las licencias crecen con cada uno), reglas únicas de tu negocio, necesidades de acceso estrictas, varios sistemas detrás de las pantallas o el plan de ofrecer la herramienta a tus clientes. Además conservas el código, así que un cambio de precios del proveedor nunca te obliga a reconstruir.
Qué cuesta cada camino en tres años
La forma del coste difiere más que el total. Low-code empieza barato y crece con cada usuario, mientras que lo a medida empieza más alto y se mantiene fijo. La tabla es un ejemplo ilustrativo con cifras supuestas, no un presupuesto: asume 30 USD por usuario al mes en licencias y 300 USD al mes de hosting y mantenimiento en el desarrollo a medida.
| Concepto (USD) | Low-code, 25 usuarios | A medida, 25 usuarios | Low-code, 100 usuarios | A medida, 100 usuarios |
|---|---|---|---|---|
| Construcción | 6,000 | 30,000 | 8,000 | 32,000 |
| Licencias u hosting y mantenimiento, 36 meses | 27,000 | 10,800 | 108,000 | 10,800 |
| Total en tres años | 33,000 | 40,800 | 116,000 | 42,800 |
En este ejemplo low-code es más barato para un equipo pequeño y lo a medida gana a medida que crecen los usuarios. Tu punto de cruce depende de los precios reales de licencias, así que pide a cada proveedor una cifra a tres años y no solo el precio de construcción.
Roles, accesos y registros de auditoría desde el día uno
Las reglas de acceso van en el primer alcance, porque una herramienta interna guarda los datos que menos quieres exponer: clientes, precios, nóminas. Si las decides con el proveedor antes de que existan las pantallas, cuestan poco. Si las añades tras el lanzamiento, afectan a cada pantalla.
Por qué importa
Las reglas de acceso y los registros de auditoría son más baratos cuando se escriben en el primer alcance y caros de añadir después. El control de acceso roto ha encabezado la lista OWASP Top 10 de riesgos de aplicaciones web, así que trátalo como una decisión de alcance, no como un añadido.
El OWASP Top 10 es la referencia estándar de los riesgos más comunes en aplicaciones web. Un buen proveedor sabrá explicarte cómo la herramienta aborda cada uno.
Quién puede ver y cambiar qué
Enumera los roles con palabras sencillas, por ejemplo agente de soporte, finanzas, responsable y administrador. Para cada rol, escribe qué pantallas ve, qué registros edita y qué acciones no podrá hacer nunca. Una tabla de cinco roles y diez acciones suele bastar. El acceso con correo de empresa y la verificación en dos pasos deciden después quién entra.
Registros de auditoría que responden quién hizo esto
Un registro de auditoría anota quién cambió qué y cuándo. Cuando un precio es incorrecto o desaparece un pedido, encuentras la respuesta en un minuto en lugar de una semana de conjeturas. Pide que toda acción sensible (editar, borrar, aprobar, exportar) quede registrada y que las personas a las que describe no puedan editar el registro.
Dónde viven los datos y quién accede
Decide dónde se almacenan los datos, quién los aloja, cómo funcionan las copias de seguridad y en qué país se guardan. Para equipos en España y la Unión Europea, eso incluye la normativa de protección de datos. Pide también entornos separados de pruebas y producción, para que los experimentos nunca toquen registros reales.
Conecta la herramienta con tu CRM, ERP y tienda
Una herramienta interna se gana su lugar cuando lee y escribe en los sistemas que tu equipo ya usa: CRM, ERP, contabilidad, tu tienda WordPress o Shopify. El objetivo es una pantalla donde la gente actúe, con cada cambio viajando de vuelta al sistema que es dueño del registro. Pregunta a cada proveedor cómo funciona esa conexión y qué pasa cuando un sistema está caído.
El diagrama muestra el camino habitual. Tus sistemas alimentan una capa de API (la puerta que usa un software para hablar con otro), la herramienta aplica roles y registra una auditoría, y el equipo actúa en una sola pantalla.
Ruta de conexión
- 01Tus sistemasCRM, ERP, WordPress o Shopify
- 02Capa de APIConecta cada sistema con la herramienta
- 03Herramienta internaAplica roles y registra auditoría
- 04Pantalla del equipoRevisan y actúan
- 05Cambios sincronizadosCada cambio llega al sistema origen
Flujo con datos de CRM, ERP y tienda entrando en una capa de API, la herramienta interna aplicando roles y auditoría, y los cambios volviendo al origen
Una fuente de verdad para cada registro
Cada registro necesita un dueño. El cliente vive en el CRM, la factura en el ERP y el pedido en la tienda. La herramienta los muestra y los edita, pero no guarda una segunda copia que se desajuste, que es como dos pantallas acaban mostrando dos precios distintos.
WordPress y Shopify exponen sus datos mediante APIs, así que una herramienta puede leer pedidos, productos y clientes sin tocar el sitio en producción. Los sistemas antiguos pueden añadir trabajo: algunos ERP ofrecen APIs limitadas o solo exportaciones de archivos, y en Latinoamérica la herramienta puede necesitar además servicios locales de facturación electrónica, como CFDI en México. Nuestro artículo sobre integraciones de API y sistemas heredados profundiza en estos casos.
Automatizaciones con n8n para los pasos rutinarios
Algunos pasos no necesitan pantalla alguna. Cuando se cierra una venta en el CRM, un workflow de n8n puede crear la carpeta del cliente, enviar el correo de bienvenida y abrir la tarea de onboarding. n8n es una herramienta de automatización de flujos, y su documentación lista los conectores disponibles. Pequeñas automatizaciones junto a la herramienta ahorran a menudo más horas que una pantalla más.
Desarrollo de herramientas internas a medida: fases y presupuesto
Una primera versión cabe en 4 a 8 semanas cuando cubre un solo flujo. Un equipo, un flujo y dos o tres roles es un objetivo inicial realista, y se puede ampliar cuando la gente ya la use.
Fases típicas semana a semana
- Semana 1
Alcance y mapa de accesos
Tú y el proveedor acordáis el flujo, las pantallas, los roles y los sistemas implicados.
- Semanas 2 a 3
Datos e inicio de sesión
Se construyen las conexiones con tus sistemas y funciona el acceso con roles.
- Semanas 3 a 6
Pantallas principales
Las pantallas del flujo toman forma, con revisiones que puedes recorrer con clics cada semana.
- Semanas 6 a 7
Pruebas con usuarios reales
Tu equipo ejecuta tareas reales y el proveedor corrige lo que les estorba.
- Semana 8
Lanzamiento y entrega
La herramienta sale a producción con una formación breve, documentación y el código en tu repositorio.
Dos o tres personas de tu equipo deberían probar durante las semanas 6 a 7, con tareas reales. Su opinión pesa más que cualquier especificación. El primer mes tras el lanzamiento sirve para eliminar pequeñas fricciones.
Qué sube o baja el precio
La tabla da rangos típicos de mercado a modo de ilustración. No son presupuestos de werun.dev, y tu alcance fija el número real.
| Tamaño | Qué cubre | Tiempo típico | Rango ilustrativo (USD) |
|---|---|---|---|
| Small | Un flujo, uno o dos roles, una fuente de datos | 4 a 5 semanas | 8,000 a 20,000 |
| Medium | Dos o tres flujos, varios roles, dos o tres integraciones | 6 a 8 semanas | 20,000 a 50,000 |
| Large | Varios equipos, reglas complejas, sistemas heredados, acceso de clientes | 3 meses o más, por fases | 50,000 en adelante |
El precio sube con el número de integraciones, los sistemas sin API, las reglas de aprobación complejas, el acceso para clientes y los informes pesados. Baja con un flujo claro, datos limpios, un diseño existente que seguir y respuestas rápidas por tu parte. En werun.dev los proyectos se dimensionan en Small, Medium, Large o Custom, y puede seguir un Retainer o un plan Care mensual cuando la herramienta esté en marcha.
Preguntas para evaluar a un proveedor y señales de alerta
Los buenos proveedores agradecen las preguntas sobre propiedad y entrega. Usa la lista siguiente en tu primera llamada y compara las respuestas entre dos o tres propuestas.
Siete preguntas antes de firmar
- ¿Quién es dueño del código y de los datos una vez pagado el proyecto?
- ¿Dónde se aloja la herramienta y en la cuenta de quién?
- ¿Cómo se gestionan los inicios de sesión, los roles y los registros de auditoría?
- ¿Cómo es la entrega y qué documentos recibo?
- ¿Qué pasa tras el lanzamiento: soporte, correcciones y tiempos de respuesta?
- ¿Quién trabajará exactamente en ella y quién es mi contacto?
- ¿Pueden mostrar trabajos similares y explicar las decisiones que tomaron?
Escucha los detalles. Un proveedor que ya lo ha hecho nombra un proveedor de hosting, describe cómo se guardan los roles y explica qué contiene el paquete de entrega. Nuestro proyecto de la app Casamiento muestra cómo es una aplicación hecha a propósito, frente a una plantilla.
Señales de alerta en las propuestas
- Un precio cerrado sin alcance escrito ni lista de lo que queda excluido.
- Código en la cuenta del proveedor sin promesa de transferencia.
- Ninguna mención a roles, inicios de sesión o pruebas.
- Hosting en un servidor personal sin plan de copias de seguridad.
- La promesa de tenerlo todo en dos semanas.
- Ningún equipo ni contacto con nombre.
- Presión para firmar antes de haber visto un plan.
Una señal de alerta es motivo para preguntar. Tres son motivo para seguir buscando.
Por dónde empezar esta semana
Empieza con una página. Elige el flujo que más horas cuesta a tu equipo y anota cinco cosas: quién lo usa, qué hace hoy, qué debe mostrar la herramienta, quién puede cambiar qué y qué sistemas guardan los datos. Envía esa página a dos o tres proveedores y compara cómo responde cada uno.
Si quieres un equipo que defina el alcance contigo, cuéntanos tu objetivo en la página de contacto y respondemos en menos de 2 horas en días laborables. Puedes ver el abanico de lo que construimos en nuestra página de soluciones, y cómo funciona un desarrollo a medida en la página de aplicaciones a medida.
Preguntas frecuentes
¿Quién puede desarrollar herramientas internas a medida para mi empresa?
Pueden hacerlo un desarrollador interno, un freelance, una agencia o un consultor low-code. Elige según el tamaño y la vida útil: un consultor low-code para necesidades de corta vida, una agencia para herramientas centrales con varias integraciones y reglas de acceso estrictas.
¿Cuánto cuesta un dashboard de administración a medida?
Los rangos típicos de mercado, dados aquí como ilustración, van de unos 8,000 a 20,000 USD para una herramienta pequeña de un solo flujo hasta 50,000 USD o más para un sistema grande de varios equipos. Las integraciones, los sistemas heredados y las reglas de acceso son lo que más mueve el precio.
¿Es mejor Retool o una herramienta interna a medida para mi equipo?
Retool y otras plataformas low-code suelen ganar en herramientas de corta vida y equipos de menos de unos 20 usuarios, porque son rápidas y baratas de arrancar. Lo a medida gana cuando muchos usuarios, reglas inusuales, accesos estrictos o una larga vida hacen costosas las licencias por usuario y los límites de la plataforma.
¿Cuánto tarda en construirse una herramienta interna?
Una primera versión que cubre un flujo suele llevar de 4 a 8 semanas: alcance, datos e inicio de sesión, pantallas principales, pruebas con usuarios reales y lanzamiento. Las herramientas más grandes se entregan por fases después de esa primera versión.
¿Qué debe incluir el contrato de una herramienta interna?
Debe indicar quién es dueño del código y de los datos, que el hosting está en tu propia cuenta, un alcance escrito con exclusiones, los requisitos de acceso y auditoría, una entrega con documentación y las condiciones de soporte tras el lanzamiento.
