# method64

> method64. Websites, software & AI integrations that make a difference. From the first line of code to production launch.

Located in South Tyrol, Italy. Websites, software, AI integrations, from South Tyrol, built to last.

Source: https://method64.com/en

## Services

Frontend, software backends, AI pipelines, SaaS architecture. Deep in each of these disciplines, not skimming the surface anywhere. Which one you need is something to figure out in conversation. Four weeks of hypercare after every launch are standard.

### 01 Web development
*Pixel-perfect websites & web apps*

Every site is built by hand. No page builders, no WordPress themes with 80 plugins — frontends with React, Next.js, GSAP and WebGL. A marketing site stays under the 1.5s LCP standard, a complex web app performs like native software. Performance, accessibility and SEO are built in, not bolted on. During the build phase: a status update with screenshots of the real build every two weeks — for web apps, additionally a live staging link.

**How we build it:**
- **01 Understand** — Goal, audience and constraints get clarified in conversation. Focused talks, not a drawn-out discovery phase.
- **02 Architecture** — Stack, hosting and build pipeline get decided. You understand every decision and why it was made.
- **03 Build** — Iteratively in 2-week slices. Status update with screenshots of the actual build every two weeks, not from Figma.
- **04 Launch + iterate** — Production deploy with monitoring, performance budget, SEO audit.

**STACK:** React 19.2 · Next.js 16.1 · TypeScript 5.5 · Vite 5.3 · GSAP 3.15 · Lenis 1.3

**RELATED PROJECTS:** Climactra frontend (live). This site itself is also a reference, deliberately overdone, but every detail here could be executed more conservatively if your project calls for it.

URL: https://method64.com/en/leistungen#webentwicklung

### 02 Software & APIs
*Backends, microservices, integrations*

APIs that integrate other systems. Data pipelines that run reliably. Microservices with clear responsibilities. Node.js and Python depending on the use case, PostgreSQL as the default, Docker for clean deploys, observability from day one. The pick is tech that's still maintainable in two years — not the latest hype framework. During the build phase: every two weeks a deployable endpoint in live staging you can test directly with Postman or curl.

**How we build it:**
- **01 API contract** — OpenAPI spec or typed-RPC first. The interface stands before code is written.
- **02 Service boundaries** — Bounded contexts, small services, clear data ownership rules. No microservices theatre when a monolith is enough.
- **03 Data & caching** — Schema migrations versioned, indexes explicit, caching layer with a clear invalidation path.
- **04 Observability** — Logs structured, metrics correlated, traces through every layer. You see problems before users report them.

**STACK:** Node.js ≥18.17 · Python 3.12 · Fastify 5 · PostgreSQL 16 · Redis 7 · Docker 27

**RELATED PROJECTS:** Climactra backend API: multi-tenant CO₂ data API with per-hotel tenant isolation, Stripe subscriptions, and a custom reporting engine that generates auditable emissions reports from energy, water, waste and occupancy data. A product by method64.

URL: https://method64.com/en/leistungen#software-apis

### 03 AI integrations
*LLMs, RAG, embeddings, agents*

AI isn't a marketing term here. method64 builds RAG pipelines that deliver genuinely relevant answers, agents with tool-use that take on real tasks, and embedding search that beats full-text. When GPT is enough, when Claude is better, when fine-tuning makes sense and when a simple prompt does the job — that's a per-use-case call, not a blanket one. During the build phase: every two weeks sample outputs and an eval snapshot in the status update.

**How we build it:**
- **01 Validate use case** — Do you really need AI? Often a full-text search, a decision tree or an if-else solves the problem faster, cheaper, more predictably.
- **02 Data + eval** — An eval dataset gets written BEFORE the first prompt. Otherwise you never know if the system is getting better.
- **03 Pipeline** — Embedding → vector search → rerank → LLM call. Each step independently testable and replaceable.
- **04 Production hardening** — Rate limits, cost caps, output validation, fallback on provider outage. AI systems that don't fail when OpenAI goes down.

**STACK:** Claude Anthropic · GPT OpenAI · pgvector 0.8 · OpenAI Embeddings text-embedding-3-large · LangChain 0.3 · Cohere Rerank 3

**RELATED PROJECTS:** This demo is built standalone to show the capability. Climactra currently doesn't use an LLM pipeline, and that gets said honestly. RAG pipelines have so far been built in in-house prototypes; the first productive client project is still ahead. Pricing reflects that, eval dataset, cost cap, iteration before scaling.

URL: https://method64.com/en/leistungen#ki-integrationen

### 04 SaaS development
*Multi-tenant, auth, billing, scale*

Building SaaS isn't "web app with a login". It's multi-tenant data isolation, subscription lifecycle, auth with magic links and OAuth, observability across tenants, and onboarding that doesn't scare people off — built in right from day one, not retrofitted. Climactra is the proof: a fully-featured platform, built entirely in-house. During the build phase: live staging from day one, which you can drop into any time with test tenants.

**How we build it:**
- **01 Tenant model** — Row-level security, schema-per-tenant, or database-per-tenant, depending on your compliance and scale needs.
- **02 Auth + billing** — Auth.js for sessions, Stripe for subscriptions, webhooks processed idempotently. Edge cases (failed payment, refund, plan change) thought through.
- **03 Observability** — Logs + metrics + traces, every entry tagged with tenantId. You see per customer who has which problem and why.
- **04 Onboarding + retention** — In-app hints, email sequences, health-score tracking. The unsexy discipline that makes SaaS profitable.

**STACK:** Next.js 16.1 · PostgreSQL 16 · Auth.js v5 (beta) · Stripe 2025-12 · @sentry/nextjs 10.47 · Nodemailer 7.0

**RELATED PROJECTS:** Climactra (live): multi-tenant CO₂ accounting for hotels. A product by method64, built in South Tyrol, now publicly available.

URL: https://method64.com/en/leistungen#saas-entwicklung

