Una app hecha con IA falla en producción casi siempre por una de nueve causas: base de datos sin seguridad por fila (RLS), claves secretas en el navegador, configuración de la vista previa distinta de la real, sesiones que caducan, otra firma en la tienda, el optimizador de release, red frágil, llamadas a IA sin límite y falta de tests. Se arregla con configuración, permisos y pruebas, casi nunca rehaciéndolo todo.

Las herramientas de vibe coding (Lovable, Bolt, v0, Replit, Cursor) son extraordinarias para llegar a algo que se puede enseñar. Cada una trae su propio atajo para producción, y lo comparamos en Lovable, Bolt, Cursor y v0: qué falta para producción. Donde flojean es en la fontanería que no se ve: configuración, permisos, firmas, errores de red. En la vista previa esa fontanería la pone la propia herramienta; en producción la tienes que poner tú. De ahí sale casi todo.

De dónde sale esta lista. De lo que vemos al auditar proyectos que nos llegan para Relevo y de nuestros propios tropiezos publicando Pax en Google Play. Donde citamos un fallo nuestro, es literal: pasó, lo pagaron usuarios reales y lo arreglamos.

¿Está tu base de datos abierta a cualquiera?

Es el fallo más grave y el más frecuente. Muchas apps generadas usan Supabase con la clave pública metida en el código del navegador, que es lo normal — siempre que la seguridad a nivel de fila (RLS) esté activada y bien escrita. Según la documentación de Supabase, una tabla sin RLS en un esquema expuesto la puede leer y escribir cualquier rol con permisos sobre ella. Lo desarrollamos en seguridad de una app de Lovable, Bolt o Supabase.

No es teórico:. en 2025 se registró la vulnerabilidad CVE-2025-48757 (Lovable la disputa: dice que cada cliente es responsable de los datos de su app). El análisis que la originó encontró RLS insuficiente en 170 de las 1.645 apps de Lovable que escaneó, con datos personales, pagos y claves de API a la vista.

• Cómo saberlo: en el panel de Supabase, cada tabla debe mostrar RLS activado y al menos una política. Una tabla sin políticas con RLS desactivado es pública.
• Cómo arreglarlo: activar RLS en todas las tablas y escribir políticas del tipo «cada usuario solo ve sus filas». Y probarlas: con la clave pública y sin sesión, una consulta debe volver vacía.

¿Hay claves secretas en el código del navegador?

La clave de OpenAI, la secreta de Stripe o la de servicio de Supabase escritas en un componente de React acaban en el JavaScript que descarga cualquier visitante. Basta abrir las herramientas de desarrollador para copiarlas. El síntoma suele llegar en forma de factura.

Arreglo: todo lo secreto vive en el servidor (una función de Supabase, de Vercel o de Firebase) y el navegador solo llama a esa función. Si una clave ha estado expuesta, no basta con moverla: hay que rotarla. Supabase lo resume así: la clave pública es la que va en el navegador; la secreta se salta la RLS y no debe salir del servidor.

¿Por qué el login funciona en la vista previa y no en producción?

URLs de redirección del login que apuntan a la vista previa, variables de entorno que existen en un sitio y no en el otro, CORS que solo permite el dominio de pruebas. El resultado típico: el login con Google abre, eliges cuenta y vuelves a la pantalla de inicio sin sesión, en bucle.

• Lista todas las variables de entorno y comprueba que existen en producción con el valor de producción.
• Añade el dominio real a las URLs de redirección del proveedor de login y a la lista de orígenes permitidos.
• Prueba el flujo completo en el dominio real, en una ventana de incógnito y en un móvil.

Sesiones que caducan y nadie renueva

En la demo nadie mantiene la sesión abierta más de una hora. En producción, el token caduca, la app no lo renueva y las llamadas empiezan a fallar en silencio: listas vacías, botones que no hacen nada. Usa el cliente oficial del proveedor de login, que renueva solo, en vez de guardar el token a mano en localStorage.

En móvil: la versión publicada lleva otra firma

Esta nos pasó con Pax. En desarrollo el login con Google funcionaba; en la versión de la tienda devolvía «Requests from this Android client application are blocked». Los ocho testers de la prueba cerrada no podían entrar.

La causa: Google Play vuelve a firmar tu app con su propio certificado (Play App Signing), y ni Firebase ni la clave de API restringida conocían esa huella. Solo estaba la de depuración.

Regla que nos quedó:. registrar las tres huellas — depuración, subida y Play App Signing — el primer día, en Firebase y en cada clave de API restringida.

La versión optimizada se carga piezas que hacían falta

Otra de Pax: una versión arrancaba y se cerraba al instante, antes de pintar nada. En desarrollo, perfecta. El optimizador de Android (R8) había eliminado un constructor que una librería usaba por reflexión; la documentación de Android lo describe: si la app se cierra tras optimizar con R8, suele ser reflexión rota. Tenemos una guía entera sobre por qué funciona en debug y falla en release. Este tipo de fallo solo existe en la compilación de release, así que si nunca pruebas esa compilación en un móvil real, lo descubren tus usuarios.

La app da por hecho que siempre hay buena red

Pax descargaba sus fuentes tipográficas de internet al arrancar. Una conexión que se cortaba a mitad bastaba para tumbar la app. Lo arreglamos empaquetando las fuentes y con un test que falla si alguien vuelve a pedir una por red. La lección general: cualquier llamada de red en el arranque necesita qué hacer cuando falla — y en un metro, un garaje o una obra, falla.

Llamadas a la IA sin límite

Si tu app llama a un modelo de lenguaje en cada pulsación y no hay límite por usuario, un solo usuario insistente (o un bot) puede costarte en una noche lo que facturas en un mes. Pon un límite por usuario y por día en el servidor, cachea lo que se repite y vigila el gasto con una alerta.

Nada avisa cuando algo se rompe

Cada vez que le pides a la IA un cambio, puede romper algo que funcionaba en otra pantalla. Sin tests de lo importante (registro, login, pago, permisos) y sin un informe de errores como Crashlytics o Sentry, te enteras por un correo enfadado. No hace falta cobertura total: hacen falta tests de lo que, si falla, te cuesta clientes.

¿Rescatar o rehacer desde cero?

Casi nunca hay que tirarlo todo (el razonamiento completo, en rescatar o rehacer una app hecha con IA). La parte visual y el flujo que ya has validado con usuarios valen mucho. Lo que suele haber que rehacer es la capa de datos y permisos. Nuestra regla rápida:

• Rescatar si el modelo de datos tiene sentido, el producto ya está validado y los fallos son de configuración, seguridad o robustez (los nueve de arriba).
• Rehacer partes si cada pantalla consulta la base de datos a su manera o la lógica de negocio está repartida por los componentes.
• Rehacer entero solo si el modelo de datos no representa el negocio. Pasa menos de lo que parece.

La IA te llevó al 80 %. El 20 % que falta es el que rompe — y es justo el que se puede auditar.

Preguntas frecuentes sobre apps hechas con IA que fallan

¿Por qué mi app de Lovable o Bolt funciona en la vista previa y falla en producción?

En la vista previa la propia herramienta pone la configuración; en producción la pones tú. Fallan las variables de entorno que no existen en el dominio real, las URLs de redirección del login, el CORS y los permisos de la base de datos. Se detecta probando el flujo completo en el dominio real, en incógnito y en un móvil.

¿Cómo sé si mi base de datos de Supabase está abierta?

En el panel de Supabase, cada tabla de un esquema expuesto debe tener RLS activado y al menos una política. La prueba definitiva es consultarla con la clave pública y sin sesión: debe devolver vacío. Si devuelve filas, cualquiera que abra las herramientas de desarrollador de tu web puede leerlas.

¿Por qué falla el login con Google solo en la versión de la tienda?

Porque Google Play vuelve a firmar la app con su propio certificado (Play App Signing) y Firebase y las claves de API restringidas solo conocen la huella de depuración. Se arregla registrando las tres huellas (depuración, subida y Play App Signing) el primer día en Firebase y en cada clave restringida.

¿Dónde deben guardarse las claves secretas de una app hecha con IA?

En el servidor: una función de Supabase, Vercel o Firebase que el navegador llama sin ver la clave. Las claves de OpenAI, Stripe o la de servicio de Supabase escritas en un componente acaban en el JavaScript público. Si una ha estado expuesta, no basta con moverla: hay que rotarla.

¿Hay que rehacer la app o se puede rescatar?

Casi nunca hay que rehacerla entera. Se rescata si el modelo de datos tiene sentido y los fallos son de configuración, seguridad o robustez. Se rehacen partes si cada pantalla consulta la base de datos a su manera. Solo se rehace todo si el modelo de datos no representa el negocio.

Fuentes

1. Row Level Security — documentación de Supabase
2. API keys — documentación de Supabase
3. CVE-2025-48757 — NVD (NIST)
4. Statement on CVE-2025-48757 — Matt Palmer
5. Use Play App Signing — Ayuda de Play Console
6. Troubleshoot app optimization (R8) — Android Developers

Hoy el registro de jornada es obligatorio para toda empresa desde 2019, pero la ley no exige que sea digital: el real decreto que lo exigirá sigue sin publicarse en el BOE a 2 de octubre de 2026. Los registros se guardan cuatro años y no llevarlos es una infracción grave, con multa de 751 a 7.500 euros. Conviene elegir ya un sistema que aguante el cambio.

Fecha de este texto: 2 de octubre de 2026. La normativa está en tramitación. Lo revisamos cuando cambie algo, pero antes de decidir nada comprueba el BOE y consulta con tu asesoría laboral. Esto no es asesoramiento jurídico.

¿Qué es obligatorio hoy en registro horario?

Desde el 12 de mayo de 2019 (Real Decreto-ley 8/2019, que añadió el apartado 9 al artículo 34 del Estatuto de los Trabajadores), toda empresa debe registrar cada día la hora de inicio y de fin de la jornada de cada trabajador. Eso incluye a las constructoras y a sus cuadrillas, estén donde estén.

• Los registros se guardan cuatro años.
• Tienen que estar a disposición de los trabajadores, de sus representantes y de la Inspección de Trabajo.
• Hoy la ley no fija el formato: papel, Excel o app valen si el registro es fiable y no se puede rehacer a posteriori, según la guía del Ministerio de Trabajo.

¿Qué cambiará con el real decreto de registro digital?

El Ministerio de Trabajo prepara un real decreto que exige que el registro sea digital, objetivo, fiable, inalterable y accesible en remoto por la Inspección. Es decir: se acaban el papel y las hojas de cálculo, porque se pueden manipular. El Ministerio sacó el borrador a audiencia pública en octubre de 2025, con entrada en vigor 20 días después de publicarse en el BOE y dictamen previo del Consejo de Estado.

Estado a la fecha de este artículo: el texto pasó por el Consejo de Estado y en septiembre de 2026 el Ministerio daba el acuerdo por cerrado, pendiente de ajustes legales. No hay fecha oficial de entrada en vigor hasta que se publique. Las estimaciones que circulan la sitúan antes de final de año, sin confirmar.

Lo que sí se repite en todos los borradores conocidos:

• Fichaje personal: cada trabajador registra su entrada y su salida, con hora y minutos.
• Registro que no se pueda modificar sin dejar rastro de quién cambió qué y cuándo.
• Acceso inmediato y remoto para la Inspección de Trabajo.
• Que el trabajador pueda consultar su propio registro.

¿Qué multa te juegas si no registras la jornada?

No llevar el registro, o llevarlo de forma que no refleje la jornada real, es una infracción grave según la Ley de Infracciones y Sanciones en el Orden Social (artículos 7.5 y 40): hoy entre 751 € y 7.500 €. La Inspección sancionó más de 20 millones de euros en el último año por incumplimientos de tiempo de trabajo. Y en una obra, donde suele haber horas extra y subcontratas, es justo donde miran.

Por qué fichar en obra es más difícil que en una oficina

Las apps de fichaje genéricas están pensadas para gente que entra por la misma puerta todos los días. Una obra no se parece a eso. Al construir Tajo con Grupo Edma nos encontramos con estos problemas reales:

• No hay cobertura en sótanos, túneles o parcelas aisladas. Si la app necesita red para fichar, el operario no ficha o ficha tarde (lo desarrollamos en fichar en obra sin cobertura).
• El operario cambia de tajo durante el día, y a la empresa le interesa saber cuántas horas fueron a cada obra.
• Desplazamientos: el tiempo entre obras, ¿es jornada? Tiene que poder registrarse aparte (ver horas de desplazamiento entre obras).
• No hay torno ni tablet fija: el fichaje va en el móvil del trabajador.
• El jefe de obra necesita ver quién está y quién falta sin llamar uno por uno.

¿Se puede fichar con geolocalización?

Sí, con condiciones. La Agencia Española de Protección de Datos admite la geolocalización en el fichaje si es proporcionada: se toma la ubicación en el momento de fichar (no se sigue al trabajador todo el día), se informa por escrito de para qué se usa y no se usa fuera del horario. En Tajo la ubicación se guarda solo al fichar y nunca bloquea el fichaje: si el operario está fuera de la zona de la obra, ficha igual y el registro queda marcado para revisión. El detalle legal está en geolocalización y fichaje de trabajadores, y el parte diario también conviene digitalizarlo: partes de trabajo digitales en construcción.

Lista para elegir sistema de fichaje si tienes obras

• ¿Ficha sin cobertura? Debe guardar el fichaje en el móvil con la hora real y enviarlo al recuperar la red.
• ¿La hora es fiable? La del servidor o una verificada; si vale la hora del móvil, se puede cambiar.
• ¿Deja rastro de las correcciones? Quién corrigió, cuándo y por qué. Sin esto no cumplirá el real decreto.
• ¿Separa horas por obra? Te sirve para costes, no solo para cumplir.
• ¿Puede exportar e informar? Informe mensual por trabajador y acceso para la Inspección.
• ¿Lo puede usar alguien que no se lleva bien con el móvil? Un botón grande, poco texto, nada de menús.
• ¿Cumple con protección de datos? Ubicación solo al fichar, información por escrito, datos en la UE.

No esperes al BOE. Implantar un sistema en una empresa con cuadrillas lleva semanas: dar de alta a la gente, enseñarla y corregir los primeros fallos. Si empiezas cuando se publique, te tocará hacerlo con prisa.

Preguntas frecuentes sobre el registro horario digital

¿Es obligatorio fichar con una app en 2026?

No, todavía no. Desde 2019 es obligatorio registrar cada día el inicio y el fin de la jornada, pero la ley no fija el formato: la guía del Ministerio admite papel o sistema telemático si el registro es fiable e inmodificable. El real decreto en tramitación sí exigirá que sea digital, pero no está publicado en el BOE.

¿Cuánto tiempo hay que conservar los registros de jornada?

Cuatro años. El artículo 34.9 del Estatuto de los Trabajadores obliga a conservarlos durante ese tiempo y a mantenerlos a disposición de los trabajadores, de sus representantes legales y de la Inspección de Trabajo y Seguridad Social. Conviene guardarlos de forma que se puedan consultar y exportar sin esfuerzo.

¿Cuánto es la multa por no llevar el registro horario?

