Thinqcraft

Tecnología

Un stack que sostiene backend, frontend, mobile, APIs, datos, infraestructura y cambios seguros tras el lanzamiento.

Discutir arquitecturaHablar de alcance

Stack

Fundamentos maduros, delivery moderno

Rails, Go, Python, JavaScript, TypeScript, React, Solid.js, SolidStart, Astro, Elixir/OTP, PostgreSQL, Redis, Docker, Linux, REST, GraphQL, tRPC y OpenAPI.

Estándares

Código que se puede operar

Tests, monitoring, documentación y manejo de errores forman parte del build desde el primer día, no una idea de último momento.

Arquitectura

Límites nombrados temprano

Ownership de datos, contratos de API, límites de integración - nombrados antes de que desaparezcan en el código.
  • Backend y APIs
  • Frontend y mobile
  • Datos y linked data
  • Docker, Linux y cloud
  • Workflows AI/LLM

Technical signal

Un sistema debe exponer sus riesgos antes de llegar a producción.

No es una API pública. Es una forma compacta de mostrar cómo pensamos el trabajo técnico: nombrar límites, hacer visibles las dependencias y mantener el ownership de release cerca del build.

RequestGET /technical-riskAccept: application/json
Response200 OK
{
  "boundaries": "named early",
  "dependencies": "visible",
  "release_path": "operable",
  "ownership": "senior"
}

Contrato de ejemplo para posicionamiento y pruebas A/B.

Calma técnica

Un stack debería facilitar la producción, no complicarla.

Un stack tiene sentido cuando se puede entender, testear y cambiar - no cuando "funciona una vez" en la demo.

Arquitectura legible

Límites y tradeoffs nombrados en claro - no enterrados en la implementación.

Hábitos de producción

Tests, colas, monitoring, deployment y manejo de fallos son parte del build, no un añadido al final.

Espacio para cambiar

Sistemas que evolucionan con migraciones y releases pequeños - no rewrites.

Rails, cuando la madurez reduce el riesgo. Herramientas nuevas, cuando resuelven el problema con claridad. La elección sigue al trabajo, no a la moda.

Mapa de capacidades

Un mapa de capacidades organizado por la capa que lleva el riesgo.

Cada capa nombra la presión que suele cargar y el movimiento que la resuelve: workflow, UX, contrato API, modelo de datos, cola, despliegue, infraestructura o pipeline IA.

De capa a delivery

Cuando la capa riesgosa es visible, el trabajo necesita un camino seguro a producción.

Las decisiones tecnológicas importan cuando se convierten en una secuencia de delivery: mapear el workflow, validar la parte riesgosa, entregar incrementos útiles, documentar decisiones y mantener producción observable tras el release.

Cuando la capa riesgosa es visible, el trabajo necesita un camino seguro a producción.
PATH
Ver el proceso de delivery
  1. Parte validada
  2. Release pequeño
  3. Rollout observable

FAQ

Preguntas sobre el stack y nuestro enfoque.

¿Por qué Ruby on Rails, y no algo más reciente?

Rails es maduro y predecible donde importa la velocidad de build sin sacrificar calidad. Tomamos herramientas más nuevas cuando de verdad resuelven el problema, no porque estén de moda.

¿Trabajan con el stack legacy que ya tenemos?

Sí. Empezamos leyendo el código y evaluando el riesgo, luego proponemos una modernización por etapas - no un rewrite completo.

¿Usan IA para escribir código?

Sí, donde reduce trabajo repetitivo. Arquitectura, tests y review siguen con el ingeniero senior.

¿Hacen también frontend y mobile, o solo backend?

Ambos. React, TypeScript y Solid.js en frontend, más flujos orientados a mobile cuando el proyecto lo pide.

¿Cómo mantienen producción segura y estable?

Monitoring, tests, deployments controlados y ownership claro de los datos forman parte del build desde el primer día, no de una auditoría al final.