Plantilla inicial de 3 pantallas para principiantes: construye más rápido

¿Por qué empezar con solo tres pantallas?

Los principiantes a menudo se bloquean porque imaginan primero el producto terminado. Eso trae una pila de pantallas, funciones y decisiones antes de que algo siquiera funcione. Cuando no puedes ejecutar la app de extremo a extremo, baja la motivación y es difícil saber qué construir después.

Una plantilla inicial de tres pantallas mantiene el alcance pequeño pero sigue pareciendo una app real. Una pantalla Lista te da algo que ver, una pantalla Añadir te permite cambiar los datos y una pantalla Settings te da un lugar para preferencias simples. Juntas crean un bucle completo: ver datos, añadir datos, cambiar una opción básica y ver el resultado.

Tres pantallas también te obligan a practicar lo que aparece en casi todas las apps, sin ahogarte en detalles.

Qué aprendes con una build de tres pantallas

Obtienes práctica rápida en habilidades que se transfieren a proyectos más grandes:

• Flujo de datos (dónde viven los ítems y cómo la lista se actualiza después de añadir uno)
• Navegación (moverse entre pantallas de forma predecible)
• Validación (bloquear entradas vacías o rotas)
• Preferencias (guardar una configuración pequeña como el orden de clasificación)
• Manejo básico de errores (mostrar un mensaje claro cuando algo falla)

Como la plantilla es pequeña, puedes terminarla en un fin de semana y aún tener tiempo para pulir. Un rastreador de libros simple, por ejemplo, puede empezar como una lista de libros, un formulario para añadir título y autor, y una página de Settings para elegir cómo se ordena la lista.

La plantilla: Lista, Añadir y Settings

Esta plantilla se mantiene pequeña pero cubre lo básico: mostrar datos, crear datos y guardar preferencias.

Pantalla 1: Lista (pantalla principal)

La pantalla Lista responde a una pregunta: ¿qué tengo ahora? Muestra tus ítems de forma clara y legible.

No ignores el estado vacío. Cuando aún no hay ítems, muestra un mensaje corto y una acción clara como “Añade tu primer ítem.” Eso evita el momento de pantalla en blanco que confunde a la gente.

Mantén la clasificación simple al principio. Elige una regla (los más nuevos primero, o alfabético) y síguela. Si añades opciones después, hazlo un control pequeño, no una pantalla nueva.

Pantalla 2: Formulario Añadir (crear un ítem)

En la pantalla Añadir ocurren la mayoría de los bugs de principiantes, así que mantenla deliberadamente aburrida. Usa solo los campos que realmente necesitas. Para una lista de tareas mínima, eso puede ser un título y una nota opcional.

La validación debe ser amigable y específica. Si un campo obligatorio está vacío, muestra un mensaje corto junto a ese campo. Después de guardar, el resultado debe ser obvio: el ítem aparece en la Lista y el formulario se reinicia (o la pantalla se cierra).

Pantalla 3: Settings (preferencias, no funciones)

Settings deberían ser pequeñas y reales. Añade un par de toggles y una preferencia de texto simple para practicar guardar y cargar elecciones de usuario. Ejemplos: un toggle de modo oscuro, un toggle “Confirmar antes de borrar” y un campo de texto como “Nombre para mostrar”.

Aquí está el flujo básico:

• Abre la app en la pantalla Lista
• Toca Añadir para abrir el formulario
• Guarda y vuelve a la Lista para ver el nuevo ítem
• Abre Settings desde un icono o menú, cambia una preferencia y vuelve a la Lista

Elige una idea de app tiny y define los datos

Escoge una “cosa” que tu app gestione. No cinco cosas. Una. Tareas, contactos, recibos, notas, entrenamientos, plantas o libros funcionan porque encajan en el mismo bucle: ves ítems, añades uno y ajustas un par de preferencias.

Una buena idea pequeña cabe en una sola frase: “Esta app me ayuda a rastrear ___.” Si necesitas oraciones extra para explicar etiquetas, recomendaciones, sincronización y compartir, ya no es tiny.

Define tus datos antes de tocar la UI. Anota de 3 a 6 campos para tu “cosa” y marca cuáles son obligatorios. Un recibo podría ser: store (obligatorio), total (obligatorio), date (obligatorio), category (opcional), note (opcional). Mantenerlo corto obliga a tomar decisiones, y las decisiones son las que hacen factible una v1.

Sé estricto sobre lo que significa “terminado” para la v1. Terminado debería significar que puedes añadir un ítem, verlo en una lista y que los settings cambien algo pequeño pero real. No búsquedas, no cuentas, no compartir.

Una forma práctica de limitar el alcance es escribir una oración por pantalla:

• Pantalla Lista: Muestra todos los ítems y su campo más importante (más una pequeña etiqueta de estado si hace falta).
• Pantalla Añadir: Crea un nuevo ítem con solo los campos obligatorios y uno opcional.
• Pantalla Settings: Controla 1 o 2 preferencias como orden, moneda o una opción simple on/off.

Ejemplo: “Una app de entrenamientos.” Lista: muestra entrenos con fecha y duración. Añadir: añade un entrenamiento con fecha, duración y notas opcionales. Settings: elige mostrar minutos vs horas y un tipo de entrenamiento por defecto. Si no puedes escribir estas tres oraciones sin colar funciones extra, reduce la idea hasta que puedas.

Mantén el modelo de datos simple a propósito

Una app amigable para principiantes avanza más rápido cuando el modelo de datos es aburrido. El objetivo no es una base de datos perfecta, sino un comportamiento predecible para que cada siguiente función se sienta como un paso pequeño, no como una reescritura.

Empieza con una única fuente de verdad para tus ítems: un lugar donde viva la lista (un array en el estado de la app o una tabla en el servidor). Evita copiar la lista en múltiples pantallas o mantener una “lista temporal” que lentamente se convierte en la real. Las copias crean bugs raros como “se guardó, pero no se actualizó”.

Mantén la forma del ítem consistente entre Lista, Añadir y Settings. Elige nombres, tipos y valores por defecto y mantente fiel a ellos. Un ítem simple puede ser:

• id (string)
• title (string)
• createdAt (date o timestamp)
• done (boolean, por defecto false)
• notes (string, por defecto vacío)

Si añades campos después, agrégalos en todas partes con valores por defecto sensatos. Un error común es usar name en una pantalla y title en otra, o tratar done como booleano y como string tipo "yes".

Planea algunos estados básicos para que la app no parezca frágil:

• Loading: qué mostrar mientras se cargan o restauran datos?
• Empty: qué mostrar cuando no hay ítems aún?
• Error: qué mostrar cuando guardar o cargar falla?
• Saved: ¿cómo sabe el usuario que funcionó?

Mantén esos estados concretos. Si la lista está vacía, muestra una oración corta y un botón que abra Añadir. Si guardar falla, mantiene el formulario con los datos y muestra un mensaje simple como “No se pudo guardar. Intenta otra vez.”

Finalmente, decide local vs servidor con una regla simple: guarda localmente si la app es útil en un solo dispositivo y no necesita compartir; usa servidor si necesitas sync, login o acceso desde varios dispositivos. Para muchos proyectos iniciales, el almacenamiento local basta. Si luego pasas a un backend (por ejemplo, un setup en Go + PostgreSQL), mantén la forma del ítem igual para que la UI apenas cambie.

Paso a paso: construye las tres pantallas en orden

Construye en un orden estricto. Cada paso debería dejar la app usable, incluso si todavía está “falsa” detrás de las escenas. Ese es el punto de la plantilla de tres pantallas: siempre tienes algo que puedas tocar.

1) Empieza por la pantalla Lista (datos falsos primero)

Crea la pantalla Lista y hardcodea de 5 a 10 ítems de ejemplo. Dale a cada ítem solo los campos necesarios para mostrarse bien (por ejemplo: title, una nota corta y un estado).

Añade el estado vacío temprano. Puedes activarlo con un toggle simple o empezando con un array vacío. Muestra un mensaje amigable y una acción clara como “Añadir ítem”.

Si quieres un control pequeño en la lista, mantenlo diminuto. Un cuadro de búsqueda que filtre por título es suficiente. O añade un filtro único como “Solo activos”. No lo conviertas en un sistema entero.

2) Construye la pantalla Añadir antes de guardar nada

Construye la UI del formulario con los mismos campos que necesita tu lista. No conectes el guardado aún. Enfócate en el diseño de inputs, las etiquetas y un botón principal claro.

Después añade validación con mensajes que digan exactamente qué arreglar:

• "Title is required"
• "Title must be under 40 characters"
• "Pick a status"

Ahora conecta Guardar para que el nuevo ítem aparezca en la lista. Empieza con estado en memoria (se reinicia al reiniciar), y luego pasa a almacenamiento o backend. La primera victoria es ver el nuevo ítem aparecer de inmediato.

3) Añade Settings al final y conéctalo a comportamientos visibles

Mantén Settings pequeñas y haz que cada opción cambie algo que puedas ver. Un toggle “Vista compacta” puede cambiar el espaciado de la lista. Un toggle “Mostrar completados” puede cambiar qué ítems aparecen. Si el setting no cambia nada, no pertenece aún.

Haz que se sienta real con pequeños toques UX

Una app para principiantes empieza a sentirse "real" cuando las pantallas responden preguntas pequeñas sin pasos extra. Estos toques no añaden mucho trabajo, pero eliminan fricción.