Es una infracción grave de la Ley de Infracciones y Sanciones en el Orden Social, con multa de 751 a 7.500 euros según el grado: mínimo hasta 1.500, medio hasta 3.750 y máximo hasta 7.500. El importe concreto depende de la inspección y de las circunstancias de cada caso.

¿Cuándo entrará en vigor el real decreto de registro digital?

No hay fecha oficial. El borrador que se sacó a audiencia pública en octubre de 2025 preveía que entrara en vigor 20 días después de publicarse en el BOE, y a 2 de octubre de 2026 sigue sin publicarse. Hasta entonces, lo que vale es el artículo 34.9 del Estatuto de los Trabajadores.

¿Se puede fichar con geolocalización en una obra?

Sí, con condiciones: la AEPD lo admite si es proporcionado. Se toma la ubicación solo al fichar, no se sigue al trabajador, se informa por escrito de la finalidad y no se usa fuera de horario. En Tajo, además, la zona de la obra nunca bloquea el fichaje: si falla, ficha igual y se marca para revisión.

Fuentes

1. Estatuto de los Trabajadores, art. 34.9 — BOE
2. Real Decreto-ley 8/2019 — BOE
3. Ley sobre Infracciones y Sanciones en el Orden Social (LISOS) — BOE
4. Guía sobre el registro de jornada — Ministerio de Trabajo
5. La protección de datos en las relaciones laborales — AEPD
6. El registro horario, en audiencia pública y en vigor 20 días tras el BOE — Bolsamanía (9 oct. 2025)

Para publicar una app en Google Play en 2026 necesitas una cuenta de desarrollador (25 dólares, pago único) y, si es una cuenta personal creada después del 13 de noviembre de 2023, una prueba cerrada con al menos 12 testers apuntados de forma continua durante 14 días antes de pedir producción. Después toca completar la ficha, la política de privacidad y el formulario de seguridad de los datos.

¿Cuenta personal o de organización? Decide antes de pagar

La cuenta de desarrollador de Google Play cuesta 25 dólares, una sola vez (a fecha de octubre de 2026). Hay dos tipos y la diferencia importa más de lo que parece:

• Personal: se abre con tu DNI. Si la creaste después del 13 de noviembre de 2023, no puedes publicar en producción sin una prueba cerrada previa (ver el punto 2). Tu nombre y tu dirección pueden aparecer públicamente si la app tiene compras.
• Organización: necesita un número D-U-N-S de tu empresa (gratuito, tarda unos días). No tiene la obligación de la prueba cerrada y la ficha muestra el nombre de la empresa.

Si tienes sociedad o la vas a tener, la cuenta de organización te ahorra dos semanas y da más confianza en la ficha. Y si todavía no has decidido con qué construir la app, mira Flutter o nativo para la app de tu empresa.

¿Qué es la prueba cerrada de 12 testers durante 14 días?

Es el requisito que más proyectos retrasa. Con cuenta personal, antes de pedir acceso a producción necesitas, según los requisitos de pruebas de Google, al menos 12 testers apuntados a una prueba cerrada de forma continua durante 14 días. Si en algún momento bajas de 12, el contador vuelve a empezar.

• Recluta a 15 o 20, no a 12: siempre hay quien se da de baja sin querer.
• Los testers tienen que aceptar la invitación desde el enlace de la prueba y tener la app instalada. Apuntarlos al correo no basta.
• Al pedir producción, Google te pregunta qué probaste y qué cambiaste. Responde con detalle: es una revisión humana.
• Usa esos 14 días de verdad: es la primera vez que tu app corre en móviles que no son el tuyo.

¿Por qué falla solo en la versión de la tienda?

Nos pasó con Pax. Durante la prueba cerrada, los ocho testers que teníamos no podían iniciar sesión con Google. En nuestro móvil, en modo desarrollo, funcionaba perfectamente.

Google Play vuelve a firmar tu app con su propio certificado (Play App Signing). Si usas Firebase, login con Google o claves de API restringidas a tu app, todas tienen que conocer tres huellas: la de depuración, la de tu clave de subida y la de Play App Signing (está en Play Console → Integridad de la app). Nosotros solo teníamos registrada la primera. Es una configuración de diez minutos que, si se olvida, deja la app inservible para todos los que la instalan desde la tienda.

Lo mismo vale para el optimizador de código: la compilación de release puede eliminar piezas que la de desarrollo conserva. Instala siempre en un móvil real la versión que descargas de la prueba cerrada antes de pensar en producción. Tenemos explicado por qué pasa en funciona en debug y falla en release en Android, y es una de las nueve causas de apps hechas con IA que fallan en producción.

La ficha y los formularios

Play Console no te deja enviar la app a revisión hasta que completas todo esto. Resérvate una tarde:

• Política de privacidad en una URL pública. Obligatoria aunque la app no recoja datos.
• Seguridad de los datos: qué datos recoge la app, para qué y si se comparten. Incluye lo que recogen tus librerías (analítica, anuncios, informes de errores).
• Eliminación de la cuenta: si la app permite crear cuentas, la política de Google exige una vía dentro de la app para borrar la cuenta y los datos, y un enlace web donde pedirlo.
• Acceso a la app: si hay login, unas credenciales de prueba para el revisor.
• Clasificación de contenido y público objetivo, con su cuestionario.
• Nivel de API objetivo: cada año Google sube el mínimo. Desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones deben apuntar a Android 16 (API 36) o superior (con posibilidad de pedir prórroga hasta el 1 de noviembre de 2026). Comprueba la tabla oficial antes de compilar.
• Icono de 512 px, gráfico destacado de 1024 × 500 y al menos dos capturas.

Que te encuentren: el título y la descripción corta

Google Play indexa sobre todo el título (30 caracteres), la descripción corta (80) y la larga. Pon en el título lo que la gente busca, no solo tu marca: «Pax: estoicismo diario» se encuentra; «Pax» a secas, no. La categoría también cuenta: elige la que usa tu competencia directa, no la más genérica.

Después de publicar

• Activa un informe de fallos (Crashlytics) antes de la primera versión pública, no después del primer problema.
• Publica en lanzamiento por fases (un porcentaje de usuarios) para que un fallo grave no llegue a todos a la vez.
• Contesta las reseñas: se ven en la ficha y Google lo tiene en cuenta.

Preguntas frecuentes sobre publicar en Google Play

¿Cuánto cuesta publicar una app en Google Play?

La cuenta de desarrollador cuesta 25 dólares, un pago único, a fecha de octubre de 2026, según la ayuda de Play Console. Se paga con tarjeta de crédito o débito (las prepago no se aceptan). Si abres una cuenta de organización, además necesitas un número D-U-N-S, y pedirlo a Dun & Bradstreet es gratuito.

¿Necesito 12 testers para publicar en Google Play?

Solo con cuenta personal creada después del 13 de noviembre de 2023. Antes de pedir producción tienes que tener una prueba cerrada con al menos 12 testers apuntados de forma continua durante 14 días. Las cuentas de organización no tienen ese requisito, pero sí necesitan un número D-U-N-S, que es gratuito.

¿Por qué mi login con Google funciona en desarrollo y falla en la tienda?

Porque Google Play vuelve a firmar la app con su propio certificado (Play App Signing) y Firebase o las claves de API restringidas solo conocen la huella de depuración. Hay que registrar tres huellas: la de depuración, la de la clave de subida y la de Play App Signing, que aparece en Play Console.

¿Qué formularios exige Play Console antes de enviar la app a revisión?

Política de privacidad en una URL pública, formulario de seguridad de los datos, clasificación de contenido, público objetivo, credenciales de prueba si hay login y, si la app permite crear cuentas, una vía para borrarlas dentro de la app y desde la web. Además, el nivel de API objetivo tiene que cumplir el mínimo vigente.

Fuentes

1. Requisitos de prueba para cuentas personales nuevas — Ayuda de Play Console
2. Crear una cuenta de desarrollador de Play Console — Ayuda de Play Console
3. Número D-U-N-S para cuentas de organización — Ayuda de Play Console
4. Use Play App Signing — Ayuda de Play Console
5. Requisitos de nivel de API objetivo — Ayuda de Play Console
6. Eliminación de cuentas de usuario — Ayuda de Play Console
7. Sección de seguridad de los datos — Ayuda de Play Console

Para que una app hecha con Lovable, Bolt, v0 o Cursor sea segura antes de lanzar hay que comprobar ocho cosas: que cada fila de la base de datos tenga dueño (RLS), que la clave secreta no esté en el navegador, que las funciones de servidor no se fíen de lo que reciben, que los buckets privados lo sean, y el login, los límites de uso, el repositorio y las cabeceras.

Las herramientas de vibe coding generan apps que se conectan directamente desde el navegador a Supabase o Firebase. Es un buen diseño, pero tiene una consecuencia: el navegador del usuario es territorio enemigo. Todo lo que tu app puede hacer desde ahí, lo puede hacer también cualquiera con la consola del navegador abierta. La seguridad no está en la interfaz; está en las reglas de la base de datos y en el servidor.

Esto ya pasó:. CVE-2025-48757 describe políticas de seguridad a nivel de fila insuficientes en proyectos generados con Lovable hasta el 15 de abril de 2025. El investigador que lo destapó analizó 1.645 proyectos y encontró 303 puntos de acceso vulnerables en 170 de ellos, con nombres, teléfonos, datos de pago y claves de API. Lovable lo disputa: sostiene que proteger los datos es responsabilidad de cada cliente. Para ti da igual quién tenga razón: el responsable ante tus usuarios eres tú.

Si buscas por qué tu app falla en producción, eso lo contamos en las 9 causas; si dudas entre arreglarla o rehacerla, en rescatar o rehacer; y qué te da cada herramienta, en hasta dónde llega cada una. Esto es otra cosa: la lista para marcar con un bolígrafo antes de lanzar.

¿Tiene dueño cada fila de tu base de datos?

En Supabase, la seguridad a nivel de fila (RLS) decide qué filas puede leer o escribir cada usuario. Con RLS activado y sin políticas, la tabla no devuelve nada por la API pública: cerrada por defecto. Sin RLS, la clave pública lo abre todo. En Firebase el equivalente son las reglas de Firestore y de Storage.

• RLS activado en todas las tablas del esquema público, sin excepción. Supabase incluye un Security Advisor en el panel que avisa de las que no lo tienen.
• Políticas de propiedad, no de sesión. auth.uid() is not null solo comprueba que hay alguien conectado; lo que quieres es (select auth.uid()) = user_id. En Firebase, la misma trampa: request.auth != null deja a cualquier usuario registrado leer los datos de todos.
• Updates con WITH CHECK. USING filtra qué filas puedes tocar; WITH CHECK controla cómo pueden quedar. Si la política no restringe una columna, el usuario puede cambiarla en su propia fila: un campo role o plan editable desde el navegador es una escalada de privilegios. Esas columnas, fuera del alcance del cliente.
• Vistas revisadas. En Postgres las vistas se saltan RLS por defecto. Créalas con security_invoker = true (Postgres 15 o superior) o no las expongas.
• Nada de reglas de «modo prueba». En Firebase, allow read, write: if true deja que cualquiera sobrescriba toda la base de datos: es para el primer día, no para producción.

Cómo probarlo: sin sesión, con la clave pública que ves en el código del navegador, pide una tabla: curl 'https://TU-PROYECTO.supabase.co/rest/v1/pedidos?select=*' -H 'apikey: CLAVE_PUBLICA'. Debe volver []. Después crea dos cuentas, A y B, y desde la consola del navegador con la sesión de A intenta leer, editar y borrar filas de B. Todo debe fallar. Un escáner que te dice «RLS activado» no te dice que las políticas sean correctas; esta prueba sí.

Nos pasó: los tests que nunca corrían. En Tajo, nuestra app de control horario para obra, las reglas de Firestore tienen tests contra el emulador, sobre todo de casos negativos: que un operario no ve los fichajes de otro, que nadie escribe donde no debe. En una auditoría descubrimos que el paso de CI que debía ejecutarlos llevaba fallando en silencio desde siempre: más de 200 tests de reglas que nunca habían llegado a correr. Lo arreglamos y ahora bloquean cada cambio. Moraleja: un test de seguridad que no ves fallar alguna vez no sabes si existe.

¿Qué clave puede verse y cuál jamás?

Supabase tiene dos familias. La pública (anon en el sistema antiguo, sb_publishable_… en el nuevo) está pensada para ir en el navegador y respeta RLS. La secreta (service_role o sb_secret_…) se salta todas las políticas. Supabase lo dice sin rodeos: nunca en un navegador, en una app publicada ni en el control de versiones.

• Busca la clave secreta en el bundle. Abre la web en producción, pestaña Sources o Network de las herramientas de desarrollador, y busca service_role y sb_secret. También en el repositorio: git grep -n service_role.
• Revisa las variables con prefijo público. Todo lo que empieza por NEXT_PUBLIC_ o VITE_ acaba en el navegador. Si ahí hay algo que no sea la URL y la clave pública, está expuesto.
• Claves de terceros igual. OpenAI, Stripe secreta, Resend, Google Maps sin restringir: fuera del cliente.
• Si una clave secreta ha estado expuesta, rótala. Moverla de sitio no basta: quien la copió la sigue teniendo.

¿Confía tu servidor en lo que le llega?

Las Edge Functions de Supabase, las Cloud Functions de Firebase o las rutas de API de Next.js suelen usar la clave secreta. Eso significa que lo que compruebe la función es la única barrera.

• El usuario sale del token, nunca del cuerpo. Si la función recibe { userId: "…" } y actúa en su nombre, cualquiera puede mandar otro userId.
• Permisos dentro de la función. Que el usuario esté identificado no quiere decir que pueda borrar ese pedido o ver esa factura.
• verify_jwt = false solo donde haga falta, como un webhook de Stripe, y en ese caso verificando la firma del webhook.
• Errores sin detalles internos. Un 500 con el SQL o la traza completa le enseña tu esquema a quien pruebe.

Cómo probarlo: llama a cada función con curl sin cabecera de autorización, con el token de otro usuario y con identificadores ajenos en el cuerpo. Las tres llamadas deben fallar.

Almacenamiento: «público» significa público

En Supabase Storage, un bucket público deja descargar cualquier fichero a quien tenga la URL. Subir, borrar o mover sigue controlado por políticas en storage.objects, pero leer no.

• Público solo para lo que de verdad lo es: logos, imágenes de producto, avatares si te parece bien.
• Facturas, DNI, nóminas, contratos: bucket privado y enlaces firmados con caducidad corta, generados después de comprobar permisos.
• Rutas con el id del dueño (user_id/fichero.pdf) y políticas que lo exijan, para que A no pueda subir ni sobrescribir en la carpeta de B.
• Límite de tamaño y tipo de fichero en la configuración del bucket.

Cómo probarlo: copia la URL de un documento privado, ábrela en una ventana de incógnito y debe dar error. Con la sesión de A, intenta subir un fichero a la ruta de B.

Login: verificación y redirecciones

