Products you can understand. Systems we can build on.

Ce era de rezolvat

Un centru medical cu un nomenclator de sute de servicii tarifare avea nevoie ca fiecare serviciu să fie o pagină proprie, găsibilă în căutare, cu preț și unitate de măsură — nu un PDF cu lista de prețuri. În plus, prețurile și echipa se schimbă, deci clinica trebuia să le poată edita singură, iar programările trebuiau să ajungă la recepție imediat, nu într-o căsuță de e-mail.

Ce am construit

Next.js 14.2.35 (App Router) cu React 18, TypeScript și Tailwind. Fiecare poziție din nomenclatorul medical a devenit o rută statică proprie: 521 de fișiere `page.tsx` în `src/app`, dintre care 481 sub `/servicii` — 184 fizioterapie, 122 servicii consultative, 61 examene medicale periodice, 27 ginecologie, 26 ozonoterapie, 23 pachete de tratament, 18 medicină alternativă, 12 diagnostic, restul pe secții. Sitemap-ul de pe producție listează 890 de adrese. Site-ul e bilingv ro/ru. Conținutul editabil (medici, pachete, tratamente, articole, setări, imagini) stă într-o bază SQLite locală prin `better-sqlite3`, cu jurnal WAL și chei străine active, administrată din `/admin` prin 20 de rute API; autentificarea folosește `jose` pentru sesiune și `bcryptjs` pentru parolă, iar schimbarea parolei invalidează sesiunile existente. Formularele de programare și de contact sunt validate cu `zod` + `react-hook-form` și trimit mesajul formatat direct în Telegram, prin Bot API. Există și un calculator de preț pe `calculator`.

Ce era de rezolvat

Meniul unui club se schimbă des, are prețuri și volume care trebuie să fie exacte, și e citit de pe telefon, în întuneric, de oameni care vorbesc trei limbi. Un PDF scanat pe un cod QR nu rezolvă nimic din asta: nu se poate căuta, nu se traduce, nu se actualizează fără să fie retipărit codul.

Ce am construit

Un meniu digital fără cadru de lucru și fără pachete: sursele reale sunt patru fișiere JSON, iar un generator Python de 402 linii scrie din ele un singur `index.html`. 119 produse în 21 de categorii, fiecare cu preț, volum, compoziție și fotografie; 119 texte scurte de prezentare, câte unul per produs; 119 seturi de recomandări de asociere („cu ce merge”), pe care le vede vizitatorul pe fiecare card. Meniul are trei limbi: româna e baza, iar rusa și engleza acoperă nu doar interfața, ci și categoriile, volumele, compozițiile, cele 82 de etichete de gust și toate cele 119 texte de prezentare. Coșul, lista de favorite și împărțirea notei rulează în browser, fără cont și fără server. Fonturile sunt găzduite pe același domeniu, nu la Google. Înainte de fiecare publicare, un script de 233 de linii rulează 16 verificări — că nu s-a strecurat niciun urmăritor, că nu se cere nimic de la un domeniu terț, că JSON-ul e valid și fiecare poză există, că meniul e complet în toate cele trei limbi, că prețurile coboară în fiecare categorie și că datele structurate din pagină sunt valide. Publicarea se face automat din GitHub Actions la fuziunea în `main`, după ce workflow-ul face o copie completă a producției și o păstrează 30 de zile.

Ce era de rezolvat

O primărie de comună trebuie să aibă pagină web oficială conformă cu HG 728/2023 — cu secțiuni fixe (transparență decizională, proiecte și decizii, anunțuri, documente, contacte, buget) — și trebuie să o poată actualiza singură, fără dezvoltator la fiecare anunț. Fără asta, informația de interes public rămâne pe hârtie sau pe un grup de Facebook.

Ce am construit

Aplicație Laravel 12 pe PHP 8.2 cu MySQL 8, front-end Vite + Tailwind, împachetată în două containere Docker (`japca_app` = nginx + PHP-FPM, `japca_db` = MySQL). Arhitectura separă intenționat două feluri de conținut: cel editorial care se schimbă rar (geografie, istoric, instituții, contacte, buget) stă într-un singur fișier de configurare PHP de 1613 linii pe care îl citesc direct șabloanele Blade, iar cel care se schimbă des (anunțuri, galerie foto, proiecte și decizii, documente, setări de transparență) stă în MySQL și se editează din panoul `/admin`. 40 de șabloane Blade, 32 de rute, 10 migrări de bază de date. Autentificarea din panou e limitată la 5 cereri pe minut de la aceeași adresă — a șasea primește 429 — iar fiecare acțiune de administrare intră într-un tabel de audit. Antetele de securitate și sitemap-ul sunt acoperite de teste automate care rulează în CI.

Ce era de rezolvat

Același lucru ca la orice meniu pe cod QR: trebuie să fie rapid pe telefon, corect la preț, citibil în trei limbi și schimbabil în cinci minute când bucătăria scoate un fel. În plus, restaurantul nu are nevoie de niciun fel de urmărire a clienților — și atunci întrebarea reală e dacă cineva chiar construiește un site care nu colectează nimic, sau doar scrie asta în politica de confidențialitate.

Ce am construit

