Il prezzo di un AI app builder dipende da ciò che conta come lavoro

Il piano più economico per 100 iterazioni di richieste alla settimana è di solito quello che conteggia meno lavoro attorno a ogni richiesta. Il prezzo mensile pubblicato dice ben poco finché non sai se un nuovo tentativo, una fase di pianificazione, un test, una distribuzione e un agente che lavora in background incidono sullo stesso contatore.

Ho visto team confrontare i piani dividendo il prezzo dell'abbonamento per 100 richieste. Il calcolo è ordinato, ma sbagliato. Una richiesta che modifica il testo di un pulsante e una che ristruttura un database contano entrambe come un messaggio per chi scrive, ma possono generare fatture molto diverse. Un confronto onesto parte da un registro del carico di lavoro e applica poi le regole di fatturazione di ciascun fornitore allo stesso registro.

Questo articolo usa un catalogo prezzi ipotetico, non i prezzi di un fornitore specifico. Lo scopo è darti un calcolo da sostituire con le condizioni reali del piano prima dell'acquisto.

Lo stesso numero di richieste può nascondere tre fatture diverse

Il numero di messaggi degli utenti misura la conversazione, non il calcolo eseguito o il lavoro completato. I piani a crediti tendono a misurare l'attività del modello, quelli basati sulle attività misurano un'unità di lavoro definita dal fornitore e quelli fissi vendono accesso entro un limite. Questi limiti producono totali diversi anche se l'applicazione e le 100 richieste settimanali restano identiche.

Immagina che un fondatore chieda ogni settimana 70 piccole modifiche dell'interfaccia, 20 modifiche che toccano diversi file e 10 modifiche di build o distribuzione. Il numero visibile è 100. Dietro le quinte, il builder può analizzare il repository, creare un piano, chiamare più volte un modello, eseguire test, correggere una modifica fallita, ricompilare l'app e mantenere attivo un agente dopo che compare la risposta in chat. Un piano può addebitare ogni chiamata al modello. Un altro può definire l'intera sequenza come una sola attività. Un abbonamento può includerla, limitarla o escluderne una parte con un costo aggiuntivo.

Qui gli acquirenti confondono spesso due concetti: un'iterazione è un ciclo decisionale dell'utente, mentre un evento fatturabile è qualsiasi cosa il venditore abbia deciso di misurare. Trattarli come sinonimi favorisce il piano con la pagina dei prezzi più vaga. Rende anche costoso un piano che sembrava economico dopo che il team ha affidato la propria applicazione alla piattaforma.

Per il confronto, usa un fattore mensile di 4.33 settimane invece di fingere che ogni mese ne abbia quattro. Cento iterazioni settimanali diventano 433 iterazioni mensili. Questa piccola correzione aggiunge 33 iterazioni prima ancora di includere un solo tentativo o lavoro in background.

Una richiesta di preventivo utile chiede al fornitore di classificare il lavoro, non soltanto di stimare un totale. Chiedi: che cosa avvia il contatore? Quando si ferma? Un'esecuzione fallita conta? Un nuovo tentativo automatico conta? Quale lavoro continua dopo che l'interfaccia indica che la risposta è completa? La capacità inutilizzata può essere riportata? Le risposte determinano la fattura.

Definisci un unico carico di lavoro prima di aprire la calcolatrice

Crea una settimana rappresentativa del lavoro che prevedi davvero e fissala prima di confrontare i piani. Se cambi il carico per ogni modello di prezzo, stai valutando il testo commerciale, non il prezzo.

Per il confronto pratico userò questo carico di lavoro settimanale:

• 70 piccole modifiche da una unità di credito ciascuna
• 20 modifiche su più file da tre unità di credito ciascuna
• 10 modifiche di build o distribuzione da cinque unità di credito ciascuna
• 25 tentativi aggiuntivi con una media di due unità di credito
• 35 esecuzioni in background che consumano in totale 45 unità di credito

Le 100 iterazioni richieste consumano 180 unità di credito ipotetiche al primo passaggio. I tentativi aggiungono 50 unità. Pianificazione, indicizzazione, test e lavoro di distribuzione ne aggiungono 45. Il totale settimanale è 275 unità, ossia 1,190.75 unità in un mese medio.

