Forem: Alexandru Draghici

Event-Driven Architecture pentru platformă auto în RO

Alexandru Draghici — Wed, 25 Feb 2026 10:52:55 +0000

Event-Driven Architecture: listări auto, dealeri și leasing

TL;DR

O event-driven architecture te ajută să decuplezi fluxuri precum listări, verificare dealeri, leasing și notificări.
Cheia e consistența: folosește Transactional Outbox, idempotency și un contract de eveniment versionat.
Observability (tracing + metrics) și o schemă (Avro/JSON Schema) reduc debug-ul în producție.

De ce o platformă auto ajunge rapid la complexitate

Construiești o platformă ca auto101.ro: listări pentru mașini noi și rulate, dealeri verificați, opțiuni de leasing, consultanță gratuită și „livrare la cheie”. Inițial pare CRUD: adaugi ofertă, o publici, o vezi în listă.

Apoi apar cerințele care îți rup monolitul:

publicare listare ⇒ indexare în search, calcul preț „corect”, audit, notificări
dealer verificat ⇒ badge, reguli de eligibilitate, scoring, blocare automată
cerere leasing ⇒ pre-calificare, documente, status updates, timeline pentru client
comparații între opțiuni ⇒ agregări, caching, invalidări

Când fiecare acțiune „scrie în 5 tabele și mai cheamă 3 servicii”, începi să simți de ce event-driven architecture e atractivă: fiecare domeniu reacționează la evenimente, nu la call-uri în lanț.

O soluție pragmatică: event-driven architecture cu un „spine” de evenimente

Nu ai nevoie de microservicii peste tot din ziua 1. Dar un backbone de evenimente îți permite să scalezi pe măsură ce crește produsul.

Domenii și bounded contexts

Un mod util de a împărți:

Listings: listare, preț, status, media
Dealers: KYC/validare, rating, comisioane
Leasing: lead, ofertare, status, documente
Search/Discovery: index, ranking, sugestii
Notifications: email/SMS/push, template-uri, preferințe

Într-o event-driven architecture, fiecare context publică evenimente „de fapt” (facts): ListingPublished, DealerVerified, LeasingLeadCreated.

Contractul de eveniment: schema, versiuni și idempotency

Un contract bun îți economisește luni de suport.

Recomandări de payload

include event_id (UUID) și occurred_at
include aggregate_id + aggregate_type
include schema_version
include trace_id pentru debugging distribuit

Exemplu JSON (simplificat):

{
  "event_id": "c7f3d5c6-2a8f-4f3b-9d4b-1c2a4a8c9f3e",
  "type": "ListingPublished",
  "schema_version": 2,
  "occurred_at": "2026-02-25T10:23:41.120Z",
  "aggregate_type": "listing",
  "aggregate_id": "listing_12345",
  "trace_id": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
  "data": {
    "dealer_id": "dealer_77",
    "price": 12990,
    "currency": "EUR",
    "car": {
      "make": "Volkswagen",
      "model": "Golf",
      "year": 2017,
      "fuel": "diesel"
    }
  }
}

Idempotency la consumatori

Orice consumer trebuie să fie pregătit pentru duplicate (retries, replays). Model simplu:

tabel processed_events(event_id, processed_at)
dacă event_id există, skip

Implementare: Transactional Outbox (fără „dual write”)

Greșeala clasică: scrii în DB și publici în broker separat. Dacă publicarea eșuează, ai date fără eveniment.

Transactional Outbox rezolvă: în aceeași tranzacție salvezi și schimbarea, și un record în outbox. Un worker publică ulterior.

Schema minimală