• Confirmación de email activada. Supabase la incluye en su checklist de producción. Sin ella, cualquiera se registra con el correo de otro; y si alguna política o regla se fía del email, peor (Firebase recomienda exigir email_verified en ese caso).
• URLs de redirección exactas en producción. Supabase recomienda la ruta exacta para el Site URL y reservar los comodines para entornos de prueba. Borra las URLs de la vista previa de Lovable o Bolt que ya no uses.
• SMTP propio, para que los correos lleguen desde tu dominio y no parezcan phishing.
• Registro abierto solo si debe estarlo. Una herramienta interna no necesita que se apunte cualquiera de internet.
• Caducidad de enlaces y códigos razonable. Supabase recomienda una hora o menos para los OTP.

Límites: que un bot no te arruine la noche

• Límite por usuario y día en cada función que llame a un modelo de IA, envíe correos o SMS, o cueste dinero por llamada.
• CAPTCHA en registro, inicio de sesión y recuperación de contraseña. Supabase lo soporta en esos tres puntos.
• En Firebase, App Check: comprueba que la petición viene de tu app y no de un script. Complementa las reglas; no las sustituye.
• Alertas de gasto en cada proveedor que facture por uso.

Cómo probarlo: un bucle de cien llamadas seguidas a tu función más cara. Debería empezar a rechazarlas mucho antes de la centésima.

El repositorio: secretos y dependencias

• .env en .gitignore y fuera del historial. Compruébalo con git log --all -- .env. Si sale algo, no basta con borrarlo: GitHub recomienda rotar la credencial de inmediato, porque limpiar el historial es lento y no deshace la exposición.
• Escaneo de secretos activado. GitHub lo hace gratis en repositorios públicos; para los privados, herramientas como gitleaks sirven igual en local.
• npm audit y revisión de lo que la IA añadió: paquetes que no se usan, nombres raros, versiones fijadas hace años.
• Lockfile en el repo, para que producción instale exactamente lo que probaste.

Cabeceras: la última capa, no la primera

Las cabeceras HTTP no arreglan una base de datos abierta, pero cierran ataques en el navegador. Se configuran en Vercel, Netlify o tu servidor en un par de líneas.

• Strict-Transport-Security para forzar HTTPS.
• Content-Security-Policy con los orígenes que de verdad usas, incluido frame-ancestors para que nadie meta tu app en un iframe.
• X-Content-Type-Options: nosniff y Referrer-Policy razonable.
• CORS de tus funciones limitado a tu dominio, no *.

Cómo probarlo: curl -I https://tudominio.com y mira qué cabeceras vuelven. Si no aparece ninguna de las de arriba, no las tienes.

¿Y si solo tienes una tarde?

1. La prueba de las dos cuentas sobre todas las tablas y buckets.
2. Buscar la clave secreta y cualquier clave de terceros en el navegador y en el historial de git.
3. Llamar a cada función sin sesión y con la sesión de otro.

Esas tres cubren lo que más daño hace. El resto es importante, pero una tabla abierta es una filtración el día uno; una cabecera de menos, no.

Que la app funcione demuestra que hace lo que quieres. La seguridad es demostrar que no hace lo que no quieres.

Preguntas frecuentes sobre la seguridad de una app hecha con IA

¿Qué es RLS en Supabase y por qué importa?

RLS, seguridad a nivel de fila, es el mecanismo de Postgres que decide qué filas puede leer o escribir cada usuario. Con RLS activado y sin políticas, la API pública no devuelve nada; sin RLS, quien tenga la clave pública puede leer y escribir la tabla. Como esa clave va en el navegador, las políticas son tu única barrera.

¿Es seguro dejar la clave de Supabase en el código del navegador?

La clave pública (anon o sb_publishable) sí: está pensada para el navegador y respeta RLS. La secreta (service_role o sb_secret) se salta todas las políticas y nunca debe estar en un navegador, en una app publicada ni en el control de versiones. Si estuvo expuesta alguna vez, hay que rotarla.

¿Cómo compruebo que mi base de datos no está abierta?

Sin sesión y con la clave pública, pide una tabla con curl: debe volver una lista vacía. Después crea dos cuentas, A y B, y con la sesión de A intenta leer, editar y borrar filas de B desde la consola del navegador. Si algo de eso funciona, las políticas están mal escritas.

¿Qué pasó con la vulnerabilidad CVE-2025-48757 de Lovable?

El CVE describe políticas RLS insuficientes en proyectos de Lovable hasta el 15 de abril de 2025. El investigador analizó 1.645 proyectos y halló 303 puntos de acceso vulnerables en 170. Lovable lo disputa: sostiene que cada cliente es responsable de proteger los datos de su aplicación.

¿Qué hago si subí un .env o una clave a GitHub?

Rótala de inmediato: borrar el fichero o limpiar el historial no deshace la exposición, porque alguien pudo copiarla ya. Comprueba el historial con git log --all -- .env y activa el escaneo de secretos. GitHub lo ofrece gratis en repositorios públicos; en privados, herramientas como gitleaks sirven en local.

Fuentes

1. CVE-2025-48757 — NVD (NIST)
2. Statement on CVE-2025-48757 — Matt Palmer
3. Understanding API keys — Supabase Docs
4. Row Level Security — Supabase Docs
5. Storage buckets fundamentals — Supabase Docs
6. Redirect URLs — Supabase Docs
7. Going into prod — Supabase Docs
8. Function configuration — Supabase Docs
9. Fix insecure rules — Firebase Documentation
10. Firebase App Check — Firebase Documentation
11. About secret scanning — GitHub Docs

Sí se puede fichar sin cobertura y que el registro valga: la app guarda el fichaje en el móvil y lo envía al volver la señal, la hora legal la pone el servidor y la del teléfono se guarda solo como prueba. La ley exige un registro fiable e inmodificable, no estar conectado.

Fecha de este texto: 2 de octubre de 2026. Lo normativo está resumido y puede cambiar: el real decreto de registro digital sigue sin publicarse en el BOE a esta fecha. Antes de decidir nada, consulta con tu asesoría laboral. Esto no es asesoramiento jurídico.

¿Qué pide la ley si en la obra no hay cobertura?

El artículo 34.9 del Estatuto de los Trabajadores obliga a registrar cada día la hora de inicio y de fin de la jornada de cada trabajador. No dice nada de cobertura. La obra sin señal no es una excepción: es tu problema técnico.

La guía del Ministerio de Trabajo da por bueno «cualquier sistema o medio, en soporte papel o telemático», siempre que proporcione información fiable, inmodificable y no manipulable a posteriori, ya sea por el empresario o por el propio trabajador. Esa frase es la que hay que tener delante al elegir sistema. Un fichaje offline cumple si el sistema puede demostrar dos cosas: que el fichaje no se ha tocado después y que la hora no la ha decidido nadie a su conveniencia.

El real decreto que prepara el Ministerio apunta a lo mismo, pero más estricto: registro digital, trazable y consultable en remoto por la Inspección. Lo contamos con detalle en Registro horario digital obligatorio.

Que el botón funcione sin red

Lo primero es obvio y aun así falla mucho: el trabajador tiene que poder pulsar «Entrada» con el móvil en modo avión y que la app lo acepte. El fichaje se guarda en el teléfono y se envía solo cuando vuelve la señal, al salir a la rampa o al acabar el día.

Parece trivial porque muchas bases de datos móviles ya guardan cambios sin conexión. Firebase, por ejemplo, tiene la persistencia offline activada por defecto en Android e iOS y sincroniza al recuperar red. El problema es que un fichaje serio no debería ser una escritura cualquiera del móvil en la base de datos.

La trampa que encontramos al diseñar Tajo. En Tajo ningún móvil escribe un fichaje: lo crea una función del servidor, para que la hora la ponga el servidor. Y esas llamadas a funciones no entran en la cola offline de Firestore: sin red, fallan y se pierden. Por eso Tajo tiene, desde la primera fase, su propia cola en el teléfono. Si se deja para después, rehacerlo con la app en producción es mucho más doloroso.

Dos detalles que separan una cola que funciona de una que da disgustos:

• Sin duplicados. Cada fichaje lleva un identificador único creado al pulsar, no al enviar. Si la app reintenta y el primer envío sí había llegado, el servidor reconoce que es el mismo y no crea otro. Un fichaje duplicado descuadra la jornada y solo se arregla con una corrección que deja rastro para siempre.
• La pantalla no miente. Mientras el fichaje espera en la cola, la app enseña el estado nuevo («En pausa») aunque el servidor aún no lo sepa. Si no, el trabajador ve «Trabajando», vuelve a pulsar, y el segundo evento lo rechaza el servidor. Acaba en un aviso rojo que culpa al trabajador de un fallo de cobertura.

¿Qué hora vale si el móvil puede mentir?

Aquí está el nudo. Sin red, la única hora disponible es la del reloj del teléfono. Y ese reloj lo puede cambiar el usuario: en Ajustes basta con desactivar la hora automática y poner la que quiera. La propia documentación de Android avisa de que el reloj de pared «puede ser ajustado por el usuario o por la red», así que la hora puede saltar hacia delante o hacia atrás.

Si tu sistema registra como oficial la hora del móvil, el registro es manipulable por el propio trabajador. Justo lo que la guía del Ministerio dice que no puede pasar. Hay varias formas de resolverlo, con distinto equilibrio:

En Tajo elegimos la primera, con red de seguridad. La hora legal la pone el servidor; la del móvil viaja con el fichaje y se guarda como prueba, nunca como fuente. Si entre las dos hay diez minutos o más, el fichaje queda marcado como «Enviado con retraso» y la jornada muestra la incidencia en el panel de RRHH. No se rechaza: el trabajador fichó de verdad, lo que falló fue la red.

El móvil dice cuándo pulsaste. El servidor dice cuándo se supo. Guardar las dos y no esconder la diferencia es lo que hace creíble el registro.

Que nadie pueda retocarlo después

Un fichaje diferido con retraso hay que poder corregirlo. La cuestión es cómo. Si RRHH puede editar la hora y la original desaparece, el registro deja de ser «inmodificable» en el sentido de la guía: nadie podría demostrar qué se cambió.

Así lo resolvimos en Tajo. Los fichajes no se editan ni se borran jamás. Corregir es crear un evento nuevo que apunta al original y lleva un motivo obligatorio. Además, cada evento se encadena con el anterior mediante una huella criptográfica (SHA-256), y una verificación periódica comprueba la cadena entera. Si alguien reescribiera un fichaje antiguo, incluso con acceso de administrador a la base de datos, la cadena se rompería y se notaría.

Pregunta para cualquier proveedor:. «Si mi encargado cambia una hora, ¿qué ve la Inspección?». La respuesta buena es «la hora original, la nueva, quién lo cambió, cuándo y por qué». Si la respuesta es «la nueva», el sistema no te protege.

¿Qué pasa si el fichaje no llega nunca?

Móvil que se queda sin batería, que se rompe o que pasa una semana en la furgoneta sin red. La cola no puede reintentar eternamente ni perder datos en silencio. En Tajo un fichaje que lleva más de 72 horas sin poder enviarse deja de reintentarse solo y se le ofrece al trabajador pedir una corrección manual, que pasa por aprobación. Si el servidor rechaza un fichaje por algo que no se arregla reintentando (por ejemplo, una cuenta dada de baja), queda a la vista como rechazado, no escondido.

Las alternativas al móvil de cada uno, con sus pegas

La app en el móvil personal no es la única opción. Todas tienen algo bueno y todas tienen su letra pequeña:

• Tablet de obra en la caseta. Un solo dispositivo, controlado por la empresa, con la hora bien configurada. Pero tiene que estar donde está la gente: si la caseta queda lejos del tajo, se ficha a destiempo. Y sigue necesitando cola offline si en la caseta tampoco hay red.
• Tablet con huella o reconocimiento facial. Atractiva contra el «fichar por otro». Pero la guía de la AEPD de noviembre de 2023 trata los datos biométricos como categoría especial y exige superar un análisis de necesidad y proporcionalidad estricto. Para fichar, en la práctica, es meterse en un problema evitable.
• Etiqueta NFC o código QR en la obra. Prueban que el trabajador estuvo junto a la etiqueta y no dependen del GPS, que en un sótano tampoco funciona bien. La pega: un QR se fotografía y se escanea desde casa, y una etiqueta se puede despegar. Ayudan a saber dónde, no resuelven el cuándo.
• Papel como respaldo. La guía lo admite si es fiable e inalterable, y para el día que se caiga todo está bien tenerlo. Pero el papel se rellena a final de semana, se pierde y no se puede consultar en remoto. Si el real decreto sale como apuntan los borradores, dejará de servir como sistema principal. El parte diario también conviene digitalizarlo: lo vemos en partes de trabajo digitales.

Sobre la ubicación: en Tajo la geocerca de la obra nunca bloquea el fichaje. Si el GPS falla o el trabajador está fuera de la zona, ficha igual y queda marcado para revisión. Bloquear es la forma más rápida de que alguien no fiche y la jornada quede sin registrar, que es justo lo que querías evitar. Lo desarrollamos en Geolocalización y fichaje.

Cinco pruebas para hacer en la propia obra

Ninguna demo en una oficina con wifi te dice nada de esto. Lleva el sistema al sitio peor de tu obra y comprueba:

• Modo avión, fichar entrada, pausa y salida. Las tres se aceptan y la pantalla enseña el estado correcto.
• Quitar el modo avión. Los tres fichajes llegan una sola vez, sin duplicados, en el orden en que se pulsaron.
• Cambiar la hora del móvil a mano y fichar. El panel tiene que enseñar la diferencia, no tragársela.
• Corregir una hora desde el panel. La original sigue visible, con quién cambió qué y por qué.
• Pedir la exportación de un mes. Tiene que salir con todas las horas e incidencias, lista para entregar.

Si un sistema pasa las cinco, el sótano deja de ser un problema de registro horario. Si falla la tercera, lo que tienes es un reloj que el trabajador puede retrasar a voluntad. Y si la cuadrilla cambia de obra a media jornada, mira también cómo contar las horas de desplazamiento entre obras.

Preguntas frecuentes sobre fichar sin cobertura

¿Es legal fichar con el móvil sin conexión?

Sí. El Estatuto obliga a registrar el inicio y el fin de la jornada, no a estar conectado. La guía del Ministerio pide que el registro sea fiable, inmodificable y no manipulable: el fichaje puede guardarse en el móvil y enviarse después si el sistema demuestra que nadie lo ha tocado.

¿Qué hora vale si el trabajador cambia la hora del móvil?

La del servidor. El reloj del teléfono lo puede ajustar el propio usuario, así que solo debería guardarse como prueba. En Tajo, si las dos horas difieren diez minutos o más, el fichaje se marca como «Enviado con retraso» y aparece en el panel de RRHH para revisarlo.

¿Sirve el papel como sistema de fichaje en obra?

Hoy la guía lo admite si es fiable e inalterable, y es un buen respaldo para el día que falle todo. Pero se rellena tarde, se pierde y no se consulta en remoto. Si el real decreto sale como apuntan los borradores, dejará de valer como sistema principal.

¿Se puede fichar con huella o reconocimiento facial?

La AEPD trata la huella y el reconocimiento facial como datos de categoría especial y, en su guía de noviembre de 2023, exige superar un análisis de necesidad y proporcionalidad estricto. Para fichar, en la práctica, es meterse en un problema que se puede evitar con otros sistemas.

Fuentes

