El trabajo vive en hojas de cálculo
Varias personas editan la misma hoja de Google, las versiones se desincronizan y nadie puede recuperar el historial de cambios.
Áreas privadas, CRM internos, calculadoras de presupuestos, paneles de gestión con roles. Una sola herramienta en lugar de hojas de cálculo y correos.
Varias personas editan la misma hoja de Google, las versiones se desincronizan y nadie puede recuperar el historial de cambios.
Un gestor calcula el presupuesto o el precio en una calculadora siguiendo instrucciones. Hay errores y la velocidad depende de la persona.
Habéis mirado varios CRM y en cada uno sobra el 80% y falta el 20% necesario. O existe, pero cuesta como un proyecto aparte.
Estado del pedido, documentos, historial: todo hay que preguntárselo a un gestor, que se pasa media jornada en ello.
Parte en el CRM, parte en el sistema contable, parte en el correo. Es imposible juntar la imagen completa.
Vuestra herramienta no solo os sirve a vosotros, y pensáis en suscripciones, planes y cuentas separadas para clientes.
Propietario, gestor, cliente, contratista: cada uno ve lo suyo.
Por departamento, sucursal o proyecto.
Quién cambió qué y cuándo, con posibilidad de deshacer.
Si hace falta, para roles con acceso a dinero y datos personales.
Una estructura para vuestras entidades, no para una plantilla ajena.
Aguantan cientos de miles de registros sin ralentizarse.
Traslado de lo que hoy vive en Excel y Google Sheets.
Las mismas con las que hoy calcula el gestor, solo que sin errores.
Por responsables, estados, líneas de negocio.
Con vuestra plantilla, no una tabla estándar.
Contratos, facturas, actas: directamente desde los datos del sistema.
En la página principal, para no montar la imagen a mano cada mañana.
Telegram, correo, SMS: donde os resulte más cómodo.
CRM, control de inventario, contabilidad.
Si es un SaaS: planes de tarifas y cobros recurrentes.
Para una app móvil o para socios.
No «qué debe saber hacer el sistema», sino cómo está organizado hoy el trabajo: quién hace qué, de dónde salen los datos, dónde se pierde el tiempo. A menudo la mitad de los deseos se cae ya aquí. 3–5 días.
Un esquema navegable de pantallas: se ve la lógica, las transiciones y los datos. Cambiar algo aquí cuesta horas, no una semana de rehacer código. 1–2 semanas.
Dividimos el sistema en módulos, cada uno con su precio y plazo. Ves qué entra en el primer lanzamiento y qué puede esperar. Junto con el prototipo.
Cada dos semanas, un módulo operativo que se puede abrir y probar. Las prioridades entre fases se pueden cambiar.
Migramos los datos, formamos al equipo y durante un mes seguimos de cerca. Después, evolución según vuestras tareas.
Una aplicación web no se calcula «por páginas», sino por la complejidad de su lógica. Las referencias de abajo salen de nuestros proyectos.
Un solo rol de usuario, lógica clara, unos pocos tipos de datos.
Varios roles, procesos propios, informes e intercambio con los sistemas existentes.
Un servicio por suscripción: muchos clientes, planes, pagos y aislamiento de datos.
La primera fase —análisis del proceso y prototipo— se puede contratar por separado por $1200. Recibes un esquema del sistema y una estimación con la que puedes acudir a cualquier proveedor, no solo a nosotros.
La pregunta «propio o ya hecho» conviene responderla con honestidad, y la respuesta suele estar del lado de lo ya hecho. Si vuestro proceso es típico y en el mercado hay un servicio que lo cubre por un precio razonable, desarrollar un sistema propio será más caro y más lento. Se lo decimos a los clientes los primeros.
Un sistema propio se justifica en tres casos. Primero: el proceso no encaja en una lógica ajena y adaptáis el trabajo al programa en lugar de que el programa se adapte a vosotros. Segundo: las funciones necesarias existen, pero cuestan de forma desproporcionada; por una sola capacidad hay que comprar el plan más caro para todo el equipo. Tercero: el propio sistema es un producto que pensáis vender.
El principal riesgo en estos proyectos no es técnico, sino que se construya el sistema equivocado. Por eso no empezamos por el código, sino por el análisis del proceso actual: quién hace qué, de dónde salen los datos, dónde exactamente se pierde el tiempo. A menudo en esta fase la mitad de los deseos iniciales desaparece: resulta que una solución más sencilla cubre la tarea.
Después viene un prototipo navegable sin diseño: un esquema de pantallas, transiciones y datos. Cambiar algo en el prototipo cuesta una hora; en código ya escrito, semanas. Aquí es donde más barato salen los errores de lógica.
El desarrollo se hace por fases, cada una con su precio y plazo. Cada dos semanas recibes una parte que se puede abrir y probar. Esto elimina el gran miedo de los proyectos grandes: en cualquier momento se ve por qué se ha pagado y en cualquier momento se puede parar teniendo en la mano un sistema operativo, y no una carpeta con código.
Un área privada o una calculadora con un solo rol: desde $6000 y 8–10 semanas. Un sistema interno con varios roles, procesos e informes: desde $12000, a partir de tres meses. Un SaaS con suscripciones: desde $20000. La estimación exacta aparece tras el prototipo.
Porque antes de analizar el proceso nadie —ni nosotros ni vosotros— conoce el alcance exacto. Se puede decir una cifra al azar, pero estará inflada «por si acaso» o será demasiado baja, y entonces por el camino «aparecen» trabajos adicionales. Damos una horquilla de entrada y el precio exacto tras el prototipo, cuando se ve cada pantalla.
A menudo sí, y seremos los primeros en decirlo. Un sistema propio se justifica cuando vuestro proceso no encaja en una lógica ajena, cuando los servicios ya hechos piden un precio desproporcionado por las funciones necesarias, o cuando el propio sistema se convierte en producto.
El prototipo, 1–2 semanas tras el inicio, y ya se puede navegar. El primer módulo operativo, que se abre en el navegador y trabaja con datos reales, en 3–4 semanas. Después, cada dos semanas se añade el siguiente módulo.
Laravel en el backend, Next.js o Inertia + React en el frontend, PostgreSQL o MySQL según la tarea. Apps móviles: Flutter. Elegimos la pila según el proyecto y según quién mantendrá el sistema después.
Sí, es una parte estándar del lanzamiento. Migramos desde hojas de cálculo, exportaciones CSV o directamente desde la base del sistema antiguo. Antes de migrar mostramos cómo encajarán los datos en la nueva estructura, para que no se descubra después que falta algo.
Durante un mes tras el lanzamiento seguimos de cerca; está incluido en el precio. Después, o bien un abono de evolución o bien trabajo por horas bajo demanda. El código, el repositorio y los accesos son vuestros: cualquier desarrollador puede continuar.
Hablar del sistema
Iniciar un proyecto