## Climactra

Climactra: multi-tenant SaaS for hotels — auditable CO₂ accounting per GHG Protocol, auto-check for 4 sustainability labels, prioritised measures. Now live.

URL: https://method64.com/en/climactra

### What's missing between Excel and €10,000 consulting.

#### The trigger

Climactra emerged from a market observation in the home region. Hotels in South Tyrol, one of the densest hotel regions in Europe, have been under growing pressure for CO₂ transparency since 2024/25, without the tool spectrum keeping pace. CSRD from 2025 forces large companies into auditable climate data, and indirectly hotels too, via the supply chain. OTAs and tour operators increasingly ask for CO₂ values per overnight stay. Banks ask for ESG data on loan applications. At the same time, the criteria catalogues of the most important certification labels are 60–80 pages of legalistic German, and consulting costs €3,000–€10,000 one-off per year. A software gap addressable in this size range.

> Climactra exists because there's a vast gap between "Excel spreadsheet" and "€10,000 consulting", and because sustainability for hotels has gone from optional to obligatory, but no one has given hoteliers the tool for it.

#### The status quo

Hotels today have three options for their CO₂ accounting, and all three are bad. Option 1: Excel. Twelve months of energy, water, waste and occupancy data in self-built spreadsheets, googling emission factors, applying the GHG Protocol by gut feeling. Result: not certifiable. Option 2: a consultant prepares the data for €3,000–€10,000 per year. The report is dead the moment it's printed. Option 3: do nothing until OTAs visibly penalise or the bank starts asking questions. The actual problem isn't the calculation, it's the translation between three worlds: hotel operating data, regulatory requirements, certification criteria. Climactra performs this translation as software. The external certification itself stays with the accredited auditor — Climactra delivers them the auditable data foundation.

#### Why hotels specifically

Three reasons. First, market: over 50,000 hotels in DACH. South Tyrol as the home market with ~10,000 accommodation businesses one of the densest hotel regions in Europe per capita. Second, pressure: hotels stand at a regulatory and market double-front — CSRD from above, OTA and guest pressure from below. Third, fit: hotels always have the same data sources (electricity, heating, water, occupancy). That's what makes standardised software possible in the first place. Personal angle: growing up as a South Tyrolean in a region where every other family is somehow connected to tourism. What moves hotels here — occupancy figures, energy costs, certification bureaucracy — is familiar from everyday conversations, not from market studies.

#### What sets Climactra apart

Generic ESG platforms, food-specific tools and consultant software for audits don't address hospitality as a holistic product. Climactra is designed hotel-specific: the HCMI standard is built in natively, CO₂ per room night and per guest night. The metrics OTAs and tour operators actually ask for. Certification is part of the core function, not a bolt-on to the accounting. Four labels (Nachhaltigkeitslabel ST, Green Key, GreenSign, EU Ecolabel) integrated as auto-check: the system acts as a pilot through the certification process up to the external audit. The accuracy is bookkeeping-grade: emission factors with validFrom versioning, IPCC-compliant biomass treatment, HICP inflation adjustment for spend-based method, scope-2 dual reporting. Measures come with amortisation time and score impact, so climate action lands in the budget plan instead of the moral discourse.

> Climactra closes the gap between Excel spreadsheet and the annual consultant data prep. The external audit by the accredited auditor stays — Climactra just makes it significantly cheaper.

### What hoteliers see in Climactra

A look inside the current build. What used to be Excel marathon, consulting bill and certification bureaucracy now runs in one cockpit.

- **Dashboard** — Overview dashboard with sustainability score, scope 1/2/3 accounting and certification readiness for four labels at a glance. The starting point: score, scope 1/2/3 accounting and label readiness at a glance, before clicking into anything.
- **Monthly activity entry** — Input form for electricity, heating oil, gas, water, waste and occupancy with live plausibility checks and certified emission factors. What the tax adviser used to do in February now happens in five minutes per month.
- **Certification auto-check** — Auto-check for Green Key, GreenSign, EU Ecolabel and Nachhaltigkeitslabel Südtirol, the system shows which criteria are already met. Certification turns from mystery to checklist.
- **Measures with ROI simulation** — Prioritised list of concrete measures with expected CO₂ effect, score impact and amortisation time in euros. From LED retrofit to heat pump: climate protection becomes a business case, not a duty topic.
- **Reports & label exports** — Six print-ready PDF reports plus four label exports, GHG-Protocol-compliant and auditable. One click generates the data report the consultant typically charges €5,000 per year for. The final audit stamp still comes from the accredited auditor.

### One price. Per hotel. Per month.

89€/month · per hotel · billed annually (€1,068)

**Included:**
- Complete CO₂ accounting (Scope 1, 2, 3)
- Auto-check for 4 certification labels
- ROI-prioritised measure recommendations
- Six print-ready PDF reports + 4 label exports
- CSRD-compliant data, GHG-Protocol auditable
- Monthly data entry in 5 minutes

## Process

How method64 builds. Discovery without an 80-page briefing PDF, architecture before the first line of code, the first increment live in week two, hypercare instead of "good luck!" at launch.

URL: https://method64.com/en/prozess

### 01 Understand
*Discovery without theatre*

Sit down together, clarify what it's actually about. No discovery workshop with 12 Post-It colours, no 60-bullet briefing PDF, focused conversations with the people who have the problem. Listen more than talk, ask for examples instead of wishes, note the differences between what you say and what surfaces when walking along with you. By the end of this phase it's clear what you really need, sometimes that's not what was on the table in the first conversation.

**METHODS:**
- Focused stakeholder conversations (max. 45 min, one question per answer)
- Constraint mapping (budget, deadline, regulatory, technical)
- User quotes noted verbatim, not paraphrased

**WHAT COMES OUT:**
- A short discovery document: what was heard, what is recommended, what won't be built
- Initial scope sketch with phase proposal

