Stocketa, la app que diseñé y construí pero nunca lancé

• Stocketa comenzó en marzo de 2020, al inicio del confinamiento por COVID, como un proyecto personal para aprender Swift y SwiftUI; se desarrolló durante más de dos años, entre 10 y 20 horas por semana, pero nunca se lanzó en la App Store
• El objetivo era ser un rastreador de portafolio para inversionistas casuales que permitiera ver en un solo lugar los activos dispersos entre varias casas de bolsa y servicios financieros, además de consultar ganancias y pérdidas por operación, realizadas y no realizadas
• La app se enfocó más en interacciones hechas a medida que en componentes estándar de iOS, e implementó pull-to-search, tarjetas de acciones, sheets y menús personalizados, acciones por swipe, widgets, importación TSV y más
• La mayor limitación práctica que bloqueó el lanzamiento fue la API de datos financieros: los problemas de calidad y cobertura de IEX, la confiabilidad de un proveedor de USD 100 al mes y los precios de datos comerciales de más de USD 2,000 al mes no encajaban con una app independiente
• Aunque ya tenía una LLC, un backend Node/Express, un TestFlight de unas 1,000 personas y miles de personas en lista de espera, se canceló por los costos de datos, la carga de soporte al cliente y la falta de tiempo; la experiencia aprendiendo SwiftUI se trasladó directamente al trabajo posterior en Rewind AI

---

El problema que Stocketa quería resolver

• Stocketa buscaba ser una app de seguimiento de portafolio bien diseñada para ver en una sola pantalla inversiones dispersas en varios lugares
  • Surgió de la experiencia personal de lo incómodo que era revisar activos repartidos entre distintas casas de bolsa y servicios financieros
  • No quería solo consultar precios, sino ver ganancias y pérdidas reales por operación reflejando su propia base de costo
• Las opciones de entonces no se ajustaban a lo que necesitaba
  • Apps simples de acciones como Apple Stocks ofrecen gráficos y noticias, pero no seguimiento de cantidades en cartera ni de ganancias y pérdidas
  • Apps de casas de bolsa como Robinhood solo muestran las posiciones dentro de esa misma casa de bolsa
  • Servicios avanzados como TradingView no estaban centrados en móvil o no ofrecían una experiencia tan elegante como la deseada
  • Servicios de asesoría de inversión como Personal Capital tienen conexión con cuentas, pero es difícil profundizar en activos individuales y están enfocados en vender sus propios servicios de asesoría
  • Las apps pequeñas de seguimiento de posiciones en la App Store no resultaban satisfactorias en diseño y UX
• Las apps financieras existentes suelen priorizar la densidad de información, obligando a entrar una y otra vez de listas a pantallas de detalle; Stocketa quería mostrar más información dentro de las tarjetas de la pantalla inicial

Estructura de la app creada con UI personalizada

• Stocketa se diseñó alrededor de un feed único y tarjetas de acciones, minimizando el chrome de UI alrededor
  • Se buscó evitar barras de pestañas o encabezados de navegación estándar
  • La estructura concentraba la mayoría de las funciones dentro de las tarjetas de acciones del timeline principal
• Casi toda la UI se creó con componentes personalizados basados en SwiftUI
  • En lugar de pull-to-refresh, usaba pull-to-search para buscar y agregar nuevos símbolos
  • Las tarjetas de acciones ofrecían inline la mayor parte de la información, como scrubbing de gráficos, acciones por swipe y estadísticas clave
  • Al tocar una tarjeta, la tarjeta existente permanecía en su lugar y aparecían con animación tarjetas de noticias y detalles de posiciones; en la implementación principal se usaron overlayPreferenceValue y anchorPreference
  • Los sheets personalizados incluían selector de fecha, pantallas de ayuda, fondo con estrellas brillando e interpolación de transparencia del fondo según el arrastre
  • El menú personalizado de la app ofrecía espacio para mostrar el plan de pago o el estado de membresía, y se diseñó para cerrarse con un toque o al hacer scroll
