Milhares de pessoas têm ideias de startups e acabam desistindo (ou pior, lançando um produto de baixa qualidade) por não terem um sócio que saiba programar. Eu e meu co-founder já repetimos tantas vezes essa história (para ajudar amigos, colegas empreendedores e em palestras), que acabamos percebendo o quão grande é esse problema hoje no Brasil. Nesse post vamos explicar como superamos esse problema para lançar o Glio.
Sou um ex-jogador profissional de poker formado em Administração pela PUC-Rio e, em minha última startup, o MaisEV, não precisava programar. Meu trabalho principal sempre foi obter usuários, publicar conteúdo de alto nível, fazer SEO, fechar parcerias, vender as soluções de propaganda, monetizar a base através de programas de afiliados, gerenciar a equipe, etc. Raras vezes tive que me preocupar com o código. Quando precisava, usava softwares pagos ou terceirizava o desenvolvimento.
Após fazer com que o MaisEV se tornasse o site de poker mais acessado do Brasil, vendi a startup e decidi que queria explorar outras oportunidades que via no mercado. Me sentia profundamente incomodado com a falta de informação de qualidade sobre restaurantes, bares, lojas, e outros estabelecimentos locais. Foi aí que resolvi lançar o Glio, uma rede social de avaliação de estabelecimentos que se diferenciasse pela qualidade da informação.
Como não programava, iniciei minha busca por um sócio de tecnologia entre amigos programadores, mas logo esbarrei em um grande problema: todos queriam se dedicar apenas part-time. E eu sempre acreditei que este fosse um erro. Fazer uma startup dar certo no Brasil já é bem difícil trabalhando 12 horas por dia, 7 dias por semana. Dividir seu precioso tempo entre dois trabalhos torna o desafio quase impossível. Concordo com o Paul Graham quando ele diz “If startup failure were a disease, the CDC would be issuing bulletins warning people to avoid day jobs”.
Segui, então, o conselho do Jason Freedman – “You don’t find a technical cofounder, you earn one” – e resolvi lançar um protótipo funcional com o intuito de aumentar as chances de conseguir o interesse de um desenvolvedor talentoso disposto a se tornar o “tech co-founder”. Para isso, trilhei o mesmo caminho que tinha seguido no MaisEV: parti pro Elance. Já tinha usado a plataforma pra contratar programadores, designers, virtual assistants e até copywriters de todas as partes do mundo, mas nunca a considerei como caminho viável para a criação de um MVP, até ouvir a história do Dan Shapiro, que usou o vWorker pra criar o protótipo do Ontela (startup depois adquirida pelo Photobucket) com apenas $600 dólares.
É importante notar que nesse caso a experiência de já ter trabalhado com freelancers e ter gerenciado uma equipe (no caso do MaisEV) foi extremamente útil e me deixou calejado em relação aos principais erros que são cometidos ao terceirizar desenvolvimento. A prospecção do candidato ideal pro trabalho e a comunicação devem ser feitas de maneira extremamente cuidadosa pra essa relação não virar um pesadelo. No caso do Glio, após uma forte peneira, consegui um developer com experiência e bem avaliado no Elance e comecei a desenvolver o protótipo com ele. Dentro de uma semana tínhamos um MVP bem básico e bem feio. Você podia apenas acessar as páginas de restaurantes do Rio de Janeiro e se cadastrar via Facebook para publicar avaliações. Mas foi o suficiente para mostrar a alguns amigos e testar a aceitação.
Alguns dias depois, fui tomar uma cerveja com um amigo. Conversando descobri que esse meu amigo, um cara muito inteligente, que estava prestes a se formar em Direito, estava profundamente insatisfeito em seu trabalho como advogado e pensando em deixar a sua empresa. Quanto mais ele falava, mais via nele o “espírito de startup” tão difícil de encontrar por aí e, apesar de não saber como ele poderia agregar a médio-longo prazo na empresa em termos técnicos, sabia que precisava ter pessoas comprometidas, inteligentes e com uma forte ética de trabalho ao meu lado. Além disso, das pessoas pras quais mostrei o Glio, o João tinha sido o mais empolgado a respeito, avaliando diversos lugares e participando ativamente. Então chamei-o para trabalhar comigo no Glio e – supreendentemente – ele aceitou na mesma hora.
Uma importante lição: todos da equipe atual não hesitaram nem um pouco ao aceitar trabalhar no Glio e mergulhar de cara na oportunidade de melhorar a experiência de consumo de serviços locais no Brasil. Todos responderam imediatamente que sim, sem perguntar sobre salário, carga de trabalho ou até exatamente a sua função. Os que hesitaram e fizeram mil perguntas e demandas ou não entraram para a empresa ou trabalharam com a gente por muito pouco tempo.
Com o João ao meu lado, demos continuidade ao plano de achar um sócio programador, enquanto continuava o desenvolvimento diário com nosso desenvolvedor do Elance. Apesar de conseguirmos uma excelente velocidade no desenvolvimento (devido a todos os cuidados tomados e forte comunicação), fomos confirmando o que já sabíamos: para conseguir desenvolver um produto de internet de alta qualidade, você precisa ter uma equipe desenvolvedora própria. Você perde muita agilidade se tiver que depender de um developer externo para mudar um botão ou uma frase do site e, para uma rede social como o Glio, sabíamos que seria necessária uma iteração diária do produto.
Então tentamos de tudo para achar um desenvolvedor: cartazes na PUC-Rio, idas a eventos de startups, conversas com amigos e amigos de amigos e buscas no LinkedIn e no GitHub. Eu passei, inclusive, a frequentar o grupo RubyOnRio (onde se encontram muitos programadores talentosos) e tive a oportunidade de conhecer alguns deles pessoalmente.
As lições que acabamos aprendendo foram as seguintes:
1. A demanda por (bons) programadores hoje é muito maior que a oferta, principalmente no Brasil. Isso se reflete no valor dos salários e benefícios. A menos que haja uma forte motivação interna, dificilmente um programador vai largar a estabilidade e a alta remuneração de uma grande empresa para trabalhar em uma startup. Portanto, se você vai contratar um bom programador de Ruby, Python ou node.js, precisa ter um enorme fôlego financeiro.
2. Apesar da área de computação ser aquela onde encontram-se o maior número de empreendedores, ainda assim, o número é muito pequeno. Meses atrás discutia esse problema com Sergio Yates, a quem considero meu mentor, e ele me perguntou: “Roberto, quantos entre os seus amigos e colegas da administração são empreendedores? 1%, 2%?”. Eu respondi que sim, provavelmente esse era o percentual, e ele replicou que dentre programadores o percentual pode ser um pouco maior, mas dificilmente foge muito disso. Aos poucos fui percebendo que a quantidade de programadores motivados a receber equity ao invés de um salário de mercado é bem baixa. Como tivemos pouquíssimos exits de startups brasileiras até hoje, ainda não existe por aqui uma cultura forte de remuneração em equity que um mercado mais maduro como o americano possui. Veja o parágrafo “Challenges of doing business in Brazil” dessa resposta do Davis Smith no Quora.
3. Ok, agora supõe que você consegue passar por esses filtros rigorosos e encontra um programador talentoso e com espírito empreendedor. O que acontece? Quase todos os programadores-empreendedores já estão tocando as suas próprias startups ou projetos de startups. E é normal que isso aconteça.
4. O último ponto e o mais delicado é o seguinte: uma sociedade é pior que um casamento, não existe separação. Portanto, você quer como sócios apenas pessoas que compartilhem da sua visão e filosofia, pessoas com as quais você já possui certa intimidade, e isso vem com o tempo. Você não vai chegar em um evento de startup, conhecer alguém e no dia seguinte se tornar sócio dessa pessoa. É preciso tempo para criar esse relacionamento. A mesma filosofia se aplica à relação com investidores. Caso contrário, você vai ter como parceiro inseparável alguém que pode ter objetivos e mentalidades diferentes e isso fatalmente vai levar a conflitos em sua empresa.
Aos poucos eu e o João fomos assimilando esses pontos e encarando de frente o #4 – apesar das nossas dificuldades tecnológicas, dificilmente aceitaríamos ter no Glio um sócio com o qual já não tivéssemos uma relação. E considerando a decisão de não pegarmos investimento antes de lançarmos e validarmos o produto, faltavam recursos na época para contratar um CTO. Em paralelo, tínhamos tentado contratar um designer full time para a equipe. Após duas semanas, ele infelizmente não aguentou o ritmo de trabalho, e esta foi a gota d’água para a decisão que iríamos tomar. Inspirados pela história de Vinicius Vacanti e do Yipit, fomos amadurecendo a decisão de aprender a programar.
Há anos lia na comunidade Hacker News perguntas sobre como encontrar um tech co-founder. A resposta clássica e quase unânime dada por fundadores de startups no Vale sempre foi: “learn to code”. Inicialmente a rejeitei, pois pensava que pessoas de negócios tinham que cuidar exclusivamente de negócios e que nunca conseguiriam ter a capacidade de programar, e vice-versa. Mas ler a história do Yipit me fez mudar de idéia.
Vinicius Vacanti é um brasileiro que trabalhava no mercado financeiro americano quando largou o emprego para fundar o Yipit, um agregador de ofertas de compras coletivas com recomendações personalizadas. De forma similar à nossa, Vinicius não tinha noção alguma de desenvolvimento web. Ele e o seu co-founder, Jim Moran, tentaram terceirizar o desenvolvimento do seu protótipo, mas não conseguiram. A versão entregue pelos desenvolvedores que contrataram simplesmente não funcionava. E aí decidiram aprender a programar e se tornar seus próprios sócios de tecnologia (ou melhor, “temporary technical co-founders”). Vinicius escreveu uma série de blog posts chamada Becoming Your Own Technical Co-Founder, que nos ajudou fortemente a encarar esse desafio.
É importante ressaltar que nem eu nem o João tínhamos nenhuma afinidade por programação. Eu tinha tentado algumas vezes aprender e o máximo que tinha conseguido foi muita dor de cabeça. Mas é impressionante como mudam as coisas que você está disposto a fazer quando não há outra opção. É mais um motivo que me leva a acreditar que dedicação exclusiva à startup é fundamental: quando o que você está fazendo é “do or die”, subitamente diversas barreiras somem e você foca apenas em achar um jeito de superar os obstáculos e executar o que precisa, seja lá o que for – conseguir entrar em uma incubadora concorrida, comprar um domínio de alguém na Indonésia, criar código em Ruby, o que for.
Apesar de ambos termos aprendido o quadro geral do funcionamento de um web app, dividimos as responsabilidades em front-end e back-end. Eu me tornei primariamente responsável pelo design e código front-end e o João pelo back-end em Rails. Inicialmente começamos utilizando tutoriais: o Rails for Zombies foi a nossa introdução ao mundo de Rails – é um tutorial essencial para entender como as diferentes partes de um app se relacionam. Já o The Intro to Rails Screencast I Wish I Had é uma aula sobre real desenvolvimento de um aplicativo funcional. Veja o screencast e siga à risca o processo para replicar o aplicativo criado em seu computador.
Depois disso, não tem muita saída além de pegar um livro aprofundado – como o Ruby on Rails 3: Learn Rails by Example – e começar a trabalhar diretamente em algo que importa para você. How I Learned Enough Ruby On Rails In 12 Weeks To Launch Freelancify é um excelente artigo, pois toca nesse ponto essencial. Tutoriais, aulas e conselhos servem pra te deixar pronto pra começar, mas você só vai efetivamente entender como é a vida de um developer se deixar as mãos sujas de código e efetivamente se preocupar para que as coisas aconteçam e não quebrem. Treino é treino e jogo é jogo, sempre.
Em termos de design, eu já estudava o assunto há um bom tempo, através de livros como o Don’t Make Me Think, por exemplo. Sempre fiz a arquitetura e wireframe dos meus sites, mas não fazia ideia de como mexer no Photoshop. Por isso costumava trabalhar com outros designers. Para aprender, usei dois sites da rede Tuts+: o Psdtuts+ e o Webdesigntuts+. Essencialmente passei metade de uma semana de trabalho fazendo alguns tutoriais gratuitos. Foi o suficiente para entender como funciona o Photoshop e em seguida poder fazer as telas do novo layout do Glio para o lançamento oficial.
A partir daí o desafio passou a ser efetivamente modificar nosso app. O maior problema pra um leigo costuma ser a instalação dos softwares necessários em seu computador. É necessário usar a command line, o que inicialmente parece bem assustador para quem está acostumado a instalar tudo através de dois cliques em um ícone bonitinho. Mas o problema principal mesmo é que é comum surgirem imprevistos na instalação e não há tutorial que resolva esse problema.
Aos poucos percebemos o poder do Google (ou do DuckDuckGo, que o João prefere): toda e qualquer dúvida ou erro com o qual você esteja se deparando provavelmente também já aconteceu com outro desenvolvedor. E outra coisa que fomos percebendo é que desenvolvedores são extremamente generosos. Não é à toa que existem fortes comunidades como o Stack Overflow e tanto software open source de qualidade disponível no GitHub.
A maioria dos desenvolvedores com quem tivemos contato desde fundar o Glio se identificaram muito com a nossa história e foram extremamente gentis, se disponibilizando a tirar dúvidas quando necessário. Acreditamos que desenvolvedores tem um genuíno e autêntico interesse em ver outras pessoas interessadas e dispostas a aprender a programar. O Google tornou-se nossa maior fonte de aprendizado: sempre que tínhamos que decidir como resolver um problema recorríamos a algum post de blog de um programador, algum tópico no Stack Overflow ou algum fórum. E quando, após tentar de todas as formas, não conseguíamos, recorríamos a algum programador amigo, que não nos “dava” o código pronto, mas nos iluminava apontando quais eram provavelmente as maiores causas do problema.
Após algumas semanas de iteração e desenvolvimento, realizamos, em abril, o lançamento oficial do Glio. Em Julho lançamos a versão mobile do site, seguindo a mesma filosofia. Hoje contamos com uma comunidade fortemente engajada que está ajudando milhares de consumidores a realizar escolhas melhores.
Essas são algumas das principais lições que aprendemos durante essa jornada:
1. Você não precisa de um diploma de Computer Science para lançar uma startup. Há pouco tempo atrás ficamos surpresos e felizes em descobrir que fundadores de diversas startups que admiramos concordam com isso. Nenhum dos fundadores do Instagram é de Computer Science. A equipe inicial do Twitter nem formação acadêmica possuía. E o primeiro CTO do Facebook? Dustin Moskovitz, que na época estudava Economia. A falta de um diploma em CS não impede que você aprenda a programar e lance seu produto.
2. No entanto você precisa de pessoas que entendam de tecnologia na empresa. Atualmente quatro pessoas full time trabalham no Glio e todas programam – apesar de apenas uma possuir formação em CS. Qualquer pessoa inteligente e dedicada pode aprender a programar. E esse conhecimento é fundamental para produzir um produto de qualidade. São raros os bons produtos desenvolvidos por empresas sem “hack culture” – uma forte cultura de programação, onde as principais figuras da empresa botem a mão na massa e ideias sejam implementadas e testadas com agilidade.
3. Alguns dos melhores fundadores de empresas de tecnologia são pessoas que ao mesmo tempo possuem a visão de business e a de tecnologia. Ou seja, se você é um administrador, marketeiro ou designer e sabe programar, terá uma grande vantagem em relação a quem é super-especializado em apenas uma área. No início de uma startup, seus fundadores precisam estar dispostos a vestir muitos chapéus. Você inicialmente vai ser o programador, o designer, o cara de finanças, o gerente de projetos, o marketeiro, o responsável por RH, e às vezes até o faxineiro. Faz parte da necessidade de fazer mais por menos. Estando incubados no Instituto Gênesis da PUC-Rio, temos a possibilidade de interagir diariamente com muitos empreendedores e aos poucos percebemos que os que mais se destacam são os que lidam bem com ambas as áreas. Um exemplo forte dessa tendência para mim é o Felipe Salvini, amigo e fundador da Sieve. O Salvini é um programador por formação, mas tem um talento nato para RH e conseguiu fazer da Sieve um dos melhores ambientes de trabalho que já vi.
4. Se você programar, a burn rate da sua startup será muito menor. Não são incomuns os casos de startups que, por terem que terceirizar todo seu desenvolvimento, gastam centenas de milhares de dólares apenas para lançar seu produto. Por termos aprendido a programar, conseguimos lançar o Glio com menos de R$35 mil, incluindo gastos de escritório, equipamentos e a compra do domínio glio.com. O exemplo do Instagram também é incrível – eles conseguiram lançar seu MVP com menos de U$65 mil. Aprender a programar, portanto, não é só uma boa escolha em termos de produto. É também uma sábia escolha sob a ótica financeira.
5. Você precisa saber programar para liderar programadores. Como você vai administrar uma equipe de programadores se não entende o que eles estão fazendo? Ter aprendido a programar foi essencial para em seguida treinar outros membros da equipe e hoje gerenciar o seu trabalho.
Você tem uma ideia e quer executá-la? Coloque a mão na massa. Não espere um sócio-programador cair do céu. Programar não é fácil, mas com uma pitada de inteligência e muita dedicação, você consegue. As pessoas dentro e em volta da sua startup vão respeitar e admirar o fato de você ter saído de sua zona de conforto para fazer com que a sua visão se torne realidade.
Software está comendo o mundo e as possibilidades são inúmeras para uma equipe com conhecimento multidisciplinar e forte ética de trabalho. Sabendo programar você vai ter a liberdade necessária para explorar as melhores oportunidades de mercado. Espero que a nossa história possa ajudar quem hoje está encarando o desafio que nós encaramos antes de lançar o Glio. Se eu puder te ajudar de mais alguma forma, me mande um email (robertoriccio arroba glio ponto com) ou tweet (@rriccio). Boa sorte.
Roberto Riccio.