La stessa attività ha una seconda forma con la fatturazione per attività. Ogni settimana genera 100 avvii di attività richiesti dall'utente, 25 avvii per tentativi e 35 avvii di attività in background. Sono 160 eventi settimanali e 692.8 eventi mensili. Che tutti i 692.8 siano fatturabili dipende dalla definizione contrattuale di attività.

Registra separatamente il lavoro riuscito e quello fallito. Un tasso di errore basato solo sui messaggi di errore visibili non rileva correzioni silenziose, fallback automatici del modello e ripetizioni dei test. L'esportazione dei dati di utilizzo della piattaforma, se disponibile, è una prova migliore della cronologia della chat, perché la chat può riunire più esecuzioni di agenti in un'unica risposta.

Usa una settimana che includa il disordine normale: una richiesta poco chiara, un conflitto di dipendenze, un test che fallisce per un motivo estraneo e una correzione della distribuzione. Una settimana dimostrativa perfetta produce un budget che dura solo fino all'inizio dello sviluppo reale.

Non gonfiare il carico di lavoro per cautelarti. Aggiungi un margine di variabilità separato dopo aver calcolato la base osservata. Tenere distinti base e margine ti permette di capire se un piano costa molto per il lavoro normale o perché hai acquistato una protezione contro un mese intenso.

I pacchetti di crediti fanno pagare il movimento dentro il builder

I pacchetti di crediti costano meno quando i prezzi unitari della piattaforma sono bassi, i crediti inutilizzati restano validi abbastanza a lungo da poter essere usati e il builder richiede pochi passaggi di correzione. Costano di più quando una semplice richiesta si dirama in più chiamate al modello che l'utente non vede.

Un credito non è un'unità standard. Può rappresentare token, chiamate al modello, passaggi di un agente, secondi o una combinazione ponderata. Un fornitore può anche addebitare quantità di crediti diverse per un modello veloce e per uno più capace. Confrontare il numero di crediti in due pacchetti non serve a nulla finché entrambe le piattaforme non definiscono il consumo nello stesso modo, cosa rara.

Valuta il carico ipotetico con un pacchetto di 500 unità al costo di $30. La domanda mensile è di 1,190.75 unità. Poiché i pacchetti sono indivisibili, l'acquirente ne deve comprare tre e paga $90. Se i crediti non scadono, a fine mese restano 309.25 unità. Il costo effettivo del lavoro consumato è circa 7.56 centesimi per unità, anche se il pacchetto pubblicizza 6 centesimi, perché è stato necessario acquistare capacità inutilizzata.

Il riporto cambia il risultato. Se le 309.25 unità restanti sopravvivono, il mese successivo potrebbero bastare due pacchetti invece di tre. Su più mesi stabili, il costo medio si avvicina alla tariffa pubblicizzata. Se i crediti scadono ogni mese, il saldo bloccato fa parte del prezzo. Non ometterlo mai dal modello.

La scelta del modello può modificare il consumo senza cambiare il numero di richieste. Se la piattaforma indirizza le modifiche complesse a un modello con moltiplicatore di quattro unità, le dieci richieste più difficili possono dominare la fattura. Chiedi se l'instradamento è automatico, se puoi verificarlo in seguito e se puoi impostare un tetto. Un modello economico che fallisce e richiede due tentativi può costare più di un modello capace che riesce al primo colpo.

I pacchetti di crediti funzionano bene per progetti irregolari perché paghi quando il lavoro avviene, a patto che i crediti restino validi abbastanza a lungo. Sono più difficili da mettere a budget per un team che sperimenta liberamente. Il contatore può cambiare i comportamenti: le persone uniscono richieste non correlate in richieste troppo grandi, evitano i test o accettano risultati deboli per risparmiare crediti. Queste scelte riducono la fattura danneggiando l'applicazione.

La domanda scomoda è se il lavoro in background debba consumare crediti. Consuma risorse, quindi farlo pagare è difendibile. Il problema nasce quando l'acquirente non può prevederlo o fermarlo. Una valutazione corretta verifica se l'interfaccia mostra ogni addebito in background e se un limite di spesa blocca il nuovo lavoro prima che il saldo raggiunga zero.