1. Guía sobre el registro de jornada — Ministerio de Trabajo (2019)
2. Estatuto de los Trabajadores, art. 34.9 — BOE
3. SystemClock — documentación de Android
4. Ajuste de fecha y hora en Android (Set time automatically, NITZ/NTP) — Zebra
5. Persistencia offline de Cloud Firestore — Firebase
6. Guía sobre control de presencia con sistemas biométricos — AEPD (nov. 2023)
7. El registro horario, en audiencia pública y en vigor 20 días tras el BOE — Bolsamanía

Una app funciona en debug y falla en release porque la compilación de release es otra app: R8 elimina código que se usaba por reflexión, Google Play la vuelve a firmar con otro certificado, se quitan recursos y el permiso de internet de debug, y se desactivan los assert. Las 8 causas se cazan probando la compilación de release en un móvil real antes de cada subida.

Cuando ejecutas flutter run estás en modo debug: sin optimizar, firmado con una clave de desarrollo, con permisos extra para que las herramientas hablen con la app y con las aserciones activas. La compilación de release cambia todo eso a la vez. Por eso hay fallos que no existen en debug ni en los tests y aparecen el día que la app llega a la tienda.

De dónde sale esta lista. De publicar Pax, nuestra app en Google Play. Algunos de estos fallos los encontramos probando la compilación de release en un móvil real; otros nos los enseñó Crashlytics después de subir una versión. Donde decimos que pasó, pasó.

¿Por qué R8 borra algo que se usaba por reflexión?

En release, Android pasa tu código por R8, que elimina lo que cree que nadie usa y renombra el resto. Flutter lo activa siempre en las compilaciones de release, y desde el Android Gradle Plugin 8.0 viene en modo completo por defecto, más agresivo. El problema: R8 no ve el código que se invoca por reflexión. Si una librería crea una clase por su nombre, R8 puede haberse cargado justo eso.

Nos pasó: la app se cerraba antes de pintar nada. Una versión de Pax se cerraba al abrirla, en todos los arranques, antes de que arrancara Flutter: 85 cierres de 9 usuarios en una semana, según Crashlytics. El error era Failed to create an instance of androidx.work.impl.WorkDatabase. Habíamos añadido una librería de anuncios que traía WorkManager como dependencia transitiva; WorkManager usa Room, Room instancia su base de datos por reflexión y R8 había eliminado el constructor sin argumentos de WorkDatabase_Impl. Se arregló con una línea en proguard-rules.pro: -keep class * extends androidx.room.RoomDatabase { <init>(); }.

La pista la dio el propio R8. Junto a cada compilación deja en build/app/outputs/mapping/release/ un usage.txt con lo que eliminó y un seeds.txt con lo que conservó por una regla. Ahí aparecía el constructor borrado; tras el arreglo, ya no. La documentación de Android lo resume bien: si ves ClassNotFoundException, NoSuchMethodException o parecidos solo en release, sospecha de reflexión y añade una regla -keep.

R8 también rompe cosas sin cerrar la app

El cierre al arrancar al menos se nota. Peor es lo que falla en silencio. En Pax, la notificación diaria —el gancho central de la app— nunca se programaba en release. El logcat decía TypeToken must be created with a type argument: R8 había quitado las firmas genéricas que Gson necesita dentro del plugin flutter_local_notifications. Y el mismo fallo tumbaba el receptor que reprograma las notificaciones al reiniciar el móvil.

Arreglo: -keepattributes Signature más las reglas de Gson y del plugin. La lección general: cuando metes una dependencia nueva con código nativo, revisa si documenta reglas de R8, y prueba la función que la usa en release, no solo que la app abra.

¿Por qué falla el login solo con la firma de Play?

Tu app tiene al menos tres certificados: el de depuración que genera el SDK, el de subida con el que firmas el bundle y el de firma de apps de Play, porque con Play App Signing Google vuelve a firmar lo que subes antes de entregarlo a los usuarios (el mismo fallo, visto desde las apps hechas con IA, en las 9 causas). Firebase, el login con Google y cualquier clave de API restringida a «Apps para Android» comprueban esa huella.

En Pax, el login con Google funcionaba en debug y en release devolvía Requests from this Android client application ... are blocked. Dos huecos a la vez: la clave de API de Android solo tenía autorizada la huella de depuración, y Firebase no conocía la de Play App Signing. Resultado: los ocho testers de la prueba cerrada no podían entrar. El arreglo no necesitó recompilar, porque la validación es del lado del servidor: añadir las huellas que faltaban y esperar a que se propagaran.

Regla que nos quedó:. registrar las tres huellas (depuración, subida y Play App Signing) el primer día, en Firebase y en cada clave de API restringida. Las de Play están en Play Console, en la página de firma de apps. Si algún día cambias la clave de firma, repite el proceso.

Recursos que desaparecen del APK

Con shrinkResources activo, el empaquetado elimina los recursos de Android que no ve referenciados. Si un recurso solo se nombra desde Dart, para Android no existe. Nos pasó con el icono pequeño de la notificación de Pax, que se pasa por nombre desde el código Flutter: lo protegimos con un res/raw/keep.xml y su atributo tools:keep antes de que la compilación de release lo dejara fuera.

¿Falta el permiso de internet en release, o hay HTTP a pelo?

Un clásico de Flutter: la plantilla de proyecto declara android.permission.INTERNET en los manifiestos de debug y profile, porque las herramientas lo necesitan para la recarga en caliente. Si tu manifiesto principal no lo declara, en debug hay red y en release no. Las llamadas fallan y, según cómo trates el error, la app solo muestra listas vacías.

El primo de este fallo: desde Android 9, las apps que apuntan a ese nivel de API o superior tienen el tráfico HTTP sin cifrar bloqueado por defecto. Si en desarrollo apuntabas a un servidor local por http://, en producción todo debe ir por HTTPS, y la excepción, si de verdad la necesitas, se declara en la configuración de seguridad de red solo para ese dominio.

Código que solo corre en debug sin que lo sepas

En release, Flutter desactiva las aserciones: todo lo que esté dentro de un assert(...) no se ejecuta. Si dentro había una inicialización «de paso», en release no ocurre. Lo mismo con ramas condicionadas a kDebugMode, valores que llegan por --dart-define en tu comando local y no en el de compilación, o un google-services.json distinto por entorno.