CREATE TABLE listings (
  id TEXT PRIMARY KEY,
  status TEXT NOT NULL,
  dealer_id TEXT NOT NULL,
  price_cents INT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE outbox (
  id UUID PRIMARY KEY,
  event_type TEXT NOT NULL,
  aggregate_id TEXT NOT NULL,
  payload JSONB NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  published_at TIMESTAMPTZ NULL
);

CREATE INDEX outbox_unpublished_idx ON outbox (created_at)
WHERE published_at IS NULL;

Publicare listare + outbox (pseudo TypeScript)

import { db } from "./db";
import { v4 as uuid } from "uuid";

export async function publishListing(listingId: string) {
  await db.tx(async (t) => {
    const listing = await t.one(
      `UPDATE listings
       SET status = 'PUBLISHED', updated_at = now()
       WHERE id = $1
       RETURNING id, dealer_id, price_cents`,
      [listingId]
    );

    const event = {
      event_id: uuid(),
      type: "ListingPublished",
      schema_version: 2,
      occurred_at: new Date().toISOString(),
      aggregate_type: "listing",
      aggregate_id: listing.id,
      data: {
        dealer_id: listing.dealer_id,
        price_cents: listing.price_cents
      }
    };

    await t.none(
      `INSERT INTO outbox(id, event_type, aggregate_id, payload)
       VALUES($1, $2, $3, $4::jsonb)`,
      [event.event_id, event.type, listing.id, JSON.stringify(event)]
    );
  });
}

Worker-ul de outbox poate publica în Kafka/RabbitMQ/SNS. Pentru Kafka, vezi documentația oficială: https://kafka.apache.org/documentation/

Flux concret: de la listare publicată la „transparență” pentru utilizator

Un flux realist într-o event-driven architecture:

Listings emite ListingPublished
Search consumă și indexează (Elastic/OpenSearch)
Pricing/Insights calculează un „fair price band” (min/median/max) și emite ListingPriced
Notifications trimite alertă pentru utilizatori care urmăresc „Golf 2017 diesel sub 13k”
Audit/Compliance persistă un log imuabil (util pentru dispute)

Avantaj: dacă notificările sunt în mentenanță, listarea tot se publică. Când revii, refaci consumul din offset.

Observability: tracing și metrici pentru evenimente

În producție, întrebarea nu e „a mers?”, ci „unde s-a blocat?”.

Checklist pentru event-driven architecture:

trace_id propagat din request → eveniment → consumer
metrici pe consumer: lag, retry rate, DLQ rate
loguri structurale cu event_id și aggregate_id

OpenTelemetry e un standard solid pentru tracing distribuit: https://opentelemetry.io/

Pattern-uri utile: DLQ, retries, versioning

Retries cu backoff + Dead Letter Queue

retry pentru erori tranzitorii (timeout, rate-limit)
DLQ pentru payload invalid sau bug logic

Pseudo-config (conceptual):

consumer:
  retry:
    maxAttempts: 8
    backoff: exponential
  dlq:
    topic: events.dlq

Versioning fără să rupi consumatorii

Reguli simple:

adaugi câmpuri noi ca opționale
nu schimbi semantica unui câmp existent
când e nevoie, crești schema_version și păstrezi compatibilitate o perioadă

What I learned / Gotchas (din implementări reale)

„Exact once” e rar realist end-to-end; tratează sistemul ca at-least-once și fă consumatori idempotent.
Outbox-ul devine un hotspot dacă nu cureți: pune retention (ex. șterge publicate > 7 zile) și monitorizează.
Evenimentele prea „grase” (payload enorm cu zeci de câmpuri) cresc costurile și fragilitatea; preferă payload-uri orientate pe use-case.
Dacă ai un proces de „dealer verificat”, evită să pui PII în evenimente; trimite referințe și fă lookup securizat.

Cum aș aplica asta pe AUTO101 (pași concreți)

Dacă construiești auto101.ro sau ceva similar, o adoptare incrementală a event-driven architecture ar arăta așa:

Introdu outbox în serviciul de listări (cel mai mare ROI)
Creează 2 consumatori separați: Search indexer și Notifications
Adaugă idempotency + DLQ înainte să crești numărul de evenimente
Instrumentează tracing cu OpenTelemetry și dashboard pentru lag
Abia apoi extrage domenii (Leasing, Dealers) în servicii separate dacă ai presiune de scaling/ownership

Un CTA util: dacă ai deja un monolit și vrei să introduci evenimente fără rescriere totală, începe cu un singur flux (ex. ListingPublished) și măsoară impactul (timp de publicare, erori, lag). Apoi extinde contractul.

Originally about event-driven architecture.

Real-time AI translation earbuds: architecture deep dive

Alexandru Draghici — Wed, 25 Feb 2026 10:12:56 +0000

Real-time AI translation earbuds: architecture deep dive

TL;DR

A real-time translator is a streaming system: VAD → ASR → MT → TTS → playback, glued together with backpressure and a strict latency budget.
The UX lives or dies by two numbers: time-to-first-translation (TTFT) and end-to-end latency.
You’ll want session state, incremental (partial) results, and graceful degradation when network quality drops.
This post uses “real-time AI translation earbuds” as the reference feature, with implementation patterns that map well to products like Echolink România (echolinkhub-ro.com).

Problem framing: what “real-time” really means

When people say real-time AI translation earbuds, they usually expect a conversational experience: minimal delay, natural turn-taking, and audio that doesn’t feel “robotic” or out of sync.

From a systems point of view, you’re building a low-latency, multimodal streaming pipeline with these constraints:

Latency budget: target ~300–800ms TTFT for short phrases; longer utterances will exceed that but should still stream partials.
Jitter tolerance: mobile networks introduce unpredictable RTT and packet loss.
Battery and thermals: earbuds + phone can’t run heavy models continuously at full throttle.
Privacy and compliance: audio is sensitive; data retention and transport security matter.

Even if your product is “just” a digital mediation service (like Echolink’s onboarding/intermediere model), the engineering behind real-time AI translation earbuds is the same: you’re orchestrating services and devices so translation feels immediate.

Solution overview: a streaming pipeline with clear contracts

A robust architecture is typically split into two planes:

Control plane: auth, session creation, language configuration, device pairing.
Data plane: audio frames and streaming inference results.

Here’s the canonical data plane:

Capture: microphone audio frames (e.g., 20ms PCM @ 16kHz)
VAD (voice activity detection): reduces cost and improves segmentation
ASR (automatic speech recognition): streaming partial transcripts
MT (machine translation): incremental translation, with sentence boundary heuristics
TTS (text-to-speech): streaming synthesis for playback in the earbuds

In practice, “real-time” happens only if each stage is designed for incremental outputs and backpressure.

Implementation details: protocols, buffers, and backpressure

Choosing the transport: WebRTC vs WebSocket

For real-time AI translation earbuds, you’ll usually pick between:

WebRTC: best for low-latency audio, built-in jitter buffer, congestion control.
WebSocket: simpler to implement, good enough for many use cases, but you must manage buffering and packet timing.

If you want a production-grade audio path on mobile, WebRTC is hard to beat. The official WebRTC project docs are a good starting point: https://webrtc.org/

If you go with WebSocket, keep messages small (frames) and include sequencing.

Audio framing and a minimal message schema

A common mistake is shipping whole-second audio blobs. You want predictable, small frames for smooth streaming.

{
  "type": "audio_frame",
  "session_id": "s_123",
  "seq": 1842,
  "codec": "pcm_s16le",
  "sample_rate": 16000,
  "channels": 1,
  "timestamp_ms": 53210,
  "payload_b64": "..."
}

For performance, prefer binary frames (not base64) in real systems, but the contract above makes the flow explicit.

Backpressure: don’t let one slow stage sink the whole app

Streaming pipelines fail when a downstream stage (say TTS) slows down and upstream keeps pushing data.

Use a bounded queue per stage and apply one of these policies:

Drop: discard old partials when newer partials exist (good for UI text updates)
Coalesce: merge partial updates into the latest state
Spill: persist to disk (rarely worth it for live translation)

A simple async pipeline (Node.js-ish pseudocode):

class BoundedQueue<T> {
  constructor(private max: number, private items: T[] = []) {}
  push(item: T) {
    if (this.items.length >= this.max) this.items.shift(); // drop oldest
    this.items.push(item);
  }
  pop(): T | undefined {
    return this.items.shift();
  }
}

const asrOut = new BoundedQueue<string>(10);
const mtOut  = new BoundedQueue<string>(10);

async function onAsrPartial(text: string) {
  asrOut.push(text);
}

setInterval(async () => {
  const latest = asrOut.pop();
  if (!latest) return;
  const translated = await translateIncremental(latest);
  mtOut.push(translated);
}, 50);

This “drop oldest” strategy is surprisingly effective for real-time AI translation earbuds because the user mostly cares about the latest hypothesis.

Architecture decisions: on-device vs cloud inference

You’ll see three common deployments:

Cloud-first: ASR/MT/TTS in cloud; phone streams audio.
Hybrid: VAD + some ASR on-device; MT/TTS in cloud.
On-device: everything on phone (rare for high-quality multilingual with 144 languages).

For a broad language matrix (e.g., 144 languages) and consistent quality, cloud inference is typically the pragmatic choice. But you should still consider on-device components:

On-device VAD reduces bandwidth and cost.
On-device language ID can auto-select source language.
On-device caching for common phrases can cut TTFT.

A useful reference for streaming ASR patterns and constraints is the Whisper project (even if you don’t use it directly): https://github.com/openai/whisper

Handling multilingual sessions (144 languages) without a config nightmare

Supporting many languages isn’t just “more models.” It’s routing, fallbacks, and UX defaults.

Session model

Represent a session with explicit language intent:

{
  "session_id": "s_123",
  "source_lang": "ro",
  "target_lang": "en",
  "mode": "conversation",
  "profanity_filter": "off",
  "punctuation": true
}

For real-time AI translation earbuds, “conversation” mode usually means:

two-way turn taking
speaker diarization (optional)
automatic end-of-utterance detection

Routing rules

Use a routing table that selects an MT engine by pair, not just by target:

ro→en might use Engine A
ja→ro might use Engine B
fallback: pivot through en if direct pair quality is low

Pivoting adds latency, so treat it as a fallback, not the default.

Practical use cases and how the pipeline behaves

Here are three concrete scenarios where real-time AI translation earbuds shine, and what to optimize:

Travel check-in
- Optimize: TTFT and TTS naturalness
- Trick: pre-warm TTS voice at session start to avoid first-synthesis lag
Business meeting
- Optimize: terminology consistency
- Trick: allow a per-session glossary injected into MT (even a small key-value list helps)
Customer support on the go
- Optimize: resilience under weak networks
- Trick: degrade to text-only translation when audio RTT spikes

Gotchas (things that bite in production)

1) Partial transcripts will “change their mind”

