# DField Solutions — full content dump

> Custom AI systems, blockchain solutions, security audits, and web & mobile app development under one roof. We design, build, and operate.

Last updated: 2026-04-18
Primary URL: https://dfieldsolutions.com
Languages: Hungarian (primary), English
Contact: dezso@dfieldsolutions.com

---

## Services

### [HU] AI rendszerek — 01
URL: https://dfieldsolutions.com/hu/szolgaltatasok/ai

LLM-ügynököket, retrieval-pipeline-okat és ML-szolgáltatásokat építünk a te adataidra — nem demókat, hanem produkcióra kész rendszereket, kiértékeléssel és megfigyeléssel.

Intro: Az AI-t produkciós rendszerként kezeljük, nem prototípusként. Kiértékelés, megfigyelés, költség-felügyelet — napról napra jobb válaszok.
Timeline: 4–12 hét

Problems we solve:
- Hallucinál, és nem tudod mérni
- Drága, mert nincs caching / routing
- Nincs eval — nem mered élesíteni
- A support csapat belefullad a tickettengerbe

Outcomes you get:
- RAG + reranker, forrás-hivatkozásokkal
- LLM-router költség- és latency-optimalizáláshoz
- Automatizált eval CI-ben, minden release-nél
- Dashboard: használat, költség, minőség

Process:
- Adat és workflow audit — Átnézzük az adataidat, a támogatás / sales / ops folyamatokat, és kijelöljük hol tud az AI valós időt megtakarítani.
- Retrieval MVP — Első hét végén RAG-pipeline prototípus a te adataidon, forrás-hivatkozásokkal. Kiértékeljük, nem csak mutatjuk.
- Agent + guardrails — Tool-use, routing, rate-limit, PII-scrubber. Produkciós eval CI-ben minden release előtt.
- Éles + finomhangolás — Deploy, megfigyelés (LLM cost, latency, minőség), heti iteráció a dashboard adatai alapján.

### [EN] AI systems — 01
URL: https://dfieldsolutions.com/en/services/ai

We build LLM agents, retrieval pipelines, and ML services against your data — not demos, but production-ready systems with eval and observability.

Intro: We treat AI as a production system, not a prototype. Eval, observability, cost controls — better answers every day.
Timeline: 4–12 weeks

Problems we solve:
- It hallucinates and you can't measure it
- Expensive because there's no caching / routing
- No evals — you don't dare to ship
- Support team is drowning in tickets

Outcomes you get:
- RAG + reranker with source citations
- LLM router for cost and latency
- Automated evals in CI, every release
- Dashboard: usage, cost, quality

Process:
- Data + workflow audit — We go through your data and the support / sales / ops workflows, and pinpoint where AI can actually save time.
- Retrieval MVP — End of week 1: a RAG pipeline prototype against your data, with source citations. We evaluate, not just demo.
- Agent + guardrails — Tool use, routing, rate limits, PII scrubber. Production evals in CI before every release.
- Live + tuning — Deploy, observability (LLM cost, latency, quality), weekly iteration driven by the dashboard.

### [HU] Blockchain — 02
URL: https://dfieldsolutions.com/hu/szolgaltatasok/blockchain

Okosszerződések, tokenomika és onchain-integrációk — auditálható kóddal és reális fenyegetés-modellel. EVM és nem-EVM ökoszisztémákban is.

Intro: Egy okosszerződés-hiba 9 számjegyet is költhet. A mi kódunk auditálható, fuzzolva, teszthálózaton élt előbb.
Timeline: 6–16 hét

Problems we solve:
- Nem auditálhatod a jelenlegi kódodat
- Tokenomika, ami nem áll ki egy spreadsheetet
- Gas-költség nem kontrollált
- L2 / crosschain integráció bonyolult

Outcomes you get:
- Foundry / Hardhat-kompatibilis teljes teszthalmaz
- Fuzz + invariáns tesztek (Echidna / Foundry)
- Gas-profiler és benchmark
- Deploy pipeline multichainre

Process:
- Threat model — Papíron átmegyünk a kontraktok meghajtóin. Gazdasági kockázat, admin flow, rollback, migráció.
- Spec + tesztek — Formális spec, invariánsok. Foundry / Hardhat teszthalmaz >90% fedettséggel, fuzz alapokon.
- Audit + fuzz — Belső audit, Echidna / foundry fuzzcampaign. Kritikus hibák javítása és re-review.
- Deploy + monitor — Testnet → canary mainnet → full rollout. Onchain monitor + pager pipeline anomáliákra.

### [EN] Blockchain — 02
URL: https://dfieldsolutions.com/en/services/blockchain

Smart contracts, tokenomics, and onchain integrations — auditable code with a realistic threat model. Across EVM and non-EVM ecosystems.

Intro: A single contract bug can cost nine figures. Our code is auditable, fuzzed, and lives on testnet before mainnet.
Timeline: 6–16 weeks

Problems we solve:
- You can't audit your current code
- Tokenomics that doesn't hold up on a spreadsheet
- Gas costs out of control
- L2 / cross-chain integration is hard

Outcomes you get:
- Foundry / Hardhat-ready full test suite
- Fuzz + invariant tests (Echidna / Foundry)
- Gas profiler and benchmarks
- Deploy pipeline for multichain

Process:
- Threat model — We walk through the contract's economic drivers on paper. Risk, admin flow, rollback, migration.
- Spec + tests — Formal spec, invariants. Foundry / Hardhat test suite with >90% coverage, fuzz on top.
- Audit + fuzz — Internal audit, Echidna / Foundry fuzz campaign. Critical issues fixed and re-reviewed.
- Deploy + monitor — Testnet → canary mainnet → full rollout. Onchain monitor + pager pipeline for anomalies.

### [HU] Kiberbiztonság — 03
URL: https://dfieldsolutions.com/hu/szolgaltatasok/kiberbiztonsag

Threat modelling, penetrációs tesztelés, biztonsági auditok és DevSecOps. Védett rendszert építünk, nem csak találunk hibákat.

Intro: Nem egy PDF-et adunk át 80 oldalon, hanem PR-eket. A rendszered védett lesz, nem csak címkézve „megvizsgálva”.
Timeline: 2–8 hét

Problems we solve:
- Nem tudod a jelenlegi támadási felületedet
- Titkok hardcode-olva vagy rosszul rotálva
- Nincs incidens-playbook, ha baj van
- Audit előtt állsz, és nincs ready-kit

Outcomes you get:
- Threat model diagram + kockázati rangsor
- Pentest eredmény PR-ekként, CI-ben lezárva
- Titokmenedzsment + rotációs policy
- Incidens-runbook + tréning a csapatnak

Process:
- Recon + threat model — Feltérképezzük az attack surface-t: publikus endpoint, belső service, supply chain, human.
- Manuális pentest — OWASP Top 10 + specifikus üzleti logika. Nem automata tool-futtatás, hanem kézzel levadászott kockázatok.
- Remediation PR-ek — Minden találathoz javító PR, vagy ha nincs jogosultságunk, konkrét patch-javaslat repro-teszttel.
- Compliance csomag — SOC2 / ISO27001 readiness kit: policy-k, runbookok, audit-evidence sablonok, tréning.

### [EN] Cybersecurity — 03
URL: https://dfieldsolutions.com/en/services/cybersecurity

Threat modelling, penetration testing, security audits and DevSecOps. We build defended systems, not just find bugs.

Intro: We hand over PRs, not an 80-page PDF. Your system ends up defended — not just labelled 'reviewed'.
Timeline: 2–8 weeks

Problems we solve:
- You don't know your current attack surface
- Secrets hardcoded or rotated badly
- No incident playbook when things break
- An audit is coming and nothing is ready

Outcomes you get:
- Threat model diagram + risk ranking
- Pentest results as PRs, closed in CI
- Secret management + rotation policy
- Incident runbook + team training

Process:
- Recon + threat model — We map the attack surface: public endpoints, internal services, supply chain, human.
- Manual pentest — OWASP Top 10 + business-logic-specific. Not just running tools — hand-hunted risks.
- Remediation PRs — Every finding gets a fix PR, or if we don't have commit access, a concrete patch proposal with repro test.
- Compliance pack — SOC2 / ISO27001 readiness kit: policies, runbooks, audit-evidence templates, training.

### [HU] Web és webalkalmazás — 04
URL: https://dfieldsolutions.com/hu/szolgaltatasok/web

Márkaépítő landing oldalaktól a többtenantos SaaS-platformokig — tervezünk, fejlesztünk, optimalizálunk. SEO-ra, sebességre és konverzióra hangolva.

Intro: A weboldal a terméked első ígérete. Sebesség, design, SEO, konverzió — mind számít, és nálunk egyben jön.
Timeline: 3–14 hét

Problems we solve:
- Lassú, Google lepontozza
- Sablonos, mint mindenki másé
- SEO rendben van, de nem konvertál
- SaaS, de multi-tenant lesz — és nincs rá kész

Outcomes you get:
- Next.js app router + ISR / edge
- Core Web Vitals minden oldalon zöldben
- Design system + komponenskönyvtár
- Multi-tenant arkitektúra, ha kell

Process:
- Felfedezés + IA — Célpiac, konverziós funnel, IA, tartalomterv, keresési szándék. SEO alapozás a lapok megnevezésétől.
- Design system — Brand tokenek, komponenskönyvtár, mozgástervezés. Tiszta átadás dev felé, nem Figma-lyukas.
- Build + perf — Next.js / React, edge / ISR / RSC. Core Web Vitals zöld mezőben minden oldalon, már a build-ben.
- Analytics + CRO — Posthog / GA4 + heatmap. A/B tesztkeret. Havi CRO-kör a főbb oldalakra.

### [EN] Web & web app — 04
URL: https://dfieldsolutions.com/en/services/web

From brand-defining landing pages to multi-tenant SaaS platforms — we design, build, and optimize. Tuned for SEO, speed and conversion.

Intro: Your site is the product's first promise. Speed, design, SEO, conversion — all of it matters, all of it together.
Timeline: 3–14 weeks

Problems we solve:
- It's slow and Google is penalising you
- Looks like everyone else's template
- SEO is fine but nobody converts
- You're SaaS — multi-tenant is coming

