Cuando reviso una idea para convertirla en software, empiezo por la decisión que debe permitir tomar. Un presupuesto puede agotarse entre supuestos sin probar y funciones que no ayudan a resolverlos. Antes de estimar, dejo por escrito usuario, problema, recorrido crítico y evidencia necesaria para financiar el siguiente paso.
Si todavía no hay evidencia del problema o del comprador, empieza por validar la idea antes de programar. Esta guía parte del siguiente paso: concretar qué software hace falta para probar su uso.
Empieza por la decisión que debe desbloquear el MVP
Formula una pregunta medible: ¿completará un cliente concreto un flujo concreto y aceptará una condición comercial concreta? Entrevistas, un prototipo o un servicio manual pueden responder antes de desarrollar. Programa solo la incertidumbre que no puedas comprobar de una forma más barata.
Define éxito y condiciones de parada por adelantado. Activación, tarea completada, uso repetido, solicitudes cualificadas o ventas son métricas útiles. Las visitas por sí solas rara vez validan un producto.
Convierte el alcance en un único corte vertical
Un MVP creíble suele necesitar un camino completo: identificarse, aportar el dato mínimo, recibir el resultado prometido y recuperarse de un error. Mantén manual la administración mientras haya poco volumen. Usa servicios consolidados para autenticación, pagos, correo y hosting.
Separa debe funcionar ahora, puede ser manual y más adelante. Cada función necesita responsable, criterio de aceptación y vínculo con el experimento. Es la disciplina que explico en cómo pienso un proyecto técnico antes de escribir código.
Ejemplo de alcance: un portal de solicitudes B2B
Este es un ejemplo hipotético, no un proyecto de cliente. Una empresa quiere comprobar si sus clientes pueden enviar solicitudes completas y consultar su estado sin perseguir al equipo por correo. La primera versión probaría ese recorrido con usuarios invitados. El número de participantes, el periodo y los umbrales se acuerdan antes de empezar según la frecuencia real del proceso.
| Necesidad | Primera versión | Límite explícito |
|---|---|---|
| Enviar una solicitud | Formulario con datos necesarios, confirmación e identificador. | Un tipo de solicitud; sin constructor de formularios. |
| Consultar el estado | El cliente ve sus solicitudes y el último estado confirmado. | Sin acceso a datos de otras empresas; sin informes personalizados. |
| Resolver la solicitud | Un operador revisa y actualiza el estado manualmente. | Responsable y tiempo dedicado registrados; sin sincronización ERP todavía. |
| Invitar clientes | Alta por invitación y permisos comprobables. | Sin registro público, planes ni facturación automática. |
| Medir el experimento | Inicio, envío válido, consulta de estado y ayuda del operador. | Contar solicitudes únicas; excluir pruebas del equipo. |
Estas exclusiones solo sirven si no invalidan la hipótesis. Si el valor depende de recibir un precio del ERP al instante, no lo sustituiría silenciosamente por trabajo manual: probaría esa integración o cambiaría el experimento. Cada tarea manual necesita responsable, límite de capacidad y registro del esfuerzo.
Aceptar el software y validar el negocio son decisiones distintas
Para aceptar la entrega de este ejemplo, pediría una demostración reproducible de estas pruebas:
- Un cliente invitado envía una solicitud válida y puede volver a encontrarla.
- Los datos incompletos producen un error claro y permiten corregirlos.
- Un reenvío tras un corte de conexión no crea otra solicitud para la misma operación.
- Un cliente no puede consultar ni modificar solicitudes de otra empresa, tampoco cambiando una URL.
- El operador cambia un estado y queda constancia de quién lo hizo y cuándo.
- Una copia se restaura en un entorno de prueba y se documenta cómo recuperar el servicio.
Superar esas pruebas demuestra el alcance entregado. Para decidir si el negocio merece otra inversión, observaría cuántos usuarios invitados completan la tarea, cuánta ayuda necesitan y si vuelven cuando aparece otra necesidad. La repetición no se puede evaluar si el periodo termina antes del siguiente ciclo de uso. Si la hipótesis es de pago, usar el portal gratis no la demuestra.
Antes del piloto, anotaría la fuente de cada señal, su denominador, el umbral acordado y quién decide. Continuaría si hay evidencia suficiente y una operación asumible; corregiría el flujo si la ayuda manual impide interpretar el resultado; pararía o replantearía la hipótesis si la necesidad no aparece. Si faltan participantes o tiempo, el resultado es inconcluso. No lo convertiría en éxito cambiando el umbral después.
Plan técnico ligero
- mapear el recorrido crítico y los fallos
- probar pantallas inciertas antes del backend
- elegir un stack convencional que el equipo pueda operar
- definir el modelo de datos y contrato API mínimos
- integrar servicios gestionados para funciones comunes
- publicar con monitorización y copias básicas
- medir, entrevistar y revisar alcance
Un monolito modular suele bastar. Añade colas solo para tareas lentas o reintentables y evita microservicios hasta que exista una necesidad real de escalado u ownership independiente. Seguridad, privacidad, permisos y borrado de datos también aplican al experimento.
En el caso Adslyfy puedes ver ejecuciones, fallos y capturas de una plataforma de monitorización de anuncios. Esa evidencia muestra cómo hacer visible la operación; no demuestra demanda ni resultados del portal hipotético.
Controla el presupuesto con puntos de decisión
Con ese alcance escrito, utiliza la guía para comparar presupuestos de software. Pide que la propuesta distinga descubrimiento, implementación y operación del piloto, e identifique las dependencias pendientes. No hay una cifra universal que sustituya esas decisiones.
Financia descubrimiento, prototipo, corte vertical y piloto como fases separadas. En cada punto compara la evidencia con los criterios de éxito antes de autorizar más trabajo. Controla alcance restante, riesgo de entrega y coste operativo mensual, no solo horas consumidas.
Despliega pronto en un entorno parecido a producción para descubrir problemas de DNS, correo, permisos, móviles y límites externos. Registra lo necesario sin guardar datos personales de más y documenta decisiones para que otro equipo entienda los atajos.
Antes de ampliar el piloto, compara también el coste total de operar y mantener el software: revisión manual, servicios externos, actualizaciones y salida. Un menor coste de desarrollo puede trasladar trabajo al equipo; mídelo antes de financiar la siguiente fase.
Errores comunes
- construir para todos los clientes posibles
- copiar a un competidor maduro función por función
- empezar con microservicios o apps nativas sin evidencia
- ocultar el trabajo manual del cálculo de costes
- aceptar estimaciones vagas sin supuestos
- cambiar alcance manteniendo fecha y presupuesto
- lanzar sin analítica, errores ni copias
- dejar cumplimiento y seguridad para después
Checklist práctico del MVP
- un usuario objetivo y un problema doloroso
- un flujo crítico y un resultado medible
- exclusiones y condiciones de parada escritas
- prototipo probado con usuarios representativos
- stack convencional y mantenible
- autenticación, permisos y protección de datos básicas
- errores, eventos auditables y copias restaurables
- coste operativo estimado al volumen del piloto
- revisión semanal de alcance y riesgos
- decisión clara al terminar el piloto
Cuándo tiene sentido contratar a alguien técnico
Un responsable técnico aporta valor antes de desarrollar cuando integraciones, datos sensibles, automatización, sistemas heredados o regulación condicionan la arquitectura. Puede cuestionar estimaciones, definir el corte vertical y distinguir atajos reversibles de trampas caras. Consulta también qué puede automatizar una empresa pequeña con poco presupuesto.
Definir el MVP antes de pedir desarrollo
Si estás preparando una primera versión, puedo ayudarte a convertir la idea en un alcance que se pueda construir y comprobar. Revisa mi servicio de software a medida y desarrollo SaaS o cuéntame el problema con el usuario objetivo, el proceso actual, la evidencia disponible y las restricciones. El siguiente paso es decidir qué merece entrar en el piloto.