Con qué trabajamos
Somos deliberadamente estrechos. Un equipo que dice dominar veinte lenguajes es un equipo que está aprendiendo uno en su proyecto. Lo que no está en esta lista, o lo aprendemos por nuestra cuenta o le decimos que contrate a otro.
- TypeScript
- Python
- Go
- Kotlin
- Swift
- SQL
TypeScript a ambos lados de la mayoría de los productos web, para que un ingeniero siga una función desde la base de datos hasta la pantalla. Python donde viven las librerías de datos y modelos, Go para servicios que deben ser pequeños y rápidos, Swift y Kotlin para apps nativas.
- React
- Next.js
- Vue
- Tailwind CSS
- Vite
- Playwright
React y Next.js por defecto, porque su equipo podrá contratar perfiles para ellos después de la entrega. Vue cuando su producto ya lo usa. Playwright para pruebas de extremo a extremo en cada cambio.
- Node.js
- FastAPI
- NestJS
- GraphQL
- gRPC
- REST
Node.js o FastAPI, según dónde viva el resto del producto. REST para la mayoría de las integraciones, GraphQL cuando muchos clientes leen los mismos datos de formas distintas, gRPC entre servicios internos.
- PostgreSQL
- Redis
- ClickHouse
- Elasticsearch
- Kafka
- dbt
PostgreSQL primero y casi siempre al final: la mayoría de los productos nunca lo supera. Redis para colas y caché, ClickHouse cuando la analítica ralentizaría la base principal, Kafka solo cuando los eventos de verdad tienen que reproducirse.
- AWS
- Google Cloud
- Docker
- Kubernetes
- Terraform
- GitHub Actions
AWS o Google Cloud en su propia cuenta, nunca en la nuestra, así que la infraestructura es suya desde el primer día. Todo está descrito en Terraform y se despliega desde CI, que es lo que hace posible una entrega limpia.
- OpenAI
- Anthropic
- Gemini
- pgvector
- LangGraph
- PyTorch
Modelos alojados de más de un proveedor detrás de una sola interfaz, para que un cambio de precio o una caída sea un cambio de configuración y no una reescritura. pgvector mantiene la búsqueda junto a datos de los que ya tiene copia.
- Swift / SwiftUI
- Kotlin / Compose
- React Native
- Expo
Swift y Kotlin nativos cuando la app depende de funciones del dispositivo o del rendimiento. React Native con Expo cuando un solo equipo debe publicar en iOS y Android y compartir lógica con la web.
- Figma
- Storybook
- Linear
- Sentry
- Grafana
- OpenTelemetry
Figma y Storybook, para que diseño y código describan los mismos componentes. Sentry, Grafana y OpenTelemetry, para que un problema aparezca en un panel antes que en un ticket de soporte.
Si su producto ya corre sobre otra cosa, trabajamos en su tecnología. Una reescritura es una decisión con justificación de negocio, no una preferencia.
Cómo elegimos para un proyecto nuevo
Lo que su equipo podrá mantener cuando nos vayamos importa más que lo que está de moda. Un stack para el que nadie de su lado puede contratar es una dependencia de nosotros, y preferimos no vendérsela.
Si el producto ya funciona sobre algo que va bien, lo mantenemos. Solo recomendamos reescribir con un caso de negocio por escrito: cuánto cuesta, qué ahorra y cuándo se amortiza.
Una herramienta que no hemos llevado a producción figura como riesgo en el documento de descubrimiento, en lugar de aprenderse en silencio con su presupuesto.
Cuéntenos qué está construyendo
Con una descripción breve basta para empezar. Respondemos con preguntas, un rango y las dos o tres cosas que lo cambiarían.