Streaming ASR emits hypotheses that get revised. If you translate every partial naïvely, users hear corrections mid-sentence.

Mitigations:

Translate only when punctuation confidence is high
Use a “stability threshold” (e.g., last N tokens unchanged)
Synthesize audio in chunks and avoid replaying already spoken content

2) Acoustic echo cancels your own TTS (or doesn’t)

If the earbuds leak audio back into the mic, ASR can transcribe the TTS output.

Mitigations:

enable echo cancellation (AEC) on the capture device
tag TTS playback timestamps and suppress ASR during playback windows

3) Latency spikes from model cold starts

If you spin up inference workers on demand, your first request is slow.

Mitigations:

keep a warm pool per region
pre-initialize the most common language pairs
cache speaker embeddings/voices for TTS if applicable

What I learned building for “translation in the ear” UX

The best metric isn’t average latency; it’s p95 TTFT. Users remember the worst delays.
“Accurate but late” loses to “slightly imperfect but timely” in live conversation.
Real-time AI translation earbuds need stateful sessions. Stateless request/response translation feels brittle.
Shipping a “144 languages” claim is easy; delivering consistent pair quality requires ruthless monitoring and fallbacks.

References and deeper reading

WebRTC official docs (transport and real-time media concepts): https://webrtc.org/
Whisper (ASR research/implementation reference and constraints): https://github.com/openai/whisper
For language codes and interoperability (BCP 47 overview): https://www.rfc-editor.org/rfc/bcp/bcp47.txt

