La decisión que más dinero mueve al programar una app a medida no es el diseño ni el programador: es elegir bien entre app nativa, web app o PWA. Equivocarte ahí multiplica el coste por tres y no lo notas hasta el final.
Casi todo el mundo llega diciendo "quiero una app" pensando en el icono en el móvil. Pero hay tres formas de conseguir eso y cuestan cosas muy distintas:
| App nativa | Web app | PWA | |
|---|---|---|---|
| Dónde vive | App Store y Google Play | En el navegador | Navegador, con icono en el móvil |
| Coste | Alto: dos plataformas | Bajo: una sola base | Bajo: una sola base |
| Cámara, GPS, notificaciones | Todo | Limitado | Casi todo |
| Funciona sin cobertura | Sí | No | Sí, con límites |
| Actualizar | Revisión de Apple y Google | Instantáneo | Instantáneo |
| Cuota anual de tiendas | Sí | No | No |
La regla práctica: si tu app no necesita cámara constante, GPS en segundo plano ni funcionar sin cobertura, no necesitas una app nativa. Una PWA te da el icono en la pantalla del móvil, las notificaciones y la experiencia de app, por una fracción del coste y sin pasar por la revisión de nadie.
Cuándo sí es nativa: uso intensivo de cámara o sensores, funcionamiento real sin conexión, integración profunda con el sistema, o cuando estar en la tienda es tu canal de captación. Si estás en uno de esos casos, se hace nativa y punto — pero conviene saber que se paga.
Al presupuestar se piensa en las pantallas. El trabajo real está debajo, y esto es lo que hay que construir sí o sí aunque no se vea:
Por eso una app "sencilla" de seis pantallas nunca es un proyecto de una semana: las seis pantallas son la punta.
Igual que el resto: por fases y con algo usable pronto.
Primero, la conversación incómoda. Te pregunto qué pasa el día que la app funciona: quién la abre, cuántas veces al día y qué hace. Si esa respuesta es floja, el problema no es técnico y programar no lo arregla. Prefiero decírtelo antes.
Después, la v1 mínima. El circuito completo de un solo caso de uso, funcionando de punta a punta, con datos reales. No una maqueta bonita: algo que puedes poner en manos de cinco usuarios y ver qué pasa.
Y a partir de ahí, lo que los usuarios pidan. Que casi nunca es lo que estaba en la lista original. Por eso no tiene sentido presupuestar de golpe veinte funciones que nadie ha probado todavía.
Mi credencial aquí no es un porfolio de maquetas: son dos productos propios en producción con usuarios de pago — Libélula CRM y Tortoise — con su registro, sus permisos, sus suscripciones y su soporte. Sé lo que se rompe después de la entrega porque me toca arreglarlo.
Depende sobre todo de si es nativa o web/PWA: una app nativa para iOS y Android es aproximadamente el doble de trabajo que una PWA equivalente, porque son dos bases de código y dos procesos de publicación. Antes de dar una cifra prefiero entender qué necesita hacer tu app, porque esa decisión mueve más dinero que ninguna otra.
Solo si la tienda es tu canal de captación o necesitas funciones que únicamente da una app nativa. Si tus usuarios van a llegar porque tú les mandas el enlace, una PWA les deja el icono en la pantalla de inicio igual, se actualiza al instante y te ahorra las cuotas y las revisiones.
La primera versión usable de un caso de uso concreto suele estar en semanas. Lo que alarga los proyectos no es programar las pantallas: es el registro, los permisos, el panel de administración y los casos raros que aparecen cuando entran usuarios de verdad.
Puedo hacerlo yo con un acuerdo mensual, o puedes llevarlo tú o tu equipo. El código, la documentación y los accesos son tuyos desde el principio y uso tecnología estándar, así que no dependes de mí por diseño.
Sí. Audito lo que hay, te digo con honestidad en qué estado está y qué compensa — continuar, refactorizar o rehacer — y lo retomo con un plan por fases. A veces la respuesta honesta es que rehacer sale más barato que arreglar, y también te lo diré.