Brújula, Mapa, Travesía: cómo presupuestamos un proyecto antes de tocar código

La mayoría de proyectos de software que fallan, fallan antes de que se escriba la primera línea de código.

Fallan porque nadie se sentó a pensar qué se iba a construir. Fallan porque “el alcance se aclarará sobre la marcha”. Fallan porque la conversación inicial entre cliente y equipo técnico duró 30 minutos y se pasó directo a “construyamos”. Y fallan, casi siempre, porque la cuenta final no tiene nada que ver con la conversación inicial.

Norteworks divide cada proyecto en tres fases — Brújula, Mapa, Travesía — por una razón muy concreta: forzar la definición antes de la construcción. No es un proceso bonito para usar en propuestas; es la manera más barata que conocemos de evitar que un proyecto de 12.000€ acabe costando 30.000€.

Este post explica, sin filtros, qué pasa en cada fase, qué te llevas, qué decisiones se toman, y dónde encaja (o no) este modelo.

Fase 1 · Brújula

Llamada estratégica de 30 minutos. Gratuita. Sin compromiso.

Su único objetivo es entender hacia dónde quieres ir y qué te frena hoy. No es una llamada de venta — es una llamada de diagnóstico.

Qué te pregunto

Estas son las 7 preguntas que estructuran cualquier Brújula:

1. ¿Qué resuelve esto que quieres construir, y para quién? Si no puedes contestar en una frase, ahí ya hay trabajo de aterrizaje.
2. ¿Qué pasa si no se construye? La respuesta diferencia un proyecto inevitable de un nice-to-have caro.
3. ¿Qué intentaste antes, y qué pasó? Aquí salen los Excel que ya no escalan, los SaaS que no cubren tu caso, los freelance que no entregaron.
4. ¿Qué restricciones tienes — presupuesto, plazo, equipo? Sin restricciones explícitas, el alcance se va de las manos.
5. ¿Qué sistemas ya tienes y cómo encajan con esto? Casi todo se integra con algo. Saber con qué cambia el coste.
6. ¿Quién va a usar esto, cuántos son, y cómo lo medimos? Define rendimiento, UX y prioridades de fase 1.
7. ¿Cómo se ve “éxito” para ti dentro de 6 meses? Sin esto, no hay forma de saber si lo entregado es valioso.

Qué NO necesitas traer

Mucha gente se sienta a la Brújula nerviosa por no tener “los requisitos listos”. No los necesitas.

No necesitas mockups, ni specs, ni una lista de features. Si los tienes, los miramos — pero a menudo el primer hallazgo de una Brújula es que la lista de features no es lo que tu negocio realmente necesita.

Lo que sí ayuda traer: el contexto de negocio (qué haces, a quién vendes, dónde te aprieta el zapato). Eso es todo.

Cuándo te digo “esto no es para mí”

A veces, después de 20 minutos de Brújula, lo correcto es decirte que Norteworks no es lo que necesitas. Tres casos típicos:

• Lo que quieres se resuelve con un SaaS de 50€/mes y dos tardes de configuración. No necesitas software a medida — te explico cuándo NO necesitas un estudio de software.
• Lo que quieres se resuelve con contratar un developer junior durante 3 meses. No necesitas un estudio — te explico cómo dimensionar la contratación.
• Lo que quieres no se sostiene como hipótesis de negocio. Te decimos qué validarías primero antes de gastar un euro construyendo.

Esta honestidad operativa tiene un coste — descartamos clientes — y un retorno: cuando alguien sí encaja con Norteworks, llega ya pre-cualificado.

Quién está al otro lado de la llamada

Hablas conmigo (Fabián), no con un comercial. La persona que diagnostica el problema en la Brújula es la misma que define el alcance en el Mapa y la misma que construye en la Travesía. Cero handoffs entre vendedor → account manager → técnico. Cero teléfono escacharrado.

Qué te llevas

• Resumen escrito del problema en 1 página.
• Hipótesis técnica inicial (stack, integraciones, esfuerzo aproximado).
• Un primer rango de inversión orientativo. El precio cerrado se define en la fase de Mapa, no aquí.
• Un siguiente paso claro, aunque ese paso no seamos nosotros.

Si tras la Brújula no encaja, no encaja. Has invertido 30 minutos. Has aprendido algo. No te he cobrado nada.

Fase 2 · Mapa

Definición. 1-2 semanas. Precio acordado tras la Brújula.

Aquí pasamos de “lo que quieres” a “lo que vamos a construir”. Es la fase más infravalorada del proceso y la que más dinero ahorra.

El framework 80/20 aplicado al alcance

El alcance ideal de un MVP siempre es el doble de lo que el presupuesto permite. Esto es universal.

