Acasă/Metode

Aplicații · monday.com

Cum construim o aplicație monday.com

Am construit o singură aplicație pentru monday.com, o vizualizare de board care scrie un scurt rezumat AI al board-ului, și am trimis-o la review în august 2026. În septembrie a fost respinsă pentru că se suprapune cu aplicații care există deja. Metoda de construcție a ținut; pasul sărit a fost să întrebăm monday, înainte de a scrie cod, dacă ideea trece de politica lor de duplicare.

Actualizat 2026-10-11

Despre ce e vorba și unde suntem

monday.com le permite dezvoltatorilor să adauge vizualizări, widgeturi și integrări pe board-uri și să le vândă prin marketplace-ul lor. Noi am construit acolo o singură aplicație, Recap: o vizualizare de board care citește board-ul și scrie, în limbaj obișnuit, ce s-a mișcat, ce e blocat și ce e scadent, cu export în PDF. Am trimis-o pe 16 august 2026. Pe 28 septembrie recenzentul monday a respins-o: funcționalitatea se suprapune semnificativ cu soluții deja disponibile, iar partea de AI nu aduce o valoare reală. Aplicația nu e listată și nu construim o a doua aplicație pentru monday.

Mai jos e metoda pe care am folosit-o, care a mers în mare parte, și decizia pe care am luat-o greșit, care n-a mers.

Citește formularul înaintea documentației

Cerințele obligatorii sunt împrăștiate între documentația pentru dezvoltatori, termenii de listare și formularul de trimitere, iar formularul e cel mai strict și cel mai actual dintre ele. Trei dintre regulile lui schimbă ce construiești. Din 13 august 2026 formularul spune că monday acceptă doar aplicații cu funcții AI, regulă pe care n-am găsit-o în niciun document pentru dezvoltatori. Facturarea trebuie să treacă prin monetizarea nativă monday. Aplicațiile no-code și cele „vibe-coded” nu sunt eligibile.

O a patra regulă decide dacă merită să construiești. Politica monday de calitate și duplicare nu acceptă o aplicație nouă al cărei scop principal dublează o integrare existentă, chiar dacă e mai bună, și spune că mici retușuri de interfață sau funcții adăugate nu înseamnă valoare nouă. Noi am citit-o ca pe o listă de conectori terți interziși. Respingerea a arătat că se aplică și funcționalității.

Datele despre cerere se obțin ușor. Marketplace-ul e alimentat din JSON public, cu numărul exact de instalări pentru fiecare aplicație; fișierele se unesc pe app_id, niciodată pe id, care le potrivește greșit fără niciun avertisment. Împărțite pe anul lansării, cele 235 de aplicații din cohorta 2026 aveau o mediană de 5 instalări când le-am măsurat, în august. Am notat asta și am construit oricum, ca pe un singur pariu.

Construirea vizualizării de board

Aplicația e o vizualizare de board: un front-end într-un iframe, care folosește SDK-ul monday, plus un backend care verifică tokenul de sesiune semnat de monday și cere unui model de limbaj un singur paragraf. Ordinea contează: creezi aplicația, adaugi o funcție de tip board view, o legi de build, dai scope-urile pe o versiune draft, promovezi versiunea în live și abia apoi instalezi. O instalare făcută cât versiunea era încă draft nu aduce vizualizarea în board.

Capcanele în care am călcat. Comanda din CLI care creează aplicația crapă fără terminal, dar creează totuși aplicația, așa că listează-ți aplicațiile înainte să reîncerci, altfel te trezești cu dubluri. O versiune promovată e blocată, iar modificările pe ea se anulează tăcut până când creezi o versiune nouă. Când fiecare apel API din vizualizare pică cu Graphql validation errors, inclusiv cea mai simplă interogare posibilă, aplicației îi lipsesc scope-urile; interogarea e în regulă. Iar ecranul de consimțământ de la instalare e singura sursă sinceră despre ce ceri: al nostru cerea acces la profil, deși propriile noastre documente spuneau că nu e nevoie, așa că l-am scos.

Am testat randarea în afara monday, cu un board real dat ca JSON. Așa am prins un status numit „Fixed” pe care codul nu-l număra ca terminat, deci raportul arăta zero iteme finalizate acolo unde 3 erau rezolvate. Cu date de test inventate, în care tot ce e gata se numește „Done”, bug-ul ar fi rămas ascuns.

Lasă monday să găzduiască

monday poate găzdui singur codul aplicației, iar propriul formular spune că asta ușurează review-ul de securitate. Noi am găzduit Recap pe serverul nostru și am plătit pentru asta. Tokenul de sesiune semnat, pe care monday îl pune în URL-ul vizualizării, ajungea în logurile de acces ale serverului web; nu aveam o perioadă de păstrare definită pentru acele loguri; iar secretele au trebuit descrise în răspunsurile despre confidențialitate. Nimic din toate astea nu există când codul e găzduit de monday. Decizia se ia când pornești proiectul, nu după ce sosesc întrebările de securitate.

Auditul dinainte de trimitere

Înainte de trimitere am rulat un audit adversarial cu 14 agenți peste cod, textul listării, paginile legale publicate și documentația monday. A întors 45 de constatări brute; 7 au rezistat contraargumentelor, iar verdictul a fost „nu e gata”. Clasele care trebuie verificate la orice aplicație: afirmații false despre concurenți (descriseserăm aplicațiile existente drept unelte bazate pe șabloane, când mai multe erau vizualizări de board fără configurare și una scria deja un rezumat AI, iar afirmația stătea exact în câmpul pe care monday îl folosește ca să judece duplicarea); texte de confidențialitate care promit mai mult decât face codul; un clasificator de status care număra „Unpaid” și „Not approved” drept finalizate; o a treia temă, black, pe lângă light și dark; și declararea suportului pe mobil pentru un buton de PDF care pe aplicația mobilă nu face nimic.