Outcomes you get:
- Next.js app router + ISR / edge
- Core Web Vitals green on every page
- Design system + component library
- Multi-tenant architecture if needed

Process:
- Discovery + IA — Target market, conversion funnel, IA, content plan, search intent. SEO from the page naming up.
- Design system — Brand tokens, component library, motion spec. Clean handover to dev — not Figma with gaps.
- Build + perf — Next.js / React, edge / ISR / RSC. Core Web Vitals green on every page, starting at build time.
- Analytics + CRO — Posthog / GA4 + heatmaps. A/B test harness. Monthly CRO round on the main pages.

### [HU] Mobilalkalmazás — 05
URL: https://dfieldsolutions.com/hu/szolgaltatasok/mobil

iOS és Android alkalmazások natívan (Swift/Kotlin) vagy React Native-vel. Offline-first, biztonságos és karbantartható architektúrával.

Intro: A mobilapp az a termék, amit a felhasználó a zsebében hord. Offline működjön, gyors legyen, és kerüljön fel az áruházba elsőre.
Timeline: 6–18 hét

Problems we solve:
- Nem natívos érzés — döcög
- Nincs offline működés, crashol metrón
- App Store review elsőre visszaszól
- Push, analytics, crash report — mind hiányzik

Outcomes you get:
- Natív Swift / Kotlin vagy RN — választunk érted
- Offline-first sync, conflict-resolution
- Store-listing, screenshots, ASO kész csomag
- Sentry + analytics + remote config

Process:
- Stack-döntés — Natív vs RN kérdés — üzleti követelmények, OS-feature-igény és csapat alapján. Nem ideológia, döntés.
- Architektúra + offline — Data-layer, sync-stratégia, conflict resolution, secure storage. Ez a rész határozza meg, mekkora lesz a bug-ütemterv két év múlva.
- Build + felhasználói tesztelés — Iteratív build, belső TestFlight / internal track, tényleges user teszt. Nem csak a golden path.
- Store-launch + ASO — Screenshots, kulcsszó-kutatás, listing, review. Launch után remote-config-driven release management.

### [EN] Mobile apps — 05
URL: https://dfieldsolutions.com/en/services/mobile

iOS and Android apps natively (Swift / Kotlin) or with React Native. Offline-first, secure, and maintainable architecture.

Intro: A mobile app is the product in your user's pocket. It must work offline, feel fast, and clear App Store review on the first try.
Timeline: 6–18 weeks

Problems we solve:
- It doesn't feel native — laggy
- No offline mode, crashes on the subway
- App Store review rejects on round one
- No push, analytics, crash report

Outcomes you get:
- Native Swift / Kotlin or RN — we pick for you
- Offline-first sync with conflict resolution
- Store listing, screenshots, ASO pack
- Sentry + analytics + remote config

Process:
- Stack decision — Native vs RN — decided from business requirements, OS-feature needs, and the team. Not ideology, a decision.
- Architecture + offline — Data layer, sync strategy, conflict resolution, secure storage. This is what shapes your bug backlog two years from now.
- Build + user testing — Iterative build, internal TestFlight / internal track, real user testing. Not just the golden path.
- Store launch + ASO — Screenshots, keyword research, listing, review. Post-launch: remote-config-driven release management.

## Articles

### [EN] NIS2 for SaaS: minimum checklist for 2026
URL: https://dfieldsolutions.com/en/blog/nis2-for-saas-en
Published: 2026-04-20
Author: Dezső Mező (Founder, DField Solutions)
Tags: NIS2, Compliance, Security, EU

TL;DR: NIS2 is live. The 5-point minimum checklist for any EU SaaS — 24/72-hour incident reporting, supply-chain risk, MFA + rotation, patch SLA, training. Without these, you're out-of-gate.

The [NIS2 directive](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) took effect on 17 October 2024, and national laws have since mandated concrete obligations on 'important' and 'essential' organisations. If your SaaS serves EU customers, you're probably 'important'. Our [Cybersecurity service](/en/services/cybersecurity) covers exactly this readiness work — here's the minimum checklist.

## 1. Incident reporting: 24h, 72h, 1 month

NIS2 mandates: an early-warning within 24 hours, an incident assessment within 72 hours, and a final report within one month. This is runbook work, not 'when-it-happens' work. Write it today.

- An on-call who can say 'I'm reporting it' at the push of a button.
- A severity rubric: Sev1 → immediate, Sev2 → within 24h, Sev3 → post-mortem.
- Pre-written early-warning template for the national CSIRT portal.

## 2. Supply-chain risk

List critical vendors (AWS, Stripe, SendGrid, …), rank by business risk, and have a DPA + security attestation (SOC2, ISO27001) for every 'important' one.

## 3. Access control: MFA, rotation, zero-standing

- MFA for everyone, no exceptions. Tech users too.
- Production SSH: just-in-time, 30-minute TTL.
- API-key rotation: quarterly at minimum, automated.

## 4. Patching and vulnerability management

NIS2 says 'reasonable timeframe'. Practical reading: critical CVE in 48h, high in 7 days, medium in 30 days. Run this as an SLA, not a 'we'll look at it'.

## 5. Training: twice a year minimum

Mandatory security awareness training. Don't stop at click-through; include phishing simulations. You must be able to show the record at audit.

## We can help

Four of the five items above can be live in 2–3 weeks with your team. The fifth (patch SLA) is a 6-month project. Email us if you want hands-on help.

---

### [HU] NIS2 magyar SaaS-nak: minimum checklist 2026-ra
URL: https://dfieldsolutions.com/hu/blog/nis2-saas-checklist-hu
Published: 2026-04-20
Author: Mező Dezső (Alapító, DField Solutions)
Tags: NIS2, Compliance, Biztonság, EU

TL;DR: A NIS2 már hatályban. 5 pontos minimum checklist EU SaaS-oknak — incidens-bejelentés 24/72 órán belül, ellátási-lánc kockázat, MFA és rotáció, patch SLA, képzés. Ezek nélkül a kapun kívül maradsz.

A [NIS2 irányelv](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) 2024. október 17-én hatályba lépett, és a magyar Kormányrendelet 2025-ben konkrét kötelezettségeket ír elő a 'fontos' és 'kulcsfontosságú' szervezetekre. Ha SaaS-t szolgáltatsz EU-ügyfeleknek, valószínűleg beleesel a 'fontos' kategóriába. A [Kiberbiztonsági szolgáltatásunk](/hu/szolgaltatasok/kiberbiztonsag) pontosan ezt a felkészítést fedi le — itt a minimum checklist.

## 1. Incidens-bejelentés: 24 óra, 72 óra, 1 hónap

Az NIS2 előírja: 24 órán belül early warning, 72 órán belül incidens-értékelés, 1 hónapon belül záró jelentés. Ez runbook-téma, nem 'majd ha baj van'-téma. Neked ezt már ma le kell írnod.

- On-call séma, aki gombnyomásra mondja ki 'bejelentem'.
- Incident severity táblázat: Sev1 → azonnal NIS, Sev2 → 24h-ban belül, Sev3 → post-mortem.
- Predefinált sablon az early warning üzenethez (NBH, Bekötési portál).

## 2. Ellátási-lánc kockázatkezelés

Listázd a kritikus vendort (AWS, Stripe, SendGrid, stb.), rangsorold őket üzletkockázat alapján, és legyen minden fontosnak valamilyen DPA + biztonsági attestation (SOC2, ISO27001).

## 3. Hozzáférés-kezelés: MFA, rotáció, zero-standing

- MFA mindenkinek, kivétel nélkül. Tech user is.
- Production SSH: just-in-time, 30 perces lejárat.
- API-kulcs rotáció: minimum negyedévente, automatizáltan.

## 4. Patchelés és sebezhetőségkezelés

NIS2 szerint 'reasonable timeframe' belül kell patch-elni. A gyakorlati értelmezés: kritikus CVE 48h-ban, magas CVE 7 napban, közepes 30 napban. Ezt SLA-ként kell futtatnod, nem 'majd megnézzük'.

## 5. Képzés: évi 2x minimum

Kötelező rendszeres security awareness tréning. Ne csak klikkelős, legyen phishing-szimuláció is. A jegyzőkönyvet el kell tudnod mutatni auditkor.

## Mi segítünk

A fenti 5 elemből 4-et 2-3 hét alatt élesbe tudsz tenni a csapatoddal, a maradék egyet (patch SLA) 6 hónap alatt. Ha kell kézzelfogható segítség — írj.

---

### [EN] MCP (Model Context Protocol): what it means for LLM agents
URL: https://dfieldsolutions.com/en/blog/mcp-protocol-llm-agents
Published: 2026-04-14
Author: Mező Dezső (Founder, DField Solutions)
Tags: AI, LLM, MCP, Standard, News

TL;DR: MCP (Model Context Protocol) standardises how LLMs access tools, data sources, and context — the USB-C of agent-land. If you're building an AI agent in 2026, MCP-first is the bet: less vendor lock-in, swappable tools, easier audit.

For years everyone's been wiring up their own integrations for LLM agents: this tool, that DB, that billing pipe. Every project starts over. MCP solves this — a client/server protocol where agents see tools and data through a single interface.

## Why it's picking up

- USB-C for tool-use: one protocol, anywhere.
- No vendor lock — OpenAI, Anthropic, local models all call the same servers.
- Auditable: every tool-call becomes loggable and explainable.
- Security: clean enforcement points at the client/server boundary.

## How we use it

New client projects start MCP-native. We expose internal tools (retrieval, DB queries, CRM calls) as MCP servers, and the agent client can be anything. Big upside: swap the LLM provider later without rewriting the tool layer.

## When not to bother

If your agent just calls a prompt and doesn't touch anything else, MCP is overkill — a REST call is simpler. Once you have 3+ tool interactions, the switch pays for itself.

[NOTE] MCP doesn't replace retrieval, evals, or guardrails. It complements them: on the server side, you still need all three.

## Takeaway

Starting a new AI agent in 2026? Go MCP-first. Already have something running? Converting the tool layer is worth the next major release — not an emergency, but a clear direction. Happy to help you migrate.