El trabajo del Mapa es separar:

• El 20% del alcance que entrega el 80% del valor — lo que entra en la fase 1 de Travesía.
• El 80% del alcance que entrega el 20% del valor — lo que se faseará en versiones posteriores (v2, v3) o se descartará por completo cuando descubras, una vez en producción, que no hacía falta.

La conversación dura — y donde se gana el Mapa — es cuando hay que descartar una feature que tú considerabas imprescindible. La respuesta no es “no se hace”; la respuesta es “se hace en v2 si los datos lo justifican”.

Por qué estimamos por fase y no por horas

Cobrar por horas es cómodo para el proveedor y un riesgo enorme para el cliente: el incentivo del proveedor es alargar, el del cliente es acortar, y las negociaciones se centran en horas trabajadas en vez de en valor entregado. Por eso facturamos por fase con precio cerrado.

Cada fase de Travesía tiene un precio cerrado acordado en el Mapa. Si tardamos más por nuestra parte, lo absorbemos nosotros. Si tardamos más porque tú cambias el alcance, lo recotizamos en un mini-anexo antes de tocarlo.

Qué hay dentro del documento de propuesta

Lo que firmas al final del Mapa es un documento de 6-10 páginas con:

• Alcance detallado por bloque, con qué entra y qué no entra explícito. El “no entra” es tan importante como el “entra”.
• Hitos con fechas y entregables tangibles cada 1-2 semanas.
• Precio cerrado por fase, sin asteriscos.
• Stack técnico concreto (base de datos, framework, cloud, integraciones de terceros).
• Periodo y términos de soporte post-launch.
• Contrato modelo con cláusulas de propiedad de código, confidencialidad, condiciones de pago y caso de estudio negociado.

Si en algún momento hay algo no cerrado en este documento, no firmamos.

El “viable check” — cuándo decimos que la idea no se sostiene

A veces, profundizando en el alcance, descubrimos que la idea no se sostiene como está planteada. Tres ejemplos neutros de cosas que han hecho saltar el viable check:

• Una integración con un sistema legacy que el proveedor no soporta. El coste real se duplica y la idea no aguanta el rango original.
• Un volumen de usuarios estimado que requiere una arquitectura de coste recurrente desproporcionado al valor por usuario.
• Una restricción regulatoria que no se descubrió en la Brújula y que cambia radicalmente el alcance.

Cuando esto pasa, te lo decimos antes de empezar a construir. Y no cobramos la fase de Mapa. Te quedas con el documento, con las decisiones tomadas, y con un siguiente paso claro — aunque ese siguiente paso sea “no construir todavía”.

El coste real de construir lo equivocado son 6 meses y 18.000€. El coste de la fase de Mapa, si decides no continuar, son 0€. Es el seguro más barato que vas a contratar.

Fase 3 · Travesía

Construcción. 4-8 semanas para una primera versión funcional. Hasta 16 semanas para producto completo.

Aquí construimos lo definido en el Mapa. Sin sorpresas — porque las sorpresas se gestionaron en las fases anteriores.

Anatomía de un bloque de 2-4 semanas

Cada bloque de Travesía tiene la misma estructura:

• Día 1: kick-off del bloque. Revisamos el alcance, qué se entrega al cierre, qué riesgos hay.
• Días 2-N: construcción. Commits a tu repositorio. Branches por feature, PRs revisados.
• Cada 5-7 días hábiles: demo en vivo de lo construido. Tú decides si la dirección es correcta o si hay que ajustar.
• Día final del bloque: entregable cerrado en staging, decisión de pasar a producción o continuar al siguiente bloque.

Esto significa que ves el producto funcionando cada semana. No slides, no avances reportados por email, no “estamos al 60%”.

Propiedad del código desde el primer commit

El repositorio es tuyo desde el primer día. No es nuestro, no es compartido — es tuyo.

