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.
Four disciplines — clickable directly via the orb or the list.
Toggle the props on the left, code on the right and preview above update live.
ABOUT
Web development at method64 means: 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. Three.js, WebGPU or specialised 3D libraries come in on request, not as default. Performance, accessibility and SEO are built-in standards. Every component has a reason. During the build phase you get a status update with screenshots of the current state every two weeks; for complex web apps, additionally a live staging link. The demo above is a genuinely wired button: change variant, size and flags, the JSX code updates live along with it, no image.
HOW IT GETS BUILT
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.
Climactra frontend (pre-launch). This site itself is also a reference, deliberately overdone, but every detail here could be executed more conservatively if your project calls for it.
hover over a node, header / body / latency appear here
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
ABOUT
Backend services get built here: 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 database, 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 plus status update. You can test the API directly with Postman or curl. The demo above sends a request along its path: Client → Gateway → Service → Postgres → Response, every hop with header, body and latency.
HOW IT GETS BUILT
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.
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.
Demo mode: keyword match on 7 hand-curated chunks, scripted answer. The real pipeline with embeddings and LLM gets built in client projects.
ABOUT
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, embedding-based search that beats full-text. When GPT-5 is enough, when Claude is better, when fine-tuning makes sense and when a simple prompt template solves the problem, that's a per-use-case call. The demo above shows the RAG flow on the basis of this site, keyword match on 7 curated chunks, no live LLM. Real pipelines with embeddings + rerank + LLM get built in client projects. During the build phase: every two weeks sample outputs and an eval snapshot in the status update, no live UI, because pure pipelines mostly don't have one.
HOW IT GETS BUILT
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.
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.
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 flows that don't scare people off. That gets built in from day one with the right architecture, not retrofitted. Climactra is the proof: a fully-featured platform, built entirely in-house, with everything a serious SaaS platform needs to have. During the build phase: live staging from day one, you can drop in any time and use the current state with test tenants. The demo above stacks the four SaaS layers — Auth, Billing, Tenancy and Observability — as planes, on larger screens as a 3D stack you pull apart by scrolling.
HOW IT GETS BUILT
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.
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.
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.
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.
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.
02 · Software & APIs
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 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.
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.
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.
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.
03 · AI integrations
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.
Default: Claude Opus or Sonnet for reasoning-heavy tasks (code, agents, complex tool-use), GPT-5 when function-calling performance is critical, GPT-5-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.
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.
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.
04 · SaaS development
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.
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.
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.
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.
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.