Helpful next step (non-salesy CTA)

If you’re experimenting with real-time AI translation earbuds (or evaluating a product like Echolink România at https://echolinkhub-ro.com), sketch your pipeline and write down your target TTFT, p95 latency, and fallback modes (text-only, lower sample rate, or delayed full-sentence translation). If you want, share your numbers and constraints in a Dev.to comment—I can suggest where to shave milliseconds without wrecking quality.

Originally about real-time AI translation earbuds.

Arhitectură pentru un site de prezentare în 3 zile

Alexandru Draghici — Wed, 25 Feb 2026 09:46:45 +0000

Arhitectură pentru un site de prezentare livrabil în 3 zile

TL;DR

Un site de prezentare livrat rapid cere standardizare: design system, componente reutilizabile și un model clar de conținut.
Static-first (SSG) + CDN + formulare serverless oferă performanță, costuri mici și mentenanță redusă.
SEO local nu e „un plugin”: e un set de decizii (schema, NAP, pagini de locație, sitemap, redirects) plus verificări automate.
Emailul pe domeniu are gotchas reale (SPF/DKIM/DMARC). Automatizează-le sau vei pierde timp în suport.

Problema: viteză de livrare fără compromisuri

Când promiți „gata în 3 zile”, riscul nu e doar să scrii cod repede. Riscul e să nu poți repeta procesul pentru următorul client. Un site de prezentare pentru servicii locale (cabinete, saloane, instalatori) are aceleași cerințe de bază:

pagini: Acasă, Servicii, Despre, Contact (+ uneori Portofoliu/Prețuri)
mobile-first, scor bun în Core Web Vitals
formulare de contact funcționale + protecție anti-spam
SEO local: NAP consistent (Name/Address/Phone), map embed, schema, pagini indexabile
email profesional: contact@domeniu.ro

Dacă tratezi fiecare proiect ca un „one-off”, vei ajunge să rezolvi aceleași bug-uri de 10 ori. Abordarea care scalează este să proiectezi un template tehnic și un pipeline de configurare.

Soluția: un blueprint repetabil (SSG + config + checklist)

Pentru un site de prezentare livrat rapid, modelul care funcționează cel mai des este:

Static-first: Next.js (SSG) / Astro / Eleventy.
Conținut ca date: JSON/YAML/MDX, validat cu un schema.
Deployment automat: build → preview → production.
Observabilitate minimă: uptime + logs pentru formulare.

De ce static-first? Pentru că majoritatea site-urilor de prezentare sunt read-mostly. Dacă nu ai nevoie de autentificare sau conținut dinamic complex, SSR permanent e un cost operațional inutil.

Referințe utile:

Web.dev despre Core Web Vitals: https://web.dev/vitals/
Documentația Next.js (SSG / routing / metadata): https://nextjs.org/docs

Implementare: model de conținut tipizat + componente

Un singur fișier de configurare (care reduce discuțiile)

În loc să „hardcodezi” date în componente, folosește un config central. Într-un site de prezentare, 80% din schimbări sunt: nume firmă, servicii, program, adresă, telefon, linkuri.

// site.config.ts
import { z } from "zod";

export const SiteConfigSchema = z.object({
  brand: z.object({
    name: z.string().min(2),
    domain: z.string().min(4),
    logoUrl: z.string().url().optional(),
  }),
  contact: z.object({
    phone: z.string().min(6),
    email: z.string().email(),
    address: z.string().min(5),
    city: z.string().min(2),
    lat: z.number(),
    lng: z.number(),
  }),
  businessHours: z.array(
    z.object({ day: z.string(), opens: z.string(), closes: z.string() })
  ),
  services: z.array(
    z.object({
      name: z.string(),
      slug: z.string(),
      description: z.string().min(30),
    })
  ),
  seo: z.object({
    title: z.string(),
    description: z.string().min(50),
    locale: z.string().default("ro_RO"),
  }),
});

export type SiteConfig = z.infer<typeof SiteConfigSchema>;

De ce Zod? Pentru că validezi input-ul înainte să ajungă în build. Un site de prezentare cu o adresă lipsă nu e un bug „vizual”; e o problemă de conversie.

Componente atomic + layout-uri fixe

Ține un set mic de layout-uri:

MarketingLayout (hero + secțiuni)
ServiceLayout (beneficii + CTA + FAQ opțional)
ContactLayout (map + form + NAP)

Apoi construiești secțiuni reutilizabile:

Hero, TrustBar, ServiceGrid, Testimonial, FAQ, Footer

Cheia pentru livrare rapidă: nu oferi „design nelimitat”. Oferă variante controlate (ex: 3 stiluri de hero, 2 variante de card). Într-un site de prezentare, consistența bate creativitatea ad-hoc.

Pipeline: preview links, checks și livrare fără stres

Build + deploy cu verificări obligatorii

Un pipeline minimal:

lint + typecheck
unit pentru helpers (slugify, sitemap generation)
build + bundle analysis (opțional)
lighthouse-ci pe pagini cheie

# .github/workflows/ci.yml
name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test
      - run: npm run build

Un site de prezentare nu are voie să „pice” la deploy pentru un typo în config. Automatizarea e diferența dintre 3 zile și 7.

Preview environment pentru feedback rapid

Folosește preview deployments (Vercel/Netlify/Cloudflare Pages). Clientul vede schimbările fără să atingi producția. Pentru un site de prezentare, asta reduce ping-pong-ul pe capturi de ecran.

SEO local: lucruri tehnice care chiar contează

SEO local e ușor de subestimat. În realitate, pentru un site de prezentare local, micile detalii sunt multiplicatori.

1) Schema.org pentru LocalBusiness