---

### [HU] MCP (Model Context Protocol): mit jelent az LLM-ügynökök jövőjére
URL: https://dfieldsolutions.com/hu/blog/mcp-protocol-llm-ugynokok
Published: 2026-04-14
Author: Mező Dezső (Alapító, DField Solutions)
Tags: AI, LLM, MCP, Szabvány, News

TL;DR: Az MCP (Model Context Protocol) szabványosítja, ahogy az LLM-ek tool-okhoz, adatforrásokhoz és kontextushoz férnek — USB-C az ügynök-világban. Ha AI-ügynököt építesz 2026-ban, MCP-kompatibilisen érdemes: kisebb vendor-lock, cserélhető eszközök, egyszerűbb audit.

Évek óta mindenki a saját integrációit építi az LLM-ügynökeihez: ez a tool, az a DB, az a billing-pipe. Minden projekt újra-kezdi. Az MCP szabvány ezt oldja meg — kliens-szerver protokoll, amin keresztül az ügynök egységes interfészen keresztül lát eszközöket és adatokat.

## Miért ez lett a hullám

- USB-C a tool-use-hoz: egy protokoll, bárhol.
- Nincs vendor lock — OpenAI, Anthropic, lokális modellek ugyanazt a szervert hívhatják.
- Audit-able: minden tool-call logolható, explainable.
- Biztonság: kontroll pontok a kliens / szerver határán.

## Amit mi csinálunk vele

Az új ügyfélprojektjeinket alapból MCP-kompatibilisen indítjuk. A belső eszközöket (retrieval, DB-query, CRM-hívás) MCP-szerverként expozáljuk, az ügynök-kliens pedig lehet bármi. Egy nagy előny: ha később váltanánk LLM-szolgáltatót, a tool-oldalt nem kell átírni.

## Mikor még ne?

Ha az ügynököd csak egy promptot hív és nem nyúl máshoz, az MCP overkill — egy REST-hívás kényelmesebb. Amint 3+ tool-interakció jön a képbe, viszont megéri a váltás.

[NOTE] MCP nem helyettesíti a retrieval-t, az evalt, vagy a guardrailt. Kiegészíti: a szerver-oldalon ezek továbbra is kellenek.

## Összefoglaló

Ha 2026-ban új AI-agent projektet indítasz, MCP-kompatibilisen kezdd. Ha már él valami, a tool-réteget érdemes átkonvertálni — nem azonnal, de a következő nagyobb release-re. Mi szívesen segítünk végigvinni a migrációt.

---

### [EN] Shipping AI agents that actually work in production
URL: https://dfieldsolutions.com/en/blog/shipping-ai-agents-that-work
Published: 2026-04-08 · Updated: 2026-04-15
Author: Dezső Mező (Founder, DField Solutions)
Tags: AI, LLM, RAG, Production

TL;DR: A demo isn't a system. Retrieval, CI-gated evals, guardrails, and an LLM router are the five layers that turn an LLM prototype into production AI — with the code, the metrics, and the trade-offs.

Most 'AI agent' projects we see start with a promising ChatGPT demo, and three months later nobody knows why it hallucinates, why it's expensive, or why it falls apart under a real user. The problem isn't the LLM. The problem is the missing systems thinking.

Here's how we deliver AI agents that behave like production systems: every release passes an eval suite, every token has a cost SLA, and we see — in real time — when behavior drifts from the trend.

## 1. Retrieval: if you only do one thing, do this

Most hallucinations aren't solved by 'bigger model' — they're solved by retrieval. If the context is in the prompt, the model has nothing to invent. Hybrid retrieval (BM25 + vector + reranker) plus careful chunking covers 80% of customer-side errors.

- Chunk size 300–800 tokens, overlap 15–20%.
- Reranker (bge-reranker, Cohere rerank-3) is a dramatic quality jump.
- Always return citations. No hits → refuse.

## 2. Evals: 'looks fine' is no longer fine

We build a golden set from the customer's data — 50–200 questions — and run it in CI before every release. LLM-as-judge + factual regression tests. If the quality trend breaks, we don't deploy.

```ts
// Eval CI step
import { runEvals } from "@dfield/eval";

const result = await runEvals({
  suite: "support-copilot",
  model: process.env.MODEL_VERSION,
  thresholds: { accuracy: 0.88, factual: 0.95, latencyP95Ms: 1800 },
});

if (!result.passed) {
  throw new Error(`Eval failed: ${result.failures.join(", ")}`);
}
```

## 3. Guardrails: PII, prompt injection, output schema

Input side: PII scrubber, prompt-injection detector (keyword + LLM classifier). Output side: JSON schema validation, topic filters. This isn't cosmetic — it's what protects the brand.

[TIP] Guardrails are cheap insurance: they barely affect latency, and they stop 99% of unsafe / off-brand output.

## 4. Cost control: LLM router + cache

Not every question needs a GPT-4o answer. Route by intent: simple FAQ → small model + cache; complex reasoning → big model. 3–5x cost reduction is realistic.

## 5. Observability: every question measured

OpenTelemetry + our own dashboard: tokens in/out, latency P50/P95/P99, quality metrics (accuracy, refusal rate), cost per user. When a metric breaks, we know instantly and a pager fires.

## Closing

An AI system isn't fundamentally different from any other backend service — it needs the same engineering discipline. If you want to start this way, email us — we can show a running prototype on your data within a week.

---

### [HU] AI ügynökök produkcióban: ne demó legyen, hanem rendszer
URL: https://dfieldsolutions.com/hu/blog/ai-ugynokok-produkcioban
Published: 2026-04-08 · Updated: 2026-04-15
Author: Mező Dezső (Alapító, DField Solutions)
Tags: AI, LLM, RAG, Produkció

TL;DR: Az LLM-prototípusból nem lesz rendszer attól, hogy a demó megy. Retrieval, CI-futtatott eval, guardrails és LLM-router együtt adja a produkciós AI-t — ebben a cikkben végigmegyünk mind az öt rétegen, konkrét kóddal.

A legtöbb „AI agent” project, amit látunk, úgy kezdődik, hogy valaki ChatGPT-n legyárt egy ígéretes demót, aztán három hónap múlva senki nem tudja, miért hallucinál, miért drága, és miért esik szét az első valódi felhasználónál. A probléma nem az LLM-mel van. A probléma a rendszerszemlélet hiányával van.

Az alábbi cikkben végigvesszük, hogyan szállítunk mi olyan AI-ügynököket, amelyek valódi produkciós rendszerként működnek: minden release előtt eval-el átmennek, van rájuk költség-SLA, és monitorozható, hogy mikor tér el a viselkedés a várt trendtől.

## 1. Retrieval: ha csak ez van, már nyertél

A legtöbb hallucinációs problémát nem a „nagyobb modell” oldja meg, hanem a retrieval. Ha a kontextus benne van a promptban, a modellnek nincs dolga kitalálni dolgokat. Hibrid retrieval (BM25 + vector + reranker) és gondos chunk-stratégia 80%-ban lefedi az ügyfélhibák halmazát.

- Chunk méret 300–800 token, overlap 15–20%.
- Reranker (bge-reranker, Cohere rerank-3) drasztikus minőségugrás.
- Mindig küldünk forráshivatkozást — ha nincs találat, refuse.

## 2. Eval: a „úgy néz ki, jó” már nem jó

Építünk egy golden-set-et az ügyfél adataiból, 50–200 kérdéssel, és ezt futtatjuk CI-ben minden release előtt. LLM-as-judge + faktuális regressziós tesztek. Ha a minőség-trend megtörik, nem deploy-olunk.

```ts
// Eval CI step
import { runEvals } from "@dfield/eval";

const result = await runEvals({
  suite: "support-copilot",
  model: process.env.MODEL_VERSION,
  thresholds: { accuracy: 0.88, factual: 0.95, latencyP95Ms: 1800 },
});

if (!result.passed) {
  throw new Error(`Eval failed: ${result.failures.join(", ")}`);
}
```

## 3. Guardrails: PII, prompt injection, output-schema

Input oldalon PII-scrubber, prompt-injection-detektor (kulcsszó + LLM-classifier). Output oldalon JSON-schema validáció, tiltott témák szűrése. Ez nem cosmetic, ez megvédi a brand-et.

[TIP] A guardrails a legolcsóbb biztosítás: alig növeli a latency-t, viszont a sértő / nem-biztonságos kimenetek 99%-át kiszűri.

## 4. Költségmenedzsment: LLM-router + cache

Nem minden kérdésre kell GPT-4o-s válasz. Routing a kérdés tipusa szerint: egyszerű FAQ → kis modell + cache. Komplex reasoning → nagy modell. 3–5x költségcsökkentés reálisan elérhető.

## 5. Megfigyelés: minden kérdés mérve

OpenTelemetry + saját dashboard: tokens in/out, latency P50/P95/P99, minőségi metrikák (accuracy, refusal rate), költség per user. Ha egy metrika elromlik, azonnal látjuk és riadó szól.

## Zárszó

Az AI rendszer nem különbözik egy rendes backend-szolgáltatástól abban, hogy ugyanolyan mérnöki fegyelmet igényel. Ha ennek a cikknek a keretei szerint szeretnél indulni — írj, egy hét alatt futó prototípust tudunk mutatni a te adataidon.

---

### [EN] React Native vs native iOS: a 2026 decision framework
URL: https://dfieldsolutions.com/en/blog/react-native-vs-native-2026-en
Published: 2026-04-02
Author: Dezső Mező (Founder, DField Solutions)
Tags: Mobile, React Native, iOS, Android

TL;DR: There's no single right answer — just six hard questions. OS-feature reach, team composition, performance target, release tempo, 5-year horizon. Here's how we decide native vs. React Native on real projects.