**WHAT SETS METHOD64 APART:** No is also an answer. If the problem is solved by a spreadsheet template, a spreadsheet template is what gets recommended. An agency that sees every problem as a software project has an incentive problem.

### 02 Architecture
*System design + API contracts before code*

Before the first line of code is written, the system is on paper. Which services? Which data models? Which integrations? Decisions get made here: what is built, what is bought, what is left out. API contracts are written first, frontend and backend can then work in parallel without blocking each other. Schema migration strategy, auth model, hosting topology and performance budget are settled before the first function exists.

**METHODS:**
- API contract (OpenAPI, GraphQL SDL or typed-RPC), before code is written
- Data model + migration strategy
- Performance budget per page and endpoint

**WHAT COMES OUT:**
- System sketch + API contract + data model
- Slice plan for the build phase

**WHAT SETS METHOD64 APART:** Three hours at the whiteboard beat six months at the refactor. Architecture decisions are documented in the repo, traceable, without you having to call.

### 03 Build
*2-week slices, deployable increments*

Every two weeks a working slice ships, with a short status update at the end, what was built, what comes next, where it's stuck; weekly on request. What you see depends on the project: a live staging link for SaaS and web apps, screenshots for marketing sites, sample outputs and eval snapshots for AI integrations. Every slice is deployable to production. Stop after eight weeks and you'd have four working increments, not zero half-finished ones. Tests on the critical paths, not blind 100% coverage.

**METHODS:**
- Every two weeks a deployable, tested slice
- Tests on the critical paths, automated build and performance gates
- Status update every two weeks, live staging, screenshots or sample outputs depending on the project

**WHAT COMES OUT:**
- Working, deployable code at the end of every slice
- Tests on the critical paths, not blind 100% coverage
- Regular status updates instead of a big-bang demo at the end

**WHAT SETS METHOD64 APART:** Everything is built so that stopping after any slice is possible without damage. No 6-month big-bang sprints. If after slice 4 the assumption turns out wrong, the plan changes, and you haven't sunk 200k.

### 04 Launch + Iterate
*Deploy + hypercare + monitoring*

Launch isn't the goal, the first day users actually work with the product is. Deployment runs via build gate + Docker, with a health check and a git-revert rollback path, not with "everyone cross your fingers". Four weeks of hypercare are in the standard offer: same response time as before (usually the same business day), logs are read and what surfaces gets fixed. Monitoring is there from day one, not "set up after launch". After the four weeks the decision is shared: pay-per-use, fixed hour budget, or you take over yourself and method64 is in lift-out mode.

**METHODS:**
- Build gate: TypeScript + bundle budget + smoke tests before deploy
- Monitoring + error tracking from day one, with user context
- Four weeks of hypercare, same response time as before

**WHAT COMES OUT:**
- Production deploy with health checks + git-revert rollback
- Four weeks of hypercare at no extra cost
- Lift-out documentation if your team takes over

**WHAT SETS METHOD64 APART:** No 12-month maintenance contracts with "security updates" for tools that were never built in to begin with. Maintenance is transparent or it doesn't exist.

## Principles

What guides every decision. Per principle the thesis, a concrete example from the work, and what it costs, because every principle has a price. Hover shows the variant that doesn't get chosen.

URL: https://method64.com/en/prinzipien

### 01 method64 builds its own software.
*An own SaaS platform, without external investors.*

Anti-variant: ~~Selling white-label SaaS from the reseller catalog.~~

**WHERE THIS SHOWS UP:**
- Climactra: a SaaS platform for CO₂ accounting in the hotel sector. From the data model to the invoicing engine, all built in-house, without external investors.
- This site itself runs on an own Hetzner server, with an own form backend, with self-hosted Umami. No Vercel, no Webflow, no form builder.

**WHAT IT COSTS:** Affiliate margins and quick launches are off the table. Spinning up a white-label CRM is a weekend, Climactra is a year. But method64 never recommends something it hasn't run itself.

### 02 Whoever plans, builds.
*No handover between sales and devs.*

Anti-variant: ~~Sales pitches, account manager mediates, then handover to devs.~~

**WHERE THIS SHOWS UP:**
- In the first call sits the person who will write your code. No slides from a sales deck, no discovery-workshop choreography.
- Architecture decisions are made by whoever implements them, not a solution architect who hands the ticket off afterwards.

**WHAT IT COSTS:** method64 doesn't scale through pyramids. One active build phase at a time, without five parallel projects. Anyone who wants an agency that sends a different account manager to every meeting is in the wrong place.

### 03 No is also an answer.
*Better no fee than a useless product.*

Anti-variant: ~~Every contract is a good contract.~~

**WHERE THIS SHOWS UP:**
- Requests get declined when the problem is solved by an Excel template. Better no fee than a product nobody needs.
- When the tech problem doesn't fit the stack, the request gets referred on, even to colleagues outside the own pipeline.

**WHAT IT COSTS:** Revenue that other agencies would take. Saying "no" costs real money, and it's the most important investment in recommendation quality.

### 04 South Tyrol, not Silicon Valley.
*Small, local, no VC pressure.*

Anti-variant: ~~As big as possible, as fast as possible, VC in the pitch.~~

**WHERE THIS SHOWS UP:**
- Set up small, no overhead. No office, no marketing manager, no investor wanting quarterly growth.
- Hosting in the EU (Hetzner Falkenstein), mail at IONOS, analytics self-hosted. GDPR is built in, not patched in afterwards.

**WHAT IT COSTS:** method64 will never be a 50-person agency. Big clients who need ten parallel streams aren't the market. Growth stays slow and intentionally small.

### 05 Architecture before the first line of code.
*Data model before code, important decisions in writing.*

Anti-variant: ~~Just start, refactor later.~~

