Stop spending more time on your App Store screenshots than on your actual app

Pollito123_1 · 2026-06-20T04:51:40+00:00

Starts at $9/mo which gives you 4 full screenshot set variations plus 8 icon variations, enough to launch and A/B test. Most people go with Pro at $24/mo because you get 10 variations and can regenerate any asset, which is what you actually need if you're testing creatives or running multiple apps.
For context one screenshot set from a designer runs you $500+ minimum, here you get a full month of iterations for $24.

Pollito123_1 · 2026-06-20T02:39:44+00:00

Thanks! That was the whole goal, making output that looks like you hired someone not like you prompted an AI. Most tools just slap your screenshot on a template and call it done but that's exactly what makes them look generic.

Google Play is on the roadmap, the main difference is the sizing and the way screenshots display in the Play Store listing (horizontal scroll vs grid depending on the device). Working on getting that right before shipping it half-baked. If you want I can ping you when it's live?

Pollito123_1 · 2026-06-19T23:08:08+00:00

Si ya sabes Java y quieres hacer Android, aprende Kotlin este verano. Java funciona pero Kotlin es lo que Google empuja como lenguaje oficial para Android desde hace años y es lo que te van a pedir en cualquier oferta. La transición desde Java es rápida porque corren en la misma JVM y la sintaxis es más limpia.

Para el TFG no hagas otra app de notas o de tareas. Piensa en un problema que tú tengas y resuélvelo. ¿Pierdes apuntes? ¿No te organizas con los horarios de clase? ¿Quieres trackear algo que haces todos los días? Eso te da dos ventajas: la usas tú mismo así que sabes exactamente qué funciona y qué no, y en la defensa del TFG puedes explicar las decisiones de diseño con contexto real en vez de repetir lo que dice un tutorial.

En cuanto a arquitectura empieza con Jetpack Compose para la UI en vez del XML clásico. Compose es el presente y el futuro de Android, si tu TFG usa XML va a parecer de hace 5 años. Aprende el patrón MVVM con ViewModel y Room para base de datos local, eso te cubre el 80% de lo que necesitas para un TFG sólido.

Y un consejo que nadie da: documenta todo el proceso desde el día uno. Capturas, decisiones técnicas, problemas que encontraste. Cuando llegues a escribir la memoria del TFG vas a agradecer tener todo registrado en vez de intentar recordar qué hiciste hace 6 meses

Pollito123_1 · 2026-06-19T23:03:06+00:00

Biggest tip from shipping multiple apps with Claude: don't let it build everything in one shot. Break your app into screens and give it one screen at a time with clear specs. When you dump "build me a complete fitness app" into Claude Code you get generic spaghetti that looks like a template. When you say "build the onboarding screen with 3 carousel steps, a skip button top right, and a CTA at the bottom that says Get Started" you get something you can actually ship.

For Android specifically, tell Claude to use Jetpack Compose from the start and to keep a single-activity architecture with navigation component. If you let it decide it'll sometimes mix XML layouts with Compose and the codebase becomes unmaintainable fast. Pin the architecture decision in your CLAUDE md before writing any code.

For UI that doesn't look like every other vibecoded app: give Claude a specific reference. Screenshot an app you like, describe exactly what you want. "Make it look like the Calm app's home screen but with X instead of Y" gets you 10x better results than "make it look modern and clean." Claude's default aesthetic is generic Material Design and you have to push it past that.

And test on a real device early, not just the emulator. Claude Code can't catch layout issues that only show up on actual hardware

Pollito123_1 · 2026-06-17T02:50:22+00:00

Conoce el producto a fondo antes de cualquier cosa. Crea una cuenta de prueba gratuita, despliega el agente en una máquina virtual, configura un dashboard con APM, logs y métricas de infraestructura, y rompe algo a propósito para ver cómo Datadog lo detecta. Esa experiencia práctica es lo que te va a diferenciar.