Un singur `index.html` generat de un script Python de 377 de linii din fișiere JSON: 146 de produse în 31 de categorii, 143 de texte scurte de prezentare, plus traducerile în rusă și engleză pentru categorii, nume, volume, compoziții, etichete și texte. Coșul, lista de favorite și împărțirea notei rulează în browser. Site-ul e servit de Caddy 2 direct, cu HTTPS automat. Partea interesantă e că nedepistarea utilizatorului nu e o promisiune, ci o regulă impusă de integrarea continuă: la fiecare cerere de fuziune, CI-ul regenerează `index.html` din surse și respinge PR-ul dacă rezultatul diferă de fișierul din repo (deci pagina publicată corespunde întotdeauna surselor), apoi rulează 14 verificări — fără urmăritori, fără nicio resursă încărcată automat de la un domeniu terț, fonturi găzduite local, fără fișiere de backup ajunse în repo, politica de confidențialitate prezentă și legată din subsol, meniul complet în trei limbi, prețurile în ordine descrescătoare în fiecare categorie, datele structurate valide — și verifică inclusiv că din configul de server nu au dispărut antetele de securitate și mascarea adresei IP din jurnale. Toate acțiunile GitHub folosite sunt fixate pe suma de control a commit-ului, iar workflow-ul pornește cu `permissions: {}`.

Ce era de rezolvat

neverificat — nu avem sursele, deci nu pot descrie problema de lucru fără să o inventez.

Ce am construit

Aplicație React compilată cu Vite, servită static de nginx, cu versiune în rusă pe `/ru/`. 181 de adrese în sitemap-ul de producție. Atât se poate afirma din exterior: sursele nu sunt pe această mașină, deci nu pot numi bibliotecile, structura sau integrările.

Ce era de rezolvat

Un centru stomatologic raional avea nevoie de listă publică de servicii cu prețuri, marcaj clar al celor acoperite de asigurarea obligatorie, echipă, program de urgențe și pagini de transparență — editabile de personal, nu de programator. Când am preluat proiectul, panoul de administrare avea o problemă gravă: parola de admin era comparată în browser și ajungea în pachetul JavaScript public, iar cererile de scriere pe API se puteau face de oricine de pe internet.

Ce am construit

Aplicație React 18 + TypeScript pe Vite 6, cu rutare `react-router-dom` — 22 de ecrane, de la servicii și prețuri până la urgențe, ortodonție, implanturi, pedodonție, transparență și feedback. În spate, un API Express 4 pornit sub PM2; nginx servește fișierele construite și trimite doar `/api` mai departe. Datele publice (servicii, echipă) stau în fișiere JSON citite atât de API, cât și direct de front-end. Partea pe care am adus-o noi e securizarea: parola nu mai părăsește serverul — `POST `login` o verifică acolo și întoarce un jeton semnat HMAC-SHA256 valabil 12 ore, cu limită de 8 încercări la 15 minute pe adresă IP și comparații în timp constant; scrierile pe `services` și `team` cer acum jetonul; secretul de semnare se generează singur într-un fișier cu drepturi 0600, ținut în afara repo-ului; API-ul ascultă doar pe 127.0.0.1, deci nginx e singura cale publică; CORS e limitat la domeniile proprii, iar corpul JSON e plafonat la 1 MB. Peste asta am pus CI care compilează, verifică tipurile și refuză pachetul dacă găsește un secret în el, plus Dependabot cu ritm săptămânal pentru npm.

Ce era de rezolvat

O companie de creditare are nevoie de mai mult decât un site: cererea trebuie să intre online, să treacă printr-un flux de decizie, să producă un contract PDF, să genereze un grafic de plăți și să lase urmă în audit — iar totul trebuie să reziste la întrebările pe care le pune un client care își cere datele personale înapoi. Partea publică (calculatoare, articole, pagini pe tip de credit) trebuie în același timp să aducă oameni din căutare.

Ce am construit

Două jumătăți în același depozit. Partea publică e o aplicație Vite + React Router compilată static — 50 de ecrane, între care patru calculatoare (credit, eligibilitate, refinanțare, grafic de plăți), pagini separate pe tip de credit, blog, pagini de informare precontractuală și de conformitate. Rutele românești rămân fără prefix, iar cele rusești merg pe `/ru/…`, cu etichete canonice și alternative generate din limba rutei active. Partea de business e un backend Express modular în TypeScript, cu Prisma peste PostgreSQL: 16 module — autentificare, drepturi pe rol, fluxul cererilor, documente, plăți, notificări, sarcini programate, blog, SEO, GDPR, clienți, leaduri, contact, calculator, Google Ads, sănătate — și 18 tabele în schema Prisma, între care `Contract`, `Payment`, `AuditLog`, `GdprRequest`, `UploadedDocument`, `DailyKpiSnapshot` și `CronJobRun`. Rulează sub PM2, cu scripturi separate pentru migrări în producție, verificări înainte de lansare, generarea secretelor, copie de siguranță și restaurare a bazei.

Ce era de rezolvat

Un service auto e căutat în combinații foarte specifice — marcă plus operațiune plus cartier („reparație cutie automată BMW Botanica”). O singură pagină „Servicii” nu poate răspunde la nimic din asta. Problema tehnică e că site-ul e o aplicație React pe o singură pagină, deci ce vede motorul de căutare e un `<div>` gol dacă nu se face ceva anume.

Ce am construit

Aplicație React 19 + TypeScript pe Vite 6, cu React Router, dar prerenderizată la compilare: fiecare rută iese din build ca fișier HTML propriu, deci motorul de căutare primește conținut, nu o pagină goală. Structura de adrese a fost extinsă în trepte verificabile în istoric — de la 206 pagini indexabile, la 316 prin adăugarea combinațiilor marcă × categorie de lucrare, a articolelor și a paginilor pe sector al Chișinăului. Rutele au versiuni pe limbă, un sitemap de imagini separat, imagini Open Graph și pachetul JavaScript împărțit pentru încărcare mai rapidă. Ultimul commit a corectat un detaliu care strică indexarea tăcut: adresa canonică, `hreflang`-ul și adresele din sitemap emit acum toate aceeași formă cu bară finală.