La fatturazione per attività dipende da dove l'attività inizia e finisce

La fatturazione basata sulle attività può essere il modello più economico quando un unico prezzo copre l'intero tentativo, inclusi pianificazione, chiamate al modello, test e correzioni. Diventa il più costoso quando ogni azione interna diventa una nuova attività.

Applica una tariffa ipotetica di $0.14 a ogni evento avviato nel registro. Con 692.8 eventi mensili, il costo è $96.99 dopo l'arrotondamento ai centesimi. È più dei $90 dei pacchetti di crediti, anche se quattordici centesimi sembrano pochi su una pagina dei prezzi.

Ora cambia una frase del contratto: addebita soltanto le 433 iterazioni richieste dagli utenti, includendo tentativi e lavoro in background in ogni attività. Il costo mensile scende a $60.62. L'applicazione non è cambiata. È cambiato il confine dell'attività, e quel confine sposta $36.37.

La fatturazione per attività completate richiede un'altra definizione. Se un'esecuzione modifica i file ma la distribuzione fallisce, la piattaforma ha completato l'attività? Se l'utente rifiuta il risultato e chiede una correzione, è una nuova attività o la continuazione della precedente? I fornitori hanno bisogno di regole per evitare lavoro illimitato sotto un'unica tariffa, ma gli acquirenti hanno bisogno di regole che possano ricostruire da un registro delle attività.

Il consiglio diffuso di confrontare il costo per richiesta riuscita è sbagliato quando il successo viene dichiarato dall'utente. Gli utenti accettano risultati parziali, dividono richieste grandi e correggono manualmente l'output. Un basso costo per successo registrato può nascondere ore di pulizia. Confronta invece il costo per modifica accettata, usando il momento in cui il team farebbe il merge, distribuirebbe o conserverebbe in altro modo il risultato.

Il prezzo per attività offre un vantaggio di budget quando l'unità corrisponde a qualcosa che una persona riconosce. Un team può stimare 400 modifiche accettate con più sicurezza rispetto a milioni di token. Il vantaggio sparisce se il prodotto definisce indicizzazione, pianificazione, test e distribuzione come attività separate. Leggi i nomi degli eventi in una fattura reale o in un'esportazione dei dati di utilizzo prima di considerare stabile l'unità.

Chiedi anche come funziona la concorrenza. Due agenti in esecuzione contemporanea possono ridurre il tempo trascorso raddoppiando gli avvii di attività. Una correzione in background che avvia un agente di test può contare una volta, due volte oppure non contare affatto. La fattura segue il contatore, non il tempo sul cronometro.

Gli abbonamenti fissi vincono solo entro il limite incluso

Un abbonamento fisso costa meno per questo carico di lavoro quando la tariffa mensile include tutte le 433 iterazioni utente, i 108.25 avvii per tentativi e i 151.55 avvii in background. Se una categoria resta fuori dall'abbonamento, aggiungila prima di dichiarare più economico il piano fisso.

Usa un piano mensile ipotetico da $79 che include fino a 600 esecuzioni interattive e di tentativi più 200 esecuzioni in background. L'esempio genera 541.25 esecuzioni interattive e di tentativi e 151.55 esecuzioni in background al mese. Entrambi i totali rientrano nei limiti, quindi il costo resta $79. In queste ipotesi, il prezzo fisso batte i pacchetti di crediti da $90 e il piano a attività avviate da $96.99.

La parola «illimitato» non merita alcun valore in un foglio di calcolo. Sostituiscila con la soglia effettiva di uso corretto, il limite di concorrenza, la restrizione del modello o la regola di rallentamento. Se il fornitore non dichiara un limite, modella un caso basso e uno alto. Un piano che sembra economico solo con un'interpretazione senza limiti non offre un prezzo affidabile.

I piani fissi creano anche costi a scatti. Con 599 esecuzioni incluse, un'esecuzione in più può non costare nulla. A 600, quella successiva può attivare un costo aggiuntivo o imporre un livello superiore. Traccia almeno tre livelli di carico: un mese tranquillo, il mese previsto e un mese di rilascio. Il solo caso previsto nasconde il punto in cui l'abbonamento aumenta.