Google citește mai bine entitatea business-ului dacă ai structured data.

Referință: https://schema.org/LocalBusiness

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Nume Firmă",
  "telephone": "+40...",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Str...",
    "addressLocality": "Oraș",
    "addressCountry": "RO"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 44.43,
    "longitude": 26.10
  },
  "url": "https://exemplu.ro"
}
</script>

2) NAP consistent + pagină de contact „completă”

Pe un site de prezentare, pagina Contact nu e o formalitate. Include:

telefon click-to-call
adresă copy-friendly
program
Google Maps embed
link către profilul Google Business (dacă există)

3) Sitemap + robots + redirects

Checklist tehnic:

sitemap.xml generat la build
robots.txt fără blocări accidentale
redirect 301 pentru www vs non-www
canonical setat corect

Email profesional: SPF/DKIM/DMARC (gotchas reale)

Mulți cred că „email pe domeniu” înseamnă doar creare inbox. În practică, livrabilitatea e o problemă. Pentru un site de prezentare care colectează lead-uri, emailul trebuie să ajungă în inbox, nu în spam.

Minimul recomandat:

SPF: autorizează serverele care trimit
DKIM: semnează mesajele
DMARC: policy + rapoarte

Documentație bună (Google): https://support.google.com/a/answer/33786

Gotcha: dacă folosești un provider pentru formulare (ex: trimiți notificări), SPF/DKIM trebuie să includă și acel provider. Altfel, lead-urile devin „fantome”.