**WHERE THIS SHOWS UP:**
- Data model, API contracts and deployment strategy are settled before the first line of code is written. Frontend and backend can work in parallel without blocking each other.
- Important decisions noted in writing, six months in, you still know why the DB is Postgres and not Mongo.

**WHAT IT COSTS:** The first one or two weeks look like nothing is happening. Anyone who wants weekly UI mockups suffers. Anyone who still has the same data model in month six wins.

### 06 Every week a result.
*Deployable slices instead of big-bang demos.*

Anti-variant: ~~Six-month big-bang sprint, then demo on the deadline.~~

**WHERE THIS SHOWS UP:**
- Every two weeks a deployable slice plus status update on the current state, no mockup, no demo stub. Should it stop after eight weeks, you'd have four working increments, not zero half-finished ones.
- Feature flags + canary deploys instead of "everyone cross your fingers". If a feature doesn't work, it gets switched off, no rollback drama.

**WHAT IT COSTS:** Slice planning and status updates cost time that big-bang sprints seem to save. Pure code time is lower than for teams that only deliver at the end. In return there's no "it'll work out, trust us".

### 07 After launch, it really starts.
*Four weeks of hypercare, then pay-per-use.*

Anti-variant: ~~Hand-off to "the maintenance contract", then radio silence.~~

**WHERE THIS SHOWS UP:**
- Four weeks of hypercare in the standard offer. Same response time as before (usually the same business day), logs get read and fixes ship.
- Pay-per-use as default maintenance. You reach out when something's up; billing is by the hour. No minimum retainer for nothing.

**WHAT IT COSTS:** Billing on the first of the month isn't an option. Cashflow is more irregular than at agencies with fixed maintenance contracts. In return, customers come back, because they don't pay for silence.

## Behind method64

**Jacob Wieser** — Founder · Solo Engineer

URL: https://method64.com/en/uber-mich

Behind method64 there's one person. No agency, no account manager in between. From the first conversation to the server that runs at night, all with me.

JENESIEN, SOUTH TYROL · DE / IT / EN · B.SC. INFORMATICS & DIGITAL BUSINESS MGMT.

### The name

- **method** — the way something gets built. With a system, step by step, never by chance.
- **64** — the number that runs in the background of every piece of software, every smartphone, every screen. As natural to the digital world as 24 is to the day or 7 to the week.

### Background & approach

#### STUDIES

I grew up in Jenesien, above Bolzano, and studied Informatics and Management of Digital Business at the Free University of Bozen-Bolzano. During those years, it became clear to me bit by bit what really pulls me toward software. On one hand, the directness: an idea, some code, Enter, and the result is right there. On the other, the leverage: that with a manageable amount of well-written code, you can solve problems someone used to spend hours or days doing manually.

#### AUTOMATION

That's exactly where what attracts me most about building software comes in: automation. Things that are set up cleanly once and then run on their own. Work that used to come up every day or every week is simply gone after the setup. A monthly report that goes out without anyone pressing a button, a database that maintains itself overnight, a form whose entries automatically land in the right system. Three small setups, three places no one has to touch manually ever again.

#### USABILITY

Equally important to me is that the software stays user-friendly. By that I don't mean grand design concepts, but concrete small things you notice in daily use. An app that someone opening it for the first time can also operate, without having to ask anywhere. A validation error that doesn't just say "invalid" but explains directly what's wrong. These details are often the difference between software you tolerate and software you actually enjoy using.

#### AESTHETICS

And then there's the matter of how something looks. A website that doesn't just work but stops you for a moment when you first open it, because the layout, the motion, and the typography actually fit together and don't come from a stock template you've seen on ten other sites. Fast, clean, beautiful, all three together, that's my standard.

### At a glance

- **DIRECT LINE:** No account manager, no ticket system. You write to me directly.
- **ARCHITECTURE TO DEPLOY:** Concept, code, infrastructure, maintenance, no external dependencies or handovers.
- **TRILINGUAL:** Projects and communication in German, Italian or English.
- **SOUTH TYROL ROOTS:** Based in Jenesien / San Genesio Atesino, above Bolzano. Local mindset, international stack.

## Interactive Features per Page

What the site actually does. These capabilities are not visible in the prerendered HTML — they activate after browser hydration.

### Home (`/`)

- **LiveBuilder Hero**: 4-phase sequence (`init` → `reveal` → `complete`). Code panel types React/JSX line by line, preview panel renders the corresponding UI in sync. Variable typing speed for realism, cursor blinks and pauses.
- **WebGL Hero Background**: Fragment shader computes an organic colour field per frame in accent + violet + cyan. Reacts to mouse position. Not a video, loads nothing extra.
- **SitePipeline (this site, in 7 stations)**: Vertical scroll-driven SVG path with a pulsing tip. Anchor dots light up as the fill passes them. Cards flip on click and reveal tech-proof on the back. Stations 6 + 7 fetch live build stats from `/build-stats.json`.
- **Editorial Section**: Magazine layout with Source Serif drop-cap, sticky headline on the left, pulled-out italic blockquote.
- **AboutSolo Teaser**: Portrait + italic hook (Source Serif) + 4-fact strip. Click opens /uber-mich.
- **CTA Section**: Mouse-follow radial glow as background, large closing headline.
- **Echo**: Mini code loop, 4 snippets cycle with typed result outputs (build time, RAG query, deploy).
- **HeroQuickCTA**: Appears after LiveBuilder phase 4. Sticky until the user scrolls.

### Services (`/leistungen`)