• Las acciones por swipe y el encabezado también se implementaron manualmente
  • Las acciones se desplazaban según la distancia del swipe y, al pasar cierto umbral, se animaban al estado seleccionado
  • Los botones del encabezado se veían sin borde en la parte superior de la página y se convertían en botones sutiles al hacer scroll
  • El texto de Stocketa se interpolaba para desaparecer hacia arriba con el scroll

Seguimiento de operaciones y funciones de la app

• La implementación inicial empezó con el scrollview de tarjetas de acciones, gráficos y persistencia de base de datos
  • Al principio usó Core Data y luego migró a Firebase
  • Se conectaron llamadas y polling a proveedores de datos financieros, usando IEX como primer proveedor
• Stocketa no solo guardaba la cantidad de acciones por símbolo, sino que implementaba seguimiento a nivel de operación
  • Buscaba mostrar no solo las ganancias y pérdidas totales por compra y venta, sino también por operación
  • Al vender, necesitaba conocer métodos de base de costo como FIFO y LIFO, y calcular de qué operación pasada se estaban vendiendo acciones
  • Los splits de acciones no debían simplemente modificar operaciones pasadas; tenía que soportar tanto la aplicación automática de nuevos splits como la aplicación manual
• Las funciones se expandieron por toda la app
  • Onboarding: en lugar de un carrusel común, usaba un flujo donde las páginas entraban empujándose sobre el eje z y presentaba componentes clave como las tarjetas de acciones
  • Importación TSV: importaba operaciones desde archivos TSV creados en hojas de cálculo y escribía de vuelta el estado de importación en el TSV para permitir reimportaciones después de sincronizar con iCloud
  • Ingreso de compras: ofrecía un formulario específico para acciones centrado en cantidad, precio y fecha; al cambiar la fecha, el precio histórico de ese día pasaba a ser el placeholder
  • Ingreso de ventas: soportaba FIFO, LIFO, costo promedio, costo más alto, costo más bajo y lotes específicos
  • Pantalla de suscripción: incluía texto con parallax, desenfoque que se despejaba con el scroll, tarjetas de funciones basadas en movimiento y un pequeño efecto de fireworks al llegar al final
  • Tarjeta de membresía: mostraba el estado de una cuenta con suscripción activa como una tarjeta interactiva, con efecto de starfield en el fondo y shimmer
  • Configuración de visualización de tarjetas de acciones: ofrecía varias formas de tarjeta y opciones, con microanimaciones al activar o desactivar toggles
  • Tarjeta de estado de posiciones: mostraba información agregada basada en la configuración en la parte superior del scroll principal
  • Widgets: ofrecía tres tipos —acción individual, portafolio y portafolio simple—, con colores de gran gradiente que cambiaban según el rendimiento
  • Periodo de gracia de Face ID: al considerarlo necesario para una app que maneja activos financieros, permitía ajustar el tiempo de gracia antes de volver a bloquearse al cambiar de app
  • Sheet de feriados del mercado: mostraba días de cierre en cuentas con posiciones de acciones, y requería código de servidor para aplicar el mismo tratamiento en widgets
  • Sheet de feedback: mostraba problemas conocidos y funciones planeadas, y permitía incluir un token de verificación de cuenta cuando la pregunta dependía de la cuenta
  • Eliminación de cuenta: según el requisito de actualización de la App Store de 2021, permitía eliminar completamente la cuenta desde dentro de la app

Aprender y rehacer con SwiftUI

• Stocketa avanzó al mismo tiempo que el proceso de aprender Swift y SwiftUI, por lo que muchas pantallas y partes de la app fueron rediseñadas y reimplementadas constantemente
• SwiftUI evolucionó desde iOS 13 en rendimiento, componentes y funciones; en iOS 17 también ofrece shaders, keyframes y scroll transitions
• SwiftUI fue útil tanto como herramienta de código como herramienta de diseño
  • Permite que un diseñador arme layouts rápidamente
  • Facilita agregar interacciones
  • Permite validar la sensación real del diseño con herramientas nativas
• Los casos que requerían UIKit eran limitados
  • Campos de texto personalizados para controlar con más detalle entrada, estilo y formato
  • CollectionView para cambiar el orden de los símbolos mediante arrastre
  • Emisores de partículas como confetti o estrellas en un cielo nocturno
  • UILongPressGestureRecognizer para obtener la posición donde empezó una pulsación larga