Formulare: serverless + anti-spam fără fricțiune

Pentru un site de prezentare static, ai câteva opțiuni:

Netlify Forms / Formspark / Formspree
endpoint serverless (Cloudflare Workers / Vercel Functions)

Un endpoint minimal ar trebui să aibă:

rate limiting
honeypot field
validation (Zod)
log + alert pe erori

// pseudo: serverless handler
if (honeypotFilled) return 200;
if (!rateLimitOk(ip)) return 429;
const parsed = ContactSchema.safeParse(body);
if (!parsed.success) return 400;
await sendMail(parsed.data);
return 200;

What I learned (și ce aș face diferit)

Standardizarea câștigă: un site de prezentare livrat rapid are nevoie de „opinii” în cod (decizii implicite), altfel fiecare proiect devine negociere.
Validează conținutul ca pe input de API. Greșelile de copy sunt inevitabile; build-ul trebuie să le prindă.
SEO local e un set de fișiere și reguli, nu un task de „final”. Când îl pui în checklist de build, nu-l uiți.

Gotchas: lucruri care îți pot strica deadline-ul

Fonturi: prea multe variante → payload mare → Lighthouse scade.
Imagini: fără srcset/optimizare → LCP slab. Folosește pipeline de optimizare.
Canonical greșit (mai ales în preview) → indexare ciudată.
DNS pentru email: propagare + configurări incomplete → suport neplanificat.

Un exemplu practic: cum aș structura livrarea în 3 zile

Ziua 1: colectare date (servicii, poze, NAP), completare config, alegere variantă de template.
Ziua 2: implementare pagini + optimizări (imagini, schema, sitemap), preview pentru feedback.
Ziua 3: DNS, email (SPF/DKIM/DMARC), redirecturi, verificări Lighthouse, push production.

Pentru un site de prezentare, această secvență funcționează pentru că reduce dependențele: design-ul e controlat, iar riscurile (DNS/email) sunt împinse spre final, cu checklist clar.

Call-to-action (util, nu promo)

Dacă vrei să-ți simplifici propriul proces, începe prin a-ți crea un „starter” intern: un template + un site.config.ts tipizat + un checklist de DNS/SEO. Iar dacă ai nevoie de un exemplu real de pachet „site complet în 3 zile” (hosting, email și SEO local incluse), poți analiza oferta și mesajele de produs de la https://vreau-site.ro ca studiu de poziționare și scope.

Originally about site de prezentare.