- **IndexHero**: 4 service titles as oversized typography. Hover state dims non-hovered siblings via CSS sibling selectors. Click scrolls to subsection.
- **Subsection header as CTA**: Each of the 4 service titles is clickable, routes to `/kontakt?service=<id>`. Arrow appears on hover.
- **ComponentPlayground** (`#webentwicklung`): Real-wired button demo. Left column: props controls (variant, size, label, flags). Right column shows live-updated JSX. Top renders the real button. Pure React state, no eval, no iframe.
- **RequestSequence** (`#software-apis`): SVG topology Client → Gateway → Service → Postgres → Response. Animated dot loops the path. Hover on a hop shows header/body/latency detail. Mobile fallback: vertical card list with all details expanded.
- **MiniRAGDemo** (`#ki-integrationen`): 4-stage pipeline (embed → search → rerank → generate) with dot indicator. User types a question or clicks a sample chip; retrieval runs against 7 hand-written knowledge chunks via keyword overlap (TF-IDF-lite); answer streams char-by-char. Demo logic, not a live LLM. Easter egg: hovering "rag" spreads the letters.
- **StackedLayers** (`#saas-entwicklung`): Four 3D glass layers (Auth, Billing, Tenancy, Observability), stacked with `preserve-3d` + rotation. Hover moves one layer +90px forward, others dim to 35% opacity. Mobile: static vertical stack.
- **FAQ accordion**: 18 Q&As grouped by service. Inline JSON-LD `FAQPage` schema so LLMs can read without JS.

### Process (`/prozess`)

- **PageHero**: 4-phase stepper with pulsing dots, scroll-aware active state.
- **ProzessStudio**: Scroll-driven 780vh sequence with 4 stations. Each station is its own visual micro-world: **Pinnwand** (sticky notes with polaroid caption + mouse-tilt), **Blueprint** (technical diagram with API banner and zones), **Inventory** (method cards + tools with mouse tilt), **MissionControl** (live build metrics + status strip).
- **Free-explore endgame**: After station 4 a pan/zoom mode unlocks for the whole sequence. Drag to pan, wheel to zoom, keyboard shortcuts (arrows, +/-, R for reset).
- **MiniMap**: Floating overlay bottom-right shows the 4 stations to scale. Click teleports to a station.
- **ConnectionLines**: SVG connections between stations.
- **Mobile fallback** (`StudioMobile`): Vertical stack, each station its own page section. No free-explore.

### Principles (`/prinzipien`)

- **PillarCarousel**: 7 principles arranged in a 3D orbit. Scroll-driven tier scaling. Active principle moves forward, others shrink.
- **AntiVariantOverlay**: One "what we don't do" reveal per principle. Hover or scroll-in shows the anti-variant. SessionStorage `prinzipien_demo_seen` gates an auto-demo to once per session.
- **PrincipleSection**: Each principle gets its own narrative section with examples, trade-offs, and a real anecdote.
- **Mobile fallback**: Carousel becomes a vertical stack, all anti-variants directly visible.

### Tech-Stack (`/tech-stack`)

- **LayerSection × 5**: Frontend, API & Backend, Data, AI & ML, Infrastructure.
- **ToolCard**: Per tool: name, version, 1-sentence rationale. Hover triggers the ConnectionOverlay.
- **ConnectionOverlay**: Hovering a tool lights up related tools — connections are defined as a static graph map in `connections.ts`. Example: hovering "Docker" highlights Hetzner, nginx, Caddy, systemd, Postgres, Redis, Umami.
- **AntiPatterns**: 10 tools we deliberately don't use, with rationale.
- **Auto-demo**: On first visit (gated via SessionStorage `techstack_demo_seen`) one tool is programmatically "hovered" for 2 seconds to demonstrate the connection mechanic.

### Climactra (`/climactra`)

- **Hero dashboard preview**: Large screenshot of the Climactra dashboard. Click opens lightbox.
- **Highlights cards**: 4 cards (Multilingual, GHG-compliant, Label-ready, EU-hosted).
- **Demo carousel**: 5 product screenshots (Dashboard, Data entry, Certification auto-check, Measures, Reports) with narrative caption per screen. Drag-to-swipe, keyboard navigation.
- **Lightbox**: Click on screenshot opens full-screen preview with zoom + pan, keyboard navigation (arrows + Esc).
- **Story section**: 4 narrative blocks (Trigger, Status quo, Why hotels, What sets Climactra apart).
- **Tech-Stack block**: 9-layer stack overview specific to Climactra (~50 tools).
- **Pricing with countdown**: Founding-member €59/month (vs €89), locked in for good, until 2026-08-31. Countdown in days/hours/minutes/seconds, ticks every second. After deadline an automatic state switch to "Founding-member ended".
- **Launch CTA**: Primary button to the live app (climactra.com) + secondary mailto link for enquiries (prefilled subject + body, no server persistence).

### Contact (`/kontakt`)

- **ConversationFlow**: 5-step chat-style form: (1) service selection, (2) project description (min. 30 chars), (3) timing, (4) budget, (5) contact details. Auto-scroll to current step, back/next navigation.
- **Honeypot field**: Invisible field bots will fill, blocks submission.
- **Mount-time check**: Submissions under 3 seconds register as bot behaviour and are blocked.
- **ServerPulse animation**: On submit a pulse strip animates through: `request → encode → transmit · TLS → deliver · ionos-smtp → ack · received`.
- **Form backend**: `POST /api/contact` to our own Fastify backend on the same Hetzner server, same-origin.

### About me (`/uber-mich`)

- **NameWordmark**: SVG wordmark with a decorative layout.
- **MetaChips**: Mono chips for location (Jenesien, South Tyrol · DE/IT/EN) and degree (B.Sc. Informatics and Management of Digital Business).
- **NameStory**: Explanation of "method" + "64" for non-technical visitors.
- **4-section bio**: Studies → Automation → Usability → Aesthetics, each section with a section label.

### Site-wide

- **Custom cursor**: Two elements — small dot follows the mouse exactly, ring follows with 0.12 lerp. Magnetic attraction to elements with `data-magnet`. Hover state (scale 2.5×), click state (scale 0.5×). Disabled on touch devices.
- **Nav**: Fixed top, initially transparent, after 80px scroll switches to `backdrop-filter: blur(20px)`. Language switcher DE/IT/EN.
- **PageTransition**: Fade transition between routes.
- **Lenis smooth scroll**: Site-wide smooth scroll with `prefers-reduced-motion` respect.
- **Reveal**: Intersection-Observer wrapper for scroll reveals (60px rootMargin, 0.8s ease-out, fires once).
- **KineticText**: Per-word stagger animation, used in hero headline reveal.