• Busca assert( y kDebugMode en el código y comprueba que ninguno esconde lógica que la app necesita.
• Escribe en un script el comando exacto de compilación de release, con todos sus --dart-define. Que no dependa de la memoria de nadie.
• Comprueba que la configuración de Firebase del bundle es la del proyecto de producción.

Debug miente sobre el rendimiento (en los dos sentidos)

El modo debug está pensado para iterar rápido, no para ir rápido. Una animación que tartamudea en debug puede ir perfecta en release, y al revés: una carrera entre dos tareas asíncronas que en debug nunca se cruzaban porque todo iba lento puede aparecer cuando la app compila optimizada. Para medir rendimiento, Flutter tiene el modo profile (y Flutter o nativo explica dónde se va de verdad el tiempo); para cazar carreras, prueba en release en un móvil modesto, no solo en el tuyo.

Los logs desaparecen y la red de la oficina es demasiado buena

En release no hay depurador ni pantalla roja de error: el fallo se queda en una pantalla gris o en nada. Si no tienes un informe de errores, los cierres de tus usuarios no los ves. Y hay fallos que no son de release pero se esconden igual de bien: Pax descargaba sus fuentes de Google Fonts al arrancar, y una conexión que se cortó a mitad provocó un error no capturado que Crashlytics nos trajo de los testers. Lo arreglamos empaquetando las fuentes, desactivando la descarga en tiempo de ejecución y con un test que falla si alguien vuelve a pedir una por red.

Guarda el mapping de cada versión:. R8 renombra clases y métodos, así que una traza de release sin su mapping.txt es ilegible. El fichero se sobrescribe en cada compilación. El plugin de Gradle de Crashlytics lo sube solo, pero si usas --split-debug-info u --obfuscate en Flutter, los símbolos de Dart hay que subirlos a mano con firebase crashlytics:symbols:upload.

¿Cómo cazarlo antes que tus usuarios?

Ninguno de estos fallos se ve en debug, y casi ninguno en los tests unitarios. La única defensa es probar la compilación de release de verdad, antes de cada subida. Flutter no ejecuta release en emuladores, así que hace falta un móvil físico. Nuestra rutina:

1. Compila en release (flutter build apk --release, o genera APKs desde el AAB con bundletool) e instálala en un móvil real con flutter install o adb install.
2. Deja adb logcat abierto y recorre lo que da dinero o retiene: arranque en frío, login, compra, notificaciones, permisos. Cinco minutos mínimo.
3. Reinicia el móvil y abre la app otra vez: los receptores de arranque fallan ahí.
4. Prueba con el modo avión a mitad de una carga.
5. Si has metido una dependencia nueva, mira el usage.txt de R8 antes de subir.
6. Sube primero a la pista de prueba interna o cerrada: es la única forma de probar con la firma de Play, la que de verdad llegará a los usuarios.

La compilación de release no es la de debug con otro nombre. Es otra app, y merece su propia QA.

Preguntas frecuentes sobre fallos solo en release

¿Por qué mi app Flutter funciona en debug y falla en release?

Porque la compilación de release cambia varias cosas a la vez: R8 optimiza y elimina código, Google Play firma con otro certificado, shrinkResources quita recursos, desaparece el permiso de internet de los manifiestos de debug y se desactivan los assert. Son fallos que no existen en debug ni en los tests unitarios.

¿Cómo sé si R8 está rompiendo mi app?

Si ves ClassNotFoundException, NoSuchMethodException o errores parecidos solo en release, sospecha de reflexión. R8 deja en build/app/outputs/mapping/release/ un usage.txt con lo que eliminó y un seeds.txt con lo que conservó. Se arregla con una regla -keep en proguard-rules.pro para la clase eliminada.

¿Por qué falla el login con Google solo en la versión de la tienda?

Porque Firebase y las claves de API restringidas validan la huella del certificado, y con Play App Signing Google vuelve a firmar la app con el suyo. Hay que registrar las tres huellas: depuración, subida y Play App Signing. La validación es del lado del servidor, así que no hace falta recompilar.

¿Falta el permiso de internet en mi app en release?

Puede ser. La plantilla de Flutter declara android.permission.INTERNET solo en los manifiestos de debug y profile, porque las herramientas lo necesitan. Si tu manifiesto principal no lo declara, en debug hay red y en release no. Además, desde Android 9 el tráfico HTTP sin cifrar está bloqueado por defecto.

¿Cómo pruebo la versión de release antes de subirla a Google Play?

En un móvil físico, porque Flutter no ejecuta release en emuladores. Instala la build de release, deja adb logcat abierto y recorre arranque en frío, login, compra y notificaciones; reinicia el móvil y prueba con modo avión. Después sube a una pista de prueba, que es la única que usa la firma de Play.

Fuentes

1. Flutter build modes — Flutter
2. Build and release an Android app — Flutter
3. Plantilla del AndroidManifest.xml de debug de Flutter — GitHub
4. Android Gradle plugin 8.0 release notes — Android Developers
5. Troubleshoot app optimization (R8) — Android Developers
6. Customize which resources to keep — Android Developers
7. Sign your app — Android Developers
8. Network security configuration — Android Developers
9. Get deobfuscated crash reports (Flutter) — Firebase Crashlytics

Arreglar o rehacer una app hecha con IA se decide por el modelo de datos, no por lo feo que esté el código: si las tablas representan tu negocio y los permisos se pueden escribir sobre ellas, se rescata; si la lógica está repartida por las pantallas, se rehace por capas; y solo si el modelo no representa el negocio se rehace entero, conservando diseño, flujos y textos.

El momento es reconocible. Le pides a la IA que arregle el carrito y deja de funcionar el registro. Le pides que arregle el registro y vuelve a fallar el carrito. Llevas semanas así y la tentación es abrir un proyecto nuevo y «hacerlo bien esta vez».

A veces es la decisión correcta. Muchas veces no. Y lo que la decide no es si el código se ve desordenado — el código generado casi siempre se ve desordenado — sino si los cimientos representan tu negocio. Eso se comprueba en cuatro sitios concretos.

Antes de tocar nada:. saca el código a un repositorio tuyo. Lovable sincroniza con GitHub, GitLab o Bitbucket en los dos sentidos y Bolt se conecta a GitHub para copiar el proyecto fuera de la herramienta. Rescates o rehagas, ese repositorio es lo que se audita y lo que te protege si la herramienta cambia de planes.

¿Solo hay dos opciones? No, son tres

«Arreglar o rehacer» deja fuera la salida más habitual: rehacer por capas. Mantener lo que ya funciona (pantallas, flujos, textos) y sustituir lo que está podrido, normalmente la capa de datos y permisos. Es menos épico que empezar de cero y casi siempre más rápido. Las herramientas se comparan en hasta dónde llega cada una.

Para saber cuál de las tres te toca, mira estas cuatro señales por orden. La primera pesa más que las otras tres juntas.

El modelo de datos: ¿cuenta la verdad de tu negocio?

Abre las tablas de la base de datos y pregúntate si alguien de tu sector las entendería. Si vendes reservas, ¿hay una tabla de reservas con su estado, su cliente y su fecha? ¿O la reserva vive repartida entre tres tablas y un campo de texto con JSON dentro?

• Cada concepto del negocio tiene su sitio, y uno solo. No hay clientes y customers conviviendo.
• Las relaciones existen de verdad (claves ajenas), no como un nombre copiado en otra tabla.
• Los datos que importan no están en campos de texto libre que nadie puede consultar.
• Hay datos de usuarios reales que habría que migrar si rehaces. Cuantos más, más cara la reescritura.

Si el modelo es razonable, casi todo lo demás se puede arreglar encima. Si no representa el negocio, cada pantalla que construyas encima heredará el problema. Es la única señal que, por sí sola, justifica rehacer.

La estructura: ¿la lógica tiene casa?

El patrón típico del código generado (y una de las 9 causas por las que estas apps fallan en producción): cada pantalla habla directamente con la base de datos, a su manera. La regla de «un pedido no puede cancelarse si ya se envió» está escrita en tres componentes, y en dos de ellos de forma distinta. Por eso cada cambio rompe otra cosa: no hay un único sitio donde vivan las reglas.

Esto no es motivo para tirarlo todo. Es motivo para rehacer por capas: sacar las reglas a un sitio común (un servicio, unas funciones de servidor) y que las pantallas lo usen. Las pantallas se quedan; lo que cambia es lo que hay detrás.

La autenticación y los permisos: ¿quién puede ver qué?

Aquí está el riesgo de verdad. Muchas apps hechas con estas herramientas usan Supabase, donde la clave pública va en el navegador y lo que protege los datos es la seguridad a nivel de fila (RLS). Si está desactivada o mal escrita, cualquiera con esa clave lee lo que no debe. La lista completa está en la seguridad de una app hecha con Lovable, Bolt o Supabase.

La pregunta para decidir no es si hay fallos — los suele haber — sino si los permisos se pueden expresar sobre el modelo actual. Si cada fila sabe a quién pertenece, escribir las políticas es trabajo acotado. Si no hay forma de saber de quién es un dato sin recorrer media aplicación, el problema vuelve a la señal 01.

Cómo lo probamos en Tajo:. nuestra app de control horario para obra tiene cuatro roles: operario, jefe de obra, RRHH y administración. En la QA recorremos la app con cada uno de ellos, no solo con el administrador. Es la única forma de ver qué puede hacer cada uno, que no siempre coincide con lo que debería poder hacer.

Los tests: ¿algo avisa cuando se rompe?

En la mayoría de proyectos generados no hay ninguno, así que esta señal rara vez decide por sí sola. Lo que sí dice es cuánto cuesta cada cambio: sin tests, cada arreglo es una apuesta. Antes de tocar nada en un rescate, lo primero es escribir tests de lo que, si falla, cuesta clientes: registro, login, pago, permisos. Esos tests sirven también si rehaces: son la especificación de lo que la versión nueva tiene que seguir haciendo.

Lo que se conserva casi siempre

Aunque acabes rehaciendo el código entero, hay trabajo hecho que no se tira. A menudo es lo más caro de conseguir:

• El diseño. Colores, tipografía, componentes de interfaz. Si ya gustan, se reutilizan tal cual o casi.
• Los flujos validados. El orden de las pantallas que tus primeros usuarios ya entienden. Cambiarlo «porque ahora lo hacemos bien» es tirar aprendizaje.
• El texto. Los mensajes, los botones, la ficha de producto. Se escribieron probando y corrigiendo; no se reescriben gratis.
• Las decisiones de producto. Qué se quitó y por qué. Anótalo antes de empezar o la versión nueva lo volverá a añadir.

¿Cómo es una auditoría seria y qué tienes que recibir?

Una auditoría seria no es «le he echado un vistazo y hay que rehacerlo». Es un documento que puedes leer, discutir y enseñar a otro proveedor. En Relevo, nuestro servicio para estos proyectos, la auditoría ocupa los primeros cinco días y es por escrito. Esto es lo que se mira:

1. El modelo de datos frente a lo que hace el negocio.
2. Los permisos: políticas de la base de datos, claves expuestas en el navegador, qué ve cada rol.
3. Dónde vive la lógica y cuánta está duplicada.
4. La configuración de producción: variables de entorno, dominios, URLs de redirección del login.
5. Qué se rompe al probar los flujos principales de punta a punta en un dispositivo real.

Y lo que tienes que recibir al final: qué se queda, qué se tira y cuánto cuesta cada opción. Con eso decides tú, no quien te lo va a cobrar. En nuestro caso, al día siguiente llega un presupuesto cerrado con precio y fecha antes de tocar una línea.

Desconfía de dos respuestas:. «hay que rehacerlo todo» sin haber mirado el modelo de datos, y «esto se arregla en un par de tardes» sin haber probado los permisos. Las dos ahorran trabajo a quien las da, no a ti.

Los errores típicos al reescribir

Si la auditoría dice que toca rehacer, el peligro cambia de sitio. Estos son los clásicos, y algunos tienen nombre desde hace décadas.

El efecto del segundo sistema

Fred Brooks lo describió en 1975 en «The Mythical Man-Month»: el segundo sistema que diseña alguien tiende a cargarse con todo lo que se quedó fuera del primero. En una reescritura suena así: «ya que empezamos de cero, metemos también los pagos recurrentes, el panel de analítica y la app nativa». Resultado: la versión nueva tarda el triple y el producto que funcionaba se queda congelado mientras tanto. La versión nueva tiene que hacer lo mismo que la vieja, bien hecho. Lo nuevo, después.

Perder lo que ya estaba validado

Joel Spolsky lo contó en el año 2000, en «Things You Should Never Do, Part I», a propósito de Netscape, que decidió reescribir su navegador desde cero: el código feo esconde arreglos de casos raros que costó encontrar con uso real. En una app hecha con IA pasa igual a pequeña escala: ese if extraño puede ser el arreglo del usuario que se registraba dos veces. Antes de borrar, haz la lista de comportamientos que funcionan y conviértela en tests.

Repetir el método que trajo el problema

Abrir un proyecto nuevo en la misma herramienta y pedirle lo mismo con otras palabras suele llevar al mismo sitio. Si rehaces, empieza por lo que faltó la primera vez: el modelo de datos escrito y revisado, los permisos definidos por rol y los tests de lo crítico. La IA puede seguir escribiendo mucho código; lo que no puede es decidir eso por ti.

Olvidarse de los usuarios que ya tienes

Si hay gente usando la app, rehacer incluye migrar sus cuentas y sus datos sin que lo noten. Es trabajo propio, con su prueba y su plan de vuelta atrás. Si no está en el presupuesto, el presupuesto está incompleto.

¿Cuál es la regla rápida para decidir?

Si tuviéramos que resumirlo en un solo esquema, sería este:

Empezar de cero parece barato porque lo caro ya lo pagaste: aprender qué querían tus usuarios. No lo tires con el código.

Preguntas frecuentes sobre rescatar o rehacer una app hecha con IA

¿Cuándo conviene rehacer una app hecha con IA en vez de arreglarla?

Cuando el modelo de datos no representa el negocio y los permisos no se pueden expresar sobre él: es la única señal que por sí sola justifica rehacer. Si el fallo es de configuración, permisos o robustez, se rescata. Si la lógica está repartida por las pantallas, se rehace por capas y se conserva la interfaz.

¿Qué se conserva al rehacer una app?

Casi siempre el diseño (colores, tipografía, componentes), los flujos que tus primeros usuarios ya entienden, los textos y las decisiones de producto, es decir, qué se quitó y por qué. Es trabajo hecho a base de probar y corregir, y suele ser lo más caro de conseguir: se reutiliza aunque se reescriba todo el código.

¿Qué debe incluir una auditoría de una app hecha con IA?

Un documento escrito que revise el modelo de datos frente al negocio, los permisos y las claves expuestas, dónde vive la lógica y cuánta está duplicada, la configuración de producción y los flujos principales probados en un dispositivo real. Al final tienes que saber qué se queda, qué se tira y cuánto cuesta cada opción.

¿Cómo saco el código de Lovable o Bolt antes de decidir?

Lo primero es copiarlo a un repositorio tuyo. Lovable sincroniza en los dos sentidos con GitHub, GitLab o Bitbucket, y Bolt se conecta a GitHub para guardar el proyecto con su historial fuera de la herramienta. Ese repositorio es lo que se audita, lo decidas como lo decidas.

¿Por qué suelen salir mal las reescrituras completas?

Por dos motivos que conocemos desde hace décadas: el efecto del segundo sistema, que carga la versión nueva con todo lo que quedó fuera de la primera, y perder arreglos de casos raros que el código viejo ya tenía. Por eso la versión nueva debe hacer primero lo mismo que la vieja, y lo nuevo, después.

Fuentes

1. Sync your Lovable project with GitHub — Lovable Docs
2. GitHub for version control — Bolt Support
3. Row Level Security — Supabase Docs
4. The Mythical Man-Month — Wikipedia
5. Things You Should Never Do, Part I — Joel on Software (6 de abril de 2000)

Sí, fichar con geolocalización es legal en España si se hace con proporcionalidad: el artículo 90 de la LOPDGDD permite tratar la ubicación para controlar el trabajo, pero la AEPD limita el uso al registro de la hora de inicio y de fin. Hay que informar antes por escrito, guardar solo un punto al fichar y no seguir al trabajador fuera de la jornada.

Fecha de este texto: 2 de octubre de 2026. Resumimos normativa y criterios públicos de la AEPD tal como están hoy. Esto no es asesoramiento jurídico: antes de implantar un sistema, revísalo con tu asesoría laboral o tu delegado de protección de datos.

¿Se puede fichar con geolocalización? La respuesta corta

El artículo 90 de la LOPDGDD dice que el empleador puede tratar datos de geolocalización para ejercer las funciones de control que le da el artículo 20.3 del Estatuto de los Trabajadores, «dentro de su marco legal y con los límites inherentes al mismo». Y el artículo 20 bis del Estatuto reconoce al trabajador el derecho a la intimidad frente a esos mismos sistemas.

Es decir: la herramienta es legal; el abuso, no. Todo lo que sigue va de dónde están esos límites.

¿Hace falta el consentimiento del trabajador? No, y no te sirve

Es el error más repetido: hacer firmar al operario un «consiento que me geolocalicen». La guía de la AEPD sobre relaciones laborales es clara: la base jurídica no es el consentimiento, sino el contrato de trabajo y las facultades de control que la ley da al empleador. En una relación laboral el consentimiento difícilmente es libre, y si el trabajador lo retira, te quedas sin base.

Para el registro de jornada en sí, la base es otra todavía: la obligación legal del artículo 34.9 del Estatuto, que explicamos en registro horario digital obligatorio. Esto importa por lo que viene después.

Informar antes, por escrito y sin letra pequeña

El artículo 90.2 de la LOPDGDD obliga a informar con carácter previo, de forma expresa, clara e inequívoca a los trabajadores y, en su caso, a sus representantes, de la existencia y características de estos sistemas. También de cómo ejercer los derechos de acceso, rectificación, limitación y supresión. A eso se suma la información del artículo 13 del RGPD.

• Qué se recoge exactamente: ¿un punto al fichar o una ruta?
• Para qué: comprobar dónde empieza y acaba la jornada, no evaluar al trabajador.
• Quién lo ve dentro de la empresa y durante cuánto tiempo se guarda.
• Qué pasa si el GPS falla o el trabajador deniega el permiso.
• Cómo pedir acceso a sus datos o su corrección.

El convenio colectivo puede añadir garantías (artículo 91 LOPDGDD), así que conviene mirarlo antes de redactar nada.

Un punto al fichar no es un mapa del día

Aquí está el corazón del asunto. La AEPD aplica dos principios del RGPD: minimización (no recoger más de lo necesario) y limitación de la finalidad (no usarlo para otra cosa). Su guía lo baja a tierra: si la geolocalización se usa para el registro horario, los datos sirven para las horas de inicio y fin, no para verificar dónde está la persona en cada momento.

El registro de jornada es «un instrumento de comprobación del tiempo de trabajo y no del lugar donde se desarrolla la actividad». — Guía de la AEPD, sobre un trabajador itinerante que ficha por geolocalización.

Añade la guía que el principio de proporcionalidad exige limitar estos sistemas a situaciones donde no haya medios menos invasivos, y que si la tecnología es nueva para la empresa conviene una evaluación de impacto antes de implantarla. Traducido a obra: guardar la posición en el instante de fichar es defendible; tener a la cuadrilla en un mapa en directo toda la jornada es muy difícil de justificar.

Cuando acaba la jornada, se apaga

El artículo 88 de la LOPDGDD reconoce el derecho a la desconexión digital fuera del tiempo de trabajo, y el 20 bis del Estatuto lo repite. Con la ubicación esto es literal. La guía de la AEPD recoge una sentencia del TSJ de Asturias (STSJ AS 4125/2017) que obligó a una empresa a garantizar que el GPS de sus vehículos no estuviera operativo una vez terminada la jornada: el poder de control termina cuando termina el trabajo.

Para una app de fichaje la consecuencia es sencilla: nada de pedir ubicación en segundo plano «por si acaso». Si la app no está abierta y el trabajador no está fichando, no tiene por qué saber dónde está. Y si la cobertura falla, el fichaje debe poder guardarse igual, como contamos en fichar en obra sin cobertura.

¿Puedes obligar a usar el móvil personal?

En obra casi todo el mundo ficha con su propio teléfono, y aquí hay que andar con cuidado. La guía de la AEPD dice que no es lícito imponer al trabajador que aporte medios personales, como su móvil, para facilitar la geolocalización, y cita una sentencia de la Audiencia Nacional (SAN 136/2019) que tumbó una cláusula que obligaba a los repartidores a tener móvil con datos para instalar una app de seguimiento.

Aviso:. en 2026 la AEPD multó con 200.000 euros a una empresa de VTC que obligaba a sus conductores a instalar en su móvil personal aplicaciones con permisos de geolocalización, entre otros. El desglose: 100.000 € por minimización, 80.000 € por falta de base jurídica y 20.000 € por información insuficiente.

La lectura práctica: si la ubicación va en el móvil del trabajador, que sea lo mínimo, que esté bien explicada y que no se convierta en condición para poder fichar. Si para trabajar hace falta geolocalizar sí o sí, lo limpio es que el dispositivo lo ponga la empresa.

Geocercas: ¿marcan o bloquean?

Una geocerca es un círculo alrededor de la obra. Cuando alguien ficha, se compara su posición con el círculo. La pregunta de diseño es qué pasa si cae fuera. Hay dos escuelas:

La ley no impone ninguna de las dos. Pero si tu objetivo es cumplir con el registro horario, bloquear juega en tu contra cada vez que el GPS se equivoca, y en obra se equivoca.

Lo probamos al revés y lo quitamos. Llegamos a tener en Tajo un modo de geocerca que rechazaba la entrada fuera del radio o sin GPS. Duró horas: con la especificación del cliente delante, lo retiramos y la regla quedó en registrar, marcar y avisar, nunca impedir el fichaje.

Cómo lo hacemos en Tajo

Tajo es nuestra app de control horario y partes de obra; la usa a diario la plantilla de Grupo Edma. Así resolvimos lo de arriba:

• Un punto, solo al fichar. Se guardan latitud, longitud y precisión del GPS en ese instante. La app no pide el permiso de ubicación en segundo plano.
• La geocerca nunca bloquea. Si fichas fuera de la obra o sin GPS, el fichaje entra igual y queda marcado para que RRHH lo revise contigo.
• Se puede decir que no. Si el trabajador deniega el permiso de ubicación, sigue fichando; el fichaje queda sin coordenadas.
• La geolocalización es opcional para la empresa, que puede dejarla apagada. Y la geocerca de cada obra solo se cambia desde el panel, quedando registrado quién la cambió y desde cuándo vale.
• Los desplazamientos van aparte. La única ruta que se graba es la de un desplazamiento que el propio trabajador inicia y termina, con una notificación visible mientras dura. Cómo contar ese tiempo está en horas de desplazamiento entre obras.

Consejo:. aunque la app lo haga bien, la información previa al trabajador la tiene que dar la empresa. Tajo trae una plantilla de política de privacidad con la sección de ubicación, pero hay que adaptarla y entregarla.

Lista rápida antes de encender la ubicación

• Tienes claro para qué la quieres: inicio y fin de la jornada en la obra, nada más.
• Solo se recoge la posición al fichar; nada en segundo plano ni fuera de jornada.
• Has informado por escrito, antes de empezar, a la plantilla y a sus representantes.
• Has revisado el convenio y, si el sistema es nuevo para ti, valorado una evaluación de impacto.
• Fichar no depende de dar la ubicación ni de que el GPS acierte.
• Las excepciones se revisan con el trabajador, no se sancionan en automático.

Preguntas frecuentes sobre fichar con geolocalización

¿Es legal pedir la ubicación a los trabajadores al fichar?

Sí. El artículo 90 de la LOPDGDD permite al empleador tratar datos de geolocalización para ejercer el control laboral del artículo 20.3 del Estatuto, dentro de su marco legal y sus límites. Debe ser proporcionado: lo defendible es guardar la posición en el instante de fichar, no el recorrido de la jornada.

¿Necesito el consentimiento del trabajador para geolocalizarle?

No, y no te sirve como base jurídica. Según la guía de la AEPD sobre relaciones laborales, la base es el contrato de trabajo y las facultades de control del empleador; para el registro de jornada, la obligación legal del artículo 34.9. Lo que sí es obligatorio es informar antes, de forma expresa, clara e inequívoca.

¿Puedo obligar al trabajador a usar su móvil personal?

La guía de la AEPD dice que no es lícito imponerle medios personales para facilitar la geolocalización, y cita la sentencia de la Audiencia Nacional 136/2019 sobre repartidores. La AEPD multó con 200.000 euros a una empresa que obligaba a sus conductores a instalar en su móvil apps con geolocalización. Lo limpio es que el dispositivo lo ponga la empresa.

¿Puede la empresa seguir al trabajador fuera de la jornada?

No. El artículo 88 de la LOPDGDD reconoce el derecho a la desconexión digital, y la guía de la AEPD recoge una sentencia del TSJ de Asturias que obligó a garantizar que el GPS de los vehículos no estuviera operativo al terminar la jornada. En una app de fichaje, nada de pedir ubicación en segundo plano.

¿La geocerca debe bloquear el fichaje si el trabajador está fuera de la obra?

La ley no lo exige, y bloquear juega en contra de cumplir el registro horario, porque el GPS falla en sótanos y bajo forjados. En Tajo la geocerca nunca bloquea: si se ficha fuera o sin GPS, el fichaje entra igual y queda marcado para que RRHH lo revise con el trabajador.

Fuentes

1. LOPDGDD (Ley Orgánica 3/2018), arts. 87, 88, 90 y 91 — BOE
2. Estatuto de los Trabajadores, arts. 20.3, 20 bis y 34.9 — BOE
3. Reglamento (UE) 2016/679 (RGPD), arts. 5.1.c, 6, 13 y 35 — DOUE
4. La protección de datos en las relaciones laborales (guía actualizada en diciembre de 2025) — AEPD
5. Resolución sancionadora PS/00454/2024 (multa de 200.000 €) — AEPD

Para la app de una pyme que necesita Android e iPhone, Flutter suele compensar: una sola base de código y de tests para las reglas del negocio. Nativo (Kotlin y Swift) compensa si la app vive pegada al hardware o al sistema, o si solo usas una plataforma. Flutter no te quita las reglas de Android ni la burocracia de las tiendas.

Primero, los términos. Nativo es escribir la app de Android en Kotlin y la de iPhone en Swift: dos proyectos, dos equipos o un equipo que sabe de ambos. Flutter es el framework de Google para escribir una sola app en Dart que se compila para Android, iOS, web, Windows, macOS y Linux. La pregunta real no es cuál es mejor, sino cuál te sale más barato de mantener durante años sin que el usuario note la diferencia.

¿Flutter o nativo? La respuesta corta (sí, empieza por «depende»)

• Flutter si necesitas Android y iPhone (o móvil más un panel web), el presupuesto es de pyme y la app es sobre todo formularios, listas, fotos, mapas y sincronización. Que es lo que son casi todas las apps de empresa.
• Nativo si la app vive pegada al hardware o al sistema: audio en tiempo real, Bluetooth con aparatos propios, widgets y extensiones del sistema por todas partes, o funciones que Apple y Google estrenan este año y quieres el primer día.
• Nativo en una sola plataforma si todos tus usuarios usan Android (pasa en muchas plantillas con móvil de empresa). Una base de código nativa también es una sola base.

Dos bases de código son dos de todo

El coste de lo nativo no está en escribir la app, está en mantenerla. Cada cambio se hace dos veces, se prueba dos veces y se puede romper de dos maneras distintas. Cada fallo hay que reproducirlo en dos proyectos. Y las dos apps tienden a separarse: un botón que en Android hace una cosa y en iPhone otra, porque se arregló un lado y el otro se quedó para la semana que viene.

En Flutter la lógica de negocio se escribe una vez y los tests también. En Tajo, el cálculo de jornadas, la cola de fichajes sin cobertura y las reglas de quién ve qué viven en un solo sitio, con sus tests, y los usa tanto la app de los operarios como el panel de escritorio de RRHH. Si esa lógica estuviera duplicada en Kotlin, Swift y JavaScript, cada regla de control horario habría que demostrarla tres veces.

Lo que no te ahorra Flutter:. las tiendas. Siguen siendo dos fichas, dos procesos de revisión, dos juegos de permisos y dos formas de firmar la app (lo contamos en publicar una app en Google Play). Flutter unifica el código, no la burocracia de Google y Apple.

¿Es más lenta Flutter? El cuello de botella casi nunca es el framework

Flutter no usa los botones y listas del sistema: dibuja cada píxel con su propio motor, Impeller, que según la documentación oficial es el único en iOS y el de serie en Android 10 y posteriores. Por eso una app Flutter se ve igual en todos los móviles, para bien y para mal: si quieres que en iPhone parezca exactamente una app de Apple, te toca trabajarlo.

¿Va más lenta? No vamos a darte una cifra, porque las comparativas que circulan miden casos de laboratorio. Lo que sí podemos decir es dónde se nos ha ido el tiempo en apps de empresa: consultas a la base de datos mal planteadas, imágenes sin comprimir, llamadas de red en el arranque. Nada de eso lo arregla cambiar de lenguaje. Por eso, en Tajo, las fotos y vídeos de los partes se comprimen en el móvil antes de subir (partes de trabajo digitales): en obra la red es lo que manda.

¿Qué pasa con GPS, cámara, NFC y segundo plano? Las reglas son de Android

Flutter accede al hardware mediante plugins: paquetes que por dentro llevan su código Kotlin y Swift y lo exponen en Dart. Para GPS, cámara, micrófono, notificaciones o biometría hay plugins muy usados y mantenidos. Para NFC existe, por ejemplo, nfc_manager, de un editor independiente y no del equipo de Flutter: antes de depender de un plugin así, mira quién lo mantiene y cuándo se actualizó por última vez.

Lo que mucha gente no espera: las restricciones del sistema operativo te alcanzan igual. En Tajo, la ruta de un desplazamiento entre obras (cómo se cuenta ese tiempo) se graba mientras dura, también con la pantalla bloqueada. Desde Android 14, eso exige un servicio en primer plano de tipo ubicación, con su permiso FOREGROUND_SERVICE_LOCATION declarado y una notificación visible. Lo resolvimos sin escribir Kotlin, con la configuración de primer plano del plugin geolocator, pero tuvimos que conocer la regla de Android al detalle. El framework no te la quita.

El recordatorio que nunca sonaba. Probando Pax en un Pixel vimos en el registro del sistema exact_alarms_not_permitted en cada arranque. El aviso diario se programaba como alarma exacta, que desde Android 12 necesita un permiso especial que la app nunca pedía, así que el recordatorio de la pantalla de perfil no tenía ningún efecto. Lo pasamos a alarma inexacta, que para un recordatorio diario sobra. El fallo era de Android; el plugin solo lo transmitía.

Cuándo hay que bajar a Kotlin (y cuánto)

Cuando no hay plugin, Flutter permite hablar con el código nativo por un canal de plataforma (MethodChannel): Dart pide, Kotlin o Swift contesta. Nuestro recuento real, para que veas la escala:

• Tajo: cero líneas de Kotlin propias. La actividad principal de Android está vacía; GPS, cámara, dictado por voz (con el reconocimiento del propio Android, sin mandar el audio fuera) y notificación de desplazamiento salen de plugins.
• Pax: unas 120 líneas de Kotlin. El widget del proverbio en la pantalla de inicio, porque los widgets de inicio se construyen con las herramientas de cada plataforma, no con Flutter. Y, mientras existió la llamada de voz con el mentor, un canal para pasar el audio al altavoz, porque el modo de grabación para conversación lo mandaba por defecto al auricular.

Esa llamada de voz con el mentor, conectada a Gemini Live, fue lo más duro que hemos hecho con Flutter. La sesión se cortaba al segundo: la conexión en tiempo real no enviaba la identidad de la app Android y Google la rechazaba por la restricción de la clave. Después el micrófono grababa sin cancelación de eco y el modelo se oía a sí mismo por el altavoz. Ninguno de los dos problemas se habría evitado escribiendo la app en Kotlin: eran de la plataforma y de la configuración.

Web y escritorio con el mismo código: sí, con letra pequeña

El panel de escritorio de RRHH de Tajo es la misma app Flutter compilada para web, con pantallas pensadas para ventana ancha. Para un cliente así es una ventaja enorme: la exportación del registro horario, los modelos de datos y las reglas de permisos son el mismo código que en el móvil.

La letra pequeña: hay código que compila sin avisar para web y falla al ejecutarse, como el acceso a ficheros del móvil o los plugins de cámara. En Tajo lo resolvimos con implementaciones separadas para web y para móvil detrás de la misma función. Y algunos errores de maquetación solo aparecían en el navegador, como una pantalla en blanco que el análisis estático no veía y solo se descubrió con la consola abierta.

Flutter Web no es para tu web pública:. la propia documentación de Flutter dice que no es adecuado para webs estáticas con mucho texto y que su salida no encaja con lo que necesitan los buscadores. Para un panel interno tras un login, perfecto. Para la web que tiene que posicionar en Google, usa otra cosa (este blog, por ejemplo, no está hecho en Flutter).

React Native, Kotlin Multiplatform y PWA

• React Native: de Meta, se escribe en JavaScript o TypeScript con React y pinta con los componentes nativos de cada sistema. Tiene sentido si tu equipo ya vive en React. El razonamiento sobre plugins y reglas del sistema es el mismo que con Flutter.
• Kotlin Multiplatform: comparte la lógica en Kotlin y, con Compose Multiplatform, también la interfaz; según JetBrains, ambos son estables en Android e iOS. Buena opción si ya tienes una app Android en Kotlin y quieres llevarla a iPhone sin reescribirla.
• PWA (web instalable): sin tiendas y con una sola base. Pero el acceso a hardware y a segundo plano es más limitado, y en iPhone las notificaciones push solo llegaron con iOS 16.4 y únicamente si el usuario añade la web a la pantalla de inicio. Para una herramienta interna sencilla puede bastar; para fichar con GPS en obra, no la elegiríamos.

Nuestra regla para decidir

Antes de elegir tecnología, haz la lista de lo que la app tiene que hacer con el móvil, no con la pantalla:

• ¿Necesita trabajar con la pantalla bloqueada o en segundo plano? Revisa las reglas de Android e iOS antes que el framework.
• ¿Hay plugin mantenido para cada pieza de hardware? Si falta uno, cuenta con escribir ese trozo en Kotlin y Swift.
• ¿Necesitas panel web o de escritorio? Ahí Flutter suma mucho.
• ¿Quién la va a mantener dentro de tres años? Una base de código se hereda mejor que dos.

Elegimos Flutter para no escribir dos veces las reglas del negocio. El hardware sigue siendo de Android y de Apple, y eso no lo cambia ningún framework.

Preguntas frecuentes sobre Flutter y nativo

¿Flutter o nativo para la app de una pyme?

Flutter suele compensar si necesitas Android e iPhone (o móvil más panel web), el presupuesto es de pyme y la app es sobre todo formularios, listas, fotos, mapas y sincronización. La lógica de negocio y sus tests se escriben una vez. Nativo compensa si la app depende del hardware o del sistema, o si solo usas Android.

¿Qué no te ahorra Flutter?

Las tiendas y las reglas del sistema. Siguen siendo dos fichas, dos procesos de revisión, dos juegos de permisos y dos formas de firmar la app. Y las restricciones de Android, como el servicio en primer plano de tipo ubicación desde Android 14, te alcanzan igual: Flutter unifica el código, no la burocracia de Google y Apple.

¿Cuánto Kotlin hace falta en una app Flutter?

Depende de la app. Nuestra app de control horario, Tajo, tiene cero líneas de Kotlin propias: GPS, cámara y dictado salen de plugins. Pax, la app de estoicismo, tiene unas 120, para el widget de la pantalla de inicio y un canal de audio. Los widgets de inicio se construyen con las herramientas de cada plataforma.

¿Sirve Flutter Web para la web pública de mi empresa?

No es lo recomendable. La documentación de Flutter dice que no es adecuado para webs estáticas con mucho texto y que su salida no encaja con lo que necesitan los buscadores. Para un panel interno tras un login funciona muy bien; para una web que tiene que posicionar en Google, usa otra tecnología.

¿React Native, Kotlin Multiplatform o una PWA son alternativas válidas?

Sí, según tu caso. React Native tiene sentido si tu equipo ya vive en React. Kotlin Multiplatform, si ya tienes una app Android en Kotlin y quieres llevarla a iPhone. Una PWA evita las tiendas, pero tiene más límites con hardware y segundo plano: para fichar con GPS en obra no la elegiríamos.

Fuentes

1. Supported deployment platforms — Flutter
2. Writing custom platform-specific code (platform channels) — Flutter
3. Web support for Flutter (FAQ) — Flutter
4. Impeller rendering engine — Flutter
5. Adding a home screen widget to your Flutter app — Google Codelabs
6. Foreground service types — Android Developers
7. Changes to schedule exact alarms (Android 14) — Android Developers
8. nfc_manager — pub.dev
9. React Native — documentación oficial
10. Kotlin Multiplatform: supported platforms — JetBrains
11. Web Push for Web Apps on iOS and iPadOS — WebKit (16 feb. 2023)

Lovable, Bolt, v0 y Replit son constructores que llegan a una demo funcional y publicable; Cursor es un editor con agente que llega hasta donde llegue quien lo maneja. Ninguna te da sola los permisos probados, los tests, la firma de la app ni las tiendas: ese último tramo es casi igual con todas y te toca a ti.

Esto no es una comparativa de precios: los planes cambian cada pocos meses. Es un mapa de qué tipo de proyecto sale bien con cada una y qué falta cuando quieres usuarios de verdad, datos de verdad y, a veces, una app en Google Play o en el App Store. Todo lo que afirmamos de cada herramienta está sacado de su documentación oficial a 3 de octubre de 2026 (la lista, al final). Si lees esto más tarde, comprueba: se mueven rápido.

Una distinción antes de empezar. Lovable, Bolt, v0 y Replit son constructores: describes, generan, publican. Cursor es un editor con agente: trabaja sobre tu código, en tu máquina, y no te da ni servidor ni base de datos. Juegan en ligas distintas y por eso se combinan tanto.

Lovable: la web completa más rápida, con el stack que ellos eligen

Lovable saca muy bien la app web clásica de producto: registro, panel, formularios, tablas, pagos. Su FAQ es clara con el stack: los proyectos creados desde el 13 de mayo de 2026 usan TanStack Start con renderizado en servidor (los anteriores, React + Vite) y una base de datos PostgreSQL, sea su backend integrado (Lovable Cloud) o Supabase. No hay elección de framework ni de base de datos.

Han trabajado la seguridad: al abrir el diálogo de publicar lanzan un escaneo rápido que revisa las políticas de seguridad a nivel de fila (RLS) y las dependencias, y hay un escaneo profundo opcional. Es un buen paso. Pero un escáner detecta políticas que faltan; no sabe si «el jefe de obra solo ve su obra» es la regla correcta de tu negocio. Eso lo tienes que escribir y probar tú.

• Dónde se queda corta: móvil nativo. Lo dice su propia FAQ: Lovable genera aplicaciones web y no proyectos React Native. Para las tiendas propone una PWA o envolver la web con Capacitor, fuera de Lovable.
• Qué añadir a mano: tests de los permisos y de los flujos críticos que vivan en el repositorio, y el empaquetado móvil si lo necesitas. La sincronización con GitHub (y Bitbucket) te deja sacar el código cuando toque; si ya lo tienes fuera y dudas entre arreglar o empezar de cero, lo comparamos en rescatar o rehacer una app hecha con IA.

No confundas las apps:. Lovable tiene app para iOS y Android, pero es para editar tus proyectos desde el móvil. No convierte lo que construyes en una app nativa.

Bolt: flexible en el front, todo JavaScript detrás

Bolt corre en el navegador y admite cualquier framework de JavaScript en el frontend, con Node.js en el backend. Su documentación avisa de que PHP o Python no son compatibles. Con Bolt Cloud tienes base de datos, autenticación (correo y Google), hosting y dominios sin salir de la herramienta.

Es de las pocas que hace móvil de verdad desde el principio: se integra con Expo y genera apps React Native. Con dos condiciones que conviene leer antes de empezar. La primera: tienes que decir «mobile app» en el primer prompt, porque un proyecto web no se pasa fácilmente a móvil. La segunda: Bolt no compila ni firma la app. Para publicar, su guía te pide descargar el código, instalar la CLI de Expo (EAS) en tu ordenador y tener tus cuentas de desarrollador de Apple y de Google.

• Saca bien: prototipos web en el framework que prefieras y apps móviles sencillas en Expo.
• Qué añadir a mano: el proceso de build y firma, la configuración de las tiendas y un backend aparte si tu lógica pide Python u otro lenguaje.

v0: la mejor interfaz, si vives en el mundo Vercel

v0 nació generando interfaces y se nota: es donde mejor salen pantallas cuidadas en React. Hoy hace también aplicaciones completas: usa Next.js por defecto, con server actions y rutas de API para el backend, e integraciones de un clic con Supabase, Neon, Upstash y Vercel Blob. Importa repositorios de GitHub, trabaja con pull requests y publica en Vercel.

Su propia guía de apps completas recomienda ir por capas: primero la interfaz, luego los datos, luego la autenticación «para que cada usuario solo vea lo suyo». Es buen consejo, y deja claro dónde está el trabajo: la capa de permisos la pides tú y la compruebas tú. Una variable con el prefijo NEXT_PUBLIC_ acaba en el navegador; si ahí metes una clave secreta, la publicas.

• Saca bien: webs y paneles con mucha interfaz, sobre Next.js y Vercel.
• Dónde se queda corta: no es una herramienta de móvil nativo ni de tiendas.

Replit: el entorno entero, con el App Store a un botón

Replit es lo más parecido a un ordenador en la nube con un agente dentro. Trae PostgreSQL gestionado y su propio sistema de login, Replit Auth, que el agente configura con un prompt. Desde enero de 2026 el agente hace apps móviles con React Native y Expo, con vista previa en simulador o en tu móvil.

Es la que más lejos llega hacia las tiendas: construye y envía a TestFlight y de ahí al App Store, sin Xcode, con tu cuenta de Apple Developer. Pero ojo al detalle: a fecha de octubre de 2026 su documentación dice literalmente que publicar en Google Play todavía no está soportado. Si tu público usa Android, ese tramo te toca a ti.

• Saca bien: prototipos completos con backend propio y apps de iPhone que quieres en TestFlight cuanto antes.
• Qué añadir a mano: Google Play, y cualquier módulo nativo que no esté en el SDK de Expo (la propia documentación avisa de que Expo Go no los admite todos).

Cursor: llega donde llegues tú

Cursor no tiene techo de stack: Flutter, Kotlin, Swift, Python, lo que sea. Su agente edita varios ficheros y ejecuta comandos, y tiene un revisor automático (Bugbot) que comenta las pull requests en GitHub señalando fallos y problemas de seguridad. Es la herramienta con la que se puede llegar más lejos, incluida una app nativa publicada.

El precio es otro: no te da servidor, base de datos, hosting ni tiendas. Y hace lo que le pides. Si no le pides tests de permisos, no los hay. Si no sabes que Google Play vuelve a firmar tu app y que el login con Google necesita esa huella, Cursor tampoco te lo va a recordar (es una de las 9 causas por las que una app hecha con IA falla en producción). Multiplica a quien ya sabe; a quien no sabe, le deja avanzar más rápido hacia el mismo muro.

¿Qué no te pone ninguna herramienta sola?

Cambia la herramienta, no cambia la lista. Esto es lo que revisamos en cualquier proyecto antes de dejarlo entrar a producción:

• Permisos escritos y probados: con la clave pública y sin sesión, una consulta a datos ajenos vuelve vacía. Con sesión de otro usuario, también.
• Secretos solo en el servidor, y rotados si alguna vez estuvieron en el navegador.
• Tests de lo que te cuesta clientes: registro, login, pago, permisos. En el repositorio y ejecutándose en cada cambio.
• Informe de errores (Crashlytics, Sentry o similar) para enterarte antes que tu usuario.
• Móvil: build de release probada en un teléfono real, firma y huellas registradas, y en Google Play con cuenta personal, la prueba cerrada de 12 testers durante 14 días.

Lo que añadimos siempre, venga de donde venga el código:. tests de los permisos (que un usuario no vea lo de otro), ejecutados en cada cambio y no solo en local. Un test que no se ejecuta solo no protege nada; lo explicamos con un caso real en la lista de seguridad antes de lanzar.

¿Cuál elijo para mi proyecto?

• Lovable si es una web de producto con usuarios y datos, y te vale su stack.
• v0 si la interfaz es lo que vende y vas a vivir en Next.js y Vercel.
• Bolt si quieres libertad de framework en JavaScript o una app Expo sencilla, y no te asusta compilarla tú.
• Replit si quieres backend propio sin montar nada y tu objetivo inmediato es el App Store.
• Cursor si hay alguien en el equipo que sabe programar, o cuando el proyecto ya ha superado al constructor.

Un patrón razonable: validar con un constructor, sacar el código a GitHub y terminar con un editor y alguien que sepa qué falta. La herramienta te lleva hasta la demo. El último tramo — permisos, tests, firma, tiendas — no depende de cuál elijas.

Elegir herramienta decide dónde te paras. Lo que falta hasta producción es casi siempre la misma lista.

Preguntas frecuentes sobre Lovable, Bolt, v0, Replit y Cursor

¿Qué diferencia hay entre Lovable, Bolt, v0 y Cursor?

Lovable, Bolt, v0 y Replit son constructores: describes la app y la generan y publican ellos. Cursor es un editor con agente que trabaja sobre tu código, en tu máquina, sin servidor ni base de datos propios. Por eso se combinan: validas con un constructor, sacas el código a GitHub y terminas en un editor.

¿Puedo publicar en Google Play una app hecha con Lovable?

Lovable genera aplicaciones web y no proyectos React Native, según su propia FAQ. Para tener una app instalable propone una PWA o envolver la web publicada con una herramienta como Capacitor, fuera de Lovable, y subir ese paquete a la tienda. En Google Play siguen aplicando las pruebas y la firma de cualquier app.

¿Replit publica apps en Google Play?

A fecha de octubre de 2026, su documentación dice que publicar en Google Play todavía no está soportado. Sí permite construir y previsualizar apps para iOS y Android con React Native y Expo, y preparar el envío a TestFlight y al App Store con una cuenta de Apple Developer. El tramo de Android lo haces tú.

¿Una app hecha con Lovable o Bolt es segura para producción?

No lo da por hecho ninguna: Lovable lanza un escaneo de RLS y dependencias al publicar, pero esos escáneres detectan políticas que faltan, no si la regla es la de tu negocio. Hacen falta tests de permisos en el repositorio, ejecutados en cada cambio, y secretos solo en el servidor antes de abrir la app a usuarios.

¿Cuál elijo si no sé programar?

Un constructor: Lovable para una web de producto con usuarios y datos, v0 si la interfaz es lo que vende, Bolt o Replit si quieres un prototipo móvil. Cursor rinde mucho más cuando alguien sabe programar. Sea cual sea, reserva a alguien con criterio técnico para revisar permisos, tests y firma antes de lanzar.

Fuentes

1. Lovable FAQ — Lovable Docs
2. Security overview — Lovable Docs
3. Git sync con GitHub — Lovable Docs
4. Supported technologies — Bolt Support
5. Expo for mobile apps — Bolt Support
6. Full-stack apps — v0 Docs
7. Native Mobile Apps — Replit Docs
8. Bugbot — Cursor Docs

Un parte de trabajo diario de obra debe recoger fecha, obra y tajo, cuadrilla con horas por persona, actividades hechas y su estado, maquinaria, materiales, incidencias, fotos y la validación del encargado. Pasarlo al móvil funciona si se rellena el mismo día con listas y dictado, y si nunca bloquea el fichaje. No es lo mismo que el registro de jornada.

Un parte de trabajo responde a una pregunta sencilla: qué se hizo hoy, en qué obra, quién lo hizo y con qué. De esa respuesta salen el coste real de cada obra, la certificación del mes y la discusión con el cliente cuando algo no cuadra. Si el parte falla, todo lo que va detrás se calcula a ojo.

¿Qué debe llevar un buen parte de trabajo?

No hay un modelo único: cada constructora lo adapta a su forma de trabajar. Pero los partes que sirven para algo comparten un esqueleto. Lo importante no es que tenga muchos campos, sino que cada campo se pueda sumar o comparar después.

• Cabecera Fecha, obra y tajo (la zona o tarea concreta dentro de la obra). Sin obra no hay coste por obra.
• Cuadrilla y horas Quién estuvo y cuántas horas cada uno, no «4 personas, 8 horas». Las horas por persona son las que se multiplican por su coste.
• Trabajo hecho Las actividades, mejor elegidas de una lista que escritas a mano, y cómo quedó cada una: terminada, a medias, parada.
• Maquinaria Qué máquina, cuántas horas y si es propia o alquilada.
• Materiales Lo que llegó y lo que se gastó, con el albarán si lo hay.
• Incidencias Lo que paró o retrasó el trabajo: falta de material, otro gremio en medio, lluvia, una orden que cambió.
• Fotos Del trabajo terminado y de cualquier problema. Una foto con fecha vale más que tres líneas de explicación.
• Validación Quién lo da por bueno, normalmente el encargado o el jefe de obra.

Un detalle que parece menor y no lo es: las actividades de una lista, no en texto libre. Fue una petición expresa de nuestro cliente en Tajo, y el motivo no es la comodidad. Si cada uno escribe a su manera, «alicatado», «Alicatado» y «alicatar baño» son tres cosas distintas para siempre, y nadie puede sacar cuántas horas se fueron en alicatar.

La plantilla: copia y adapta

Esta es la lista de campos que recomendamos como punto de partida. Sirve igual para un parte en papel, una hoja de cálculo o una app. Quita lo que no uses: un campo que nadie rellena solo enseña a la cuadrilla que el parte se puede dejar a medias.

¿Por qué el parte en papel llega tarde o no llega?

El problema del papel no es el papel. Es todo lo que tiene que pasar para que ese papel acabe convertido en un número en la oficina.

• Se rellena tarde. Al final de la semana, de memoria. Las horas de un martes se reconstruyen el viernes, y se redondean.
• Viaja mal. Va en la guantera, en el bolsillo del pantalón, en una foto de WhatsApp con la mitad cortada.
• Alguien lo tiene que teclear. En la oficina, otra vez, con letra que no siempre se entiende. Cada transcripción es una oportunidad de error.
• Nadie avisa de lo que falta. Si un día no hay parte, se descubre cuando ya no se puede reconstruir.
• Las fotos van por otro lado. En el móvil de quien las hizo, sin saber a qué obra ni a qué día pertenecen.

Y un matiz importante: el parte no es el registro de jornada. Registrar a diario la hora de entrada y salida de cada trabajador es obligatorio por el artículo 34.9 del Estatuto de los Trabajadores, y esos registros se guardan cuatro años (qué cambiará: registro horario digital obligatorio). El parte es control interno de la empresa. Pueden compartir datos, pero no son lo mismo, y no deberían depender uno del otro.

¿Cómo pasar el parte al móvil sin que la cuadrilla lo odie?

Pasar un parte a una app es fácil. Conseguir que lo rellene alguien con guantes, a las seis de la tarde y con ganas de irse a casa, no tanto. Esto es lo que aplicamos en Tajo:

1. Lo mínimo por escrito. Botones grandes, listas para elegir, estados en un toque. Lo ideal: que el responsable deje asignado el tajo antes, que el trabajador lo acepte al fichar y que al salir solo confirme cómo quedó (terminado, pendiente, bloqueado o sin empezar).
2. Dictar en vez de escribir. El trabajo que no estaba previsto se puede contar hablando. Tajo usa el reconocimiento de voz del propio Android: el audio no sale del teléfono ni se guarda, y funciona sin cobertura en los móviles que tienen el modelo de idioma descargado. Lo dictado lo interpreta código propio con un vocabulario de obra, no un modelo de IA, así que no se inventa actividades.
3. Las horas se reparten solas. Nadie teclea minutos por tarea: las horas fichadas en la obra se reparten entre las actividades del día. Así el parte no se pelea con el fichaje, y los trayectos entre obras (cómo contarlos) no se imputan dos veces.
4. Sin cobertura, igual. El parte se guarda en el móvil y sube cuando hay red (la misma cola que usamos para fichar en obra sin cobertura). Las fotos van primero al disco del teléfono, comprimidas, y luego a la nube.
5. El fichaje nunca se bloquea por el parte. Si falta el parte, la salida se registra igual y queda marcado para que alguien lo reclame. Al revés sería absurdo: un fallo de un control interno te impediría cumplir una obligación legal.
6. En su idioma. Las pantallas del parte, el dictado y las fotos están traducidas al español, inglés, francés y rumano. Quien no lee bien español no debería necesitar ayuda para hacer su parte.

El dictado que se perdía en silencio. Probando el dictado con micrófono real en un móvil de verdad, no en simulación, vimos que si el reconocedor se paraba solo tras unos segundos de silencio, lo dicho se perdía sin ningún aviso. La pantalla volvía al principio y quien había hablado creía que estaba guardado. Lo arreglamos para que dé igual cómo termine la escucha. En la obra, un parte que parece guardado y no lo está es peor que no tener app.

Empieza por lo que ya rellenan:. copia los campos de vuestro parte en papel actual, quita los que nadie usa y no añadas ninguno nuevo el primer mes. Cambiar de formato y de soporte a la vez es la forma más rápida de que la cuadrilla vuelva al papel.

Qué se gana: costes por obra y certificaciones con base

El parte digital no se justifica por ahorrar papel. Se justifica porque los datos llegan el mismo día, ya ordenados por obra, y se pueden sumar sin teclear nada.

• Coste real por obra. Horas por persona multiplicadas por su coste hora, más material, vehículos y otros gastos. En Tajo, si una ficha no tiene coste hora, el coste sale vacío y rotulado, nunca como 0 €: un cero en una suma es un dato falso que nadie distingue de «no costó nada».
• Desviaciones a tiempo. Comparar lo previsto con lo real cuando todavía se puede corregir, no al cerrar la obra.
• Certificaciones con respaldo. En obra pública, la Ley de Contratos del Sector Público (artículo 240) prevé certificaciones mensuales de la obra ejecutada. Llegar a esa medición con partes diarios y fotos fechadas da base para defender lo que se certifica.
• Menos llamadas. El panel de oficina enseña solo lo que falla: el parte que no llegó, las horas que no cuadran, el tajo bloqueado. No hace falta revisar trabajador por trabajador.

Sobre la firma (texto a 2 de octubre de 2026). Un garabato en la pantalla o un botón de «validar» deja rastro de quién y cuándo, y eso sirve como prueba interna. Pero no es una firma electrónica avanzada en el sentido del Reglamento eIDAS (artículo 26), que exige requisitos concretos. Si necesitas que el parte tenga ese valor ante terceros, consúltalo con tu asesoría. Esto no es asesoramiento jurídico.

Por dónde empezar mañana

No hace falta una app para mejorar el parte. Hace falta decidir qué campos se van a sumar después y quitar el resto. Si cuando lo tengas claro el cuello de botella es la transcripción, el retraso o las fotos perdidas, entonces sí: pásalo al móvil, con el menor texto posible y sin bloquear nunca el fichaje.

El mejor parte no es el más completo. Es el que se rellena el mismo día.

Preguntas frecuentes sobre el parte de trabajo

¿Qué debe llevar un parte diario de obra?

Fecha, obra y tajo, la cuadrilla con las horas de cada persona, las actividades hechas y su estado, la maquinaria con sus horas, los materiales recibidos y gastados, las incidencias, fotos y la validación del encargado o jefe de obra. Lo importante es que cada campo se pueda sumar o comparar después, no que haya muchos.

¿Es lo mismo el parte de trabajo que el registro de jornada?

No. El registro de jornada, obligatorio por el artículo 34.9 del Estatuto de los Trabajadores, anota la hora de inicio y de fin de cada trabajador y se conserva cuatro años. El parte es control interno de la empresa sobre qué se hizo y dónde. Pueden compartir datos, pero no deberían depender uno del otro.

¿Por qué el parte en papel llega tarde o no llega?

Porque se rellena de memoria al final de la semana, viaja mal (guantera, foto de WhatsApp cortada), alguien tiene que teclearlo después, nadie avisa cuando falta y las fotos quedan en otro móvil. El problema no es el papel, sino todo lo que tiene que pasar hasta que se convierte en un número en la oficina.

¿Un parte digital con validación vale como firma electrónica avanzada?

No necesariamente. Un botón de validar o un garabato en pantalla deja rastro interno de quién y cuándo, pero la firma electrónica avanzada del Reglamento eIDAS (artículo 26) exige requisitos concretos. Si el parte debe tener ese valor ante terceros, conviene consultarlo con la asesoría.

¿Cómo se pasa el parte al móvil sin que la cuadrilla lo rechace?

Con lo mínimo por escrito: botones grandes, listas para elegir y estados en un toque; dictado por voz para lo imprevisto; horas repartidas solas desde el fichaje; funcionamiento sin cobertura; y sin bloquear nunca el fichaje por falta de parte. Además, empezar copiando los campos del parte en papel actual, sin añadir ninguno nuevo el primer mes.

Fuentes

1. Estatuto de los Trabajadores, art. 34.9 — BOE
2. Ley 9/2017 de Contratos del Sector Público, art. 240 — BOE
3. Reglamento (UE) 910/2014 (eIDAS), art. 26 — DOUE
4. ¿Cómo hacer un informe diario de obra? — ProjectManager

Depende del trayecto. Ir de casa a la primera obra y volver no es tiempo de trabajo como regla general (artículo 34.5 del Estatuto), salvo circunstancias como las de la sentencia Tyco. Moverse entre obras con la jornada ya empezada sí lo es: se hace por orden de la empresa y a su disposición. El convenio de la construcción lo confirma para las obras de larga extensión.

Fecha de este texto: 2 de octubre de 2026. Resumimos normativa y sentencias públicas tal como están a esta fecha. Cada caso depende de los hechos y de tu convenio provincial. Esto no es asesoramiento jurídico: antes de decidir, habla con tu asesoría laboral.

Hay dos desplazamientos que en obra se mezclan y no deberían: el de casa a la obra (y vuelta) y el que se hace entre obras con la jornada ya empezada. La ley, los tribunales y el convenio los tratan distinto. Vamos por partes.

¿Cuándo empieza la jornada? En el puesto de trabajo

El artículo 34.5 del Estatuto de los Trabajadores dice que el tiempo de trabajo se computa de modo que, al comienzo y al final de la jornada, el trabajador se encuentre en su puesto de trabajo. Traducido: ir al trabajo y volver a casa no es jornada. Es la regla general y el Supremo la sigue aplicando.

El convenio general de la construcción va en la misma línea. Su artículo 71.9 define el tiempo de trabajo efectivo, citando la Directiva 2003/88/CE y el artículo 34 del Estatuto, como aquel en que la persona trabajadora está a disposición de la empresa y en el ejercicio efectivo de su actividad. No dedica ninguna regla general al trayecto de casa a la obra.

¿Qué dijo la sentencia Tyco? Sin centro fijo, la casa es la salida

El 10 de septiembre de 2015 el Tribunal de Justicia de la UE resolvió el asunto C-266/14, una cuestión que le planteó la Audiencia Nacional en un conflicto entre CC.OO. y Tyco Integrated Security. Los hechos importan, porque la sentencia se ciñe a ellos:

• Tyco cerró en 2011 sus oficinas provinciales y adscribió a los técnicos a la central de Madrid.
• Los técnicos salían cada día de casa con un vehículo de la empresa hacia clientes distintos, con una hoja de ruta y unos horarios que les enviaba la empresa la víspera.
• Antes del cierre, la empresa contaba como jornada el viaje desde la oficina hasta el primer cliente. Después, empezó a contar solo desde que llegaban al primer cliente.

El TJUE concluyó que, en esas circunstancias, para trabajadores sin centro de trabajo fijo o habitual, el trayecto entre su domicilio y el primer y último cliente es tiempo de trabajo según la Directiva. Su razonamiento: desplazarse es la herramienta necesaria para hacer el trabajo, la empresa podía cambiar el orden de las citas por el camino y el trabajador no podía disponer libremente de ese tiempo.

La Directiva decide qué es tiempo de trabajo. Cuánto se paga ese tiempo lo decide el derecho nacional.

Esa frase resume los apartados 47 a 49 de la sentencia: Tyco seguía siendo libre de fijar la retribución de esos trayectos. Una cosa es que computen para los límites de jornada y los descansos; otra, cómo se pagan.

¿Qué dice el Supremo? Tyco es la excepción, no la regla

En España, el Tribunal Supremo ha aplicado Tyco caso por caso. La sentencia más reciente que hemos localizado sobre el tema es la STS 1305/2024, de 27 de noviembre (Sala de lo Social, recurso 88/2023), sobre técnicos de mantenimiento de ascensores que iban de casa al primer cliente.

Su doctrina: el trayecto de casa al primer cliente y del último a casa, como regla general, no es tiempo de trabajo efectivo a efectos remuneratorios, salvo que concurran circunstancias específicas parecidas a las de Tyco. En ese caso no las vio y dio la razón a la empresa, anulando la sentencia de la Audiencia Nacional.

La misma sentencia repasa cuándo el Supremo sí lo ha considerado tiempo de trabajo. De ahí sale una lista de señales que conviene revisar en tu empresa:

• Antes se contaba como jornada el viaje desde la nave o la delegación, y la empresa cambió el sistema para empezar a contar en el primer destino.
• La empresa fija cada día el destino y el horario, y el trabajador va en vehículo de la empresa con el material y la herramienta.
• Los desplazamientos pueden ser largos (en Tyco se citaban más de 100 km) y cambian cada día.
• Hay trabajadores de la misma empresa a los que sí se les paga ese trayecto sin una razón objetiva para la diferencia.

Si en tu caso se dan varias, el «como regla general» puede dejar de aplicarse. Ahí es donde hace falta la asesoría, no un artículo de blog.

¿Cuenta el trayecto entre obras? Sí, con la jornada empezada

Aquí hay mucha menos discusión. Si el operario ya ha empezado su jornada en la obra A y el encargado lo manda a la obra B, ese trayecto lo hace por orden de la empresa, dentro de su jornada y a su disposición. Es exactamente la definición de tiempo de trabajo del convenio.

La propia sentencia Tyco lo da por hecho: la empresa ya contaba como jornada los desplazamientos intermedios entre un cliente y otro, y el TJUE incluye expresamente el desplazarse de un cliente a otro durante la jornada entre los momentos en que el trabajador está «en el trabajo».

El convenio de la construcción añade un caso concreto. En las obras de larga extensión (carreteras, canalizaciones, tajos repartidos por varios municipios que forman una misma obra), el artículo 90.2 dice que moverse entre tajos no es desplazamiento en sentido técnico, pero que el tiempo invertido en esa movilidad dentro de la obra se computará como trabajado. Y el artículo 87 pone a cargo de la empresa los gastos de locomoción de los desplazamientos a otro centro.

No confundas tiempo con dinero:. dietas, medias dietas y kilometraje son compensaciones de gastos que regulan el convenio general y el provincial. Que un trayecto sea jornada no dice nada de la dieta, y al revés.

Cómo registrarlo en el control horario

El registro de jornada obliga a anotar la hora de inicio y de fin de cada día (artículo 34.9 del Estatuto; el convenio lo repite en su artículo 71.8; el panorama completo, en registro horario digital obligatorio). Con eso basta para cumplir. Pero si solo apuntas entrada y salida, los trayectos quedan escondidos dentro de la jornada y luego nadie sabe cuántas horas fueron de obra y cuántas de furgoneta. Lo que recomendamos registrar:

1. Inicio y fin de cada trayecto, con hora del servidor, no la del móvil.
2. Obra de origen y obra de llegada, para que las horas posteriores se imputen a la obra correcta.
3. Vehículo (de empresa o propio) y, si es de empresa, los kilómetros del cuentakilómetros.
4. Qué pasa si el trayecto queda abierto: alguien olvida cerrarlo, sale de la jornada a mitad de camino o se queda sin batería.

Y una decisión de empresa, por escrito: si el trayecto entre obras cuenta como trabajado (lo normal, por lo visto arriba) y cómo se trata el de casa a la primera obra según tu convenio provincial y tu forma de organizar las cuadrillas.

Cómo lo resuelve Tajo

En Tajo, la app de control horario que hacemos para constructoras como Grupo Edma, el desplazamiento es un registro aparte. Así funciona:

• Dentro de la jornada. Solo se puede empezar un trayecto con la jornada abierta. No mide el viaje de casa a la obra: mide el de obra a obra.
• En el mismo registro que el fichaje. Inicio y fin de trayecto son dos eventos más del registro horario, con hora del servidor y sin posibilidad de borrarlos ni editarlos desde el móvil.
• Cuenta como trabajado, pero se ve aparte. Suma en las horas trabajadas y además se totaliza por separado; el trabajador ve su día dividido en trabajando, trayecto y descanso.
• La obra de llegada abre su propio tramo. Al cerrar el trayecto, las horas siguientes se imputan a la obra de destino sin que nadie tenga que repartirlas a mano, como en los partes de trabajo digitales.
• Sin cobertura, también. El trayecto se puede empezar sin red; se guarda en el móvil y se envía al recuperar conexión, sin duplicarse (el mecanismo, en fichar en obra sin cobertura).
• GPS solo con la app abierta. No hay seguimiento en segundo plano, que es lo que defiende la AEPD (lo explicamos en fichaje con geolocalización): la ubicación se toma al empezar y al terminar, y durante el trayecto mientras la app está en pantalla. Con vehículo de empresa, mandan los kilómetros del cuentakilómetros.

El trayecto que se contaba dos veces. Al revisar el código antes de cerrar esta parte encontramos un fallo nuestro: el servidor ya descontaba el trayecto de las horas que el operario debe imputar en el parte, pero el reparto automático del parte en el móvil no. Resultado: a quien aceptaba el reparto que proponía la app, el control nocturno le marcaba horas mal imputadas. Lo arreglamos con un test que lo vigila. La lección: cada vez que cambia qué cuenta como trabajado, hay que revisar todo lo que usa esa cifra.

Que el trayecto entre obras cuente como trabajado es nuestra opción por defecto, y la dejamos señalada para confirmarla con cada empresa según su convenio. Es la parte del registro horario que más conviene acordar antes de ponerlo en marcha, no después.

Preguntas frecuentes sobre el tiempo de desplazamiento

¿Es tiempo de trabajo ir de casa a la obra?

Como regla general, no. El artículo 34.5 del Estatuto computa la jornada de modo que el trabajador esté en su puesto al empezar y al terminar, y el Supremo (STS 1305/2024) lo aplica al trayecto de casa al primer cliente. La excepción son circunstancias parecidas a las de la sentencia Tyco, y cada caso depende de los hechos.

¿Cuenta como jornada el trayecto entre dos obras?

Sí, si la jornada ya ha empezado. El operario se desplaza por orden de la empresa, dentro de su jornada y a su disposición, que es la definición de tiempo de trabajo efectivo del convenio de la construcción. Conviene registrarlo como trayecto aparte para saber cuántas horas fueron de obra y cuántas de furgoneta.

¿Qué dijo la sentencia Tyco sobre los desplazamientos?

El TJUE resolvió en 2015 (asunto C-266/14) que, para trabajadores sin centro de trabajo fijo o habitual, el trayecto entre su domicilio y el primer y último cliente es tiempo de trabajo según la Directiva. Pero la Directiva solo define el tiempo; cuánto se paga lo decide el derecho nacional.

¿Qué dice el convenio de la construcción de las obras de larga extensión?

Su artículo 90.2 dice que moverse entre tajos dentro de una obra de larga extensión (carreteras, canalizaciones…) no es desplazamiento en sentido técnico, pero que el tiempo invertido en esa movilidad dentro de la obra se computa como trabajado. Los gastos de locomoción de los desplazamientos a otro centro corren a cargo de la empresa (art. 87).

¿Cómo se registra el desplazamiento entre obras en el control horario?

Con inicio y fin de cada trayecto, hora del servidor, obra de origen y de llegada, y vehículo. Así las horas siguientes se imputan a la obra correcta y queda claro qué hacer si el trayecto se queda abierto por olvido o falta de batería. La decisión de si cuenta como trabajado conviene dejarla por escrito.

Fuentes

1. Estatuto de los Trabajadores, arts. 34.5 y 34.9 — BOE
2. VII Convenio colectivo general del sector de la construcción, arts. 71, 87 y 90 — BOE (23/09/2023)
3. Sentencia del TJUE de 10 de septiembre de 2015, asunto C-266/14 (Tyco) — EUR-Lex
4. STS 1305/2024, de 27 de noviembre (rec. 88/2023), ECLI:ES:TS:2024:5973 — CENDOJ