Cada año alguien nos pregunta qué herramientas usamos. Y cada año la respuesta cambia un poco, porque las herramientas que no evolucionan se vuelven deuda técnica. Pero la filosofía detrás de nuestras decisiones se mantiene: elegimos lo que nos permite entregar mejor producto, más rápido, con menos fricción.
Este no es un artículo de "las mejores herramientas de 2026". Es un inventario honesto de lo que usamos en producción, por qué lo elegimos y en qué casos optamos por algo distinto. Si estás armando tu stack o evaluando un cambio, esto te puede ahorrar meses de prueba y error.
Frontend
Astro — Sitios estáticos y marketing
Para sitios que son primordialmente contenido (landing pages, sitios corporativos, blogs, portafolios), Astro es nuestra primera opción. ¿Por qué? Porque entrega HTML estático por defecto y solo carga JavaScript cuando realmente lo necesitas. El resultado: sitios que cargan en menos de un segundo y puntajes perfectos en Core Web Vitals.
La arquitectura de islas de Astro nos permite usar componentes de React, Svelte o Vue solo donde se necesita interactividad, sin contaminar el resto del sitio con un framework pesado. Para un sitio de marketing, eso es exactamente lo correcto.
Next.js — Apps con necesidades de server-side
Cuando el proyecto necesita server-side rendering, API routes, autenticación compleja o manejo de datos en tiempo real, usamos Next.js. Es nuestro framework para aplicaciones web que van más allá de mostrar contenido: dashboards, plataformas SaaS, portales de clientes, e-commerce con lógica de negocio pesada.
El App Router de Next.js maduró lo suficiente para que lo usemos con confianza en producción. Los Server Components cambiaron cómo pensamos sobre la separación entre servidor y cliente, y las Server Actions simplificaron mucho el manejo de formularios y mutaciones.
React — SPAs y dashboards
Para aplicaciones single-page donde el SEO no es prioridad (paneles internos, dashboards de administración, herramientas internas), usamos React con Vite. Rápido para desarrollar, un ecosistema maduro de bibliotecas y fácil de reclutar talento.
Nuestra regla: performance primero, framework segundo. Elegimos la herramienta por lo que el proyecto necesita, no por preferencia personal.
CSS
Tailwind CSS — Cuando la velocidad importa
Tailwind es nuestro default para la mayoría de proyectos. No porque sea "mejor" que escribir CSS, sino porque acelera el desarrollo sin sacrificar calidad. Las utility classes eliminan el cuello de botella de nombrar clases, mantener archivos CSS gigantes y lidiar con especificidad.
Con Tailwind podemos prototipar una interfaz en horas, no días. Y la consistencia visual viene gratis gracias al sistema de design tokens integrado.
Vanilla CSS — Cuando la precisión importa
Para proyectos donde cada pixel importa (sitios de marca con animaciones custom, experiencias interactivas, micrositios con identidad visual muy particular), escribimos CSS puro. Las animaciones complejas, las transiciones con curvas custom y el control fino sobre tipografía se manejan mejor sin la abstracción de un framework.
No es uno u otro. En un mismo proyecto podemos usar Tailwind para la estructura y CSS custom para los detalles que hacen la diferencia.
Backend
Node.js + Express — APIs y servicios
Node.js sigue siendo nuestra base para APIs REST y servicios backend. Express es ligero, flexible y lo conocemos profundamente. Para proyectos que necesitan más estructura, usamos Fastify por su rendimiento superior y sistema de plugins.
La ventaja de estar en JavaScript/TypeScript en todo el stack no es menor: un solo lenguaje reduce el cambio de contexto, simplifica la contratación y permite compartir tipos entre frontend y backend.
Python — Data y machine learning
Cuando el proyecto involucra procesamiento de datos, integración con modelos de lenguaje, análisis estadístico o pipelines de ML, usamos Python. No intentamos forzar Node.js para cosas donde Python tiene décadas de ventaja. FastAPI para endpoints de ML, pandas para procesamiento, y las integraciones nativas con servicios de AI que en Python son de primera clase.
Base de datos
PostgreSQL — El default que nunca falla
Si no tienes una razón específica para usar otra cosa, usa PostgreSQL. Es nuestra respuesta por default a "¿qué base de datos uso?". Relacional, robusta, con soporte nativo para JSON, full-text search, y una comunidad que lleva décadas resolviendo problemas reales.
PostgreSQL escala más de lo que la mayoría de startups necesitan. Antes de saltar a una base de datos "más moderna", asegúrate de que ya le sacaste el jugo a lo que Postgres ofrece.
Supabase — Cuando la velocidad de desarrollo importa
Supabase nos da PostgreSQL con superpoderes: autenticación, storage, realtime y un dashboard de administración listo para usar. Para MVPs, prototipos y proyectos donde el tiempo de desarrollo es crítico, Supabase nos ahorra semanas de configuración.
El row-level security de Supabase es particularmente útil: definir permisos a nivel de base de datos en lugar de en la aplicación elimina toda una categoría de vulnerabilidades.
Redis — Caching y datos efímeros
Redis para lo que hace mejor: caché de consultas frecuentes, manejo de sesiones, rate limiting, colas de trabajo. No lo usamos como base de datos principal, sino como la capa que hace que todo lo demás responda más rápido.
Hosting e infraestructura
Vercel — Frontend y jamstack
Los sitios en Astro y las apps en Next.js van a Vercel. Deploy automático desde Git, previews por branch, edge functions, analytics integrado. El developer experience es difícil de igualar y para proyectos frontend es nuestra plataforma predeterminada.
AWS — Infraestructura a escala
Para proyectos que necesitan control total sobre la infraestructura: contenedores (ECS/Fargate), almacenamiento (S3), CDN (CloudFront), bases de datos managed (RDS). AWS es complejo, pero cuando necesitas escalar a miles de usuarios concurrentes o cumplir con requisitos de compliance específicos, no hay sustituto.
Railway — Deploys rápidos y servicios backend
Railway es nuestro "Vercel para el backend". Cuando necesitamos deployar una API, un worker o un servicio auxiliar sin configurar toda una infraestructura en AWS, Railway nos resuelve en minutos. Perfecto para proyectos en fase temprana y para servicios internos.
Diseño y productividad
Figma — Todo el diseño
Figma para todo: wireframes, diseño de interfaces, prototipos, sistemas de diseño, presentaciones internas. La colaboración en tiempo real eliminó el ciclo de "te mando el archivo, ábrelo, dame feedback, te mando otra versión". Las variables y los modos de Figma nos permiten manejar design systems con dark mode, responsive y múltiples marcas en un solo archivo.
Notion — Documentación y specs
Notion es nuestro segundo cerebro. Specs de producto, documentación técnica, wikis internos, bases de datos de clientes, templates de procesos. Todo lo que no es código ni diseño vive en Notion.
Analytics
Google Analytics 4 — El estándar
GA4 para tracking de tráfico, conversiones y comportamiento general. No es perfecto (la interfaz sigue siendo confusa), pero los datos que genera son el estándar que todo cliente entiende y que se integra con Google Ads sin fricción.
Hotjar — Mapas de calor y grabaciones
GA4 te dice qué pasa. Hotjar te muestra por qué. Los mapas de calor y las grabaciones de sesión son invaluables para entender dónde la gente se pierde, qué ignora y dónde hace clic sin éxito. Es la herramienta que más insights actionables nos da por el precio.
Control de versiones
Git + GitHub
Git para versionamiento. GitHub para colaboración, code reviews, CI/CD con GitHub Actions y gestión de proyectos con Issues y Projects. No hay mucho que debatir aquí: es el estándar y funciona.
Herramientas que dejamos de usar (y por qué)
Igual de importante que saber qué usamos es saber qué dejamos atrás:
- WordPress (como plataforma de desarrollo): Para sitios custom, el workflow de PHP + MySQL + plugins se siente anticuado frente a Astro o Next.js. Seguimos soportando sitios WordPress existentes, pero no iniciamos proyectos nuevos con él salvo que el cliente lo requiera específicamente.
- Sass/SCSS: Tailwind cubrió la mayoría de nuestros casos de uso. Y para lo que no, CSS nativo ya tiene variables, nesting y container queries. Sass dejó de resolver un problema real para nosotros.
- Heroku: Railway hace lo mismo con mejor developer experience y precios más predecibles. Heroku se volvió caro y lento para lo que ofrece después de su adquisición.
- MongoDB: Lo usamos durante años para proyectos donde "los esquemas son flexibles". Aprendimos que la flexibilidad de esquema casi siempre se convierte en caos de datos. PostgreSQL con columnas JSONB nos da lo mejor de ambos mundos.
- Sketch: Figma lo superó en colaboración, performance y ecosistema de plugins. No hemos abierto Sketch en más de dos años.
Cómo elegimos herramientas
Nuestro framework de decisión se reduce a cuatro preguntas:
- ¿Resuelve un problema real que tenemos hoy? No adoptamos tecnología por hype. Si lo que tenemos funciona, no cambiamos.
- ¿Tiene una comunidad activa y documentación sólida? Las herramientas con comunidades pequeñas son riesgosas. Si algo falla a las 2 AM, necesitas que alguien más haya tenido ese problema antes.
- ¿Nuestro equipo puede aprenderla en menos de una semana? La mejor herramienta del mundo no sirve si la curva de aprendizaje paraliza al equipo.
- ¿Qué tan fácil es migrar si decidimos cambiar? El vendor lock-in es un costo oculto. Preferimos herramientas basadas en estándares abiertos.
Construyamos tu producto
Elegir el stack correcto es solo el primer paso. Lo que importa es cómo se usa para resolver problemas reales de negocio. En Tank Studio Lab no vendemos tecnología: vendemos productos digitales que funcionan.
Si estás buscando un equipo que entienda tanto el negocio como la tecnología, conoce nuestros servicios de desarrollo de software y desarrollo web. O escríbenos para platicar sobre tu proyecto.