Backend y operación de TestFlight

• Al principio se pensó como una app simple sin backend ni cuentas de usuario, pero pronto se volvió necesario un backend propio
  • Se creó un proxy de backend para no incluir llaves de API de datos financieros dentro de la app
  • Se agregaron rate-limiting y throttling para evitar que el abuso de la API aumentara los costos
  • Se agregó Sign In With Apple
  • Se cacheaban durante cierto tiempo estadísticas por símbolo para que, aunque varias cuentas pidieran los mismos datos, solo se obtuvieran una vez
• El backend, basado en Node/Express, creció hasta unas 13,000 LOC
  • Corría en Cloud Run
  • Se encargaba de autenticación, caché, noticias, lógica central de negocio, limpieza de datos, notificaciones, widgets, integraciones con varias API y algo de scraping
• La gestión del trabajo se hizo con Linear
  • Se administraban tareas, ideas, funciones, feedback de clientes e hitos
• TestFlight comenzó como una pequeña alfa para amigos cercanos y se fue ampliando gradualmente
  • En un momento se invitó a unas 1,000 personas
  • Había miles de personas en lista de espera, pero no se amplió más por los costos de API y hosting y la carga de soporte y respuesta a feedback
  • El feedback mezclaba buenas primeras impresiones, solicitudes de funciones y reportes de bugs

Diseño e implementación del sitio web

• El sitio web inicial era una landing page sencilla para generar interés y recolectar emails de lista de espera
• El diseño inicial incluía elementos ondulados que aludían vagamente a las subidas y bajadas de los gráficos bursátiles, además de minitarjetas de acciones flotantes
  • Las minitarjetas tenían gráficos de líneas en SVG y se animaban al cargar la página
  • El efecto de movimiento suave en el fondo se implementó con CSS offset-path y 2 animaciones keyframe
• La homepage v1.0 se completó a inicios de 2021
  • Como ya había suficiente implementación para mostrar funciones de la app, se creó una homepage más completa
  • En lugar de la estructura típica de una homepage de app con marco de teléfono y titular, se probó una composición donde un marco 3D de teléfono se movía con el scroll y se reproducía un video teaser de la app
  • En vez de Lottie, se eligió un enfoque donde JavaScript dibujaba secuencias de frames en canvas y offscreenCanvas
  • Con Rotato se hicieron screencasts breves de Stocketa como video 3D de teléfono y secuencias de frames PNG
  • Luego, generar, optimizar y actualizar esas secuencias de frames se volvió muy engorroso
• La homepage v2.0 se rediseñó un año después
  • Para mostrar más funciones y mejoras, se quería una lista de funciones fácil de escanear en lugar de módulos largos y repetitivos
  • Se adoptó una estructura de 2 paneles, con un marco de dispositivo fijo a la derecha y una lista de funciones desplazable a la izquierda
  • Al pasar el mouse sobre un elemento de función, cambiaba la captura de pantalla en el marco del dispositivo
  • En móvil, el encabezado se convirtió en un carrusel desplazable de marcos de dispositivo
  • Se agregaron gradientes de texto hero según el scroll, cambios de color en íconos, gradientes de fondo en hover y un emisor de partículas de íconos

Límites impuestos por las API de datos financieros

• La calidad de los datos financieros de los que dependía Stocketa no alcanzaba el nivel necesario para lanzar
• El primer proveedor, IEX, tenía varios problemas
  • A veces los gráficos estaban desactualizados o los precios eran incorrectos
  • Los activos con poco volumen en el exchange de IEX eran especialmente problemáticos
  • No tenía datos de mercados OTC, y había que firmar una licencia costosa directamente con OTC
  • Los datos de acciones listadas en Nasdaq también estaban muy limitados, y faltaban datos básicos como premarket y after-hours
  • Suspendió por completo los datos de fondos mutuos sin aviso previo
• Otro proveedor comercialmente viable usado después costaba USD 100 al mes, pero tenía problemas aún mayores de datos y confiabilidad
  • Los endpoints devolvían datos antiguos o incorrectos
  • Al reportar problemas, ignoraban los bugs o respondían que no existían