The mobile-stack question turns into a religious war — which is a waste. The answer is technical, and hinges on six hard questions. Our [Mobile app service](/en/services/mobile) is ready for both paths: [React Native](https://reactnative.dev/) and native [SwiftUI](https://developer.apple.com/xcode/swiftui/) / [Jetpack Compose](https://developer.android.com/jetpack/compose). Let's run through them.

## 1. How much native OS surface do you use?

If the app leans heavily on native iOS features (Live Activities, Widgets, CallKit, HealthKit, ARKit), native Swift is the right answer. RN can bridge it, but you'll run out of oxygen.

## 2. One codebase or two?

RN = one codebase, but in practice ~15–25% platform-specific. Native = two. If your team is 3 people, RN is economically sharper. If it's 10, native isn't expensive either.

## 3. Performance-critical?

Video editors, 3D renderers, low-latency audio: native. Plain CRUD / chat / feed: RN is perfectly fine at 60 FPS.

## 4. App Store review tempo

RN + Expo → faster release (OTA updates). Native → every release goes via the App Store. If 'I ship daily' is the strategy, RN wins.

## 5. Team capability, long-term

What does your team know today? 5 React devs → RN is a faster start. Nobody knows Swift → native means a long learning curve. This is a heavy factor that's hard to reverse.

## 6. The 5-year window

Most mobile products live 5+ years. Think about 2031: which ecosystem scales better for your use case — Expo / RN, or Swift 6.x / Kotlin 2.x? Today, both are stable.

## Our typical choices

- B2B SaaS companion → React Native.
- Consumer (finance, fitness, photo) → native Swift + Kotlin.
- MVP for quick validation → RN (Expo), rewrite later if the product sticks.

---

### [HU] React Native vagy natív iOS? Döntési keret 2026-ra
URL: https://dfieldsolutions.com/hu/blog/react-native-vs-native-2026
Published: 2026-04-02
Author: Mező Dezső (Alapító, DField Solutions)
Tags: Mobil, React Native, iOS, Android

TL;DR: Nincs egyetlen helyes válasz — csak 6 kemény kérdés. OS-feature igény, csapatösszetétel, performance, release-tempó, 5 éves horizont. Mi így döntünk a projekteken, és mikor választunk natívot vagy React Native-t.

A mobil-stack kérdés vallási háborúvá szokott válni — kár. A válasz technikai, és hat kemény kérdésen múlik. A [Mobilalkalmazás szolgáltatásunk](/hu/szolgaltatasok/mobil) mindkét útra felkészült: [React Native](https://reactnative.dev/) és natív [SwiftUI](https://developer.apple.com/xcode/swiftui/) / [Jetpack Compose](https://developer.android.com/jetpack/compose). Szedjük sorra.

## 1. Mennyit használsz natív OS-feature-ökből?

Ha az app nagy részben használ natív iOS-feature-t (Live Activities, Widgets, CallKit, HealthKit, ARKit), natív Swift a helyes válasz. RN hídon keresztül is megoldható, de ki fog fogyni a levegőből.

## 2. Egy vagy két kódbázis?

RN = egy kódbázis, de gyakorlatban ~15–25% platform-specifikus kód. Natív = kettő. Ha a csapatod 3 ember, RN gazdaságilag értelmesebb. Ha 10, natívoldal sem drága.

## 3. Performance-kritikus?

Videószerkesztő, 3D renderer, alacsony-latencyű audio: natív. Sima CRUD / chat / feed: RN is tökéletes, 60 FPS-en futtatható.

## 4. App Store review szempont

RN + Expo → gyorsabb release (OTA update). Natív → minden release App Store-on megy. Ha 'naponta deploy-olok' a stratégia, RN nyer.

## 5. Csapat hosszú távú képessége

A csapatod mit tud ma? Ha 5 React dev van, RN gyorsabb start. Ha senki nem ismeri a Swift-et, natív = hosszú tanulási görbe. Ez súlyos tényező, nehéz visszacsinálni.

## 6. 5 éves ablak

A legtöbb mobil-termék 5+ évig él. Gondold át a 2031-es jövőt: az Expo / RN ökoszisztéma, vagy a Swift 6.x / Kotlin 2.x jobban fog skálázni a te use case-edben? Ma mindkettő stabil.

## Tipikus választásaink

- B2B SaaS companion → React Native.
- Consumer (pénzügy, fitness, foto) → natív Swift + Kotlin.
- MVP gyors validálásra → RN (Expo), majd átírás később, ha tartóssá válik.

---

### [EN] Smart contract audit checklist — the one we actually use
URL: https://dfieldsolutions.com/en/blog/smart-contract-audit-checklist
Published: 2026-03-22
Author: Dezső Mező (Founder, DField Solutions)
Tags: Blockchain, Security, Solidity, Audit

TL;DR: A single smart-contract bug can cost nine figures. This 7-step checklist — threat model, invariant tests, fuzz, static analysis, manual review, phased deploy, onchain monitor — runs on every DField project before the first mainnet tx.

A single re-entrancy bug cost $180M once. A single access-control miss zeroed out thousands of users. Blockchain doesn't forgive. This checklist is what we run on every project before the first mainnet transaction.

## I. Threat model (1–2 days)

- Economic actors: who profits from an exploit?
- Admin surface: what permissions exist, who controls them?
- Oracle dependencies: which oracle, what's the fallback?
- Flashloan surfaces: can the contract be manipulated within a single tx?
- MEV / front-running exposure.

## II. Test coverage

100% line coverage isn't the goal — the goal is a scenario test for every economic situation. Foundry or Hardhat, augmented with invariant tests.

```sol
// Foundry invariant test
contract TreasuryInvariants is Test {
    function invariant_totalSupplyMatchesBalances() public {
        uint256 sum;
        for (uint256 i = 0; i < users.length; i++) {
            sum += treasury.balanceOf(users[i]);
        }
        assertEq(sum, treasury.totalSupply());
    }
}
```

## III. Fuzz campaign

- Echidna 10M+ runs with every property instrumented.
- Foundry fuzz on the edges of the parameter range.
- Special attention: reentrancy, overflow, access control, rounding.

## IV. Static analysis

- Slither — baseline net, but many false positives.
- Mythril symbolic execution, slower but deeper.
- Aderyn (Rust-based) — fast, modern.

## V. Manual review

Tools don't find every business-logic bug. Read the contracts line by line. Focus: state transitions, permissioning, rollback, migration. Four-eye principle — two independent reviewers.

## VI. Deploy pipeline

- Local anvil / hardhat node: integration tests.
- Testnet (Sepolia, Arbitrum Sepolia): ~2 weeks of traffic.
- Canary mainnet: TVL cap, phased.
- Full rollout + TVL lift in steps.

## VII. Onchain monitor

30–90 days of production monitoring: anomaly detection (flashloan patterns, TVL jumps, suspicious gas usage). Pager pipeline at threshold.

[WARN] Never deploy to mainnet on a Friday afternoon. Ever. Not even for a 'small update'.

## Summary

This list isn't complete, but it's the repeatable part of what we do. If you'd like, we can run it against your code — 2–8 weeks to a full audit report as PRs.

---

### [HU] Okosszerződés audit checklist — amit mi is használunk
URL: https://dfieldsolutions.com/hu/blog/okosszerzodes-audit-checklist
Published: 2026-03-22
Author: Mező Dezső (Alapító, DField Solutions)
Tags: Blockchain, Biztonság, Solidity, Audit

TL;DR: Egy okosszerződés bug 9 számjegyet is költhet. Ez a 7 lépéses checklist — threat model, invariáns tesztek, fuzz, statikus elemzés, kézi review, fázisos deploy, onchain monitor — minden projektünkben fut, mielőtt egy tranzakció is mainnet-re kerülne.

Egy rossz re-entrancy 180 millió dollárba került egyszer. Egy rossz access-control sok ezer felhasználó hozzáférését nullázta le. A blockchain nem bocsát meg. Az alábbi checklist az, amit mi is minden projektnél végigfuttatunk, mielőtt az első tranzakció átmenne a mainnet-en.

## I. Threat model (1–2 nap)

- Gazdasági szereplők: ki tud profitot realizálni egy exploit esetén?
- Admin felület: mik a jogosultságok, ki kontrollálja őket?
- Oracle-függőségek: melyik oracle, mi a fallback?
- Flashloan-felületek: lehet-e a szerződést manipulálni egy tranzakción belül?
- MEV / front-running kitettség

## II. Teszt-lefedettség

Nem a 100% line-coverage a cél, hanem az, hogy minden gazdasági szcenárióra legyen scenario-teszt. Foundry vagy Hardhat, de invariáns-tesztekkel kiegészítve.

```sol
// Foundry invariant test
contract TreasuryInvariants is Test {
    function invariant_totalSupplyMatchesBalances() public {
        uint256 sum;
        for (uint256 i = 0; i < users.length; i++) {
            sum += treasury.balanceOf(users[i]);
        }
        assertEq(sum, treasury.totalSupply());
    }
}
```

## III. Fuzz campaign

- Echidna 10M+ runs, minden property kiemelt.
- Foundry fuzz a paraméter-tartomány szélein.
- Különös figyelem: reentrancy, overflow, access control, rounding.

## IV. Statikus elemzők

- Slither — mint alap-szintű háló, de sok false positive.
- Mythril symbolic execution, lassabb de mélyebb.
- Aderyn (Rust-alapú) — gyors, modern.

## V. Manual review

A tool-ok nem találnak meg minden üzleti-logika-hibát. Minden szerződést sor-ről-sor megnézünk, focus: állapot-változások, jogosultság, rollback-lehetőség, migráció. Négy szem alapelv — két ember párhuzamosan, independent.

## VI. Deploy-pipeline

- Lokális anvil / hardhat node: integration tesztek.
- Testnet (Sepolia, Arbitrum Sepolia): kb. 2 hét forgalom alatt.
- Canary mainnet: TVL-cap és kör gondosan.
- Full rollout + TVL-emelés lépésekben.

## VII. Onchain monitor

Deploy után 30–90 nap éles monitorozás: anomália-detektor (flashloan-minta, hirtelen TVL-ugrás, gyanús gas-használat). Pager-pipeline, ha valami megüti a küszöböt.

[WARN] Soha ne deploy-olj mainnet-re péntek délután. Soha. Még akkor sem, ha ún. kis frissítés.

## Összefoglaló

Ez a checklist nem kompletnek van szánva, de a megismételhető része annak, amit mi csinálunk. Ha szeretnéd, átfuttatjuk a te kódodon — 2-8 hét alatt teljes audit-jelentést kapsz PR-formában.

---

### [EN] Multi-tenant SaaS with Next.js: from template to production
URL: https://dfieldsolutions.com/en/blog/multi-tenant-saas-nextjs-en
Published: 2026-03-10
Author: Dezső Mező (Founder, DField Solutions)
Tags: Web, SaaS, Next.js, Multi-tenant

TL;DR: Subdomain vs. custom domain, Postgres Row-Level Security vs. schema-per-tenant, per-tenant feature flags, Stripe metered billing, isolated background queues. The Next.js reference stack we ship for SaaS scaling past 10k tenants.

Past ~10 tenants, multi-tenant architecture isn't a luxury — it's survival. Here's the reference stack we run on [Next.js](https://nextjs.org/docs/app) with [Postgres Row-Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html). We ship this under our [Web service](/en/services/web).

## 1. Tenant detection: subdomain vs custom domain

Subdomain (acme.app.com) is the default. Custom domain (app.acme.com) ships in the Growth plan. Next.js middleware resolves the tenant and attaches it to the request.

```ts
// middleware.ts — tenant resolution
import { NextResponse, type NextRequest } from "next/server";

export async function middleware(req: NextRequest) {
  const host = req.headers.get("host") || "";
  const subdomain = host.replace(/\.app\.com$/, "");
  const tenant = await resolveTenantBySubdomain(subdomain);
  if (!tenant) return NextResponse.redirect(new URL("/404", req.url));

  const res = NextResponse.next();
  res.headers.set("x-tenant-id", tenant.id);
  return res;
}
```

## 2. Data isolation: Row-Level Security vs schema-per-tenant

Postgres RLS (PolicyScope) works well up to ~500 tenants. Above that, schema-per-tenant (or cluster-per-tenant for big customers). We default to RLS, and give dedicated schemas to critical accounts.

## 3. Per-tenant feature flags

Growth sees different features than Enterprise. We don't do if-elseif for this — PostHog feature flags + tenant group. The code stays clean.

## 4. Billing: Stripe + per-seat + usage

- Stripe Subscription per tenant; customer = tenant.
- Metered billing for usage-based products.
- Webhook → Postgres → cache invalidation.

## 5. Background jobs per tenant

Don't run tenant jobs in one global queue. BullMQ per-tenant queues or a Temporal namespace. A noisy tenant then can't tip the rest over.

## Summary

This architecture stands up in 2–8 weeks. If you're starting a SaaS today, start multi-tenant — retrofitting is always more expensive.

---

### [HU] Multi-tenant SaaS Next.js-szel: sablontól a termelésig
URL: https://dfieldsolutions.com/hu/blog/multi-tenant-saas-nextjs
Published: 2026-03-10
Author: Mező Dezső (Alapító, DField Solutions)
Tags: Web, SaaS, Next.js, Multi-tenant

TL;DR: Subdomain vs custom domain, Postgres Row-Level Security vs schema-per-tenant, feature flag per-tenant, Stripe metered billing, izolált background queue. A teljes referenciastack Next.js-szel, amin a SaaS-ügyfeleinket 10k tenant-ig skálázunk.

Ha a te SaaS-ed 10+ tenant fölé skálázik, a multi-tenant architektúra nem luxus, hanem túlélés. Itt az általunk használt referencia-stack [Next.js](https://nextjs.org/docs/app)-szel és [Postgres Row-Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)-vel. Ugyanezt szállítjuk a [Web és webalkalmazás szolgáltatásunk](/hu/szolgaltatasok/web) keretében.

## 1. Tenant-felismerés: subdomain vs custom domain

A subdomain (acme.app.com) a default. A custom domain (app.acme.com) szerepel a Growth csomagban. Next.js middleware-ben feloldjuk a tenant-et és hozzá-csapjuk a request-hez.

```ts
// middleware.ts — tenant resolution
import { NextResponse, type NextRequest } from "next/server";

export async function middleware(req: NextRequest) {
  const host = req.headers.get("host") || "";
  const subdomain = host.replace(/\.app\.com$/, "");
  const tenant = await resolveTenantBySubdomain(subdomain);
  if (!tenant) return NextResponse.redirect(new URL("/404", req.url));

  const res = NextResponse.next();
  res.headers.set("x-tenant-id", tenant.id);
  return res;
}
```

## 2. Adatizoláció: Row-Level Security vs schema-per-tenant

Postgres RLS (PolicyScope) jól működik ~500 tenant-ig. Efölött schema-per-tenant (vagy cluster-per-tenant nagy ügyfeleknek). Mi default RLS-t használunk, kritikus ügyfeleknek dedikált schema-t.

## 3. Feature flag per-tenant

A Growth csomag más feature-t lát, mint az Enterprise. Ezt NEM if-elseif-ben csináljuk — PostHog feature flag + tenant group. A kód tiszta marad.

## 4. Billing: Stripe + per-seat + usage

- Stripe Subscription per-tenant, customer = tenant.
- Metered billing a usage-alapú termékekhez.
- Webhook → Postgres → cache invalidation.

## 5. Background job per-tenant

Ne egy globál queue-ban fussanak a tenant-job-ok. BullMQ per-tenant queue vagy Temporal namespace. Így egy csapkodó tenant nem dönti be a többit.

## Összefoglaló

Ez az architektúra 2–8 hét alatt felállítható. Ha most indítasz SaaS-t, kezdettől multi-tenant legyen — később átállni sokkal többe kerül.

---

### [EN] GDPR + AI: training on user data in 2026 — what's allowed, what isn't
URL: https://dfieldsolutions.com/en/blog/gdpr-ai-training-2026
Published: 2026-03-05
Author: Mező Dezső (Founder, DField Solutions)
Tags: GDPR, AI Act, Compliance, Training data

TL;DR: You can train on user data. But whether you asked for consent, and whether that data can be extracted from the model later, both matter. This walks through the legal bases, the pitfalls (see: the ChatGPT opt-out cases), and a checklist your team can sign off on tomorrow.

Most AI-first SaaS have the same temptation: 'we'll train on user data, because that makes the product better.' Legally this is never obvious — in 2026, GDPR and the AI Act both apply.

## Legal bases — short version

- Consent: broadest, but revocable — once revoked, the data can't stay in the model.
- Legitimate interest: strict balancing test; rarely holds up for training.
- Contract performance: only if training is literally part of the service. Not a general bucket.

## The pitfall everyone underrates

Under GDPR, users have a right to erasure. If personal data is baked into a model, in theory it has to be removable. In practice you can't extract it — that's the right-to-be-forgotten vs. machine unlearning tension the EU started taking seriously in 2026.

## What we actually do today

- Anonymise at the pipeline entry — training never sees personal data.
- Consent log: who, when, what they agreed to (timestamp + version).
- Opt-out tracking: on revocation, filter before retraining / release.
- Model card: what you trained on, when, which version. Auditable.
- Tenant-level isolation for multi-tenant embeddings.

[WARN] If you're doing RAG and user documents only flow into prompts (not into training), compliance is dramatically simpler. That's why we bias ~80% of projects toward RAG over training.

## Where 2026 is heading

Stronger DPA enforcement, bigger fines, and real progress on machine unlearning. Our take: every model pipeline should ship with a consent flag and an opt-out retraining cycle. Retrofitting is brutal.

## Takeaway

Training on user data isn't banned, but cutting corners is expensive. If it helps, we'll take your pipeline apart with you in half a day — compliance risk map plus a concrete fix list.

---

### [HU] GDPR + AI: felhasználói adattal tanítani 2026-ban — mit szabad, mit nem
URL: https://dfieldsolutions.com/hu/blog/gdpr-ai-tr%C3%A9ning-2026
Published: 2026-03-05
Author: Mező Dezső (Alapító, DField Solutions)
Tags: GDPR, AI Act, Compliance, Training data

TL;DR: Felhasználói adaton tanítani modellt lehet, de nem mindegy, hogy kérsz-e rá hozzájárulást, és hogy a modellből kihúzható-e a tanító-adat. Ez a cikk végigveszi a jogalapokat, a buktatókat (lásd: ChatGPT-Opt-out perek), és egy checklistet, amit a csapatod holnap aláírhat.

A legtöbb AI-vel induló SaaS-nak ugyanaz a kísértése: „a user-ek adatával tanítunk, mert így lesz jobb a termékünk”. Jogilag ez egyetlen pillanatra sem egyértelmű — 2026-ban a GDPR és az AI Act együtt vonatkozik rá.

## Jogalapok — röviden

- Hozzájárulás (consent): legszélesebb, de visszavonható, az után nem maradhat a modellben.
- Jogos érdek (legitimate interest): szigorú balance-teszt, ritkán állja meg a helyét tréninghez.
- Szerződés teljesítése: csak ha a tréning direkt a service része. Nem általános célú.

## A buktató, amit mindenki alábecsül

A GDPR szerint a felhasználónak joga van a törléshez. Ha a személyes adata bele van sütve a modellbe, azt elvileg törölni kellene. Gyakorlatban a modellből nem tudod kiolvasni — ez az ún. right to be forgotten és machine unlearning feszültség, amit az EU 2026-ban elkezdett komolyan venni.

## Amit ma mi csinálunk

- Anonimizálás már a pipeline elején — személyes adatot ne érjen el a tréning.
- Consent log: ki, mikor, mire adott engedélyt (időbélyeg, verzió).
- Opt-out nyomkövetés: ha visszavon, retraining / modell-kiadás előtt kiszűrjük.
- Model card: mire tanítottunk, mikor, milyen verzióval. Auditálható.
- Tenant-szintű izoláció multi-tenant embeddingseknél.

[WARN] Ha RAG-ot csinálsz, és a user saját dokumentumai csak prompt-ba mennek (nem tanítasz rajtuk), a compliance lényegesen egyszerűbb. Ezért favoritizáljuk a RAG-ot training helyett 80%-ban.

## A 2026-os irány

Erősödő DPA-ellenőrzések, nagyobb bírságok, és a machine unlearning technológiai fejlődése. Javaslatunk: minden modell-pipeline-ba építs be consent-flag-et és opt-out-retraining cycle-t. Utólag rátenni extrém drága.

## Összefoglaló

A user-adatos tréning nem tiltott, de a mulasztás drága. Ha segít, fél napban átvesszük veled a te konkrét pipeline-odat — compliance-risk map-pel és konkrét fix-listával.

---

### [EN] EU AI Act for SaaS: what you actually have to do in 2026
URL: https://dfieldsolutions.com/en/blog/eu-ai-act-saas-2026
Published: 2026-02-18
Author: Mező Dezső (Founder, DField Solutions)
Tags: AI Act, Compliance, GDPR, News

TL;DR: The EU AI Act now affects most SaaS, even if you're 'just running a chatbot on the site.' This piece walks through the risk tiers, the three near-term deadlines, and exactly what to ship into your product now.

I've spoken to a lot of SaaS founders in the last month, and the line I hear most is: 'it doesn't apply to us, we only use a chatbot'. About 80% of the time that's wrong. The AI Act classifies by use context, not by technology.

## Four risk tiers — the short version

- Unacceptable: social scoring, manipulative behavioural systems. Banned.
- High risk: HR screening, credit decisions, critical infrastructure. Strict compliance.
- Limited: user-facing generative AI — transparency duty (e.g. 'AI-generated' labels).
- Minimal: internal productivity, spam filters. Effectively no obligation.

## 3 things most SaaS need to do now

- Label AI-generated content: if the user sees AI output, it needs to say so.
- Data-handling register: what you train on, from what source, and retention. Complements GDPR, doesn't replace it.
- Incident plan: what your team does when a hallucinated or harmful output ships.

## Three deadlines worth writing down

Q1 2026: unacceptable systems phased out. Q2: transparency for user-facing AI. Q4: full compliance for high-risk systems. If you're unsure which tier you're in, spend an hour with outside counsel or an engineer who's done the mapping — before you guess wrong.

[WARN] Fines go up to EUR 35M or 7% of global annual revenue. For a mid-stage SaaS this is not a theoretical risk.

## Takeaway

Don't push this to 2027. Classification, labels, and the register need to happen now. We run a half-day AI Act session for SaaS teams — if you want a concrete output plan, reach out.

---

### [HU] EU AI Act magyar SaaS-oknak: mit kell tenni 2026-ban
URL: https://dfieldsolutions.com/hu/blog/eu-ai-act-magyar-saas-2026
Published: 2026-02-18
Author: Mező Dezső (Alapító, DField Solutions)
Tags: AI Act, Compliance, GDPR, News

TL;DR: Az EU AI Act 2026 elejétől a legtöbb SaaS-t is érinti, még akkor is, ha „csak egy chatbot van az oldalon”. Ez a cikk végigveszi a kockázati osztályokat, a három közeli határidőt, és konkrétan mit pakolj a terméketedbe most.

Sok magyar SaaS-alapítóval beszéltem az elmúlt hetekben, és szinte mindenkinél ugyanaz a mondat: „ránk nem vonatkozik, mi csak egy chatbotot használunk”. Ez kb. 80%-ban téves. Az AI Act a felhasználási kontextus alapján osztályoz, nem a technológia alapján.

## A négy kockázati szint — röviden

- Elfogadhatatlan: social scoring, manipulatív viselkedést célzó rendszerek. Tiltott.
- Magas kockázat: HR-szűrés, hitelbírálat, kritikus infrastruktúra. Szigorú compliance.
- Korlátozott: generatív AI user-facing — transzparencia-kötelezettség (pl. AI-tartalom jelölés).
- Minimális: belső termelékenység, spam-szűrés. Gyakorlatilag nincs kötelezettség.

## 3 dolog, amit a legtöbb SaaS-nak most kell

- AI-generated tartalom jelölése: ha a terméked user-facing AI-output-ot ad, legyen rajta „AI-generated”.
- Adatkezelési nyilvántartás: mit tréningelsz, miből, meddig tárolod — kiegészíti a GDPR-t, nem helyettesíti.
- Incidens-terv: hogy reagál a csapatod, ha hallucinált vagy káros output ment ki.

## A három határidő, amit érdemes a naptárba tenni

2026. Q1: tiltott rendszerek kivezetése. Q2: transzparencia-követelmények user-facing AI-ra. Q4: magas kockázatú rendszerek teljes compliance-e. Ha bizonytalan vagy, melyik kategóriába esel, érdemes egy órát külső szakértővel átbeszélni, mielőtt félrefordulsz.

[WARN] A bírság 35M EUR-ig vagy a globális éves árbevétel 7%-áig terjedhet. Magyar SaaS-nál ez nem elméleti probléma.

## Összefoglaló

Ne várj 2027-ig. Az AI Act nem elméleti — a minősítést most kell elvégezni, a jelöléseket most kell feltenni, a nyilvántartást most kell elkezdeni. Ha kell, segítünk végigmenni egy fél napos sessionben.

---

### [EN] Core Web Vitals on Next.js: from 4.5s LCP to 0.9s in 3 weeks
URL: https://dfieldsolutions.com/en/blog/core-web-vitals-nextjs-case-study
Published: 2026-02-14
Author: Dezső Mező (Founder, DField Solutions)
Tags: Web, Performance, Next.js, SEO

TL;DR: A real Next.js CWV audit: LCP 4.5s → 0.9s in three weeks. Five concrete changes — image priority, RSC boundaries, edge ISR, CLS zeroing, TTFB tuning — and the user sees the first pixel three times faster.

[Core Web Vitals](https://web.dev/vitals/) is a Google ranking factor, and the user feels the difference. Here's a real audit of a [Next.js](https://nextjs.org/)-based B2B SaaS marketing site — anonymised, but the numbers are exact. We run this audit under our [Web service](/en/services/web).

## Starting point

- LCP: 4.5s (red)
- CLS: 0.21 (red)
- INP: 420ms (amber)
- TTFB: 1.1s (amber)

## 1. Hero image + font: the biggest visible win

The hero image wasn't priority-loaded, and the custom font with font-display: auto held back the first paint. Two tiny changes (-1.4s LCP):

```tsx
// Before
<Image src={heroImg} alt="" />

// After
<Image
  src={heroImg}
  alt="Hero illustration"
  priority
  fetchPriority="high"
  sizes="(min-width: 1024px) 600px, 100vw"
/>
```

## 2. RSC boundaries: carve out the slow parts

On the marketing page, nothing needed to be interactive above the fold. Switching to RSC reduced hydration payload from 110kb to 22kb; INP dropped from 420ms to 180ms.

## 3. Edge + ISR

Blog pages got 300s ISR + edge runtime. TTFB fell from 1.1s to 90ms. Guests from Singapore now hit the home page in sub-second.

## 4. CLS: current 0.00

- Reserve height for ads / embeds — no reflow.
- font-size-adjust for fallback — no text jump.
- Aspect-ratio on every image.

## Result, after 3 weeks

- LCP: 0.9s (green)
- CLS: 0.01 (green)
- INP: 120ms (green)
- TTFB: 90ms (green)
- Organic traffic +34% in three months

## Takeaway

You don't need to rebuild the whole app. 3–5 targeted changes on 20% of the user journey is enough for CWV green. We can run the audit on you — 1–2 weeks for the audit + the fix PRs.

---

### [HU] Core Web Vitals Next.js-szel: hogyan lett 4.5s-ből 0.9s LCP
URL: https://dfieldsolutions.com/hu/blog/core-web-vitals-nextjs-esettanulmany
Published: 2026-02-14
Author: Mező Dezső (Alapító, DField Solutions)
Tags: Web, Performance, Next.js, SEO

TL;DR: Valódi Next.js CWV audit: LCP 4.5s → 0.9s három hét alatt. Öt konkrét változtatás — image priority, RSC határok, edge ISR, CLS-nullázás, TTFB-tuning — és a felhasználó háromszor gyorsabban látja az első pixeled.

A [Core Web Vitals](https://web.dev/vitals/) Google-ranking faktor, és a felhasználó is érzi a különbséget. Íme egy valódi audit egy [Next.js](https://nextjs.org/)-alapú B2B SaaS marketing oldalról — névtelenítve, de a számok pontosak. A teljes folyamatot a [Webfejlesztés szolgáltatásunk](/hu/szolgaltatasok/web) keretében is futtatjuk.

## Kiindulás

- LCP: 4.5s (piros)
- CLS: 0.21 (piros)
- INP: 420ms (narancs)
- TTFB: 1.1s (narancs)

## 1. Hero image + font: a leglátványosabb nyereség

A hero image nem volt priority loaded, és a custom font a font-display: auto-val várakozásra kényszerítette az első renderelést. Két apró változtatással (-1.4s LCP):

```tsx
// Before
<Image src={heroImg} alt="" />

// After
<Image
  src={heroImg}
  alt="Hero illustration"
  priority
  fetchPriority="high"
  sizes="(min-width: 1024px) 600px, 100vw"
/>
```

## 2. RSC határok: lelassított részek kivágása

A marketing oldalon semmi sem kellett, hogy interaktív legyen a hajtás felett. RSC-re váltva a hydration-payload 110kb-ról 22kb-re csökkent, az INP 420ms-ról 180ms-re.

## 3. Edge + ISR

A blog-oldalakon 300s ISR + edge runtime. A TTFB 1.1s-ről 90ms-re zuhant. A vendégfelhasználók most Singapore-ból is szub-másodperc alatt érik el a főoldalt.

## 4. CLS: a jelenlegi 0.00

- Reklám / embed magasság-reserve, nincs hely-visszafoglalás.
- Font-size-adjust a fallback-hez — nincs szövegugrás.
- Image aspect-ratio minden képnél.

## Eredmény, 3 hét után

- LCP: 0.9s (zöld)
- CLS: 0.01 (zöld)
- INP: 120ms (zöld)
- TTFB: 90ms (zöld)
- Organic trafik +34% három hónap alatt

## Tanulság

Nem kell refaktorálni az egész appot. 3–5 konkrét változtatás a látogatói útvonal 20%-ában elhozza a CWV-zöld státuszt. Ha szeretnéd, mi is lefuttatjuk rajtad — 1–2 hét az audit és a javító PR-ek.

---

### [EN] Picking a vector DB in 2026: pgvector, Pinecone, Weaviate
URL: https://dfieldsolutions.com/en/blog/vector-db-pick-2026
Published: 2026-01-22
Author: Mező Dezső (Founder, DField Solutions)
Tags: AI, Vector DB, pgvector, RAG

TL;DR: No production RAG without a vector DB. But the three real contenders (pgvector, Pinecone, Weaviate) have very different DNA. This is how we decide, across three of our own 2026 projects — and where the scale cliff is that forces a migration.

On most new RAG projects this is the first real architecture decision: where does the vector DB live. Get it wrong and you're not just out some money — you're out months migrating later. Three serious contenders: pgvector, Pinecone, Weaviate.

## pgvector — the 'just Postgres' route

If you already run Postgres, pgvector is usually the right first pick. Extension, no new system, transactional data and embeddings in the same DB. Cost: effectively zero. Performance: comfortable up to ~1M vectors. IVFFlat + HNSW supported.

- Pros: zero new infra, JOINs work, row-level security works.
- Cons: tuning IVFFlat past 10M vectors is non-trivial.
- Sweet spot: 0 to ~1M vectors, per-customer knowledge bases.

## Pinecone — managed and fast

If you don't want to run a vector index and want an API call away, Pinecone makes sense. Multi-tenant serverless, metadata filtering, autoscale. Cost: scales up faster than you expected if sharding is wrong.

- Pros: zero ops, fast ramp, stable tail latency.
- Cons: vendor lock, no JOIN back to transactional data, expensive past 10M vectors.
- Sweet spot: fast MVP, SaaS scale-outs across thousands of tenants.

## Weaviate — the hybrid take

Weaviate plays a different game: native hybrid search (BM25 + vector + filter), GraphQL API, modules (reranker, generator). Self-host or managed. Stronger for document-centric use cases.

- Pros: native hybrid search, rich schema, multi-tenant.
- Cons: steeper learning curve; ops overhead if self-hosted.
- Sweet spot: knowledge-base search, document platforms, hybrid-first retrieval.

## Our decision framework

- Already have Postgres and &lt; 1M vectors? → pgvector.
- Multi-tenant SaaS, &lt; 10M per tenant, fast launch? → Pinecone.
- Large document corpus, hybrid search is first-class? → Weaviate.
- Unsure? Start with pgvector — the switching cost is lower than vendor lock-in.

[TIP] The typical mistake: jumping to Pinecone too early, then watching a 3-month bill kill the project. Start with pgvector and switch only when there's a concrete numeric reason.

## Takeaway

There's no universal answer. There is a framework. Happy to look at your setup — 30 minutes is enough for a directional recommendation.

---

### [HU] Vector DB választás 2026-ban: pgvector, Pinecone, Weaviate
URL: https://dfieldsolutions.com/hu/blog/vector-db-valasztas-2026
Published: 2026-01-22
Author: Mező Dezső (Alapító, DField Solutions)
Tags: AI, Vector DB, pgvector, RAG

TL;DR: Vector DB nélkül nincs production RAG. De a három jelöltnek (pgvector, Pinecone, Weaviate) teljesen eltérő a DNS-e. Ez a cikk a három saját projektünk alapján sorolja rendre, mikor melyik nyer — és hol az a méret, amikor váltani kell.

A legtöbb új RAG-projektünknél ez az első igazi architektúra-döntés: vector DB-t hova teszünk. Egy rossz választás nem csak pénz, hanem hónapok migrációja. Három komoly jelölt: pgvector, Pinecone, Weaviate.

## pgvector — a „csak Postgres” út

Ha már van Postgresed, a pgvector valószínűleg az első választás. Egy extension, nincs új rendszer, a tranzakcionális adat és az embeddings ugyanabban a DB-ben. Ár: gyakorlatilag nulla. Teljesítmény: ~1M vektorig nagyon szép. IVFFlat + HNSW támogatás.

- Előny: 0 új infrastruktúra, JOIN működik, RLS működik.
- Hátrány: nagy skálán (10M+) IVFFlat beállítás nem triviális.
- Ideális: kezdéstől ~1M vektorig, ügyfél-specifikus tudásbázisok.

## Pinecone — a menedzselt gyorsulás

Ha nem akarod a vektor-indexet üzemeltetni és egy API-hívásnyira van szükséged, a Pinecone jó választás. Multi-tenant serverless, metadata filter, auto-scale. Ár: gyorsan feljebb megy, mint vártad, ha rossz a sharding.

- Előny: zero ops, gyors ramp-up, stabil latency.
- Hátrány: vendor-lock, nincs JOIN a tranzakcionális adatra, drága 10M+ vektorig.
- Ideális: gyors MVP, SaaS-ügyfelek ezreinek skálázott tartományai.

## Weaviate — a hibrid szemlélet

A Weaviate más ligát játszik: natív hibrid keresés (BM25 + vektor + filter), GraphQL-API, modulok (reranker, generator). Self-host vagy menedzselt. Jobb dokumentum-centrikus use-case-re.

- Előny: natív hibrid search, gazdag schema, multi-tenant.
- Hátrány: tanulási görbe magasabb, self-host esetén ops-teher.
- Ideális: tudásbázis-keresés, dokumentum-platformok, hibrid search szerkezet.

## A mi döntési keretünk

- Van Postgresed és &lt; 1M vektor? → pgvector.
- Multi-tenant SaaS, &lt; 10M/tenant, gyors launch? → Pinecone.
- Nagy dokumentum-korpusz, hibrid keresés first-class? → Weaviate.
- Ha bizonytalan — kezdd pgvectorral, váltás költsége alacsonyabb, mint a vendor-lock.

[TIP] A tipikus hiba: túl korán Pinecone, aztán 3 hónap múlva a számla miatt ugrik a projekt. Kezdd a pgvectorral és csak akkor válts, ha van konkrét numerikus ok rá.

## Összefoglaló

Nincs univerzális válasz. De van döntési keret. Ha segít, szívesen nézzük meg a te konkrét setup-odat — 30 perc elég egy iránypontos ajánláshoz.

---

## Case studies

### [HU] AI support copilot egy EU neobanknak — 42% költségcsökkenés, 18% CSAT-emelkedés
URL: https://dfieldsolutions.com/hu/esettanulmanyok/fintech-ai-support-copilot
Client: Anonymised (EU neobank) · Industry: fintech · Duration: 9 weeks
Stack: LangGraph, pgvector, OpenAI, Python, PostHog, OpenTelemetry

Egy gyorsan növő EU neobank support-csapata belefulladt a Tier-1 ticket-tengerbe. Retrieval-alapú copilot, szigorú guardrails-szel, élő forgalom a 4. héten, valódi CSAT-on mérve.

Problem:
- Tier-1 ticket-mennyiség 3×-ra nőtt 8 hónap alatt; a toborzás nem tudta követni.
- Előző vendor chatbotja számlaegyenleget hallucinált — a jogi csapat lekapcsoltatta.
- Nem volt eval pipeline; minden release lottó volt.
- Compliance szerint PII-nek az EU VPC-ből nem szabad kilépnie.

Solution:
- Hibrid retrieval (pgvector + BM25 + reranker) 12 ezer KB-cikken.
- LLM-router: kis modell FAQ-ra, GPT-4o érvelésre. 3,4×-es költségcsökkentés.
- Guardrails: PII-scrubber, prompt-injection-detektor, refuse-to-answer.
- CI eval halmaz 180 arany kérdéssel; ha <95% faktuális pontosság, blokkolja a deploy-t.
- Teljes observability: token, latency, minőség, cost per tenant.

Outcome:
- Megoldott ticketenkénti költség: −42%
- CSAT: +18 pont AI-kezelt beszélgetéseken
- Tier-1 deflection: 61%
- Nulla PII-szivárgás 12 hetes audit alatt
- Élő a 4. héten, teljes rollout a 9. héten

---

### [EN] AI support copilot for an EU neobank — 42% cost drop, 18% CSAT lift
URL: https://dfieldsolutions.com/en/case-studies/fintech-ai-support-copilot
Client: Anonymised (EU neobank) · Industry: fintech · Duration: 9 weeks
Stack: LangGraph, pgvector, OpenAI, Python, PostHog, OpenTelemetry

A fast-growing EU neobank's support team was drowning in Tier-1 tickets. We built a retrieval-augmented copilot with strict guardrails, live traffic in week four, metered against real CSAT.

Problem:
- Tier-1 ticket volume grew 3× in 8 months; hiring couldn't keep up.
- Previous vendor's chatbot hallucinated account balances — legal pulled it.
- No eval pipeline; every release was a gamble.
- Compliance required PII to never leave the EU VPC.

Solution:
- Hybrid retrieval (pgvector + BM25 + reranker) over 12k KB articles.
- LLM router: small model on FAQs, GPT-4o on reasoning. 3.4× cost cut.
- Guardrails: PII scrubber, prompt-injection detector, refuse-to-answer.
- CI eval suite with 180 golden questions; blocks deploy if factual accuracy < 95%.
- Full observability: tokens, latency, quality, cost per tenant.

Outcome:
- Cost per resolved ticket: −42%
- CSAT: +18 points on AI-handled conversations
- Tier-1 deflection: 61%
- Zero PII leaks during 12-week audit
- Live in week 4, full rollout by week 9

---

### [HU] Single-tenantból multi-tenant SaaS 14 hét alatt
URL: https://dfieldsolutions.com/hu/esettanulmanyok/saas-multi-tenant-migration
Client: Anonymised (US-EU B2B SaaS) · Industry: saas · Duration: 14 weeks
Stack: Next.js, Postgres RLS, Stripe, Vercel, Cloudflare, Datadog

Egy 40 tenantos B2B SaaS nekiütközött a single-tenant arkitektúra plafonjának. Átköltöztettük Postgres RLS-re, custom domainekre, metered Stripe billingre — nulla downtime-mal.

Problem:
- Minden új enterprise-deal ~2 hét DevOps-munkát igényelt külön tenantért.
- Nem volt feature-flag fegyelem; minden tenant a saját branch-ére drift-elt.
- Egy 7 számjegyű Fortune 500-deal leállt az adatizoláció miatti biztonsági aggályok miatt.
- Stripe billing manuális volt; a revenue-leakage becslés 4–6%.

Solution:
- Postgres Row-Level Security per-tenant adatizolációra; külső biztonsági cég auditálta.
- Custom domain provisioning + automatikus SSL az edge-en.
- PostHog feature flag-ek tenant-csoport szerint (Free / Pro / Enterprise).
- Stripe Subscription + metered billing, webhook → Postgres → cache invalidation.
- Admin portál tenant-váltással és teljes audit loggal.

Outcome:
- Enterprise onboarding: 2 hét → 4 óra
- Fortune 500 deal 11 héttel a migráció után zárva
- Revenue-leakage 0.3% alatt
- Nulla downtime a cutover alatt (fázisos, tenant-enként)
- A platform 120+ tenantot szolgál közös infrán

---

### [EN] From single-tenant to multi-tenant SaaS in 14 weeks
URL: https://dfieldsolutions.com/en/case-studies/saas-multi-tenant-migration
Client: Anonymised (US-EU B2B SaaS) · Industry: saas · Duration: 14 weeks
Stack: Next.js, Postgres RLS, Stripe, Vercel, Cloudflare, Datadog

A 40-tenant B2B SaaS hit the ceiling of its single-tenant architecture. We migrated to Postgres RLS, custom domains, and metered Stripe billing — with zero downtime.

Problem:
- Each new enterprise deal required ~2 weeks of DevOps to spin up a dedicated tenant.
- No feature-flag discipline; each tenant drifted to its own branch.
- Security review blocked a 7-figure Fortune 500 deal over data-isolation doubts.
- Stripe billing was manual; revenue leakage estimated 4–6%.

Solution:
- Postgres Row-Level Security for per-tenant data isolation; audited by an external security firm.
- Custom domain provisioning + automatic SSL at the edge.
- PostHog feature flags keyed by tenant group (Free / Pro / Enterprise).
- Stripe Subscription + metered billing, wired through webhook → Postgres → cache invalidation.
- Admin portal for ops to switch tenants with full audit log.

Outcome:
- Enterprise onboarding: 2 weeks → 4 hours
- Fortune 500 deal closed 11 weeks after migration
- Revenue leakage under 0.3%
- Zero downtime during cutover (phased, tenant-by-tenant)
- Platform now serves 120+ tenants on shared infra

---

### [HU] Core Web Vitals mentőakció: LCP 4.5s → 0.9s, organic +34%
URL: https://dfieldsolutions.com/hu/esettanulmanyok/ecommerce-cwv-rescue
Client: Anonymised (EU DTC brand) · Industry: ecommerce · Duration: 3 weeks
Stack: Next.js, Shopify Hydrogen, Cloudflare, Playwright

Egy DTC-brand Next.js + Shopify storefrontja kizárólag sebesség miatt veszített rankingot. Három hét, öt célzott változtatás, a forgalom visszatért.

Problem:
- LCP 4.5s (piros), CLS 0.21 (piros), INP 420ms (narancs).
- Organic forgalom −22% YoY változatlan tartalom mellett.
- Mobil konverzió 37%-kal alacsonyabb, mint desktop — iparági normán túl.

Solution:
- Hero image priority-loaded, font-display swap kalibrálva.
- Marketing-oldalak RSC-re konvertálva — hydration-payload 110 KB → 22 KB.
- Edge ISR a termékoldalakon, 300s revalidation.
- Aspect-ratio minden képen és embed-en; CLS vissza 0,01-re.
- TTFB 1,1s → 90ms Cloudflare Pages-szel.

Outcome:
- LCP: 4.5s → 0.9s
- CLS: 0.21 → 0.01
- Organic forgalom: +34% 3 hónap alatt
- Mobil konverziós rés: −37% → −8%
- Shopify Hydrogen audit átadás + runbook

---

### [EN] Core Web Vitals rescue: LCP 4.5s → 0.9s, organic +34%
URL: https://dfieldsolutions.com/en/case-studies/ecommerce-cwv-rescue
Client: Anonymised (EU DTC brand) · Industry: ecommerce · Duration: 3 weeks
Stack: Next.js, Shopify Hydrogen, Cloudflare, Playwright

A DTC brand's Next.js + Shopify storefront was losing rank to competitors purely on speed. Three weeks, five targeted changes, traffic back on track.

Problem:
- LCP 4.5s (red), CLS 0.21 (red), INP 420ms (amber).
- Organic traffic down 22% YoY despite stable content.
- Mobile conversion 37% lower than desktop — beyond industry norms.

Solution:
- Hero image priority-loaded, font-display swap tuned.
- Marketing pages converted to RSC — hydration payload 110 KB → 22 KB.
- Edge ISR on product pages, 300s revalidation.
- Aspect-ratio reserved on every image and embed; CLS back to 0.01.
- TTFB cut from 1.1s to 90ms via Cloudflare Pages.

Outcome:
- LCP: 4.5s → 0.9s
- CLS: 0.21 → 0.01
- Organic traffic: +34% in 3 months
- Mobile conversion gap: −37% → −8%
- Shopify Hydrogen audit handover + runbook

---

## Comparisons

### [HU] React Native vs Flutter
URL: https://dfieldsolutions.com/hu/osszehasonlitas/react-native-vs-flutter

Verdict: JS-heavy csapatnak és CRUD-típusú terméknek React Native nyer sebességre. Ha a csapat pixel-azonos UI-t akar minden platformra és vállalja a Dart-befektetést, Flutter nyer konzisztenciára.

When React Native:
- A csapatod már ismeri a React/TypeScript-et
- Meg akarod osztani a logikát a web-termékkel
- Rugalmasság kell a natív réteghez (bridging, third-party modulok)
- Expo-t használsz OTA frissítésekhez

When Flutter:
- Pixel-pontos UI-identitás iOS + Android között a fő cél
- Beleéred a Dart-szakértelmet a csapatba
- Nagy a custom grafika / animáció igény
- Önálló UI-toolkit kell, platform-stílus-furcsaságok nélkül

---

### [EN] React Native vs Flutter
URL: https://dfieldsolutions.com/en/compare/react-native-vs-flutter

Verdict: For a JS-heavy team and a CRUD-style product, React Native wins on velocity. For a team that wants pixel-identical UI across platforms and can invest in Dart, Flutter wins on consistency.

When React Native:
- Your team knows React/TypeScript already
- You want to share logic with the web product
- You need flexibility with the native layer (bridging, third-party modules)
- You use Expo for OTA updates

When Flutter:
- Pixel-perfect UI identity across iOS + Android is the main goal
- You can afford to build Dart expertise on the team
- You lean heavily on custom graphics / animations
- You want a self-contained UI toolkit without platform styling quirks

---

### [HU] Next.js vs Astro
URL: https://dfieldsolutions.com/hu/osszehasonlitas/nextjs-vs-astro

Verdict: Termék-jellegű oldal dinamikus UI-jal? Next.js. Marketing + blog + nagyrészt statikus docs? Astro általában nyer a súlyon és perfon. A mi oldalunk Next.js, mert kell dinamikus OG-image, API és típusos routing.

When Next.js:
- Kellenek API-routok, server actions, RSC, middleware
- Interaktív termék-jellegű UI van
- React csapatod van
- Multi-tenant, i18n, image-optimization out of the box kell

When Astro:
- Az oldal nagyrészt tartalom (marketing, blog, docs)
- MDX + minimális JS a cél
- Keretrendszer-mix (React + Svelte + Vue)
- Tisztán statikus CDN-kiszolgálás elég

---

### [EN] Next.js vs Astro
URL: https://dfieldsolutions.com/en/compare/nextjs-vs-astro

Verdict: Product-shaped site with dynamic UI? Next.js. Marketing site + blog + mostly-static docs? Astro usually wins on weight and perf. Our own site is Next.js because we need dynamic OG images, APIs, and typed routing.

When Next.js:
- You need API routes, server actions, RSC, middleware
- Your site has interactive product-style UI
- You already have a React team
- You want multi-tenant, i18n, image optimization out of the box

When Astro:
- Your site is mostly content (marketing, blog, docs)
- You want MDX + low JS shipped to the client
- You want to mix frameworks (React + Svelte + Vue)
- Pure static output on a CDN is enough

---

### [HU] Solidity (EVM) vs Rust (Solana / Anchor)
URL: https://dfieldsolutions.com/hu/osszehasonlitas/solidity-vs-rust-smart-contracts

Verdict: Maximális composability, ökoszisztéma-mélység, L2 gas-hatékonyság → Solidity L2-re. Magas throughput + alacsony latency + egy-láncos közönség → Rust Solana-ra. Mi mindkettőt írjuk.

When Solidity (EVM):
- Már meglévő DeFi-primitívekkel kell integrálódni
- A felhasználóid MetaMask-ot / wallet-connectet várnak
- Chainlink / oracle / bridge kell out of the box
- L2 gas (~1¢) belefér a unit economics-be

When Rust (Solana / Anchor):
- Sub-second finality + magas throughput kell (consumer app)
- Solana növekvő consumer userbase-ét célzod
- Rust típusrendszere és biztonsága a preferenciád
- Vállalod a kisebb ökoszisztémát a perf-ért cserébe

---

### [EN] Solidity (EVM) vs Rust (Solana / Anchor)
URL: https://dfieldsolutions.com/en/compare/solidity-vs-rust-smart-contracts

Verdict: Need maximum composability, ecosystem depth, and L2 cost efficiency → Solidity on an L2. Need high throughput + low latency + a single-chain audience → Rust on Solana. We write both.

When Solidity (EVM):
- You need to integrate with existing DeFi primitives
- Your users expect MetaMask / wallet-connect
- You want Chainlink / oracles / bridges out of the box
- L2 gas (~1¢) fits your unit economics

When Rust (Solana / Anchor):
- You need sub-second finality + high throughput (consumer apps)
- You're targeting Solana's growing consumer userbase
- You prefer Rust's type system and safety
- You're fine with a smaller ecosystem in exchange for perf

---

## Contact
Email: dezso@dfieldsolutions.com
Address: Budapest, HU