I posti contano quando la fatturazione segue gli utenti anziché il lavoro. Un piano da $79 per una persona costa $316 per quattro posti obbligatori, anche se il team condivide le stesse 433 iterazioni. Non dare per scontato che sia consentito condividere un account. Calcola le persone che devono rivedere le richieste, approvare le distribuzioni o controllare l'uso.

Una tariffa fissa può incoraggiare una sperimentazione sana, perché ogni idea fallita non genera un microaddebito visibile. Può anche nascondere sprechi finché la piattaforma non limita l'account. La visibilità dell'uso resta importante. Devi sapere se gli agenti entrano in un ciclo e se un mese di rilascio supererà il limite incluso.

Gli sconti annuali vanno inseriti nel calcolo per ultimi. Prima individua il modello più economico alle condizioni mensili. Poi applica lo sconto e il costo dell'impegno. Pagare dieci mesi per uno strumento abbandonato dopo tre non è un risparmio.

I tentativi fanno parte della base, non di una nota a piè di pagina

I tentativi sono normale lavoro di sviluppo, quindi un confronto dei prezzi che presume risultati perfetti al primo passaggio non è adatto a un acquisto. Il numero utile è l'amplificazione dei tentativi: tentativi totali divisi per iterazioni richieste.

L'esempio conta 125 tentativi interattivi per 100 iterazioni richieste, con un'amplificazione di 1.25. Questo non significa che il 25 per cento delle richieste fallisca semplicemente. Alcune richieste richiedono chiarimenti, alcune modifiche superano i controlli del codice ma non rispondono all'intento e alcuni errori dipendono da strumenti o dipendenze. L'effetto sulla fatturazione è lo stesso quando il piano misura un altro tentativo.

Misura i tentativi con una regola che due persone possano applicare in modo coerente. Conta un tentativo quando l'utente ripete lo stesso risultato desiderato dopo aver rifiutato o corretto l'output precedente. Non contare un requisito davvero nuovo come tentativo. Etichetta separatamente quelli automatici, perché l'utente potrebbe non vederli mai.

Un piccolo progetto pilota dovrebbe includere le attività che prevedi saranno difficili. Se testi solo testi per landing page e cambi di colore, il tasso di tentativi dice poco su migrazioni di database, autenticazione, gestione dello stato o build mobile. Sottoponi almeno una modifica rischiosa a ogni candidato e controlla il registro delle attività.

I tentativi influenzano i modelli in modo diverso:

• La fatturazione a crediti di solito addebita le risorse consumate da ogni tentativo.
• La fatturazione per attività avviate di solito addebita ogni tentativo se genera un evento.
• La fatturazione al completamento può assorbire i tentativi falliti, secondo la sua regola di completamento.
• La fatturazione fissa assorbe i tentativi finché non raggiungono un limite incluso o un controllo di uso corretto.

Non accettare i tentativi gratuiti come risposta completa. Chiedi se il tentativo usa lo stesso modello, se un fallback automatico consuma un limite separato e quanto resta aperta la finestra per i tentativi gratuiti. Una correzione inviata il mattino successivo può diventare una nuova attività anche se il lavoro è chiaramente lo stesso.

Esiste anche un costo umano dei tentativi. Un piano può costare poco in denaro e molto in attenzione se gli utenti devono supervisionare ogni correzione. Durante il progetto pilota, registra i minuti di revisione per modifica accettata. Non forzare quel tempo nella fattura della piattaforma, ma mostrala accanto alla fattura affinché un prezzo basso non nasconda un flusso di lavoro scadente.

Gli agenti in background sono il moltiplicatore invisibile

Il lavoro degli agenti in background deve comparire in una riga dedicata perché può continuare dopo che l'utente vede una risposta. Indicizzazione del repository, pianificazione, controlli delle dipendenze, test, monitoraggio della build, distribuzione e agenti di correzione possono tutti consumare budget senza aggiungere un altro messaggio in chat.

Il nostro esempio assegna 35 esecuzioni in background e 45 unità di credito alla settimana. Sono ipotesi rese volutamente visibili. Sostituiscile con i dati di utilizzo di un progetto pilota. Se un fornitore mostra soltanto un totale combinato, esegui la stessa richiesta una volta con l'automazione opzionale disattivata e una con l'automazione attivata. La differenza è una stima, non una prova, ma è meglio che trattare il lavoro come gratuito.