Trimiterea

Câmpurile de text lung se opresc la 2.000 de caractere și, în loc să taie textul, fac contorul roșu, așa că un răspuns prea lung arată bine până când blochează formularul. Unul dintre ale noastre a trebuit scurtat de la 2.672 de caractere la 1.994. Câțiva pași țin de proprietarul contului și nu se pot automatiza: acceptarea termenilor pentru dezvoltatori, angajamentul ferm de a răspunde utilizatorilor în 2 zile lucrătoare și o imagine cu semnătura.

Am trimis formularul cu un răspuns greșit la prețuri și aproape că ne-am retras din cauza asta. Documentația spune că prețurile inițiale se verifică în cadrul review-ului aflat în curs, deci se puteau corecta acolo; singura alegere care nu se mai poate schimba ulterior e modelul de preț. Primul răspuns monday vine în cel mult 72 de ore lucrătoare, iar restul review-ului se desfășoară pe un board comun.

Unde am greșit

Propria noastră analiză din august spunea să nu construim deloc pentru monday, cu o singură excepție, Recap, și doar după ce obținem în scris acordul de principiu pe idee față de politica de duplicare: un pas fără cod, de aproximativ 72 de ore lucrătoare. Am trimis aplicația în aceeași zi și n-am întrebat niciodată. Răspunsul l-am aflat din respingere.

Respingerea a venit pe email pe 28 septembrie și a stat necitită 7 zile. Watchdog-ul nostru de mail căuta doar expeditorul de review de la Atlassian, iar noi am raportat „niciun mail nou” când de fapt verificaserăm un singur expeditor. Acum verificarea începe cu o căutare largă și spune pe ce canale a căutat.

Și afirmația despre concurenți de mai sus ține tot de aici. Am prins-o înainte de trimitere, dar reflexul de a-i descrie pe vecini mai slabi decât sunt e exact ce testează un review de duplicare.

Limite și listă de verificare

Pașii de construcție au ținut: vizualizarea a mers pe board-uri reale și a trecut de auditul nostru. Asta nu spune nimic despre dacă monday vrea aplicația sau dacă o va instala cineva, iar ambele întrebări au răspuns înainte de prima linie de cod.

1. Acordul de principiu. Întreabă monday în scris, înainte să construiești, dacă ideea trece de politica de duplicare.

2. Formularul. Citește formularul de trimitere actual, nu notițele de luna trecută; plănuiește o funcție AI reală din prima zi.

3. Găzduirea. Pornește implicit cu găzduirea monday, dacă nu ai un motiv anume să n-o faci.

4. Scope-urile. Citește-le pe ecranul de consimțământ și scoate-le pe cele nefolosite.

5. Auditul. Verifică afirmațiile despre concurenți, textele de confidențialitate, logica de status, temele și mobilul înainte de trimitere.

Întrebări și răspunsuri

De ce poate fi respinsă o aplicație din marketplace-ul monday.com?

O aplicație din marketplace-ul monday.com poate fi respinsă pentru că se suprapune cu soluții deja disponibile. Politica monday de calitate și duplicare nu acceptă o aplicație nouă al cărei scop principal dublează o integrare existentă, chiar dacă e mai bună, iar mici retușuri de interfață sau funcții adăugate nu înseamnă valoare nouă. O aplicație de rezumat AI pentru board-uri a fost respinsă exact așa.

Care sunt principalele cerințe pentru trimiterea unei aplicații monday.com?

Principalele cerințe pentru trimiterea unei aplicații monday.com apar cel mai strict în formularul de trimitere actual. Formularul spune că monday acceptă doar aplicații cu funcții AI, că facturarea trebuie să treacă prin monetizarea nativă monday și că aplicațiile no-code sau „vibe-coded” nu sunt eligibile. Unii pași țin de proprietarul contului: acceptarea termenilor, angajamentul de suport și o imagine cu semnătura.

De ce nu apare vizualizarea de board monday.com după ce instalez aplicația?

Vizualizarea de board monday.com nu apare de obicei pentru că aplicația a fost instalată cât versiunea era încă draft. Ordinea contează: creezi aplicația, adaugi o funcție de tip board view, o legi de build, dai scope-urile pe o versiune draft, promovezi versiunea în live și abia apoi instalezi. O versiune promovată e blocată, așa că modificările ulterioare cer o versiune nouă.

Este mai bine să găzduiesc singur aplicația monday.com sau s-o găzduiască monday?

Pentru o aplicație monday.com, găzduirea de către monday e de obicei varianta implicită mai bună, pentru că formularul monday spune că ușurează review-ul de securitate. La găzduirea proprie, tokenul de sesiune semnat pe care monday îl pune în URL-ul vizualizării poate ajunge în logurile serverului, logurile au nevoie de o perioadă de păstrare, iar secretele trebuie descrise în răspunsurile despre confidențialitate. Decizia se ia la pornirea proiectului.

Ce trebuie verificat înainte de trimiterea unei aplicații monday.com?

Înainte de trimiterea unei aplicații monday.com trebuie verificate afirmațiile despre concurenți, textele de confidențialitate, logica de status, temele și suportul pe mobil. O afirmație care îi descrie pe concurenți mai slabi decât sunt poate sta exact în câmpul folosit de monday ca să judece duplicarea. Textele de confidențialitate nu trebuie să promită mai mult decât codul, iar aplicația trebuie să suporte și tema black.

Toate metodele