El portafolio es la herramienta de ventas más importante de un desarrollador de apps móviles freelance. Más que el CV. Más que las certificaciones. Un cliente que ve una app funcionando en su teléfono ya tiene el 70% de la convicción que necesita para contratar.
El problema es que muchos devs construyen portafolios que no convencen: código en GitHub sin contexto, capturas de pantalla sin explicación o proyectos académicos que no resuelven problemas reales.
Esta guía explica cómo construir un portafolio de desarrollo móvil que funcione como herramienta de ventas real.
Qué busca realmente un cliente en tu portafolio
Antes de hablar de qué incluir, hay que entender qué evalúa un cliente no técnico (que es la mayoría):
- ¿Puedes entregar algo que funcione? No les importa si usaste Redux o Riverpod.
- ¿Lo que hiciste se parece a lo que necesitan? La relevancia supera la calidad técnica.
- ¿Puedes trabajar de forma autónoma? Proyectos terminados y publicados indican que puedes llevar algo de inicio a fin.
Un proyecto simple pero completo, publicado en la tienda, vale más que código complejo sin entregar.
La estructura de un portafolio efectivo
3-5 proyectos es suficiente
Más no es mejor. Un portafolio de 3 proyectos bien presentados supera a 10 proyectos sin contexto. La calidad de la presentación importa tanto como la calidad del código.
Qué incluir por proyecto
Por cada proyecto en tu portafolio:
Nombre y descripción en una línea: Qué hace la app y para quién.
El problema que resuelve: No “es una app de lista de tareas”. Sino: “Diseñada para freelancers que trabajan en múltiples proyectos y necesitan separar las tareas por cliente sin cambiar de app”.
Tecnología usada: React Native, Flutter, Swift, Kotlin. Si usaste librerías relevantes (Supabase, Firebase, Stripe), mencionarlas es una señal de competencia.
Link a la tienda o video demo: Obligatorio. Si no está publicada, un video de 1-2 minutos mostrando la app funcionando.
Tu rol: Si fue trabajo en equipo, aclara qué hiciste tú específicamente.
Resultado o métricas (si aplica): Descargas, usuarios activos, reseñas. Aunque sean pequeñas.
Qué proyectos construir si no tienes experiencia
Proyecto 1: App utilitaria simple (para demostrar que puedes entregar)
Algo que resuelva un problema cotidiano tuyo o de alguien cercano. Ejemplos:
- Conversor de moneda con tasas en tiempo real
- Tracker de gastos con categorías y gráfica mensual
- App de hábitos con notificaciones locales
Tecnología a usar: Flutter o React Native. Publicar en Google Play ($25 USD pago único).
Proyecto 2: App con autenticación y base de datos (para demostrar stack completo)
Un nivel arriba: users, login, datos guardados en la nube. Supabase o Firebase como backend.
- App de diario personal con cuenta de usuario
- Directorio de lugares con fotos y favoritos por usuario
- Gestor de contactos con sincronización
Proyecto 3: App relevante para tu mercado objetivo (para demostrar especialización)
Si quieres trabajar con restaurantes, construye algo para restaurantes. Si quieres clientes de e-commerce, construye un catálogo. La relevancia temática acelera la conversión.
Cómo presentar el portafolio
| Formato | Pros | Cons |
|---|---|---|
| Sitio web propio | Profesional, personalizable | Requiere tiempo o dinero |
| Notion público | Rápido de crear, fácil de actualizar | Menos impacto visual |
| PDF de 1-2 páginas | Fácil de enviar, funciona en cualquier canal | No interactivo |
| Linktree o similar | Centraliza links | Poca personalización |
Para empezar: un Notion público con los tres proyectos bien documentados es suficiente. No pierdas semanas construyendo un sitio web cuando el tiempo es mejor invertido en proyectos reales.
El portafolio en GitHub: útil pero secundario
GitHub es importante para clientes técnicos (CTOs, devs líderes que evalúan al equipo). Para dueños de negocio, no es útil por sí solo.
Si vas a mostrar código en GitHub:
- README claro con qué hace el proyecto y cómo instalarlo
- Commits con mensajes descriptivos (no “fix” o “update”)
- Código organizado en carpetas lógicas
El código sucio con commits tipo “asdfasd” dice más de ti que cualquier descripción.
Actualizarlo continuamente
El portafolio no es un documento que haces una vez. Cada proyecto que terminas es una oportunidad de mejorar la sección más visible de tu negocio freelance.
La práctica más útil: después de cada proyecto entregado, escribe la descripción del caso mientras los detalles están frescos. Si esperas meses, pierdes contexto.
Pedir permiso al cliente para incluir el proyecto
Siempre, siempre pide permiso antes de incluir un proyecto de cliente en tu portafolio. La mayoría acepta; algunos tienen restricciones de confidencialidad. Si el cliente no quiere que menciones su nombre, puedes describir el proyecto sin identificarlo: “App de inventario para empresa distribuidora en CDMX”.
¿Estás construyendo tu portafolio y tienes dudas sobre qué proyectos mostrar o cómo presentarlos? En el foro de Nomadaz Digitalez puedes compartirlo para recibir feedback de otros devs remotos que ya pasaron por el mismo proceso.