La modalità di pianificazione merita particolare attenzione. Un piano può ridurre costose implementazioni fallite individuando presto i conflitti, oppure aggiungere un passaggio a pagamento prima di ogni modifica banale. Provala separatamente su modifiche piccole e grandi. La politica giusta potrebbe essere usare la pianificazione per modifiche di schema e lavoro su più file, saltandola per le modifiche di testo.

L'indicizzazione ha una struttura di costo diversa. Il primo passaggio su un repository può costare molto, mentre gli aggiornamenti incrementali successivi costano poco. Un progetto pilota di una settimana può esagerare il costo a regime se include l'indicizzazione iniziale, oppure sottostimarlo se il repository di produzione è molto più grande. Separa il consumo di configurazione da quello ricorrente.

Test e distribuzione non sono sprechi facoltativi. Disattivarli per rientrare in un limite di crediti trasferisce agli utenti il rilevamento degli errori. Calcola il flusso di lavoro sicuro che intendi seguire, compresi i controlli che lo proteggono. Un confronto basato su test disattivati risponde alla domanda aziendale sbagliata.

Koder.ai supporta la modalità di pianificazione, la distribuzione e l'hosting, gli snapshot e il rollback, oltre all'esportazione del codice sorgente. Un progetto pilota può quindi osservare queste parti del flusso di lavoro invece di valutare soltanto i messaggi in chat. Nomi e prezzi dei piani vanno comunque verificati nell'interfaccia attuale del prodotto, perché il contesto del sito qui definisce i livelli, non le loro soglie attuali.

Imposta un budget per il lavoro in background se il prodotto lo consente, ma non confondere un tetto con la prevedibilità. Un tetto evita una spesa eccessiva bloccando il lavoro. L'applicazione può comunque perdere una pubblicazione mentre un agente attende altra capacità. Registra sia il limite finanziario sia la conseguenza operativa.

Sottoponi ogni candidato allo stesso registro

Un registro rende il confronto riproducibile e mette in luce le ambiguità contrattuali prima che diventino una contestazione della fattura. Ogni riga dovrebbe descrivere un singolo evento misurato, con contesto sufficiente per associarlo a crediti, attività e limiti dell'abbonamento.

Copia questa intestazione CSV e usala durante un progetto pilota:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Tieni separati tipo di evento e risultato. Un test in background può completarsi con successo mentre la modifica richiesta continua a non essere accettata. Se riunisci questi fatti in un solo stato, non puoi verificare la regola del fornitore sulle attività completate.

Alla fine della settimana, calcola quattro valori:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Poi applica le condizioni del piano senza modificare le righe. Per il catalogo ipotetico, il calcolo è:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

Un foglio di calcolo dovrebbe mostrare anche i crediti bloccati, la capacità inclusa residua e il prossimo limite di prezzo. Il piano vincente nell'esempio ha ancora 58.75 esecuzioni interattive e 48.45 esecuzioni in background. Questo margine non basta per una settimana di rilascio che raddoppia il lavoro di distribuzione, quindi il team dovrebbe calcolare quel caso prima di impegnarsi.

Chiedi al fornitore di esaminare una pagina anonima del registro. Non chiedere quale piano sia più economico, chiedi come verrebbe classificata ogni riga. Una classificazione scritta è più utile di una stima commerciale perché puoi confrontarla con la prima fattura.

La variabilità conta più del prezzo in vetrina

Il risultato dell'esempio è un abbonamento fisso a $79, pacchetti di crediti a $90 e fatturazione per attività avviate a $96.99. Questa classifica vale solo per il catalogo e il carico dichiarati. Una piccola modifica nel trattamento dei tentativi o nel lavoro in background incluso può ribaltarla.

Calcola il punto di pareggio per ogni coppia. Il piano fisso da $79 batte i pacchetti di crediti da $30 ogni volta che la domanda mensile richiede tre o più pacchetti, supponendo che i crediti inutilizzati non abbiano valore futuro. Se il riporto permette all'acquirente di usare ogni unità, $79 equivalgono a circa 1,316.7 unità di credito a sei centesimi ciascuna. Sotto quel consumo, i crediti usati interamente costano meno.