### What the site explicitly does NOT do

- No cookies
- No 3rd-party tracking (no Google Analytics, no Vercel Analytics, no Pixel)
- No 3rd-party fonts (all self-hosted)
- No 3rd-party CDNs
- No cookie banner (not required, see privacy policy §8 + §10)
- Analytics: Umami self-hosted at `analytics.method64.com`, cookieless, hashed IP with daily-rotating salt

## Tech Stack

From the pixel in the browser to the machine in the datacenter, every layer with the rationale why.

URL: https://method64.com/en/tech-stack

### 01 Frontend & UI — What runs in the browser

The frontend is the layer with the most micro-decisions, typographic hierarchy, animation easing, loading states, accessibility. Stack choice: uncompromisingly React-centric, because it's the only ecosystem where all capabilities (3D, animation, accessibility, forms, routing) are in one hand. TypeScript everywhere, no "let's just throw a bit of JS in there". Tailwind instead of CSS-in-JS solutions, because it disappears at build time and costs nothing in the browser. Three.js and GSAP only where it's really about interactive 3D or choreographed sequences, otherwise CSS.

- **React (18 / 19.2)**: Component model that has held up for 12 years. The method64 site itself runs on React 18 with Vite, Climactra and client projects on Next.js with React 19.2, where Concurrent Features and the React Compiler actually pay off.
- **TypeScript (5.5)**: Strict mode everywhere, a whole class of runtime errors disappears as you type.
- **Next.js (16.1)**: Server Components, App Router, built-in routing + i18n. In use wherever SSR or multi-tenancy are required (Climactra), this site gets by with Vite + a prerenderer.
- **Vite (5.3)**: Dev server in under a second, production build in under ten. Webpack tried for five years to deliver this, Vite just did it.
- **React Router (6)**: When Vite is used instead of Next.js, React Router is the honest, independent routing, no hidden magic conventions.
- **Tailwind CSS (v4)**: Utility-first saves hundreds of custom CSS classes per project. The build output contains only what's actually used.
- **CSS Modules**: For component-specific styling outside the Tailwind world, no class collisions, no BEM bureaucracy.
- **shadcn/ui**: Components as source code, not as an npm package, changeable instead of fighting the API.
- **GSAP (3.15)**: For timeline-driven sequences with precise easing, where CSS transitions don't give enough control and JS animation libs have too much overhead.
- **Three.js (r170)**: WebGL without the boilerplate. Used when 3D really makes sense, otherwise it stays out, because it's a bundle heavyweight.
- **Lenis (1.3)**: Smooth scroll without the typical native bugs, and with `prefers-reduced-motion` respect out of the box.
- **Lucide React (0.577)**: Icon family that actually looks consistent. Imported individually, not the whole library bundle.
- **Webfonts (self-hosted)**: Plus Jakarta Sans, Inter, JetBrains Mono, Source Serif 4, self-hosted, woff2, font-display:swap. No Google tracking, no third DNS lookup.

### 02 API & Backend Services — What sits between browser and database

The API layer builds contracts, not endpoints. Every route has a Zod schema, every response is typed, frontend and backend speak the same language, guaranteed by the compiler. Fastify instead of Express, because schemas get written anyway and Fastify uses them for performance. Python comes in when ML / embeddings / data pipelines are involved, Node isn't the right tool there.

- **Node.js (≥18.17)**: Default runtime for everything JavaScript-side. LTS branch, no edge-cutting.
- **Python (3.12)**: When ML, data engineering or embeddings are involved, everything there has a better-maintained Python path than the JS counterpart.
- **Fastify (5)**: Schema-driven, fast, small. Express replacement, since validation and JSON schemas are written anyway.
- **Zod (4.3)**: One schema definition for validation, TypeScript types and JSON schema export, DRY without a generator pipeline.
- **Nodemailer (7.0)**: SMTP client that has worked precisely for 16 years. Standard SMTP means: changing providers is config, not a rewrite, no lock-in like with Resend or SendGrid and their proprietary HTTP APIs.
- **next-intl (4.8)**: i18n in Next.js apps with Server Components support, no separate provider layer in the tree.

### 03 Data, Auth & Payments — What ends up on disk, and who gets in

The data layer is conservative, because migrations hurt and auth bugs cost trust. Postgres as default, no vendor DB. Prisma as ORM, because the generated types connect frontend to database. pgvector instead of a standalone vector database, one DB per project is enough. Auth.js, because it's auditable and doesn't have to grow into vendor lock-in with Auth0 / Clerk.

- **PostgreSQL (16)**: A relational DB that has been maturing for around 40 years. JSONB, full-text, pgvector, all in one engine.
- **Prisma (6.19)**: Schema as single source of truth, migrations versioned, types generated automatically. Simply the best DX in the Node ecosystem.
- **pgvector (0.8)**: Vector search directly in Postgres, no Pinecone pricing model, no second database.
- **Redis (7)**: In-memory caching and rate limiting, when Postgres gets too many writes for ephemeral data.
- **Auth.js (v5 (beta))**: Auth without a vendor account (formerly NextAuth.js). Self-hostable, OAuth-provider-flexible, no pricing cliff at MAU growth. v5 has been stable in the beta channel for months, good enough for production.
- **bcryptjs (3.0)**: Password hashing that doesn't depend on a C lib, runs everywhere, including serverless environments.
- **Stripe (2025-12)**: Payment layer with the best developer experience. Webhook-first architecture matches the one used here. For Italian customers the bridge to SdI goes via Aruba Fatturazione Elettronica, Stripe charges, Aruba issues the electronic invoice.
- **@react-pdf/renderer + ExcelJS**: PDF and Excel exports generated server-side, Climactra produces six print-ready climate reports and four certification-label exports with this. Templates live in code, not in a designer tool, the same diff-able versioning as the rest of the app.

