Vi suona familiare?

01

Un tipo di campo che non esiste, così il team lo simula in una casella di testo

02

Un passaggio manuale che qualcuno ripete ogni giorno perché nulla lo automatizza

03

Un sistema esterno che dovrebbe restare sincronizzato, e oggi non lo è

04

Un report che il team ricostruisce a mano ogni mese

05

Una regola che il sistema dovrebbe imporre e che invece vive nella memoria di qualcuno

06

Un’operazione rischiosa da eseguire sui dati reali, senza rete di sicurezza

Cosa realizziamo per voi

Interfacce, layout, pannelli, hook, endpoint e operazioni, scritti con lo stesso standard di quelli che pubblichiamo pubblicamente, perché è proprio così che ci trovano.

Interfacce su misura

L’input di cui i vostri dati hanno davvero bisogno: un selettore su mappa, un editor strutturato, un campo calcolato, una ricerca su un altro sistema. Qualsiasi cosa impedisca al team di aggirare il software.

Hook e automazioni

Logica che scatta quando qualcosa cambia: validazioni, notifiche, sincronizzazioni verso altri sistemi, l’applicazione di una regola che oggi dipende dalla memoria di una persona.

Endpoint dedicati

Rotte API disegnate per l’app o per il partner che le consuma, invece di esporre l’intero schema sperando che vada bene.

Pannelli per la dashboard

I numeri che oggi il team esporta in un foglio di calcolo, mostrati dove sta già lavorando e aggiornati senza che nessuno ci metta mano.

Operazioni sicure sui dati reali

La nostra estensione open source per il rename sicuro esiste perché rinominare una collezione in Directus può rompere relazioni, permessi e flussi. Mettiamo la stessa cura in tutto ciò che tocca la produzione.

Open source dove ha senso

Se ciò che costruiamo per voi è utile a tutti e non contiene nulla di vostro, vi chiediamo se possiamo pubblicarlo. Voi ottenete la manutenzione di una community più ampia, noi la reputazione. Mai senza il vostro consenso.

Il lavoro sulle estensioni è adatto se:

Usate già Directus e avete incontrato un limite

Il team ha inventato un aggiramento manuale per qualcosa che il sistema dovrebbe fare

Directus deve dialogare con qualcosa di specifico del vostro settore

Volete che il lavoro lo faccia chi pubblica estensioni in pubblico

Deve restare manutenibile da chi verrà dopo di noi

Come si svolge il lavoro su un’estensione:

01

Ci descrivete il limite, idealmente mostrandoci l’aggiramento che usate oggi

02

Verifichiamo se un’estensione esistente lo risolve già: a volte succede, e ve lo diciamo

03

Una proposta a prezzo fisso per lo sviluppo, con il comportamento messo per iscritto

04

Sviluppiamo su una copia del vostro ambiente, non sui dati reali

05

La provate nel vostro ambiente prima che si avvicini alla produzione

06

Consegna con sorgenti, documentazione e periodo di garanzia

FAQ

Common questions about estensioni directus

L’estensione che sviluppate è nostra?

Sì, completamente: codice sorgente e diritti pieni. Se si rivela utile in generale e non contiene nulla di specifico della vostra impresa, potremmo chiedervi se siete d’accordo a pubblicarla come open source. Sempre chiedendo, mai dando per scontato.

E se Directus aggiungesse questa funzione in futuro?

Sarebbe un buon risultato, e ve lo diciamo quando lo riteniamo probabile. Le estensioni sono autonome, quindi potete abbandonare la nostra e passare alla versione nativa. Preferiamo sconsigliarvi uno sviluppo piuttosto che vendervi qualcosa con vita breve.

Potete sistemare o riprendere un’estensione esistente?

Di solito sì. Mandateci il repository e vi diremo onestamente se conviene ripararla o riscriverla — anche quando la risposta ci fa perdere il lavoro più grande.

Come valutiamo la qualità prima di affidarvi il lavoro?

Leggendo il nostro codice. Le nostre estensioni sono pubbliche su GitHub e npm, con tutta la loro storia. È una referenza più onesta di un caso studio scritto da noi su di noi.

Pronti a iniziare?

Raccontateci il limite che avete incontrato. Se un’estensione esistente lo risolve già, vi indirizziamo lì invece di fare un preventivo.