No primeiro ano de operação da Alice, as LPs eram feitas por freelancers, mas ao passo que a operação de growth cresceu, a demanda por LPs ficou cada vez maior. Começou a ficar inviável aguardar de 3 a 4 semanas para a produção de uma LP que ficaria 2 semanas em teste. Além disso, havia o custo alto e a inconsistência das páginas. Ao passo que o time de design da Alice cresceu, foi possível absorver o layout dessas páginas, mas a implementação continuava sendo terceirizada e as inconsistências continuavam. Assim identificamos os principais problemas a serem resolvidos:

Aumento de demanda - conforme o time de Growth e PLG cresceram, as demandas de LPs deixaram de ser algo pontual e de prioridade baixa. Agora tínhamos uma operação com foco em criação de leads e retenção de membros que precisava de muito auxílio do time de design.

Falta de escalabilidade - mesmo com o aumento de prioridade dessas páginas, entendemos que esse aumento não deveria crescer exponencialmente para o time de design. Precisaríamos trabalhar focando em escalabilidade e agilidade. Uma vez que uma LP teste pode ficar no ar apenas 2 semanas, não fazia sentido demorar 4 semanas pra construí-la.

Inconsistência - o uso de freelancers somado a uma nova estrutura de design fez com que, no começo da operação de landing pages, surgissem diversas inconsistências de layout/visual. Mas, uma vez que a operação cresceu e o time de design se consolidou, não fazia mais sentido publicar páginas que não seguissem nossa identidade.

LP = Código - no fim do dia, LP é código. O design system da Alice já se encontrava maduro o suficiente pra ser aplicado e desdobrado na área de landing pages.

Pensando nisso, e após o sucesso da biblioteca de emails, decidimos criar a biblioteca de LPs.