### 04 AI & ML — What understands language and computes embeddings

Model selection is pragmatic: Claude for long contexts and code, GPT for cheap bulk calls, embeddings from OpenAI because they still deliver the best price-performance semantically. LangChain as glue, not as framework religion, but as a library used selectively when standard patterns repeat. No lock-in to one provider, everything via Anthropic / OpenAI directly, no aggregator in between.

- **Claude (Anthropic)**: Long-context, code-reasoning and tool-use at a level GPT will be chewing on for a while. Default for everything that needs accuracy over speed.
- **GPT (OpenAI)**: When latency and cost matter, e.g. bulk classification or simple generation in high volume.
- **OpenAI Embeddings (text-embedding-3-large)**: Best embedding quality for RAG, combined with pgvector as storage.
- **Cohere Rerank (3)**: Reranking stage between vector search and LLM. Measurably lifts RAG answer quality, about two dollars per thousand queries, negligible against the LLM costs behind it.
- **LangChain (0.3)**: Selectively for standard patterns like retrieval chains. Not as a framework wrap of all LLM calls.

### 05 Infrastructure, Observability & DevTools — Where it runs and how it gets watched

Infra is deliberately unspectacular: Docker for reproducibility, Hetzner instead of hyperscalers because the orders of magnitude fit, nginx instead of application routers because it has run without drama for 20 years. Observability in two stages, Sentry for errors with stack trace, Umami for pageviews without cookies. Deploy manually via SSH + git pull + docker compose, at this scale faster than a pipeline, no second provider needed.

- **Docker + Compose**: Reproducible environments, no "runs on my machine" debates. Compose for local multi-service setups.
- **Hetzner Cloud**: Real VMs in German datacenters, half the price of AWS for comparable specs. No vendor lock-in.
- **nginx**: Reverse proxy, TLS termination, static hosting, one config, three jobs. Default for the method64 site and any setup where a classic web server is called for.
- **Caddy (2.8)**: Reverse proxy with auto-Let's-Encrypt in container setups. In Climactra it saves a config layer, same job as nginx, different trade-off.
- **systemd**: Service management without daemon soap opera. Auto-restart, logs in journald, standard on every Linux.
- **IONOS (SMTP+DNS)**: EU-hosted infrastructure for the own mailboxes and DNS records. Established enough that banks and authorities use it. For product volume (Climactra), Amazon SES in eu-central-1 is used depending on scale.
- **@sentry/nextjs (10.47)**: Errors with stack trace, source-map-resolved, problems surface before users report them.
- **Umami (self-hosted)**: Pageview statistics without cookies, without IP storage, GDPR-compliant. Self-hosted on the own Hetzner server.
- **Vitest (4.1)**: Test runner that inherits Vite configs, no double setup. Faster than Jest, same Jest API.
- **ESLint (9)**: Lint layer that automatically enforces project-wide code conventions, strict rules, no "warning" loopholes.
- **tsx (4.21)**: Run TypeScript files directly from Node, build scripts and migration tools work without a separate ts-compile step.

### WHAT'S NOT IN USE

A stack decision isn't just what's in. Just as important: what stays out, and why.

- **WordPress**: Maintenance overhead for themes, plugins and security patches grows disproportionately with site complexity. For a marketing site that can be served as static prerendered HTML, it's over-dimensioned.
- **Bootstrap**: Tailwind has been the better tool for utility-oriented styling for years. Bootstrap class sets are rigid, the override effort for a distinctive design is disproportionate.
- **jQuery**: Browsers now have native APIs for DOM manipulation, event handling and HTTP requests. The ~30 kB footprint no longer pays off.
- **Webpack (directly configured)**: Configuration is involved and build times are noticeably slower than Vite. For new projects, Vite is the more pragmatic choice.
- **MongoDB**: The schemaless idea just shifts the schema burden from the database to the application layer. Postgres with JSONB columns delivers the same flexibility without the trade-off on transactions and joins.
- **Redux / Redux Toolkit**: Global state management is unnecessary in most apps. React state, Context and server-state libraries like TanStack Query solve the same with significantly less boilerplate.
- **Vercel (hosting)**: Very good DX, but edge function pricing scales quickly beyond what a dedicated server costs. Next.js gets deployed directly on own hardware.
- **AWS Amplify**: An additional abstraction over AWS services that creates more problems than it solves under real complexity. When AWS is the right call, going directly with the primitive services works better.
- **Page-Builders (Webflow / framer.com)**: Visual drag-and-drop tools make performance optimisation, custom logic and versioning harder. For non-trivial sites that hits limits a code-first approach doesn't have.
- **No-code backends (Supabase Auth)**: Useful for prototypes, but lock-in problems surface quickly in production. Auth logic belongs in own code so it stays auditable and migratable.

## FAQ

What clients ask before the first call.

### Which framework gets recommended for marketing sites vs web apps?

For marketing sites: Next.js with static generation or Vite + prerendering. Fast, SEO-strong, low maintenance. For complex web apps: Next.js App Router or a Vite SPA with React Query, depending on whether SSR makes sense or whether the app is fully client-rendered after login anyway. A tool gets recommended because it fits the use case, not out of preference.

### Is design-only or development-only an option?

Both are possible. Design often happens in-house because it's one integrated craft, a site that looks good in Figma but falls apart in the browser isn't design. If you already have a design system or mockups, development gets handed over gladly and the design gets checked upfront for implementability + performance.

### How fast does a site load?

Standard target: LCP under 1.5s on mid-range mobile, Lighthouse score 95+ across all categories. This site currently has LCP ≈ 1.2s and Lighthouse 100/98/100/100 (Performance / Accessibility / Best Practices / SEO), as a running example. Sites get built with hard performance budgets as a build gate: if a change pushes the bundle over the limit, the build fails.