Pantalla Lista: señales pequeñas que reducen la confusión

Añade uno o dos bits de contexto cerca de la parte superior, como el conteo de ítems y una línea simple tipo “Actualizado hace un momento” tras cambios. Si tus ítems tienen un estado, muéstralo como una etiqueta corta como “Open” o “Done” para que la gente pueda escanear.

Una regla útil: si el usuario puede preguntar “¿Cuántos?” o “¿Esto está al día?”, respóndelo en la pantalla Lista.

Formulario Añadir: valores por defecto y un final claro

La pantalla Añadir debe ser más rápida que escribir en una app de notas. Usa valores por defecto para que el usuario pueda enviar con esfuerzo mínimo. Empareja tipos de entrada con los datos: teclado numérico para cantidades, selector de fecha para fechas, toggles para opciones on/off.

Haz el botón principal imposible de perder y etiquétalo claramente. “Guardar” funciona, pero “Añadir a la lista” es aún más claro.

Pequeños toques de formulario que dan resultado rápido:

• Poner el foco en el primer campo automáticamente.
• Prefill valores comunes (por ejemplo quantity = 1).
• Mostrar errores cortos junto al campo, no como alertas vagas.
• Deshabilitar el botón principal hasta que los campos requeridos sean válidos.
• Tras enviar, limpiar el formulario o volver a la lista con una confirmación breve.

Settings: solo opciones que cambian comportamiento

Settings no deberían convertirse en un cajón de trastos. Mantén 2 o 3 opciones que realmente afecten cómo funciona la app, como orden, unidades o un toggle simple de archivado. Cada setting debe tener un efecto inmediato en la pantalla Lista; de lo contrario parece inútil.

Hazla usable: teclado, foco y accesibilidad básica

Muchas apps de principiantes parecen torpes porque el teclado cubre botones, el foco salta o los objetivos táctiles son pequeños. Arreglar esto temprano hace que cada prueba sea más fluida.

Cheques rápidos:

• ¿Se puede enviar el formulario desde el teclado (Next, Done)?
• ¿El foco se mueve en orden lógico de arriba abajo?
• ¿Las etiquetas son visibles (no solo texto placeholder)?
• ¿Los botones son lo bastante grandes para tocar cómodamente?
• ¿Las etiquetas de estado tienen texto, no solo color?

Una lista de la compra es un buen ejemplo: cantidad por defecto 1, etiqueta “Comprado” en la lista y un setting como “Agrupar por pasillo” pueden hacerla útil sin ir más allá de tres pantallas.

Trampas comunes que frenan a los principiantes

La forma más rápida de atascarse es ampliar el alcance antes de que la app funcione de extremo a extremo. Esta plantilla está pensada para llevarte a un bucle funcional: ver una lista, añadir un ítem y ajustar una o dos preferencias que cambien comportamiento real.

Las ralentizaciones que más aparecen:

• Cuentas desde el día uno. Las cuentas traen reglas de contraseña, emails y casos borde. Manténlo single-user al principio.
• Sobrediseñar la base de datos antes de que la UI funcione. Si tu pantalla Lista sigue en blanco, más tablas no ayudarán.
• Settings que no están conectados a nada. Si no puedes señalar dónde se usa un setting, sáltatelo.
• Saltar la validación. Sin comprobaciones básicas, tus datos serán poco fiables y cada bug parecerá aleatorio.
• Entrar rápido en editar y borrar antes de que añadir sea estable. Si Añadir es inestable, editar y borrar multiplican los mismos problemas.

Un ejemplo rápido: si construyes una lista de la compra tiny y añades cuentas familiares temprano, pasarás horas en pantallas de login antes de que alguien pueda añadir “leche”. Si omites la validación, luego te preguntarás por qué la lista está llena de filas en blanco.

Cuando sientas ganas de ampliar, haz esto en su lugar:

1. Haz el flujo de añadir imposible de malinterpretar (etiquetas, valores por defecto, texto claro en botones).
2. Añade una regla de validación y un mensaje útil.
3. Haz que un setting cambie la lista inmediatamente.
4. Guarda una instantánea funcional antes de cambios grandes para poder revertir si hace falta.

Protege el bucle central y podrás añadir editar, borrar y cuentas más tarde sin rehacerlo todo.

Checklist rápido antes de ampliar la app

Antes de añadir búsqueda, etiquetas, cuentas o notificaciones, asegúrate de que las tres pantallas que ya tienes funcionen bien. Si lo básico es lento o confuso, cada nueva función multiplicará el dolor.

Cinco comprobaciones que te ahorran horas

Prueba como si fueras un usuario por primera vez en una pantalla pequeña, con una mano.

