Frontend, Software-Backends, KI-Pipelines, SaaS-Architektur. In jeder Disziplin tief drin, statt überall an der Oberfläche zu kratzen. Welche du brauchst, wird im Gespräch geklärt. Vier Wochen Hypercare nach jedem Launch sind Standard.
Vier Disziplinen — direkt anklickbar über den Orb oder die Liste.
Toggle die Props links, Code rechts und Preview oben aktualisieren live.
ÜBER
Jede Site wird von Hand gebaut. Keine Page-Builder, keine WordPress-Themes mit 80 Plugins — Frontends mit React, Next.js, GSAP und WebGL. Eine Marketing-Site bleibt unter dem 1.5s-LCP-Standard, eine komplexe Web-App performt wie native Software. Performance, Accessibility und SEO sind eingebaut, nicht nachgerüstet. Während der Bauphase: alle zwei Wochen ein Status-Update mit Screenshots des echten Builds — bei Web-Apps zusätzlich ein Live-Staging-Link.
WIE ES GEBAUT WIRD
01
Verstehen
Ziel, Zielgruppe und Constraints werden im Gespräch geklärt. Fokussierte Gespräche, keine langwierige Discovery-Phase.
02
Architektur
Stack, Hosting und Build-Pipeline werden entschieden. Du verstehst jede Entscheidung und warum sie so getroffen wurde.
03
Bauen
Iterativ in 2-Wochen-Slices. Alle zwei Wochen ein Status-Update mit Screenshots des echten Builds, nicht aus Figma.
04
Launch + Iterate
Production-Deploy mit Monitoring, Performance-Budget, SEO-Audit.
Climactra-Frontend (live). Diese Site selbst ist ebenfalls eine Referenz, bewusst übertrieben, aber jedes Detail hier ließe sich auch konservativer ausführen, wenn dein Projekt das verlangt.
hover über einen Knoten, header / body / latency erscheinen hier
0
Clientt = 0ms
POST /api/orders
{ "items": [...], "currency": "EUR" }
1
Gateway+8ms
JWT verify · rate-limit · route
auth=ok · tenant=hotel-42 · forwarded
status: 200
2
Order Service+34ms
fastify @ node 20
validate(payload) · enqueue(stripe-charge)
status: 200
3
Postgres+11ms
INSERT INTO orders RETURNING *
tenant_id filter via RLS · 1 row · 2.3ms
status: 200
4
Client53ms total
201 Created
{ "id": "ord_8a2f...", "status": "pending" }
status: 201
ÜBER
APIs, die andere Systeme integrieren. Daten-Pipelines, die zuverlässig laufen. Microservices mit klaren Verantwortungen. Node.js und Python je nach Use-Case, PostgreSQL als Default, Docker für saubere Deploys, Observability ab Tag eins. Gewählt wird Technik, die in zwei Jahren noch wartbar ist — nicht das letzte Hype-Framework. Während der Bauphase: alle zwei Wochen ein deploybarer Endpoint im Live-Staging, den du direkt mit Postman oder curl gegentesten kannst.
WIE ES GEBAUT WIRD
01
API-Vertrag
OpenAPI-Spec oder typed-RPC zuerst. Schnittstelle steht bevor Code geschrieben wird.
02
Service-Schnitt
Bounded Contexts, kleine Services, klare Datenbesitz-Regeln. Kein Microservices-Theater wenn ein Monolith reicht.
03
Daten & Caching
Schema-Migrations versioniert, Indexe explizit, Caching-Layer mit klarem Invalidierungs-Pfad.
04
Observability
Logs strukturiert, Metrics korreliert, Traces durch alle Layer. Du siehst Probleme bevor User sie melden.
Climactra Backend-API: Multi-Tenant CO₂-Daten-API mit per-Hotel-Tenant-Isolation, Stripe-Subscriptions, eine eigene Reporting-Engine, die aus Energie-, Wasser-, Abfall- und Belegungsdaten auditierbare Emissions-Berichte generiert. Ein Produkt von method64.
Demo-Modus: Keyword-Match auf 7 hand-kuratierten Chunks, scripted Antwort. Die echte Pipeline mit Embeddings und LLM entsteht in Kundenprojekten.
ÜBER
KI ist hier kein Marketing-Begriff. method64 baut RAG-Pipelines, die wirklich relevante Antworten liefern, Agents mit Tool-Use, die echte Aufgaben übernehmen, und Embedding-Suche, die Volltextsuche schlägt. Wann GPT reicht, wann Claude besser ist, wann Fine-Tuning sinnvoll ist und wann ein simpler Prompt genügt — das wird pro Use-Case entschieden, nicht pauschal. Während der Bauphase: alle zwei Wochen Sample-Outputs und ein Eval-Snapshot im Status-Update.
WIE ES GEBAUT WIRD
01
Use-Case prüfen
Brauchst du wirklich KI? Oft löst eine Volltextsuche, ein Decision-Tree oder eine If-Else das Problem schneller, billiger, vorhersagbarer.
02
Daten + Eval
Ein Eval-Datensatz entsteht BEVOR der erste Prompt geschrieben wird. Sonst weißt du nie ob das System besser wird.
Diese Demo ist eigenständig gebaut, um die Capability zu zeigen. Climactra nutzt aktuell keine LLM-Pipeline, das wird ehrlich kommuniziert. RAG-Pipelines sind bisher in eigenen Prototypen entstanden, das erste produktive Kundenprojekt steht noch aus. Kalkuliert wird entsprechend vorsichtig: Eval-Datensatz, Cost-Cap, Iteration vor Skalierung.
scrolle weiter — die Schichten ziehen sich auseinander
ÜBER
SaaS bauen ist nicht "Web-App mit Login". Es ist Multi-Tenant-Datenisolation, Subscription-Lifecycle, Auth mit Magic-Links und OAuth, Observability über Tenants hinweg und Onboarding, das nicht abschreckt — ab Tag eins richtig eingebaut, nicht nachgerüstet. Climactra ist der Beweis: eine voll ausgestattete Plattform, komplett selbst gebaut. Während der Bauphase: Live-Staging ab Tag eins, in das du jederzeit mit Test-Tenants reinklickst.
WIE ES GEBAUT WIRD
01
Tenant-Modell
Row-Level Security, Schema-pro-Tenant, oder Database-pro-Tenant, abhängig von deinem Compliance- und Scale-Bedarf.
02
Auth + Billing
Auth.js für Sessions, Stripe für Subscriptions, Webhooks idempotent verarbeitet. Edge-Cases (Failed-Payment, Refund, Plan-Change) durchgedacht.
03
Observability
Logs + Metrics + Traces, jeder Eintrag mit tenantId. Du siehst pro Kunde wer warum welches Problem hat.
04
Onboarding + Retention
In-App-Hints, E-Mail-Sequences, Health-Score-Tracking. Die unsexy Disziplin die SaaS profitabel macht.
Für Marketing-Sites: Next.js mit Static Generation oder Vite + Prerendering. Schnell, SEO-stark, niedriger Wartungsaufwand. Für komplexe Web-Apps: Next.js App Router oder Vite-SPA mit React Query, abhängig davon ob SSR Sinn macht oder ob die App nach Login sowieso komplett client-rendered ist. Empfohlen wird kein Tool aus Vorliebe, sondern weil es zum Use-Case passt.
Beides ist möglich. Design entsteht oft im Haus, weil es als integriertes Handwerk verstanden wird, eine Site die in Figma gut aussieht, aber im Browser zerfällt, ist kein Design. Wenn du schon ein Design-System oder Mockups hast, wird das Development gerne übernommen und das Design vorab auf Implementierbarkeit + Performance geprüft.
Standard-Ziel: LCP unter 1.5s auf Mid-Range Mobile, Lighthouse Score 95+ in allen Kategorien. Diese Site hier hat aktuell LCP ≈ 1.2s und Lighthouse 100/98/100/100 (Performance / Accessibility / Best Practices / SEO), als laufendes Beispiel. Gebaut wird mit harten Performance-Budgets als Build-Gate: wenn eine Änderung den Bundle über das Limit schiebt, schlägt der Build fehl.
4 Wochen Hypercare-Phase ist im Standard-Angebot dabei: gleiche Antwortzeit wie sonst (meist am selben Werktag), Logs werden gelesen und Auftauchendes wird gefixt. Danach Pay-per-Use oder optional ein festes Stundenkontingent, kein Mindest-Retainer. Keine "Sicherheits-Updates"-Pakete für Tools, die gar nicht erst eingebaut wurden.
02 · Software & APIs
Vor "Skalierung" kommt "Messung". Services entstehen so, dass exakt sichtbar wird, wann was teuer wird: strukturierte Logs, Latency-Histogramme, DB-Query-Profiling. Skalierung selbst kommt dann gestaffelt: Vertical scale → Read-Replicas → Caching → Service-Sharding. Keine "10x scale"-Architektur für ein Produkt, das noch keinen Product-Market-Fit hat.
Node.js für Web-Backends, APIs mit hohem I/O-Anteil, Real-Time-Features, alles was nahe am Frontend hängt. Python für Daten-Pipelines, ML/AI-Workloads, Skripte mit numerischer Berechnung, alles wo das Ökosystem (NumPy, Pandas, scikit-learn, Hugging Face) den Unterschied macht. Mischen ist okay solange jeder Service eine klare Sprachwahl hat, nicht JS-Code in Python-Service.
Migrations sind versioniert (Prisma, Alembic, oder hand-written SQL je nach Stack), laufen in CI gegen einen Snapshot der Production-DB, und werden in Staging vorab gefahren. Bei großen Schemas: erst neue Spalte hinzufügen (nullable), dann Code auf Read-Both umstellen, dann Backfill, dann Code auf Read-New, dann alte Spalte droppen. Vier Releases statt einem, aber kein Downtime und kein Wochenend-Deploy mit Notfall-Rollback.
Beides möglich. Der Service entsteht typisch so, dass er sich auf Hetzner, Fly.io, Railway, AWS oder eigenem Kubernetes deployen lässt, dein Hosting bleibt deine Wahl. Wenn du komplettes Setup willst: Hetzner + Docker + nginx oder Fly.io von A-Z, inklusive Backups, Monitoring, Alerting.
Unit-Tests für Pure-Logic, Integration-Tests gegen echte Datenbank (Docker Compose im CI), Contract-Tests an API-Boundaries, gelegentlich End-to-End wenn der Workflow es rechtfertigt. Coverage ist kein Ziel, kritische Paths haben 100%, glue code oft 0%. Keine gemockte DB in Tests, die DB-Verhalten verifizieren sollen.
03 · KI-Integrationen
RAG ist meistens die richtige Antwort: deine Daten ändern sich, du brauchst keine eigenen Schreib-Stile, du willst Antworten mit Quellen-Referenz. Fine-Tuning lohnt sich wenn: Daten sind statisch, du brauchst spezifischen Output-Stil oder -Format, oder Latenz/Kosten von Long-Context werden untragbar. Oft ist die Antwort: RAG für Wissen + leichtes Fine-Tuning für Format.
Default: Claude Opus oder Sonnet für Reasoning-heavy Tasks (Code, Agents, komplexes Tool-Use), GPT wenn Function-Calling-Performance kritisch ist, GPT-mini oder Haiku für Volumen-Tasks. Embeddings: OpenAI text-embedding-3-large als Default für Allgemein-Domänen, Voyage AI (voyage-3-large oder Domain-Modelle wie voyage-finance-2 / voyage-code-2) wenn die Domäne spezialisiert ist und Retrieval-Qualität messbar besser wird. Gewählt wird pro Use-Case nach Qualität und Kosten, nicht nach Vendor-Loyalität.
Drei Layer: (1) Retrieval mit Rerank, nur Top-Chunks nach semantic + keyword relevance gehen ins LLM. (2) Prompt instruiert das Modell, "ich weiß nicht" zu antworten wenn die Chunks nichts dazu sagen. (3) Output-Validation: Antworten werden gegen die Source-Chunks geprüft (auch via LLM-as-Judge bei kritischen Domänen). Hallucination-Rate auf 0 ist nicht erreichbar, auf akzeptable Levels schon.
Beide. Q&A-RAG ist der häufigste Use-Case und für viele Probleme genau richtig. Agents (Tool-Use, mehrstufige Planung, externe Aktionen) sind 5x komplexer in Entwicklung + Eval und 10x komplexer in Production-Hardening. Agents entstehen, wenn der Use-Case es wirklich verlangt, z.B. ein Reservierungs-Bot der echte API-Calls macht, nicht ein FAQ-Bot der Marketing-Material zitiert.
04 · SaaS-Entwicklung
Default: Row-Level Security mit tenantId-Spalte und PostgreSQL RLS-Policies. Schnell, einfach, gut indizierbar. Wenn Compliance-Anforderungen es verlangen (z.B. Healthcare): Schema-pro-Tenant. Database-pro-Tenant fast nie, Operativer Overhead steigt linear, ohne dass es einen klaren Vorteil gibt. Performance-Trick: alle Queries gehen durch einen Middleware-Layer der tenantId injiziert, sodass kein Code "vergessen" kann zu filtern.
Auth.js (NextAuth) als Default, fertige OAuth-Provider, schnelles Setup, kein Vendor-Lock-In, selbstgehostet. Clerk oder WorkOS wenn du B2B-Features (SAML, SCIM) brauchst und das Pricing in Ordnung ist. Supabase Auth wird seltener empfohlen, es funktioniert, aber die Migration weg ist mühsam wenn du später Postgres-Self-Hosted willst.
Stark abhängig von Feature-Tiefe und Integrationen, typisch 2-4 Monate für eine fokussierte SaaS mit Auth, Billing, Multi-Tenant-Daten, einem Core-Feature und einfachem Dashboard. KI-Pipelines oder komplexe Datenintegrationen schieben den Plan entsprechend nach hinten. Geliefert wird in 2-Wochen-Slices, du siehst Fortschritt kontinuierlich, kein "alles am Ende". Konkreter Zeitplan entsteht nach dem Erstgespräch wenn Scope und Constraints stehen.
GDPR-konforme SaaS entsteht standardmäßig: Data Processing Agreements, Right-to-Delete-Implementation, EU-Hosting (Hetzner Falkenstein als Default), Audit-Logs, verschlüsselte Backups, Data-Export für User. Climactra ist als italienische SaaS unter EU-Recht entwickelt, die Anforderungen sind aus dem eigenen Aufbau bekannt, nicht nur aus Lehrbüchern.
Wenn die SaaS auf Standard-Tech läuft (Postgres + Node/Python + S3-kompatibler Storage + Docker), ist Hosting-Wechsel ein Zwei-Wochen-Projekt, kein Existenzdrama. Vendor-Lock-In wird bewusst vermieden: keine AWS-only-Services wo Standard-Alternativen existieren. Wenn du AWS RDS willst, fine, aber gebaut wird so, dass Postgres-on-Hetzner ein Switch wäre, nicht ein Rewrite.