Romana
English
Francais
Deutsch
EspanolPunctul de plecare
OmniWatchGuard a crescut rapid pe parcursul catorva luni — functii noi, pagini noi, copy nou la fiecare sprint. La un moment dat mi-am dat seama ca nu mai stiam sigur, fara sa verific codul, care afirmatii de pe site erau adevarate si care ramasesera din faza de planificare.
Nu a fost o decizie deliberata de a minti. A fost genul de discrepanta care apare natural intr-un produs solo-founder: scrii copy pentru o functie inainte s-o construiesti, o pui pe roadmap, apoi in graba de a lansa alte lucruri, copy-ul ramane neschimbat luni de zile.
Rezultatul auditului e acum reflectat direct in produs — vezi planurile actualesau testeaza gratuit ca sa vezi exact ce e implementat, nu ce promitea copy-ul vechi.
Procesul: cum am gasit discrepantele
N-am pornit de la o lista de suspiciuni. Am pornit de la o intrebare simpla:fiecare fisier care genereaza continut public — pagini, componente de FAQ, schema JSON-LD, calculatorul de pret — corespunde cu ce exista efectiv in cod?
- Am enumerat toate fisierele care produc copy vizibil userului sau motoarelor de cautare:
FAQ.astro,FAQSchema.astro,FAQEnterprise.astro,PricingSchema.astro,Comparison.astro,Calculator.astro,SoftwareAppSchema.astro,AggregateRatingSchema.astro,privacy.astro - Pentru fiecare afirmatie de functionalitate ("suporta X", "monitorizeaza Y"), am cautat implementarea reala in backend/crawler
- Am clasificat fiecare afirmatie in trei categorii: adevarata (implementata si testata), partial adevarata (implementata dar cu limitari nementionate), falsa (doar pe roadmap sau niciodata construita)
- Pentru fiecare afirmatie falsa sau partiala, am ales una din doua actiuni: fie corectez copy-ul sa reflecte realitatea, fie construiesc functia ca sa devina adevarata
Ce am gasit
Rating-uri si testimoniale hardcodate
AggregateRatingSchema.astro si Testimonials.astro aveau un rating fix de 4.9, un numar fix de "200+ recenzii" si "500+ companii", plus nume si citate de testimoniale scrise direct in cod — nu existau clientii respectivi. Am inlocuit totul cu date reale, calculate din tabelul reviews din baza de date: rating mediu si numar de recenzii real, sectiunea de testimoniale se ascunde singura daca nu exista inca nicio recenzie reala. CTA-ul "lasa o recenzie" ramane vizibil permanent.
Functii pe roadmap prezentate ca live
Monitorizarea de pagini cu login, RBAC (roluri si permisiuni) si SSO apareau in FAQ si in tabelul de comparatie ca functii disponibile. Nu erau. Am corectat toate cele sase fisiere afectate (FAQ, FAQSchema, PricingSchema, Comparison, Calculator, SoftwareAppSchema) sa arate clar "Roadmap 2026" pentru RBAC/SSO, si am eliminat complet afirmatia despre aplicatii iOS/Android care nu existau si nu erau planificate.
Bug de afisare care ascundea o problema reala
Componenta Comparison.astro de pe homepage avea un bug de rendering care afisa bifa verde (✓) pentru orice functie, indiferent de datele reale din spate — inclusiv pentru functii pe care concurenta le avea si noi nu. Practic, tabelul de comparatie mintea din cauza unui bug tehnic, nu doar din copy invechit.
| Ce am gasit | Inainte | Dupa |
|---|---|---|
| Rating si testimoniale | Hardcodate, false | Din baza de date reala, se ascund daca nu exista date |
| Login-page monitoring | Prezentat ca live | Corectat la "Roadmap 2026", apoi construit efectiv |
| RBAC / SSO | Prezentat ca live | Marcat clar "Roadmap 2026" |
| Aplicatii iOS/Android | Mentionate | Eliminate — nu exista, nu sunt planificate |
| Tabel de comparatie | Bug: afisa ✓ pentru orice | Reparat, reflecta date reale |
De ce am ales sa construim functia, nu doar sa corectam copy-ul
Pentru monitorizarea de pagini cu login, am avut de ales: corectez copy-ul (rapid, o ora de munca) sau construiesc efectiv functia (mai mult efort, dar rezolva problema la radacina). Am ales a doua varianta. Am adaugat o coloana criptata (AES-GCM) pentru cookie/header de autentificare pe tabelul de monitoare, crawler-ul decripteaza si injecteaza header-ul pe ambele cai de fetch (plain si Puppeteer), si detecteaza expirarea sesiunii prin cod 401/403 sau redirect catre o pagina de login. Am testat-o end-to-end chiar pe dashboard-ul propriu OmniWatchGuard (care foloseste Authorization: Bearer, nu cookie) inainte sa republicam copy-ul ca fiind adevarat.
Ce a ramas neschimbat
Nu tot ce am gasit incomplet a fost si corectat prin construire. RBAC si SSO raman pe roadmap real pentru 2026 — sunt marcate ca atare, fara ambiguitate, si nu promitem o data exacta pana nu incepem lucrul efectiv la ele.
Intrebari frecvente
De ce publicati asta in loc sa corectati linistit?
Pentru ca procesul in sine e util altor solo-founderi care se lovesc de aceeasi discrepanta naturala intre roadmap si copy de marketing, si pentru ca transparenta despre ce e adevarat azi construieste incredere mai buna decat orice testimonial.
Cum preveniti sa se repete aceeasi problema?
Nu exista inca un proces automatizat care sa previna complet discrepanta — e un risc structural la orice produs cu iteratie rapida. Ce s-a schimbat concret: rating-urile si testimonialele nu mai pot fi hardcodate (vin exclusiv din baza de date), iar orice functie noua mentionata in copy trece printr-o verificare manuala fata de cod inainte de publicare.
Auditul a acoperit si paginile in engleza?
Da, toate corectiile au fost aplicate simetric pe versiunile RO si EN ale fiecarui fisier afectat, inclusiv schema JSON-LD folosita de motoarele de cautare.