• Algunos datos eran difíciles de obtener incluso con API pagadas, así que fue necesario crear un motor de scraping en el backend
  • dividend yield
  • earnings dates
  • OEF data
• Los datos de mercado de alta calidad tenían una estructura de precios que no encajaba con desarrolladores independientes
  • Los precios comerciales de datos de algunos proveedores importantes de mercados de EE. UU. empezaban en USD 2,000 al mes
  • Los datos de índices u opciones requerían costos adicionales
  • Un proveedor ofreció un plan para startups de USD 499 al mes más cargos por MAU, pero aun así se consideró demasiado caro para lo necesario
• Los proyectos que dependen de API de datos financieros asumen el riesgo de construir un negocio sobre API de empresas externas; se consideró un problema similar a los cambios en las API de Twitter y Reddit

Por qué se detuvo el lanzamiento

• Stocketa fue desde el inicio un proyecto paralelo, no un negocio real
  • Para convertirlo en un negocio real habría necesitado más funciones y formas de monetización
  • Tal vez habría tenido que entrar en áreas como asesoría financiera o compraventa de acciones, espacios saturados donde compiten grandes empresas
  • Esa dirección no encajaba con el punto de partida: crear una app simple y elegante
• Los motivos para detenerlo se resumen en tres
  • Datos: para lanzarlo con un precio de suscripción razonable se necesitaban datos financieros confiables, baratos y de alta calidad, pero el costo y la dificultad de conseguirlos eran elevados
  • Soporte: por el uso observado en TestFlight, se habría requerido una inversión considerable en soporte al cliente, emails, mantenimiento y desarrollo continuo de funciones
  • Tiempo: se eligió Rewind AI como foco principal, y Stocketa ya había ocupado durante años noches, fines de semana e incluso tiempo para escribir en el blog
• El objetivo original de aprender Swift y SwiftUI sí se cumplió
  • Aunque nunca se lanzó, permitió aprender mucho sobre desarrollo nativo para iOS
  • El conocimiento de SwiftUI adquirido con Stocketa ayudó mucho en el trabajo en Rewind AI

[GN⁺]

Comentarios de Hacker News

