În Q3 din #OneAppPerQuarter am construit un sistem mic care mă ajută să creez, să personalizez și să livrez site-uri Next.js pentru afaceri locale, cu mai puțină muncă repetitivă. În testul meu înregistrat, pregătirea unui demo a durat în medie sub o jumătate de oră pentru fiecare încercare de contact.
Fluxul are trei puncte de plecare: cabinete medicale, servicii profesionale și servicii pentru casă. ChatGPT pregătește un brief verificat. Cursor implementează pagina. Clientul primește în continuare codul site-ului și îl poate publica în conturile lui.
Am întârziat puțin cu articolul de Q3. Q4 este deja bine pornit și nu am vrut să las o gaură în serie.
Ce este proiectul din Q3, pe scurt?
- Autor: Lucian Olosutean, software engineer în Cluj-Napoca, România.
- Provocare: #OneAppPerQuarter, câte un proiect publicat în fiecare trimestru din 2026.
- Rezultatul din Q3: un mod repetabil de a pregăti un demo de site Next.js pentru o afacere locală.
- Puncte de plecare: cabinete medicale, servicii profesionale și servicii pentru casă.
- Unelte: ChatGPT pentru un brief verificat, Cursor pentru implementare, Next.js pentru site.
- Ritmul înregistrat: sub 30 de minute în medie pentru o încercare de contact, în testul meu.
- Predare: clientul primește codul site-ului și îl publică în conturile lui.
- Limită: un site de client terminat are în continuare nevoie de o conversație, de materiale, de revizuiri și de verificări înainte de publicare.
Ce este #OneAppPerQuarter și ce a fost înainte de Q3?
#OneAppPerQuarter este provocarea mea din 2026: să public câte un proiect real în fiecare trimestru. Singura regulă este ca proiectul să fie disponibil online.
În Q1 am construit Tavoris, un instrument asistat de AI pentru pregătirea documentelor de înființare a unei firme în România. Am scris despre trimestrul acela în articolul Q1 #OneAppPerQuarter.
În Q2 am lucrat la experiențe conversaționale. Am adăugat un AI chat pe lolotech.io și un asistent AI pe Weddnesday. Pașii aceștia sunt în articolul despre AI chat-ul din portofoliu și în articolul Q2 despre Weddnesday.
Q3 a mers în altă direcție. Construisem site-uri pentru clienți și tot observam munca care se repetă de la un proiect la altul. Pregătirea proiectului, așezarea în pagină, adaptarea conținutului, verificarea pe telefon, publicarea și predarea. Niciunul dintre pașii aceștia nu este deosebit de greu de unul singur. Împreună, însă, consumă timp.
Am vrut să văd cât din procesul acesta pot simplifica.
De ce prefer în continuare să scriu site-ul în cod?
Ar trebui să încep cu o preferință personală: îmi plac site-urile scrise în cod. Știu că WordPress și constructorii de site-uri își au locul lor și că, pentru unele proiecte, sunt alegeri perfect rezonabile. Mie îmi place să am control deplin asupra a ceea ce construiesc.
Când un client cere un anumit layout sau o anumită interacțiune, nu vreau să-mi petrec timpul luptându-mă cu o temă sau ocolind un plugin. Prefer să implementez direct ceea ce are nevoie. Acesta este unul dintre motivele pentru care îmi place să lucrez cu Next.js.
Construiam deja un site de prezentare cu mai multe pagini pentru un client, folosind Next.js și asistență AI. Procesul a fost surprinzător de direct. Puteam ajusta designul pe măsură ce îl discutam, publica rezultatul pe Vercel și păstra proiectul în conturile de GitHub și Vercel ale clientului.
Pentru site-ul acela de prezentare, planurile gratuite au acoperit ce ne trebuia. Domeniul a fost costul separat. Asta nu înseamnă că orice site poate rula gratuit la nesfârșit. Depinde de trafic, de funcționalități și de serviciile pe care le folosește. Pentru un site relativ simplu, a fost o configurație bună.
Mi-a plăcut și partea de proprietate. Clientul avea codul și publicarea în conturile lui. Nu depindea de mine doar ca să țină site-ul online.
După proiectul acela m-am întrebat dacă următorul site poate fi și mai ușor de construit.
Cum a devenit un site de client un proces repetabil?
Primul pas a fost o pagină de site-uri pe LOLOTECH. Voiam o ofertă simplă, pe care proprietarul unei afaceri mici să o înțeleagă fără o conversație tehnică înainte.
Apoi am început să lucrez la procesul din spatele paginii.
Am creat un proiect ChatGPT dedicat și i-am dat documentație despre tipurile de afaceri cu care voiam să lucrez, despre informațiile necesare unui site, despre lucrurile care trebuie verificate înainte de start și despre felul în care voiam să fie pregătite demo-urile.
O parte mi-a cerut mai multă atenție decât mă așteptam: ca informația să fie corectă. Când pregătești un concept de site pentru o afacere reală, AI-ul umple ușor golurile cu ceva care sună plauzibil. Un serviciu pe care firma l-ar putea oferi. O afirmație despre experiență. O dată de contact luată de la o firmă cu nume asemănător.
Asta nu este suficient de bun pentru un site real.
Așa că am petrecut timp definind ce poate folosi sistemul, ce trebuie verificat și ce trebuie pur și simplu lăsat pe dinafară. ChatGPT a devenit util pentru a organiza cercetarea și a pregăti un brief consecvent, nu pentru a genera un text atrăgător.
Pe partea de dezvoltare am folosit Cursor. Am pus reguli de proiect, documentație și structuri de site reutilizabile, ca să nu explic aceleași decizii de fiecare dată când începeam un demo nou.
Cum își împart ChatGPT și Cursor treaba?
Am împărțit munca între cele două unelte. ChatGPT ajută la pregătirea informațiilor despre afacere și a direcției pentru site. Cursor lucrează cu brief-ul acela și implementează pagina. Eu verific în continuare conținutul, așezarea în pagină și comportamentul.
A fost nevoie de destulă încercare și eroare ca să iasă responsabilitățile astea bine. La început, mai multe instrucțiuni păreau soluția evidentă. Instrucțiuni mai clare și mai puține responsabilități suprapuse au funcționat mai bine.
Care sunt cele trei puncte de plecare?
Am ajuns la trei puncte de plecare principale. Împart o mare parte din codul de dedesubt și nu ar trebui să arate sau să se citească la fel.
- Cabinete medicale. Serviciile și datele de contact trebuie să fie ușor de găsit.
- Servicii profesionale. Tonul trebuie să rămână precis. Site-ul unui avocat are nevoie de o voce diferită de site-ul unui instalator.
- Servicii pentru casă. Un buton clar de apel și o explicație directă a lucrării contează adesea mai mult decât o pagină lungă.
Șabloanele îmi dau o structură de start. Partea interesantă este adaptarea structurii la o anumită afacere.
Pot pregăti un concept de site folosind informațiile verificate ale afacerii, îl deschid local, fac ajustări vizuale sau de conținut și public un demo pentru revizuire. Nu mai recreez configurarea proiectului de fiecare dată.
Direcțiile generale se văd aici:
Cum primește clientul site-ul gata?
Am lucrat și la ultima parte a procesului, ușor de trecut cu vederea când partea interesantă este dezvoltarea: predarea. Odată ce site-ul este gata, am o comandă care pregătește o versiune de sine stătătoare a proiectului pentru repository-ul clientului. Uneltele reutilizabile rămân la mine. Clientul primește codul site-ului și poate gestiona publicarea finală în conturile lui.
Asta contează pentru mine. Nu vreau ca un site simplu de prezentare să ceară o relație complicată cu dezvoltatorul care l-a construit. Oferta pe care o susține fluxul acesta este pe pagina de site-uri LOLOTECH.
Ce s-a schimbat după câteva demo-uri?
La început îmi imaginam că provocarea principală este să generez site-uri repede. După ce am lucrat cu afaceri și concepte diferite, am realizat că viteza nu era singurul lucru care merita îmbunătățit.
Uneori informația disponibilă era prea subțire pentru o pagină personalizată bună. Alteori afacerea avea deja un site perfect rezonabil, iar înlocuirea lui cu o versiune de o pagină nu ar fi ajutat. Alteori un șablon avea prea multe secțiuni, iar rezultatul devenea mai clar după ce scoteam câteva.
Am început să fiu mai atent la deciziile astea:
- Ce informație este cu adevărat utilă?
- Secțiunea aceasta îl ajută pe vizitator?
- Site-ul este mai ușor de înțeles pe telefon?
- Aș fi confortabil să public fiecare afirmație de pe pagină?
A fost și întrebarea practică despre cât durează totul. Am ținut evidența timpului petrecut cu cercetarea, pregătirea informațiilor, generarea demo-urilor și corecțiile. Asta m-a ajutat să văd munca repetitivă și să nu petrec ore îmbunătățind lucruri care mergeau deja suficient de bine.
Cât durează un demo de site personalizat?
Până la finalul experimentului, aveam un flux care putea pregăti demo-uri de site personalizate într-un timp relativ scurt. În testul meu înregistrat, procesul de ansamblu a durat în medie sub o jumătate de oră pentru fiecare încercare de contact. Este destul de diferit de a deschide un proiect gol și de a decide totul de la zero.
Asta nu înseamnă că orice site de client terminat poate fi livrat într-o jumătate de oră. Proiectele reale au în continuare nevoie de conversații, de materiale de la client, de revizuiri și de verificări înainte de publicare. Ce a devenit mult mai rapid este ajungerea la o primă versiune utilă.
Ce m-a învățat Q3 despre folosirea AI-ului?
Trimestrul acesta a fost puțin diferit de cele două dinainte. Nu am construit o funcționalitate AI cu care vizitatorul interacționează direct. Cea mai mare parte a muncii cu AI se întâmplă în spate, în timp ce pregătesc și construiesc ceva ce vizitatorul site-ului poate să nu știe niciodată că a fost făcut cu asistență AI.
Și îmi place lucrul acesta.
Nu cred că fiecare produs are nevoie de un AI chat sau de un buton de AI. Uneori, cea mai bună folosire a AI-ului este pur și simplu să facă mai puțin repetitivă munca de a construi un produs.
Mă întorc mereu la Tiny Experiments de Anne-Laure Le Cunff, cartea care a ajutat la inspirarea întregii provocări #OneAppPerQuarter. Îmi place ideea de a-mi da o perioadă limitată ca să explorez ceva, să văd ce învăț și apoi să decid ce merită mai multă atenție.
Pentru Q3, asta a însemnat să văd dacă dezvoltarea de site-uri poate deveni un proces mai repetabil. Mi-a plăcut să lucrez la detalii, să testez șabloanele și să fac fluxul din ce în ce mai ușor de folosit. Am învățat și că a construi un proces eficient și a găsi oportunitatea de afaceri potrivită pentru el sunt două întrebări diferite. Este util să știi asta înainte să investești mai mult timp într-o idee.
Ce iau cu mine este sistemul pe care l-am construit. Am acum șabloane reutilizabile, un mod mai bun de a pregăti conținutul unui site, un drum mai rapid de la idee la demo și un proces de predare mai simplu. Pot folosi piesele astea în munca viitoare cu clienții fără să reconstruiesc totul.
Articolul a întârziat, dar proiectul a meritat.
Acum, mai departe cu Q4.
Learning is my superpower.Întrebări frecvente
Ce ai construit în Q3 din #OneAppPerQuarter?
Am construit un sistem care creează, personalizează și livrează site-uri Next.js pentru afaceri locale, cu mai puțină configurare repetată. Este proiectul meu din Q3 în provocarea #OneAppPerQuarter din 2026, iar acest articol a fost publicat pe 30 octombrie 2026.
Cât durează un demo de site cu acest flux?
În testul meu înregistrat, o încercare de contact a durat în medie sub 30 de minute. Un site de client terminat are în continuare nevoie de conversații, materiale, revizuiri și verificări înainte să fie publicat.
Ce afaceri acoperă cele trei șabloane?
Trei puncte de plecare: cabinete medicale, servicii profesionale și servicii pentru casă. Împart codul de bază și sunt adaptate la ton, secțiuni și îndemnuri la acțiune.
Site-ul rămâne al clientului?
Da. O comandă pregătește o versiune de sine stătătoare pentru repository-ul clientului. Uneltele reutilizabile rămân la mine. Clientul primește codul site-ului și îl poate publica în conturile lui.
Ce unelte folosește fluxul din Q3?
Next.js pentru site-uri, un proiect ChatGPT dedicat pentru cercetare și brief, și Cursor pentru implementare. Eu verific în continuare conținutul, așezarea în pagină și comportamentul.
Unde pot vedea cele trei direcții de site?
Demo-urile publice sunt pentru cabinete medicale la demo.lolotech.io/medical, pentru servicii profesionale la demo.lolotech.io/professional și pentru servicii pentru casă la demo.lolotech.io/home-services. Pagina ofertei este lolotech.io/websites.