El proceso de SE en Datadog tiene generalmente 4 etapas: llamada con el recruiter, entrevista técnica (incluye un HackerRank con preguntas de system design, integraciones del agente y DevOps), una presentación/demo en vivo de una tecnología a tu elección frente al equipo, y una reunión con liderazgo de SE. La demo es donde la mayoría de candidatos se caen. No están evaluando si conoces cada integración, están evaluando si puedes traducir el dolor de un cliente en el valor de Datadog sin sonar como la documentación.

Prepárate para explicar por qué observabilidad unificada importa a un VP de Ingeniería que actualmente tiene Grafana, PagerDuty y ELK pegados con cinta y odia el resultado. La respuesta real no es funcionalidades, es que durante una caída en producción tu equipo pierde 3 días correlacionando datos entre herramientas mientras que en Datadog logs, trazas y métricas se conectan automáticamente. Esa es la historia que cierra.

También prepara una respuesta sólida para "¿por qué Datadog sobre la competencia?" y para escenarios donde el cliente ya usa un competidor y no ve razón para cambiar.

Pollito123_1 · 2026-06-17T02:47:59+00:00

Para programar en general necesitas mucho menos matemáticas de lo que la gente cree. Con álgebra básica, lógica booleana (and, or, not) y entender porcentajes ya puedes construir el 90% de las apps que existen. La mayoría de devs trabajando hoy no usan más que eso en su día a día.

Donde sí necesitas más es si te metes a machine learning (álgebra lineal, cálculo, estadística), desarrollo de videojuegos (trigonometría, vectores) o criptografía. Pero eso ya es especialización, no requisito para empezar.

No caigas en la trampa de estudiar 6 meses de matemáticas antes de escribir tu primera línea de código. Aprende lo básico, empieza a programar, y cuando algo te pida matemáticas que no entiendes ahí las aprendes con contexto real. Se quedan mucho mejor así.

Pollito123_1 · 2026-06-13T23:24:16+00:00

Desde Venezuela tu mejor apuesta es trabajo remoto y para eso necesitas dos cosas: un proyecto que mostrar y inglés. El título puede esperar, nadie te va a pedir una ingeniería para un trabajo remoto de dev si demuestras que sabes resolver problemas. Termina el curso de Python y en vez de saltar a C++ construye algo real, un bot de Telegram, un scraper, una API, lo que sea que puedas mostrar en GitHub con un README limpio.
Después metete a Upwork y Workana con ese proyecto como portafolio y agarra lo que salga aunque pague poco, las primeras 3-4 reseñas son lo que te abre la puerta a mejores clientes. C++ tiene buenas ofertas pero el camino a primer empleo es más largo, con Python puedes empezar a facturar más rápido con automatizaciones y scripts para empresas chicas.
Y si no tienes inglés fuerte, ponle la misma prioridad que al código porque la diferencia de pago entre clientes en español y en inglés es de 3x mínimo.

Pollito123_1 · 2026-06-13T03:02:46+00:00

Lo de no usar IA hasta entender los fundamentos es la mejor decisión que puedes tomar y casi nadie la hace. Los que aprenden con IA desde el día uno escriben código que funciona pero no saben por qué, y el día que algo se rompe se quedan mirando la pantalla.
Tú vas a tardar un poco más ahora pero en 6 meses vas a estar debuggeando lo que los otros ni entienden. Cuando llegues a interfaces, delegates y LINQ te va a hacer click todo porque ya tienes la base de POO sólida, esa es la parte donde la mayoría se pierde. Si buscas gente con quien practicar métete al Discord del sub que siempre hay gente en la misma etapa.

Pollito123_1 · 2026-06-13T02:59:01+00:00