• Organización en GitHub o GitLab a tu nombre (o el de tu empresa).
• Tus permisos: tú decides quién tiene acceso y con qué nivel.
• Convención de branches estándar (main, develop, feature/*, fix/*).
• PRs como cualquier equipo serio: con descripción, con review, con merge limpio.
• Documentación técnica en docs/ desde el primer commit, no al final.

Si en cualquier momento del proyecto decides cancelar, te quedas con todo lo construido hasta ese punto. No hay rescate de código, no hay handover dramático, no hay claves que pedir.

Comunicación: qué va síncrono y qué va asíncrono

Para que el modelo funcione, la mayoría de la comunicación es asíncrona:

• Asíncrono (90% del tiempo): PRs, mensajes en el canal acordado (Slack/Telegram/email), commits, status semanal por escrito.
• Síncrono (10% del tiempo): demo semanal de 30 min, decisiones de trade-off importantes, cierre de hito.

Esto te libera tiempo de calendario y te da una traza escrita de cada decisión. Si dentro de 4 meses te preguntas “por qué decidimos hacer X así”, está documentado.

Cambios de alcance a mitad de proyecto

Los cambios de alcance pasan. Una integración nueva que descubres, un cambio en tu modelo de negocio, una feature que ves clara después de la primera demo. Cuando pasa:

• Cambios pequeños (1-3 días de trabajo): entran sin recotizar, los gestionamos como ajuste de bloque.
• Cambios medianos o grandes: paramos, evaluamos, te paso un mini-anexo por escrito con coste y plazo del cambio, decides si entra o se faseará.

Cero “te lo metemos en la próxima fase y ya veremos”.

Handover detallado

El final de la Travesía incluye:

• Producción funcionando en tu infraestructura (Cloudflare, AWS, GCP, donde tenga sentido).
• Monitorización configurada — logs, errores, métricas básicas.
• Documentación técnica completa: arquitectura, despliegue, runbook de incidentes típicos.
• Accesos transferidos — todas las cuentas, claves y secrets en tu propiedad.
• Sesión de transferencia con tu equipo (o el equipo que vayas a contratar) si aplica.

Soporte post-launch

El periodo de soporte acordado (típicamente 1-3 meses) cubre:

• Bugs encontrados en producción.
• Micro-ajustes y consultas técnicas.
• Patching crítico de seguridad.

NO cubre: nuevas features, cambios de alcance, refactors. Eso se trata como una fase nueva con su propio Mapa.

Por qué este orden y no otro

La industria estándar funciona al revés:

1. Te piden “tus requisitos” sin haber entendido tu negocio.
2. Te dan un presupuesto sobre esos requisitos.
3. Empiezan a construir.
4. Aparecen las preguntas que nadie hizo antes.
5. Aparecen los retrasos y los anexos.

El orden Brújula → Mapa → Travesía invierte la secuencia:

1. Entendemos tu negocio primero (Brújula).
2. Definimos qué construir antes de tocar código (Mapa).
3. Construimos lo definido, sin sorpresas (Travesía).

La diferencia operativa son 1-2 semanas más arriba. La diferencia económica son entre 3.000€ y 18.000€ menos abajo. La diferencia psicológica es no tener que defenderte cada lunes de “por qué se ha retrasado otra vez”.

Errores típicos que evita este proceso

Tres anti-patrones de la industria que vemos repetidamente, y cómo cada fase los previene:

Error 1 · El proyecto que se duplica de precio

Cómo ocurre: el cliente firma un presupuesto basado en “los requisitos” iniciales sin haber aterrizado el alcance MVP. A las 3 semanas aparece la primera feature “imprescindible” que no estaba estimada. A las 6 semanas, otra. Al cierre, el precio se ha duplicado y la relación está rota.

Cómo lo previene el Mapa: el alcance se define en detalle antes de empezar, con el “no entra” explícito. Los cambios mid-project se gestionan con mini-anexo antes de tocarlos, no se cuelan en el siguiente hito.

Error 2 · El producto que se construye pero nadie usa

Cómo ocurre: el cliente pidió X porque “siempre quiso tener X”. Nadie preguntó si X resolvía un problema real. Se construye, se lanza, los usuarios no aparecen. Pérdida total.

Cómo lo previene la Brújula: las preguntas 2 (“qué pasa si no se construye”) y 7 (“cómo se ve éxito en 6 meses”) fuerzan a articular la hipótesis de valor antes de gastar un euro. Si la hipótesis no es defendible, no se llega al Mapa.

Error 3 · El handover que nunca se completa

Cómo ocurre: el equipo externo construye en su repositorio, con sus claves, con su infraestructura. Al cierre, “te pasamos el código” se convierte en semanas de fricción para que liberen accesos, documentación y propiedad. A veces, nunca llega.

Cómo lo previene la Travesía: el código vive en tu repo desde el primer commit. La documentación se escribe en docs/ mientras se construye, no después. Los accesos están a tu nombre, no al nuestro. No hay nada que “transferir” porque nunca dejó de ser tuyo.

Estos tres errores cuestan, en estimaciones razonables, entre el 30% y el 100% adicional sobre el coste base del proyecto. El proceso no los elimina al 100% — los reduce a una probabilidad gestionable.

Quién encaja con este proceso y quién no

Norteworks no es para todo el mundo. Filtrar bien al principio ahorra tiempo a ambos lados.

Encaja si

• Eres una PYME invirtiendo entre 6.000€ y 25.000€ en su primer producto digital serio o en la modernización de uno existente.
• Eres founder de una startup pre-seed o seed con un MVP claro que necesitas validar o construir.
• Eres fundador no-técnico y necesitas un partner técnico con quien hablar de tú a tú, sin filtros.
• Tienes un equipo interno pequeño que necesita un especialista externo durante 2-6 meses para sacar una pieza concreta.
• Valoras tener el código en tu propiedad desde el primer día, sin lock-in técnico ni comercial.

No encaja si

• Necesitas pasar por compras corporativas, comité de aprobación o procesos RFP formales. El proceso de Norteworks asume agilidad de decisión.
• Buscas freelance por horas para “echar una mano puntual”. Aquí está la diferencia entre contratar un estudio y un freelance.
• Tu equipo ya tiene specs cerradas y detalladas y solo necesita “manos que ejecuten” — vas a pagar overhead innecesario por una fase de Mapa que no necesitas.
• El alcance está intencionadamente abierto porque “ya lo vamos viendo sobre la marcha”. No trabajamos así.
• Esperas un partner que diga sí a todo. Si te decimos “esa feature no entra ahora”, es porque tras analizarlo no entra. Renegociar cada decisión técnica desgasta a ambos lados.

Si no estás seguro de en qué grupo encajas, la Brújula es exactamente para descubrirlo. 30 minutos, gratis, sin compromiso.

Preguntas frecuentes

¿Y si tras el Mapa no tengo presupuesto para la Travesía completa?

El Mapa por diseño puede fasearse: te entregamos el documento con la fase 1 como precio cerrado y la fase 2 como rango orientativo. Puedes empezar solo la fase 1, validar en producción, y decidir luego si continuar. Si la fase 1 no se sostiene, paramos sin daño.

¿Cómo me aseguro de que otro equipo pueda mantener el código después?

Tres cosas: (1) el código sigue convenciones estándar del ecosistema (no inventamos abstracciones propias), (2) la documentación técnica vive en el repositorio desde el primer día (docs/architecture.md, docs/deployment.md, runbook), (3) en el handover hacemos una sesión técnica grabada con tu equipo o el equipo que contrates. Para validarlo, puedes pedir auditoría externa antes de cerrar el soporte — lo recomendamos.

¿Puedo añadir más gente al equipo si necesitamos acelerar?

Sí, pero con cabeza. Norteworks no escala metiendo juniors — la propuesta de valor es construcción senior directa. Si necesitas acelerar, evaluamos juntos si el cuello de botella se resuelve con más manos (raro) o con paralelizar fases del Mapa (más frecuente). Si hace falta refuerzo, lo subcontratamos con un perfil cualificado, con el coste transparente.

¿Cómo funciona si trabajo desde otro huso horario?

Todo el modelo es asíncrono por defecto. Las demos semanales se agendan en una ventana compatible con tu huso. La comunicación operativa va por canal escrito sin esperar respuesta en tiempo real. Hemos trabajado con clientes desde España con LATAM (UTC-5 a UTC-3) sin fricción material.

¿Qué pasa si necesito un NDA antes de la Brújula?

Sin problema. Mándalo antes de la llamada, lo firmo y volvemos a agendar. Si prefieres usar uno modelo nuestro, lo enviamos. Para la mayoría de Brújulas no hace falta — pero si lo necesitas, no es bloqueante.

¿Puedo ver código en progreso o solo demos?

Las dos cosas. El repositorio es tuyo desde el primer commit, así que puedes mirar el código en cualquier momento. Las demos semanales son para que veas funcionalidad sin tener que leer código. Si quieres revisar PRs como parte de tu equipo, te invitamos como reviewer.

¿Y si tras el lanzamiento descubrimos un bug crítico?

Durante el periodo de soporte acordado (1-3 meses tras lanzamiento), los bugs en producción los arreglamos sin coste extra. Fuera del periodo de soporte, se trata como una intervención puntual con presupuesto cerrado, normalmente por unas horas o un día. Bugs de severidad crítica (caída total, pérdida de datos) los atendemos en primera prioridad incluso fuera del periodo de soporte — no es algo que dejemos sin respuesta.

Cómo empezar

Tres caminos según tu nivel de definición:

• Si solo tienes una idea aproximada: calcula un rango orientativo en 30 segundos. La calculadora te da un orden de magnitud antes de hablar con nadie.
• Si tienes claro que quieres hablar: agenda la Brújula — 30 minutos, gratuita, sin compromiso. Lleva el contexto de negocio, no necesitas requisitos cerrados.
• Si prefieres explorar antes: lee el resto del blog o mira la versión visual del proceso con timeline horizontal y comparativas.

Si tras la Brújula no encaja, no encaja. Pero al menos sabrás por dónde empezar.