Thinqcraft

Technologie

Ein Stack, der Backend, Frontend, Mobile, APIs, Daten, Infrastruktur und sichere Änderungen nach dem Launch trägt.

Architektur besprechenScope besprechen

Stack

Reife Fundamente, moderne Delivery

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

Standards

Code, der sich betreiben lässt

Tests, Monitoring, Dokumentation und Fehlerbehandlung gehören von Tag eins zum Build, nicht als Nachgedanke.

Architektur

Grenzen früh benannt

Daten-Ownership, API-Verträge, Integrationsgrenzen - benannt, bevor sie im Code verschwinden.
  • Backend und APIs
  • Frontend und Mobile
  • Daten und Linked Data
  • Docker, Linux und Cloud
  • AI/LLM-Workflows

Technical signal

Ein System sollte Risiken sichtbar machen, bevor sie Produktion erreichen.

Das ist keine öffentliche API. Es ist eine kompakte Form, unsere Arbeitsweise zu zeigen: Grenzen benennen, Abhängigkeiten sichtbar machen und Release Ownership nah am Build halten.

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

Beispielvertrag für Positionierung und A/B-Tests.

Technische Ruhe

Ein Stack sollte die Produktion leichter machen, nicht schwerer.

Ein Stack ergibt Sinn, wenn er verstanden, getestet und verändert werden kann - nicht, wenn er nur einmal in einer Demo „funktioniert".

Lesbare Architektur

Grenzen und Tradeoffs in klarer Sprache benannt - nicht in der Implementierung vergraben.

Produktions-Gewohnheiten

Tests, Queues, Monitoring, Deployment und Fehlerbehandlung gehören zum Build, nicht als Nachgedanke.

Raum für Veränderung

Systeme, die sich über Migrationen und kleine Releases entwickeln - keine Rewrites.

Rails, wenn Reife das Risiko senkt. Neue Tools, wenn sie das Problem klar lösen. Die Wahl folgt der Arbeit, nicht der Mode.

Capability Map

Eine Capability Map nach der Schicht, die das Risiko trägt.

Jede Schicht benennt den Druck, den sie typischerweise trägt, und den Schritt, der ihn löst: Workflow, UX, API-Vertrag, Datenmodell, Queue, Deployment, Infrastruktur oder AI-Pipeline.

Von der Schicht zur Lieferung

Wenn die riskante Schicht sichtbar ist, braucht die Arbeit einen sicheren Produktionspfad.

Technologieentscheidungen zählen erst, wenn daraus eine Delivery-Sequenz wird: Workflow kartieren, riskanten Slice validieren, nützliche Inkremente liefern, Entscheidungen dokumentieren und Produktion nach dem Release beobachtbar halten.

Wenn die riskante Schicht sichtbar ist, braucht die Arbeit einen sicheren Produktionspfad.
PATH
Delivery-Prozess ansehen
  1. Validierter Slice
  2. Kleiner Release
  3. Beobachtbarer Rollout

FAQ

Fragen zum Stack und unserem Ansatz.

Warum Ruby on Rails, nicht etwas Neueres?

Rails ist reif und vorhersehbar, wenn Baugeschwindigkeit zählt, ohne Qualität zu verlieren. Wir greifen zu neueren Tools, wenn sie das Problem tatsächlich lösen, nicht weil sie im Trend liegen.

Arbeiten Sie mit dem Legacy-Stack, den wir schon haben?

Ja. Wir beginnen damit, den Code zu lesen und das Risiko zu bewerten, dann schlagen wir eine Modernisierung in Schritten vor - keinen Rewrite von Grund auf.

Nutzen Sie KI zum Schreiben von Code?

Ja, wo es wiederholbare Arbeit verkürzt. Architektur, Tests und Review bleiben beim Senior Engineer.

Machen Sie auch Frontend und Mobile, oder nur Backend?

Beides. React, TypeScript und Solid.js im Frontend, plus mobile-orientierte Flows, wenn das Projekt es braucht.

Wie halten Sie die Produktion sicher und stabil?

Monitoring, Tests, kontrollierte Deployments und klares Daten-Ownership gehören von Tag eins zum Build, nicht zu einem Audit am Ende.