Fabrica de site-uri

Problema și motivația

Foarte multe afaceri mici din România, frizerii, restaurante, cafenele, saloane de înfrumusețare, ateliere, sunt prezente online doar printr-o pagină de Facebook, un profil pe o aplicație de livrare sau un fișă de Google Maps. Nu au site propriu, nu au domeniu, sau au unul mort ori parcat. Pentru ele, un site nu este o problemă de tehnologie, ci una de timp și de încredere: nimeni nu le-a arătat cum ar arăta concret site-ul lor.

The Website Factory pornește exact de la această observație. În loc să vândă o promisiune abstractă, sistemul construiește mai întâi o demonstrație palpabilă, site-ul fiecărui prospect, randat din datele lui reale, pe un URL pe care îl poate deschide imediat. Argumentul de vânzare devine: site-ul tău există deja, mai trebuie doar pornit.

Arhitectura și cum funcționează

Sistemul este un pipeline în mai mulți pași, fiecare un modul Python separat care scrie într-o singură bază DuckDB, website.duckdb. Pașii sunt: descoperire, îmbogățire, scoring, randare mockup, apoi un CRM de tip pâlnie pentru urmărirea vânzării.

Descoperirea (maps_prospect_scan.py) este hibridă și rulează pe lane-uri gratuite. Coloana vertebrală este OpenStreetMap prin API-ul public Overpass: pentru fiecare oraș și fiecare cod CAEN se lansează o interogare pe granița administrativă a orașului, filtrată pe etichete OSM. Maparea CAEN către etichete OSM este explicită: 9602 (coafură, frizerie) către shop=beauty|hairdresser, 5610 (restaurante) către amenity=restaurant|fast_food, 5630 (cafenele, baruri), 9604 (fitness), 4520 (service auto), 5510 (cazare). O a doua bandă, Google Places, este dormantă și se activează doar când apare o cheie, stocând strict place_id și verdictul propriu, pentru a respecta condițiile de utilizare. O a treia bandă, cascada de scraping, verifică în pasul de îmbogățire dacă afacerea chiar are sau nu site.

Scoringul (prospect_score.py) este partea care dă direcție întregului efort. Scorul final, de la 0 la 100, combină două dimensiuni. Nevoia (score_need) măsoară golul digital: fără site sau site mort înseamnă 1.0, doar Facebook 0.8, site slab 0.5, site bun 0.0. Accesibilitatea (score_reach) măsoară cât de ușor poate fi contactată și convinsă afacerea: prezența unui telefon, semnale de cumpărare precum rating și număr de recenzii, și un steag pentru afacerile care sunt pe o aplicație de livrare dar nu au site. Formula este scor = 100 · nevoie · (0,4 + 0,6 · accesibilitate), astfel încât nevoia domină, iar accesibilitatea scalează rezultatul. Practic, în vârful listei ajung afacerile care au cea mai mare nevoie de site și sunt cel mai ușor de contactat.

Generarea mockup-urilor

Aici se află inima sistemului. Au existat două generații. Prima, mockup_gen.py, cerea unui model de limbaj gratuit să producă un one-pager în română din datele prospectului. S-a dovedit că această abordare genera schelete subțiri, cu detalii inventate. A doua generație, render_mockup.py, a înlocuit improvizația modelului cu un randor determinist pe șabloane.

Randorul determinist umple un șablon real per verticală, restaurant, cafenea sau frizerie cu accent dedicat, folosind doar câmpuri chiar culese. Tot ce nu a fost cules, fotografii, meniu exact, ore precise, se randează ca un placeholder demonstrativ clar etichetat, niciodată inventat și prezentat ca fapt. Această decizie nu este cosmetică: este o garanție de onestitate, fotografiile, meniul și recenziile reale se injectează abia într-un pas separat de culegere de active, înainte de trimitere.

Peste conținut, scriptul injectează determinist o postură de protecție pe care nu o lasă niciodată pe seama modelului: o meta-etichetă noindex ca demo-urile să nu apară în motoarele de căutare, plus o panglică-filigran vizibilă în partea de sus care anunță clar, în română, că este o propunere demo, un site neoficial realizat ca demonstrație pentru proprietar, cu numele afacerii, data și mențiunea că se șterge la cerere. Fiecare mockup primește un slug și un URL de previzualizare bazat pe cale, sub mockups.popescubogdan.ro. Nimic nu se publică automat: orice deploy rămâne o decizie confirmată manual.

