Thinqcraft

Technologie

Un stack qui porte le backend, le frontend, le mobile, les API, les données, l’infrastructure et des changements sûrs après le lancement.

Discuter architectureParler périmètre

Stack

Des fondations matures, un delivery moderne

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

Standards

Du code qui peut être exploité

Tests, monitoring, documentation et gestion des erreurs font partie du build dès le premier jour, pas une réflexion après coup.

Architecture

Des frontières nommées tôt

Ownership des données, contrats d’API, frontières d’intégration - nommés avant de disparaître dans le code.
  • Backend et API
  • Frontend et mobile
  • Données et linked data
  • Docker, Linux et cloud
  • Workflows AI/LLM

Technical signal

Un système doit exposer ses risques avant la production.

Ce n'est pas une API publique. C'est une manière compacte de montrer notre approche: nommer les frontières, rendre les dépendances visibles et garder l'ownership de release près du build.

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

Contrat exemple pour le positionnement et les tests A/B.

Calme technique

Un stack devrait faciliter la production, pas la compliquer.

Un stack a du sens quand il peut être compris, testé et changé - pas quand il « marche une fois » en démo.

Architecture lisible

Frontières et compromis nommés en clair - pas enfouis dans l’implémentation.

Habitudes de production

Tests, queues, monitoring, déploiement et gestion des pannes font partie du build, pas d’une réflexion après coup.

De la place pour changer

Des systèmes qui évoluent par migrations et petits releases - pas des rewrites.

Rails, quand la maturité réduit le risque. Des outils neufs, quand ils résolvent clairement le problème. Le choix suit le travail, pas la mode.

Carte de capacités

Une carte de capacités organisée par la couche qui porte le risque.

Chaque couche nomme la pression qu’elle porte souvent et le mouvement qui la résout : workflow, UX, contrat API, modèle de données, queue, déploiement, infrastructure ou pipeline IA.

De la couche au delivery

Quand la couche risquée est visible, le travail a besoin d’un chemin sûr vers la production.

Les choix technologiques comptent quand ils deviennent une séquence de delivery : cartographier le workflow, valider la tranche risquée, livrer en incréments utiles, documenter les décisions et garder la production observable après le release.

Quand la couche risquée est visible, le travail a besoin d’un chemin sûr vers la production.
PATH
Voir le processus de delivery
  1. Tranche validée
  2. Petit release
  3. Rollout observable

FAQ

Questions sur le stack et notre approche.

Pourquoi Ruby on Rails, pas quelque chose de plus récent ?

Rails est mature et prévisible là où la vitesse de build compte sans sacrifier la qualité. Nous prenons des outils plus récents quand ils résolvent vraiment le problème, pas parce qu’ils sont à la mode.

Travaillez-vous avec le stack legacy que nous avons déjà ?

Oui. Nous commençons par lire le code et évaluer le risque, puis proposons une modernisation par étapes - pas un rewrite complet.

Utilisez-vous l’IA pour écrire du code ?

Oui, là où ça réduit le travail répétitif. Architecture, tests et review restent avec l’ingénieur senior.

Faites-vous aussi frontend et mobile, ou seulement backend ?

Les deux. React, TypeScript et Solid.js côté frontend, plus des flux orientés mobile quand le projet le demande.

Comment gardez-vous la production sûre et stable ?

Monitoring, tests, déploiements contrôlés et ownership clair des données font partie du build dès le premier jour, pas d’un audit à la fin.