• Velocidad del flujo de añadir: abrir la app y guardar un nuevo ítem debería sentirse rápido. Si tarda más de ~30 segundos, el formulario es muy largo, el botón difícil de encontrar o los valores por defecto son incorrectos.
• Prueba de estrés en la lista: debe verse bien cuando está vacía y seguir siendo usable con decenas de ítems. Revisa scroll, espaciado y cómo se ajustan nombres largos.
• Claridad de errores: los mensajes deben decir qué arreglar. “Inválido” no basta. “El nombre no puede estar vacío” sí.
• Impacto de Settings: cada ajuste debe causar un cambio visible que puedas notar de inmediato.
• Supervivencia de datos: si elegiste persistencia, cierra y vuelve a abrir la app. Los ítems deberían seguir ahí y la carga no debe resultar confusa.

Un guion simple: añade tres ítems, comete un error a propósito, cambia un setting y reinicia la app. Si algún paso resulta incierto, arregla eso antes de construir la pantalla cuatro.

Escenario de ejemplo: una lista de la compra que se mantiene pequeña

Una lista de la compra es perfecta para esta plantilla porque se siente real pero se mantiene simple. No estás construyendo una “plataforma de compras”. Guardas ítems, añades nuevos y eliges algunas preferencias.

Los datos tiny que necesitas

Cada ítem de la compra puede ser un registro con pocos campos claros:

• Name (por ejemplo, “eggs”)
• Quantity (por ejemplo, 12)
• Store (por ejemplo, “Trader Joe’s”)
• Notes (opcional, por ejemplo, “free range”)
• Created date (autollenado al añadir)

Eso basta para practicar crear y leer sin diseñar un sistema grande.

Settings que realmente cambian la app

Mantén Settings pequeñas, pero haz que cada opción haga algo visible de inmediato. Para esta app, tres settings son suficientes: tienda por defecto, “agrupar ítems por tienda” y un toggle de modo oscuro.

Un recorrido rápido que puedes construir rápido:

Crea dos ítems:

1. Name: “Bananas”, Quantity: 6, Store: “Costco”, Notes: “green”
2. Name: “Milk”, Quantity: 1, Store: “Whole Foods”, Notes: (vacío)

Vuelve a la pantalla Lista. Deberías ver ambos ítems con su tienda y cantidad. Si muestras la fecha de creación, mantenla sutil (por ejemplo “Añadido hoy”).

Ahora abre Settings y pon Store por defecto en “Costco.” Vuelve a Añadir y crea “Bread.” El campo Store debería venir ya completado. Ese cambio hace que Settings sea útil.

Después, activa “Agrupar ítems por tienda.” Vuelve a Lista. Los ítems deberían agruparse bajo cabeceras como “Costco” y “Whole Foods.”

Por último, activa Modo oscuro. La app debe cambiar de tema de inmediato. Si quieres un aprendizaje extra, haz que el modo oscuro persista tras reiniciar la app.

Siguientes pasos: crecer desde tres pantallas sin perder el foco

Una vez que tus tres pantallas funcionen de extremo a extremo, el siguiente objetivo no es “más pantallas.” Es una conducta útil más que todavía encaje en tu app tiny. Si no puedes explicar el cambio en una frase, probablemente es demasiado grande.

Añade una función a la vez y termínala por completo (UI, datos, estados vacíos y una prueba rápida). Buenas primeras mejoras: editar un ítem, borrar con deshacer, añadir búsqueda (solo si la lista se alarga) o categorías simples.

Después de lanzar una mejora, párate y pregunta: ¿esto hizo la app más clara o solo más complicada? Los principiantes suelen apilar funciones que tocan los mismos datos de formas distintas y la app se vuelve desordenada rápido.

Cuándo añadir un backend

Empieza sin backend si la app es personal y vive en un dispositivo. Añade un backend cuando necesites inicio de sesión, sincronización entre dispositivos, compartir con otra persona o copias de seguridad confiables.

Al introducir un backend, mantén la primera versión aburrida: guarda y carga los mismos datos que ya tienes. Deja ideas avanzadas como roles o analytics hasta que CRUD básico sea estable.

Mantén los cambios seguros (snapshots y rollback)

A medida que amplías, el mayor riesgo es romper lo que ya funciona. Trabaja en pequeños puntos de control: antes de una nueva función, toma una instantánea de la versión que funciona. Si la nueva función sale mal, vuelve atrás e inténtalo de nuevo con un paso más pequeño.

Si quieres una forma guiada por chat para construir esta plantilla, Koder.ai (koder.ai) está diseñado para generar web, backend y apps móviles a partir de prompts en lenguaje natural; además soporta instantáneas y rollback para iterar sin perder una versión que funciona.

La idea principal se mantiene: haz crecer la app mediante mejoras pequeñas y seguras, no con una gran reconstrucción.