### What happens after launch?

A 4-week hypercare phase is included in the standard offer: same response time as before (usually the same business day), logs get read and issues get fixed as they come up. Afterwards pay-per-use or optionally a fixed hour budget, no minimum retainer. No "security update" packages for tools that were never built in to begin with.

### How does scalability get built into a new service?

Before "scaling" comes "measuring". Services get built so that it's exactly visible when what gets expensive, structured logs, latency histograms, DB query profiling. Scaling itself then comes in stages: vertical scale → read replicas → caching → service sharding. No "10x scale" architecture for a product that doesn't have product-market fit yet.

### Node.js or Python, when which?

Node.js for web backends, APIs with a high I/O share, real-time features, anything close to the frontend. Python for data pipelines, ML/AI workloads, scripts with numerical computation, anything where the ecosystem (NumPy, Pandas, scikit-learn, Hugging Face) makes the difference. Mixing is fine as long as every service has a clear language choice, not JS code in a Python service.

### How do database migrations stay safe?

Migrations are versioned (Prisma, Alembic, or hand-written SQL depending on the stack), run in CI against a snapshot of the production DB, and are pre-run in staging. For large schemas: first add a new column (nullable), then switch code to read both, then backfill, then switch code to read new, then drop the old column. Four releases instead of one, but no downtime and no weekend deploy with emergency rollback.

### Does DevOps come included or should I handle it?

Both possible. The service typically gets built so it can deploy on Hetzner, Fly.io, Railway, AWS or your own Kubernetes, your hosting stays your choice. If you want a complete setup: Hetzner + Docker + nginx or Fly.io end-to-end, including backups, monitoring, alerting.

### How are backend services tested?

Unit tests for pure logic, integration tests against a real database (Docker Compose in CI), contract tests at API boundaries, occasional end-to-end when the workflow justifies it. Coverage isn't a goal, critical paths have 100%, glue code often 0%. No mocked DB in tests that should verify DB behaviour.

### When is fine-tuning worth it, when is RAG enough?

RAG is the right answer most of the time: your data changes, you don't need a custom writing style, you want answers with source references. Fine-tuning is worth it when: data is static, you need a specific output style or format, or latency/costs of long context become unsustainable. Often the answer is: RAG for knowledge + light fine-tuning for format.

### Which model gets used and why?

Default: Claude Opus or Sonnet for reasoning-heavy tasks (code, agents, complex tool-use), GPT when function-calling performance is critical, GPT-mini or Haiku for volume tasks. Embeddings: OpenAI text-embedding-3-large as default for general domains, Voyage AI (voyage-3-large or domain models like voyage-finance-2 / voyage-code-2) when the domain is specialised and retrieval quality measurably improves. Selection is per use case by quality and cost, not by vendor loyalty.

### How do hallucinations get prevented?

Three layers: (1) Retrieval with rerank, only the top chunks by semantic + keyword relevance go into the LLM. (2) The prompt instructs the model to answer "I don't know" when the chunks say nothing about it. (3) Output validation: answers get checked against the source chunks (also via LLM-as-judge in critical domains). Hallucination rate at 0 isn't achievable, at acceptable levels, yes.

### Are agents in scope or only Q&A?

Both. Q&A RAG is the most common use case and exactly right for many problems. Agents (tool-use, multi-step planning, external actions) are 5x more complex in development + eval and 10x more complex in production hardening. Agents get built when the use case really demands it, e.g. a reservation bot that makes real API calls, not an FAQ bot that quotes marketing material.

### How does multi-tenancy work without performance loss?

Default: row-level security with a tenantId column and PostgreSQL RLS policies. Fast, simple, well indexable. When compliance requires (e.g. healthcare): schema-per-tenant. Database-per-tenant almost never, operational overhead grows linearly without a clear benefit. Performance trick: all queries go through a middleware layer that injects tenantId, so no code can "forget" to filter.

### Which auth system gets recommended?

Auth.js (NextAuth) as default, ready OAuth providers, fast setup, no vendor lock-in, self-hosted. Clerk or WorkOS when you need B2B features (SAML, SCIM) and the pricing is reasonable. Supabase Auth gets recommended less often, it works, but migration away is painful when you later want self-hosted Postgres.

### How long does SaaS MVP development take?

Heavily dependent on feature depth and integrations, typically 2-4 months for a focused SaaS with auth, billing, multi-tenant data, one core feature and a simple dashboard. AI pipelines or complex data integrations push the schedule back accordingly. Delivery happens in 2-week slices, you see progress continuously, no "everything at the end". A concrete timeline gets set after the first call when scope and constraints are clear.

### What about GDPR and data protection?

GDPR-compliant SaaS gets built by default: data processing agreements, right-to-delete implementation, EU hosting (Hetzner Falkenstein as default), audit logs, encrypted backups, data export for users. Climactra is developed as an Italian SaaS under EU law, the requirements are known from that build, not just from textbooks.

### Can hosting be switched later?

When the SaaS runs on standard tech (Postgres + Node/Python + S3-compatible storage + Docker), a hosting switch is a two-week project, not an existential drama. Vendor lock-in gets deliberately avoided: no AWS-only services where standard alternatives exist. If you want AWS RDS, fine, but the build is structured so Postgres-on-Hetzner would be a switch, not a rewrite.

## Contact

Five short questions, then an answer. No discovery call, no long questionnaire. Just enough to know what it's about and how fast.

- Email: hello@method64.com
- Reply time: Answer usually within the same business day.
- URL: https://method64.com/en/kontakt

## Legal

- [Legal Notice](https://method64.com/en/impressum)
- [Privacy Policy](https://method64.com/en/datenschutz)
- [Sitemap](https://method64.com/sitemap.xml)