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
Webentwicklung bei method64 heißt: 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. Three.js, WebGPU oder spezialisierte 3D-Libraries kommen auf Anfrage rein, nicht als Default. Performance, Accessibility und SEO sind eingebaute Standards. Jede Komponente hat einen Grund. Während der Bauphase bekommst du alle zwei Wochen ein Status-Update mit Screenshots des aktuellen Stands; bei komplexen Web-Apps zusätzlich einen Live-Staging-Link. Die Demo oben ist ein echt verkabelter Button: Variante, Größe und Flags ändern, der JSX-Code aktualisiert sich live mit, kein Bild.
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 (Pre-Launch). 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
Backend-Services entstehen so: 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-Datenbank, Docker für saubere Deploys, Observability von Tag eins. Gewählt wird Tech, die in zwei Jahren noch wartbar ist, statt das letzte Hype-Framework. Während der Bauphase: alle zwei Wochen ein deploybarer Endpoint im Live-Staging plus Status-Update. Du kannst die API direkt mit Postman oder curl gegentesten. Die Demo oben schickt einen Request auf seinen Weg: Client → Gateway → Service → Postgres → Response, jeder Hop mit Header, Body und Latenz.
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, Embedding-basierte Suche, die Volltextsuche schlägt. Wann GPT-5 reicht, wann Claude besser ist, wann Fine-Tuning sinnvoll ist und wann ein simpler Prompt-Template das Problem löst, wird pro Use-Case entschieden. Die Demo oben zeigt den RAG-Flow auf Basis dieser Site, Keyword-Match auf 7 kuratierten Chunks, kein Live-LLM. Echte Pipelines mit Embeddings + Rerank + LLM entstehen in Kundenprojekten. Während der Bauphase: alle zwei Wochen Sample-Outputs und ein Eval-Snapshot im Status-Update, keine Live-UI, weil reine Pipelines meistens keine haben.
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-Flows, die nicht abschrecken. Das wird ab Tag eins mit der richtigen Architektur eingebaut, nicht nachgerüstet. Climactra ist der Beweis dafür: eine voll ausgestattete Plattform, komplett selbst gebaut, mit allem, was eine seriöse SaaS-Plattform haben muss. Während der Bauphase: Live-Staging ab Tag eins, du kannst jederzeit reinklicken und den aktuellen Stand mit Test-Tenants benutzen. Die Demo oben stapelt die vier SaaS-Schichten Auth, Billing, Tenancy und Observability als Ebenen, auf größeren Bildschirmen als 3D-Stapel, den man scroll-getrieben auseinanderzieht.
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-5 wenn Function-Calling-Performance kritisch ist, GPT-5-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.