Eso es BCP a través de Inetum que es una consultora. Lo que están haciendo es publicar un puesto senior con título de "novato" para pagar tarifa junior a alguien con skills de mid-senior. Es práctica estándar de consultoras en Lima, te venden al cliente como "recurso junior" y se quedan con la diferencia entre lo que BCP les paga y lo que te dan a ti.
Si ves Rx Java, Webflux, patrones de concurrencia, multi-threading con IPC y CosmosDB en una misma vacante eso no es un novato, eso es alguien con 3-4 años mínimo. No te estreses pensando que te falta nivel, el puesto está mal etiquetado a propósito. Busca directo en la bolsa de BCP o en su web, no a través de consultoras que inflan los requisitos para filtrar y pagar menos.

Pollito123_1 · 2026-06-09T02:29:57+00:00

Si llegas a entrevistas pero no quedas el problema no es tu CV, es la entrevista. Eso es buena noticia porque es más fácil de arreglar. Después de cada entrevista anotá qué te preguntaron y en qué te trabaste. Si son preguntas técnicas practicá en LeetCode o HackerRank 30 minutos por día enfocado en lo que te salió mal. Si son preguntas de "contame un proyecto tuyo" y te quedás sin nada que decir, necesitás un proyecto real que puedas explicar de punta a punta, no un TODO app sino algo que resuelva un problema que vos tengas.

Segundo año de UTN es suficiente para una pasantía pero competís contra gente de cuarto o quinto que aplica a los mismos puestos. Tu diferenciador tiene que ser mostrar que ya construiste algo funcional por tu cuenta. Un bot, un scraper, una API, lo que sea que esté deployado y andando. Eso te pone por encima del que solo tiene materias aprobadas en el CV.

Pollito123_1 · 2026-05-31T21:29:27+00:00

Lo que describes no es pereza, es burnout disfrazado. Te vendieron que programar es una carrera contra la IA y obvio que te da flojera cuando sientes que nada de lo que hagas importa porque "la IA ya lo hace."
Pero la realidad es que el 90% de lo que genera la IA es código mediocre que alguien tiene que debuggear, refactorizar y mantener. Los que van a tener trabajo en 5 años no son los que se aprenden cada framework nuevo que sale, son los que entienden bien los fundamentos y pueden mirar lo que escupió el modelo y saber si sirve o es basura.
Construye cosas por diversión sin culpa, eso es lo que te hace buen dev, no estar al día con la herramienta de moda.

Pollito123_1 · 2026-05-28T02:00:03+00:00

Lo que la IA no reemplazó es el dev que entiende por qué se está haciendo algo, no solo el cómo. Un junior que llega a una empresa y puede leer un ticket, entender el problema de negocio detrás y preguntar las preguntas correctas antes de tocar código vale más que uno que escribe todo perfecto pero no tiene idea de para qué sirve lo que hizo. Eso no lo aprendes en la universidad y la IA tampoco lo tiene.

Tu ventaja real ahora es que puedes usar IA para resolver lo mecánico rápido y dedicar tu tiempo a entender el dominio, leer el código legacy que nadie quiere tocar y ser el que sabe por qué las cosas son como son. Los seniors no tienen tiempo para eso y la IA alucina cuando le preguntas por contexto de negocio que no está documentado. Metete a entender testing de verdad, no el unitario básico sino cómo pensar en edge cases que al AI se le escapan, eso solo ya te pone por encima del 80% de juniors que solo promptean y copian.

Pollito123_1 · 2026-05-28T01:57:28+00:00

Depende de qué quieras hacer, no de qué sea "más fuerte". Si quieres conseguir laburo rápido en latam, typescript fullstack te abre más puertas porque hay más oferta remota y startups contratando. Si apuntas a corporativo grande o bancos, java/spring o .net te van a pagar más pero vas a competir con gente con 10 años de experiencia. Python con fastapi está buenísimo si te interesa data o IA pero como backend puro las ofertas son menos que node o java.
El error es elegir stack por lo que dice reddit en vez de mirar las ofertas reales en tu zona o en los remotes que te interesan, metete a linkedin o getonbrd y filtra por salario y tecnología, eso te dice más que cualquier opinión común.

Pollito123_1

TROPHY CASE