Rispetto alle attività avviate da $0.14, $79 equivalgono a circa 564.3 eventi. I 692.8 eventi previsti superano quel punto. Se però il piano per attività addebita solo 433 iterazioni richieste, costa $60.62 e vince. Ancora una volta, una definizione conta più della tariffa principale.

Esegui casi di sensibilità invece di fingere che la stima sia esatta. Per questo carico, varia l'amplificazione dei tentativi da 1.10 a 1.50, il lavoro in background da 20 a 60 eventi settimanali e il consumo delle modifiche complesse con un moltiplicatore ragionevole dichiarato dal fornitore. Non servono decine di scenari. Servono le poche variabili che possono cambiare la decisione.

Considera separatamente flusso di cassa e vincolo contrattuale rispetto al costo unitario. I pacchetti possono preservare la flessibilità. Un abbonamento mensile crea un tetto prevedibile finché resti nel suo limite. Un abbonamento annuale scambia flessibilità con uno sconto. Esportazione del codice sorgente e snapshot possono ridurre il costo di abbandonare un builder, ma non rendono gratuita la migrazione: l'applicazione esportata richiede comunque una build funzionante, infrastruttura e qualcuno che sappia mantenerla.

Un fondatore con un utilizzo incerto dovrebbe preferire il modello il cui svantaggio è visibile. Questo può significare pacchetti con un lungo riporto, anche quando il totale mensile previsto è leggermente più alto. Un team con lavoro costante e misurato può acquistare un piano fisso vicino al centro del suo intervallo incluso. Un piano per attività è adatto al lavoro che corrisponde chiaramente a risultati accettati e include le correzioni nell'attività.

Non scegliere in base al vincitore dell'esempio. Scegli dopo aver sostituito ogni tariffa e soglia ipotetica con condizioni che puoi indicare e ogni ipotesi di carico con un'osservazione del progetto pilota.

Sottoponi il modello di fatturazione a un test di accettazione

Un modello di prezzo è pronto per una decisione quando un'altra persona può ricostruire il totale mensile dal registro e dalle condizioni del piano. Se il calcolo dipende dal fatto che un commerciale interpreti un'attività interna a posteriori, il modello non supera il test.

Usa questa breve lista di controllo:

1. Registra 100 iterazioni richieste rappresentative, oppure un campione più piccolo che includa ogni grande tipo di lavoro.
2. Etichetta tentativi, tentativi automatici, piani, test, build, distribuzioni e altre esecuzioni in background.
3. Associa ogni evento alla regola del fornitore per crediti, attività o soglie incluse.
4. Calcola i totali del mese previsto, tranquillo e di rilascio con lo stesso fattore 4.33.
5. Salva le condizioni del piano e confronta la prima fattura reale con la previsione.

Stabilisci una tolleranza prima del progetto pilota. Per esempio, potresti indagare qualsiasi totale superiore di oltre il 10 per cento alla previsione. La percentuale è una scelta gestionale, non uno standard di settore. Serve a imporre una revisione mentre la cronologia degli eventi è ancora disponibile.

Se l'utilizzo effettivo supera la previsione, individua la categoria di righe responsabile. Più lavoro accettato è diverso da più tentativi. Più esecuzioni di distribuzione pianificate sono diverse da un ciclo di un agente. Il rimedio potrebbe essere un piano più grande, una politica più restrittiva per gli agenti, richieste più chiare o una correzione della fatturazione. Un solo totale non può dirti quale.

Tieni il registro accanto alla fattura per i primi tre cicli di fatturazione, perché un progetto pilota tranquillo può non cogliere lavori in batch, attività di rilascio e correzioni automatiche. Il modello più economico per 100 iterazioni settimanali dipende quindi dalle condizioni, ma la decisione non deve essere vaga. Nell'esempio esplicito vince l'abbonamento fisso da $79. Con la fatturazione per attività limitata al successo, lo stesso lavoro costa $60.62 e vince la fatturazione per attività. I pacchetti di crediti vincono con un consumo più basso o discontinuo quando il riporto evita sprechi. Scrivi che cosa conta, misura il lavoro nascosto e lascia che la fattura dimostri la promessa.