Una aplicación merece la pena cuando ayuda a alguien a completar una tarea que hoy cuesta resolver. El punto de partida es qué necesita hacer esa persona y qué resultado debería obtener, aunque todavía no sepas qué pantallas o tecnología harán falta.
Puedes llegar con una idea por definir o con requisitos listos para construir. Ricardo puede ayudarte a concretar el recorrido y desarrollar la solución según lo que ya tengas resuelto. Esta guía muestra las decisiones que conviene acordar, con ejemplos y ayudas opcionales para profundizar cuando te sirvan.
Empieza por una situación concreta
“Una plataforma para gestionar proyectos” admite demasiados productos diferentes. “Quiero encontrar por qué elegimos una opción y qué decisiones siguen abiertas” permite empezar a diseñar una tarea.
Usaremos Cuaderno de decisiones, un ejemplo ficticio para registrar decisiones de un proyecto. Primero lo utiliza una persona; después exploramos qué cambia si trabaja un equipo y si varios equipos usan el producto como servicio.
La pregunta inicial es sencilla: cuando alguien decide algo, ¿qué necesita conservar para comprenderlo después? En el ejemplo son proyecto, título, motivo, alternativas y estado. Esa información ya permite discutir un primer recorrido sin empezar por una lista de tecnologías.
Un recorrido de principio a fin
Describe qué sucede en seis momentos:
| Momento | Cuaderno de decisiones | Pregunta que debes responder en tu idea |
|---|---|---|
| Inicio | Se crea o se abre un proyecto | ¿Qué situación lleva a usar la aplicación? |
| Entrada | Se escribe una decisión y su motivo | ¿Qué información hace falta y de dónde sale? |
| Regla | Una decisión tomada necesita un motivo | ¿Qué condición permite continuar? |
| Resultado | La decisión aparece con su estado | ¿Cómo se reconoce que la tarea terminó? |
| Continuidad | Se guarda, encuentra y recupera después | ¿Dónde queda el trabajo y cómo se conserva? |
| Error | Un archivo inválido no sustituye el trabajo válido | ¿Cómo se corrige o se sale de un fallo? |
El valor está en la relación entre esos momentos. Una pantalla de alta no resuelve un cuaderno si luego resulta imposible encontrar lo guardado. Una confirmación no ayuda si aparece antes de que el dato se haya conservado.
La plantilla de briefing de aplicación puede ayudarte a conservar estas respuestas y las dudas. No necesitas completarla para comentar una idea.
Elige cómo debe llegar a la persona
Una web, una aplicación web, una PWA y una app móvil responden a contextos diferentes. La elección depende de la tarea, la conectividad, el dispositivo y la distribución.
Para consultar una decisión publicada puede bastar un enlace. Para crear y recuperar decisiones necesitas comportamiento de aplicación. Si hay que trabajar sin red, conviene acordar qué estará disponible y cómo se recuperarán los cambios. Si una función del dispositivo es imprescindible, Ricardo puede comprobarla en las plataformas relevantes antes de comprometer una arquitectura.
Una PWA sigue utilizando tecnologías web y puede añadir instalación y otras capacidades. Su disponibilidad concreta varía entre navegadores y plataformas. MDN explica ese enfoque, consultado el 10/09/2026.
El artículo de web, aplicación web y móvil compara esas decisiones con el mismo ejemplo. La herramienta para elegir solución permite obtener alternativas y preguntas según tu caso, incluida la posibilidad de utilizar algo que ya existe.
Comprueba primero si una solución existente encaja
Tener una regla propia no obliga a desarrollar todo. Puede existir una herramienta que cubra la tarea esencial con una configuración razonable.
Conviene probarla con el recorrido real, incluidos el error y la salida. En el Cuaderno, una herramienta existente debería permitir registrar el motivo, encontrar decisiones, controlar acceso cuando haya un equipo y conservar la información al salir. Puedes explicar qué echas en falta; Ricardo puede contrastar alternativas contigo.
Anota qué cubre, qué exige adaptar y qué queda fuera. Si una limitación afecta al trabajo principal, merece una alternativa. Si solo cambia una preferencia de presentación, valora cuánto importa antes de asumir desarrollo y mantenimiento propios.
La decisión útil explica por qué una opción encaja y qué condición la haría dejar de encajar. No necesita una puntuación que esconda los criterios.
Define una primera capacidad completa
La primera versión del Cuaderno puede limitarse a una persona, proyectos y decisiones, búsqueda, guardado y exportación. Colaboración, avisos y adjuntos pueden esperar si la tarea inicial se completa sin ellos.
Ese límite requiere decisiones precisas. Guardar y recuperar son esenciales para conservar un registro; añadir una red social alrededor de cada decisión probablemente no lo es.
Para acordar la primera entrega, sirve distinguir tres grupos:
- Inicial: sostiene la tarea que se quiere completar ahora.
- Posterior: tiene una razón para existir, pero necesita otra capacidad o una necesidad adicional.
- Excluido: no forma parte del encargo y no debe aparecer como incluido en la propuesta.
El mapa de alcance incluye plantilla y ejemplo con razones, dependencias y criterios de aceptación. El artículo de primera versión de una aplicación enseña a comprobar que la reducción de alcance conserva el resultado principal.
Dibuja los datos y sus estados
Antes de elegir pantallas, identifica qué cosas existen en el producto y cómo se relacionan.
En el Cuaderno hay proyectos y decisiones. En una versión de equipo aparecen además organizaciones y miembros. Una decisión pertenece a un proyecto; el proyecto pertenece a una organización; una persona accede por una relación y un permiso.
Después hay que definir qué puede cambiar. Una decisión puede estar pendiente, tomada o en revisión. Esos nombres necesitan significado: qué permite pasar a cada estado, quién puede hacerlo y qué se conserva. Tú puedes aportar cómo funciona el trabajo; Ricardo puede convertirlo en reglas y comprobaciones del producto.
Una tabla de este tipo evita ambigüedades:
| Estado de decisión | Qué significa | Qué necesita para avanzar |
|---|---|---|
| Pendiente | Existe una pregunta por resolver | Alternativas e información suficiente |
| Tomada | Se ha elegido una opción | Motivo y persona responsable |
| En revisión | Una condición nueva obliga a volver sobre ella | Explicar qué cambió y revisar la decisión anterior |
No añadas campos porque otra aplicación los tenga. Cada dato debe ayudar a completar, revisar o mantener la tarea. Si se elimina un campo, pregunta qué decisión dejaría de poder tomarse.
Cuando entra otra persona cambian los permisos
Pasar de uso individual a equipo implica más que añadir un botón de invitar. Hay que decidir quién puede leer, crear, corregir, exportar y administrar.
En el ejemplo, una editora trabaja con decisiones; una lectora consulta; una propietaria administra el equipo y sus opciones. La condición “pertenece a la misma organización” sigue siendo necesaria aunque dos personas tengan el mismo nombre de rol.
Los permisos se comprueban donde se ejecuta la acción. Ocultar un botón ayuda a orientar la interfaz, pero una aplicación real debe rechazar también una petición no permitida. OWASP recoge estos principios de autorización, consultado el 10/09/2026.
La guía de usuarios, roles y datos convierte esa decisión en una matriz y en pruebas de acceso permitido y denegado.
Si se ofrece como servicio a varios equipos
Un producto SaaS requiere operar una aplicación de forma continuada. Además del recorrido de usuario, aparecen administración, soporte, costes, continuidad y separación entre organizaciones.
El Cuaderno de equipos del laboratorio SaaS permite explorar esos comportamientos con personajes y datos de prueba. Los pagos son simulados; el caso explica qué controles pertenecen a la demostración y qué exigiría una operación real.
Una suscripción es una decisión de prestación y negocio. No obliga a que el producto sea una app móvil ni demuestra por sí sola que exista disposición a pagar. El artículo sobre convertir un servicio en SaaS ayuda a decidir si la unidad de valor y la operación admiten ese modelo.
Incluye el ciclo de pago en el alcance cuando lo necesites
Si el producto cobra, decide qué concede acceso, qué ocurre si falla un pago, cuándo termina una cancelación y qué información conserva la persona.
Una pantalla con un botón de pagar deja abiertas muchas de esas decisiones. También hay eventos que llegan después o se repiten. Por eso el estado de acceso y el del proveedor deben poder conciliarse.
El artículo de pagos y suscripciones como parte del alcance recorre un caso y sus estados. Si la aplicación se distribuye en tiendas, sus políticas de cobro y publicación necesitan revisión específica; una integración web no resuelve automáticamente ese contexto.
Revisa una aplicación usando tareas
Al revisar avances, pide ver una tarea completa con datos de ejemplo. Para el Cuaderno, puede ser crear una decisión, corregirla, guardarla, recargar y encontrarla; después, comprobar un archivo inválido y un rol que no puede editar. La preparación y ejecución técnica de esas pruebas corresponde al desarrollo.
El caso de aplicación web recorre el mismo constructor de briefing que puedes utilizar en esta web. Permite observarlo desde sus datos, estados y funcionamiento.
Al comunicar una incidencia, describe situación, acción, resultado esperado y resultado observado. “Al volver al proyecto no aparece la decisión que guardé” permite investigar una diferencia concreta; “el panel falla” todavía necesita contexto.
La aceptación debe relacionar cada requisito con una comprobación y dejar visibles los límites de la entrega.
Prepara la operación antes de lanzar
Decide quién mantiene el producto y qué necesita para hacerlo. Según el alcance, pueden hacer falta copias, restauración, administración de acceso, seguimiento de errores, actualización de dependencias y atención de solicitudes.
Incluye también la salida: qué ocurre cuando alguien deja un equipo, cancela un plan o necesita exportar información. Diseñar ese recorrido evita convertir el final de una relación en un problema de datos.
El lanzamiento se verifica en la URL y el entorno que utilizará la persona. Las pruebas deben separarse de las métricas de uso. Después observa si se completa la tarea, dónde aparecen dudas y qué necesidades justifican una ampliación.
Cómo continuar desde tu punto de partida
Al terminar esta guía puedes identificar una tarea principal, el resultado que importa y las dudas que cambiarían el encargo. La elección de solución, el alcance y las reglas de datos, roles y operación pueden concretarse contigo durante el proyecto.
Si te ayuda, puedes usar el briefing de aplicación, contrastar alternativas en la herramienta de elección y concretar límites en el mapa de alcance. También puedes contarle a Ricardo qué necesitas construir, tanto si la idea está abierta como si ya tienes requisitos; esos documentos no son un paso previo.
La siguiente decisión ya no tiene por qué ser “qué tecnología elegimos”. Puede ser una prueba pequeña y concreta que resuelva la incógnita que más cambia el proyecto. Si ya necesitas pedir o comparar propuestas de desarrollo, sigue la guía para encargar software a medida.