Nativas y multiplataforma para iOS y Android. Llegar a las tiendas es la parte fácil: la difícil es que alguien la vuelva a abrir al día siguiente.
analiza --uso "qué hace la persona en 30 segundos"
una sola mano · pantalla pequeña · red inestable
comprueba --hace-falta-una-app
si solo hay que consultar información, una web cuesta una fracción
./tiendas --requisitos
[ok] cuentas de Apple y Google a tu nombre
[ok] tiempos de revisión previstos en la planificación
esperando
$ ./app --dia 30
Una pantalla de inicio no tiene espacio infinito y nadie la ordena por amabilidad. En los primeros días tras la instalación, las apps que no dan un motivo para volver desaparecen solas. Mira.
20 apps aún abiertas
Quedan 3. El trabajo es ser una de esas.
// cuándo hace falta
Publicar es fácil. Difícil es merecerse un sitio en la pantalla de inicio de alguien. Si no reconoces al menos tres de estos puntos, probablemente lo que necesitas es una web bien hecha.
// qué construimos
Cambia quién la usa y cambia todo: interfaz, prioridades, incluso la elección de la tecnología.
Reservas, pedidos, fidelización, soporte. El canal directo con quien te elige, sin intermediarios que se llevan un porcentaje.
Mediciones, checklists, partes de trabajo, almacén, firmas. Funcionan sin red y se sincronizan cuando vuelve la señal.
El compañero móvil de un sistema de gestión o de un portal: mismos datos, misma lógica, interfaz pensada para el teléfono.
No tenemos ninguna tecnología que defender. Una base de código cuando conviene, dos cuando hacen falta rendimiento o sensores.
// cómo llegamos
La revisión de Apple y Google es variable y no depende de nosotros: la contamos desde el principio, junto con el margen para una posible petición de cambio.
Quién la usará, dónde, con cuánta red y con cuántas manos libres. De aquí sale también la honestidad: a veces la respuesta es que no hace falta una app.
Un flujo real que se toca en el teléfono, no diapositivas. Lo pruebas con quien la usará antes de que exista código definitivo.
Compilaciones instalables cada dos semanas en TestFlight y canal interno de Android. Se prueba en el dispositivo real, no en el simulador.
Fichas de tienda, capturas, etiquetas de privacidad, revisión. Después mantenimiento con acuerdo escrito, o formamos a vuestro equipo.
$ cat stack.json
$ ./domande --frequenti
Sí, y deben estar a vuestro nombre, no al nuestro: la ficha en las tiendas, las reseñas y los cobros tienen que seguir siendo vuestros aunque algún día cambiéis de proveedor. Os guiamos en el alta y la configuración, pero las cuentas son vuestras.
Al desarrollo hay que sumarle el tiempo de revisión de las tiendas, que es variable y no depende de nosotros. Lo contamos en la planificación desde el principio, junto con el margen por si piden algún cambio.
Si hace falta, sí. Es una decisión que se toma al principio porque cambia la arquitectura: añadirla después cuesta mucho más que preverla ya.
Podemos ocuparnos nosotros con un acuerdo de mantenimiento, o formamos a vuestro equipo. Las cuentas de tienda y las credenciales son vuestras desde el primer día, así que publicar nunca depende de nosotros.
Depende de lo que tenga que hacer. Multiplataforma conviene cuando la app son pantallas, datos y flujos: los plazos y los costes bajan de verdad. Nativa conviene cuando hacen falta rendimiento gráfico, uso intensivo de sensores o integración profunda con el sistema. La decisión la tomamos juntos en el análisis, con los motivos escritos.
Las variables son cuántas pantallas, cuántas integraciones y si tiene que funcionar sin conexión. Damos una cifra después del prototipo, cuando el alcance es visible: antes sería una apuesta disfrazada de estimación.
fymera init --proyecto "el tuyo"
Treinta minutos por vídeo para saber quién la usará y si merece la pena hacerla. Si te basta con una web, te lo decimos.