• Que un proyecto de varios años nunca llegue a usarse en la práctica a veces se siente casi como una medalla de honor. No una medalla muy sabia, pero para un desarrollador como yo, que se obsesiona en el buen sentido y se deja absorber por completo, también es casi una lección necesaria.
  Cuando cuento experiencias pasadas y el dolor que vino con ellas, siento que la gente se queda en blanco. Si nunca pasaste más de 10 horas al día durante más de un año dedicado a algo, creo que es difícil entender la sensación de haber invertido miles de horas y no obtener ningún resultado.
  He tenido muchos proyectos exitosos y ahora también me va bien, pero esos proyectos de varios años no se pueden deshacer. Tal vez fueron necesarios para aprender, pero al recordarlos todavía me da tristeza y soledad.

  • En 2016 me pasó algo parecido mientras aprendía Swift y UIKit por mi cuenta y hacía una app para iOS. Durante 2 años le metí unas 2 horas al día, 5 días a la semana, más de 1,000 horas, pero esa app nunca se publicó.
    A cambio, adquirí habilidades que me hicieron un programador mucho mejor y terminé tomando cariño a Swift. Si fuera hoy, gracias a cómo han avanzado en los últimos 7 años las herramientas de desarrollo y las API de Apple, creo que podría rehacer toda esa app desde cero en un fin de semana.
    Estos proyectos merecen conmemorarse. Programar puede ser arte, y el arte, como salida creativa, también puede hacerse solo para uno mismo.
  • Arrepentirse de algo así solo tiene sentido si en ese momento ya podías saber que no iba a funcionar y aun así seguiste empujando contra tu mejor criterio. Si tomaste la mejor decisión posible con la información que tenías entonces, eso era todo lo que podías hacer; lo demás depende de la suerte.
    No sirve de mucho atormentarse por proyectos pasados con un pensamiento centrado en el resultado, usando conocimiento que solo adquiriste después. La mayoría de los proyectos y negocios fracasan, y esa es la realidad.
    Recuerdo algo que escribió un exfinanciero: “a nadie lo despiden por ganar dinero por casualidad con una mala operación”. En una cultura centrada en resultados, es fácil olvidar que lo único que realmente controlamos es el proceso.
  • Le dediqué 10 años a un proyecto de software y, aunque lo terminé hace 6 meses, todavía no he ganado ni un centavo :(
    Aprendí lecciones valiosas, como saber cuándo detenerme, pero fue una clase larguísima. Todavía no logro pensarlo con claridad.
  • No hay nada más desmoralizante que dedicarle años a un proyecto y que, apenas se lo muestras a alguien, lo aparte diciendo “no me gusta”, o que simplemente te diga que hagas X.
  • Probablemente duele más porque el objetivo era el éxito, es decir, el uso de la app o los ingresos. Si la razón principal hubiera sido disfrutar o aprender, quizá se habría sentido distinto.
    Me pregunto si recomendarías no empezar un proyecto de más de un año si no tienes la certeza de que no te arrepentirás aunque nadie lo use.

• Es un gran texto, pero la conclusión se siente triste. Hay muchísimas apps de las que uno quisiera tener una versión “sin nada innecesario”, y la cantidad de trabajo que hay aquí es asombrosa.
  Lancé una app de iOS mucho más simple y, con crecimiento orgánico, llegó a unos 1,000 usuarios activos diarios, pero al final la cerré. Le puse una compra dentro de la app de $1.99 o $2.99 para quitar anuncios, ganaba unos $70 al mes y atendía reportes de bugs.
  En ese entonces SwiftUI todavía no estaba maduro, así que tuve que usar UIKit, y seguía topándome con casos límite difíciles de arreglar.
  El golpe final fue cuando Google afirmó que yo había hecho clic en mis propios anuncios y dejó de mostrarlos. Prácticamente todos los ingresos se cortaron, y me di cuenta de que, aunque trabajara mucho en esto, al final dependía de los caprichos de las grandes tecnológicas.
  Apple se quedaba con el 30% de todas las compras dentro de la app, los ingresos por anuncios eran migajas y Google podía apagarlos sin motivo y sin una forma real de apelar. No pretendía hacerme rico, pero necesitaba una razón para dedicarle tiempo y energía, y ya no podía justificarlo.

  • Que Google corte los anuncios por clics en anuncios propios parece una estupidez demasiado severa.
    No entiendo por qué no deja que el desarrollador registre dispositivos excluidos de ingresos, rangos de IP o listas de ubicaciones. Al final uno termina usando su propia app, y en muchos casos, al hacer scroll, es casi imposible no tocar un anuncio por accidente.
    También es importante probar en un entorno real, e incluso existe una pequeña posibilidad de que un anuncio sea realmente interesante y hagas clic legítimamente como cliente potencial. Pero con el sistema actual, en la práctica te están diciendo que no uses tu propia app.
    No sé a quién beneficia esta política fundamentalmente tonta, salvo a los desarrolladores o gerentes de Google que insisten en mantenerla. Me pregunto si de verdad es tan difícil manejarlo aunque sea un poco mejor.

• Se puede pensar de forma similar en un músico de cuarto que durante 20 años no ha dado conciertos ni sacado discos, un deportista de infancia que no volvió a tocar una pelota desde los 18, un corredor que no compite o una mente brillante que no enseña.
  Bajo la misma premisa de “producto externo = valor”, incluso podría extenderse a un ser humano que vivió décadas sin tener hijos. No es mi creencia; solo digo que así sigue la lógica.
  Pero ese tipo de juicio es una construcción humana, y parece un reflejo del mandato biológico de sacar al mundo a “nuestros hijos” largamente gestados. Nos preguntamos por qué no deberían obtener vida propia, y queremos que sigan produciendo por sí mismos y aporten hilos al futuro.
  ¿Seguir ese mandato es la cumbre de lo moral, lo ético o lo placentero? Para algunas personas sí, y no quiero juzgarlo. Pero para otras, curiosamente, no lo es.

• Me pregunto si estaría dispuesto a vender este proyecto. Me gusta el concepto y parece que hay clientes interesados, pero no parece que quiera encargarse de la carga de soporte ni de convertirlo en negocio.
  Hace alrededor de un año creé un rastreador de activos (https://jch.app), pero todavía estoy muy lejos en funciones y experiencia de usuario.
  Es un trabajo enorme, y también me gustó el registro tan profundo del recorrido. Tengo ganas de ver qué saldrá después de rewind.ai.

• No es muy distinto de la infinidad de personas que han dedicado horas sin fin a montones de proyectos que no significaban mucho para nadie más. Es como hackear una bicicleta o ponerse a jugar con trenes a escala.
  La diferencia es que una app se puede publicar, documentar y conservar con tanta facilidad, mientras que “el tiempo pasado cortando y soldando piezas raras de bicicleta” es difícil de tratar así, salvo que lo subas todo a YouTube.
  Claro que mucha gente lo hace, y hasta cierto punto tiene sentido, pero cuando uno intenta convertir un hobby y una búsqueda personal en un producto con objetivos distintos a sí mismo, también puede perder un poco el punto central.
  No quiero decir que este texto esté mal. No suena a queja ni a enojo; como dice al principio, se siente como “quiero dejarlo registrado en algún lado, de alguna manera”. La mayor parte de mi GitHub es igual.

  • Es profundo eso de que lo que pudo haber sido se vuelve el punto de referencia para evaluar lo que realmente ocurrió.
    Este ajuste apresurado del criterio de evaluación puede ser poco útil porque nubla el resultado real. En este caso, al autor le sería fácil avergonzarse del esfuerzo “desperdiciado”, pero una reacción más adecuada sería agradecer lo aprendido.
    Lo que se aprende en proyectos así es enorme.

• Este artículo da miedo porque me veo demasiado reflejado. Meterse de lleno en crear un gran producto, sumergirse en la identidad de artesano y sentir rechazo por el enfoque “sin alma” de un MVP rápido y sucio y pruebas de mercado iterativas.
  Si alguna vez entraron al subreddit r/SaaS, eso es exactamente lo contrario de lo que disfruto como desarrollador de software.
  Pero también sé que, si pudiera cambiar mi mentalidad sobre las pruebas de mercado y la iteración rápida y sucia, en realidad tendría una mejor base para relajarme y concentrarme en la artesanía.

• Te entiendo. Yo todavía estoy construyendo un backend bancario. Llevo 5 años con eso, incluyendo core, contabilidad, clientes, cuentas, pagos (SEPA y tarjetas), notificaciones (algo tipo ServiceNow), revisión de sanciones, motor de riesgo y monitoreo, flujo de eventos y reporting.
  Estoy empezando a dudar si fue una locura o una estupidez haber asumido algo tan enorme. Todavía ni siquiera diseñé una landing page, y el código anda por unas 150 mil líneas.

  • Como alguien que está en este rubro, recomiendo mucho que empieces a contactar clientes potenciales y a construir confianza lo antes posible.
    Aunque las plataformas existentes tenían muchos bugs, limitaciones y problemas de seguridad, nos llevó bastante más de 5 años ganarnos la confianza suficiente para convencer a los clientes de pasarse a nuestra plataforma de core bancario.
  • Yo también construí una solución de comercio electrónico con pagos, mensajería REST, servidor de correo (IMAP/SMTP), publicidad de afiliados y pagos, reporting y control de acceso propios. Llegué a tener la solución completa en estado alfa, incluyendo frontends web para desktop y móvil.
    Pero cuando las apps móviles se volvieron importantes, también empecé a crear apps nativas, y eso fue demasiado. Al final terminé quemado y hasta en bancarrota, así que no recomiendo los megaproyectos.
    Aprendí mucho, pero el desperdicio no valió la pena. El tiempo es demasiado valioso para rehacer tantas cosas. Ahora solo hago proyectos “pequeños” de 6 a 12 meses como máximo.
  • ¿Estás haciendo un backend bancario como proyecto paralelo? Interesante. Me da curiosidad si es más bien un proyecto por diversión o si tiene un objetivo comercial.
    También me pregunto si hay alguna posibilidad de que sea open source.
  • Tienes que lanzarlo. Puedes empezar subiendo capturas, una lista de funciones y otra lista separada de funciones previstas, y crear un formulario para solicitar acceso a la beta.
    Si no puedes lanzar una versión básica quitando todo lo que quieres agregar, deberías considerar pausarlo un tiempo.
    En los últimos más de 20 años he creado muchos proyectos y productos, y 2 o 3 crecieron mucho. Los demás tienen miles de usuarios, pero no una fuente de ingresos sostenida.
    Uno que se convirtió en un negocio rentable lo lancé como versión de “fin de semana” y luego lo fui construyendo durante 7 años.
  • También deberías preguntarte: “¿cómo se vería el éxito?”. Si en 5 años no hubo ingresos, probablemente ya te acostumbraste a esta etapa.
    Ese estado de comodidad puede convertirse en una trampa que te hace seguir encontrando trabajo previo al lanzamiento. Por eso podría servirte replantear el marco mentalmente.

• Hace poco leí que Leonardo DaVinci era un procrastinador tremendo y que tenía muchísimos proyectos sin terminar.
  Siempre lo admiré por haber tenido tanto éxito en varios campos, pero saber eso me cambió la perspectiva: la procrastinación es parte de quienes somos como personas creativas.
  Puede verse como un fracaso, pero también puede reinterpretarse como parte del proceso. Al final, disfrutamos crear cosas.

• Básicamente aceptó el consejo habitual de “haz un MVP, lánzalo rápido e itera”, y luego hizo exactamente lo contrario.

  • Después de pasar 10 años en grandes empresas tecnológicas lanzando solo experiencias por debajo del nivel esperado, era de esperar que hiciera exactamente lo contrario y se enfocara en la calidad. https://paulstamatiou.com/craft/
  • No sé si ese consejo aplica también para desarrolladores individuales. En productos inevitablemente maximalistas como esta app, donde tienes que hacerte cargo solo hasta del detalle más pequeño, no existe eso de moverse rápido.

• Excelente artículo sobre un side project que se ve genial. Lo estaba leyendo con interés y encontré rewind.ai, que también se ve bueno
  En algo potencialmente invasivo como la grabación automática continua de pantalla y audio, la privacidad es clave, así que al ver la sección “Privacy first” me surgió una duda
  Dice: “Cifra tus datos con FileVault. Apple FileVault funciona con Rewind. Al activarlo, tus datos quedan cifrados”. ¿Rewind hace algo para que Apple FileVault “funcione con Rewind”?
  ¿O se refiere al cifrado de disco general que aplica a todo? Pregunta en serio. Quiero usar Rewind, pero esta formulación puede interpretarse como puro empaque innecesario
  La frase “solo se envían a la nube los datos relevantes basados en texto, y se cifran en tránsito” me da una impresión similar. ¿“Cifrado en tránsito” significa el cifrado TLS estándar? Rewind se ve bueno, pero tiene que ser confiable

  • En el sitio web de Rewind dice esto:
    “No se necesitan integraciones en la nube. Todo funciona automáticamente sin necesidad de conectarse a varios servicios como Gmail, Dropbox o Slack”
    Pero si uno ve los detalles de la política de privacidad oficial en https://www.rewind.ai/privacy, dice esto:
    “[Elementos recopilados:] Información generada por OpenAI. Como parte de la integración de OpenAI de Rewind AI, también podemos recopilar salidas generadas por OpenAI, como resúmenes de transcripciones de grabaciones de audio y otros datos generados por la integración de OpenAI”
    Entonces, aunque “no se necesitan integraciones en la nube”, ¿mi audio se comparte con OpenAI?
    Además, en https://www.rewind.ai/privacy-first dice: “¿Qué pasa cuando buscas en Rewind? Todos los datos grabados permanecen en local”
    No sé cuál de las dos cosas es cierta. Quiero confiar en Rewind, pero las inconsistencias en cómo explican el tratamiento de los datos de los usuarios me hacen dudar
  • Gracias por avisar. Parece que tenemos que actualizar esa página, y también contamos con cifrado propio. Hay más detalles aquí: https://help.rewind.ai/en/articles/7242593-is-the-rewind-dat...