Decizii tehnice cheie

Produsul final, scheletul din SITES/client-template, este construit pe Astro cu randare statică și i18n. Limba implicită este româna, fără prefix în URL, iar engleza stă sub /en/, ca rute reale, nu ca un comutator JavaScript. Trei pagini de start verticale, broșură, servicii cu programare, și magazin sunt cablate ca rute i18n adevărate, fiecare cu varianta ei EN, astfel încât pentru fiecare client se păstrează verticala potrivită.

Layout-ul partajat, Base.astro, folosește deliberat un stack de fonturi de sistem, fără fonturi web care ar bloca randarea, ca să rămână prietenos cu Lighthouse. Culorile de accent per verticală se injectează prin variabile, iar comutarea de limbă se face pe bază de rută. Componentele de verticală primesc string-uri per limbă ca proprietăți, deci o singură componentă servește două rute, fără duplicare.

Pentru editare proprie, sistemul folosește Decap CMS din public/admin/, care editează src/data/site.json (brand, telefon, WhatsApp, email, adresă, titlu și subtitlu în RO și EN) plus folderul de blog. Pagina de start citește din acest JSON, deci editarea fișierului urmată de un rebuild actualizează site-ul, lucru verificat pe toate verticalele.

Formularul de contact este o Pages Function (functions/api/contact.ts): verifică token-ul Cloudflare Turnstile prin endpoint-ul siteverify, apoi trimite mesajul printr-un binding Email Workers către o adresă verificată pe zona clientului. Astfel formularul funcționează fără un server propriu și fără cost lunar.

Anti-fragilitate, performanță, cost și testare

Mai multe decizii sunt orientate spre robustețe. Descoperirea respectă lane-urile publice: o pauză politicoasă între interogările Overpass și interogări secvențiale, ca să nu suprasolicite serviciul gratuit. Postura noindex plus filigranul plus mențiunea de proprietar protejează demo-urile, atât din punct de vedere legal cât și etic. Regula de a nu inventa nimic, ci de a marca explicit orice placeholder, ține întreaga producție în limitele a ceea ce se poate susține cu date reale.

Pe performanță, scheletul de client a fost măsurat cu Lighthouse: scor de performanță 0,99, accesibilitate 0,95 și SEO 1,0 pe pagina de start, peste pragul intern de 90. Stack-ul de fonturi de sistem și randarea statică sunt cauza directă a acestor scoruri.

Pe cost, întregul produs rulează pe nivelul gratuit Cloudflare: Pages pentru găzduire, DNS, SSL și Email Routing pentru email, Turnstile pentru anti-bot, toate la 0 EUR pe lună. Pipeline-ul de descoperire și scoring rulează tot pe lane-uri gratuite și local. Pe testare, scheletul include scripturi de QA pe build, qa_dist.py și qa_leak.py, care verifică existența rutelor, scanează textul vizibil EN după scurgeri de română și verifică rezolvarea legăturilor din footer. Descoperirea are o poartă de smoke test: un oraș cu două coduri CAEN înainte de a scala.

Rezultatul și starea curentă

Sistemul a produs aproximativ 100 de mockup-uri individuale pentru afaceri reale din Iași, Cluj-Napoca, Timișoara și Sector 1, fiecare cu propriul slug și URL de previzualizare. Modelul comercial este simplu și fix: 2.000 RON cu plată integrală la semnare, livrare în 7 zile de la plată și conținut, site bilingv întotdeauna, editabil de către client prin CMS, găzduit la 0 EUR pe lună. Procesul de vânzare este telefonic, condus de proprietar, cu o cadență de trei atingeri: apel, link-ul mockup-ului în aceeași zi, reapel la trei zile și un memento la șapte zile. Pe scurt, The Website Factory este o linie de producție care duce o afacere fără prezență web de la o intrare într-un registru public până la un site demonstrativ pe care îl poate vedea înainte să spună da.