Esto no empieza con código. Empieza mirando cómo trabajan hoy.
Cuatro fases. Cada una tiene un gate de salida, y el gate limita al proveedor, no a ti: no se avanza a la siguiente hasta cumplirlo.
- 01
Medir el proceso
Qué pasaNos sentamos con quien hace el trabajo, no solo con quien lo dirige. Escribimos el proceso paso a paso como ocurre de verdad, con sus excepciones y sus parches. Contamos cuántas personas lo tocan, cada cuánto y cuánto tiempo les toma, y traducimos eso a lo que cuesta al mes.
Qué necesito de tiUna conversación con la persona que hoy sostiene el proceso, y acceso de lectura a lo que ya existe: la hoja de cálculo, el reporte, la bandeja de correo. Nada de preparar material.
Con qué te quedasEl proceso escrito paso a paso y su costo mensual, en un documento tuyo. Sirve aunque no sigas conmigo.
No se avanza hasta que confirmes que el número es real y que ese proceso vale la pena resolver.
- 02
Definir el alcance
Qué pasaEscribo qué va a hacer la solución y, más importante, qué deliberadamente no va a hacer. Definimos una métrica que decide si funcionó, antes de construir nada. Acá es donde se decide lo caro: cada funcionalidad que suena razonable y nadie pidió es margen que se va y una entrega que se estira.
Qué necesito de tiQue alguien con autoridad para decidir revise el alcance y diga que sí o que no. Media hora, no un comité.
Con qué te quedasAlcance cerrado por escrito, precio fijo y la métrica de éxito acordada. Sin sorpresas después.
No se avanza hasta que el alcance esté firmado y los dos sepamos qué queda fuera.
- 03
Construir lo mínimo
Qué pasaConstruyo lo más pequeño que mueve la aguja, no la plataforma completa. Programo con IA, así que lo repetitivo va rápido y el tiempo se me va en la arquitectura y en los casos raros de tu operación, que es donde un proyecto de software se cae. Por eso lo ves funcionando temprano y con tus datos, no en una demo con datos de mentira. Si algo no encaja con cómo trabajan, se corrige ahí y no tres meses después.
Qué necesito de tiUna persona de tu equipo disponible para probarlo y decirme qué está mal. Es el rol más importante del proyecto y el que más se subestima.
Con qué te quedasLa solución corriendo y usada por tu equipo, no un entregable esperando aprobación.
No se avanza hasta que tu equipo lo esté usando y confirme que resuelve el cuello.
- 04
Dejarlo instalado
Qué pasaPasa a producción en tus cuentas y con tus accesos. Antes de que nadie de tu equipo lo toque hago revisión de seguridad, porque el software maneja datos de terceros y las vulnerabilidades son invisibles hasta que se explotan. Documento cómo opera y qué hacer si algo falla.
Qué necesito de tiQue definas quién queda como dueño interno del sistema. Alguien tiene que poder responder "¿a quién le pregunto?".
Con qué te quedasCódigo, datos y accesos a nombre de tu empresa, más el runbook de operación.
No se avanza hasta que corra en tu producción sin que yo tenga que estar apagando incendios.
Una hoja de cálculo no puede negarse. Un sistema con tus reglas escritas, sí.
Así se ve lo que sale de la fase 03 cuando el proceso es cotizar. Las reglas de precio dejan de vivir en la cabeza de una persona y pasan a estar escritas donde se aplican: el descuento por volumen entra solo si la cantidad lo justifica, el plazo fuera de política pide aprobación en vez de pasar sin que nadie lo note, y un descuento por encima del máximo no se puede guardar.
Es una ilustración del producto, no un caso de cliente. Los números son de ejemplo y se pueden sumar en la misma pantalla: acá no hay ninguna cifra de resultado que no puedas verificar.
Ilustración de producto. Datos de ejemplo.
Si mañana dejo de estar, todo esto sigue funcionando.
La objeción de fondo cuando contratas software a medida es quedarte colgado del proveedor. Estas cuatro cosas existen para que eso no pase, y no son un extra del final: se cumplen desde el primer día.
- El repositorio es tuyo El código vive en una cuenta de tu empresa desde el primer commit, no en la mía. No hay nada que "transferir" al cierre porque nunca fue mío.
- Los datos y accesos también Las cuentas de los servicios que usa la solución van a nombre de tu empresa y pagadas por tu empresa. Puedes cambiar la contraseña hoy y seguir operando.
- Está documentado para otro dev El runbook explica cómo corre, qué se rompe primero y qué hacer. Está escrito para que otro desarrollador lo tome, no para que dependas de mí.
- Stack estándar, no propietario Se construye con herramientas que cualquier desarrollador conoce. Nada que solo yo pueda mantener, porque eso te ata y no es un favor.
Acá no se cobra por hora. Se cobra por el proceso que queda resuelto.
Cobrar por hora premia al proveedor lento y castiga al que resuelve rápido. Cobrar por licencia por usuario te penaliza justo cuando la solución funciona y más gente la usa. Ninguno de los dos modelos está alineado con lo que tú quieres, que es que el proceso deje de costarte. El precio fijo se sostiene por lo mismo que hace posible la fase 03: con IA, construir dejó de ser la parte cara del proyecto. La parte cara es decidir qué construir, y esa se resuelve antes de que empiece el trabajo.
Por eso cada propuesta parte del número de la fase 01: lo que ese proceso te cuesta hoy al mes. Sobre ese número se define un precio fijo y cerrado, por escrito, antes de que empiece cualquier trabajo. Si el proceso no cuesta lo suficiente como para justificar resolverlo, la respuesta honesta es esperar, y te la voy a dar.
No publico una lista de precios porque cobrar lo mismo por automatizar un reporte semanal que por construir un cotizador con reglas de margen no le sirve a nadie. El modelo sí está acá completo: no mostrar precios y no explicar cómo cobras son dos cosas distintas.
No todo proceso vale la pena automatizar. Te lo digo en la primera llamada.
Una llamada de 30 minutos. Salgo de ahí con tu proceso escrito paso a paso y qué te cuesta al mes. Si no vale la pena automatizarlo todavía, te lo digo.