Tecnología Informal

065. Conanbatt: Kaya.gs

  • 54:33
  • Fri Dec 12 2025
  • Temporada 2 • Ep. 27
  • startup
  • founders
  • historia de startup
  • errores al emprender
  • construir comunidad
  • go programming
  • go server
  • kaia.gs
  • tecnología informal
  • product launch

En este nuevo episodio de Tecnología Informal, volvemos a un terreno muy personal. Es una especie de continuación de Origins, donde cuento cómo fue lanzar y eventualmente cerrar Kaia.gs, el server de Go que armé cuando decidí que no iba a seguir como profesional del juego. Crear un producto, escalarlo, levantar plata, construir comunidad, lidiar con conflictos entre founders y, finalmente, ver morir el proyecto. Una historia de manija, errores de novato y aprendizajes, en uno de los momentos más personales del podcast. 🔗 Encontrá todas nuestras búsquedas abiertas en: silver.dev/jobs 🎓 Prepará tus entrevistas con Interview Ready: ⁠https://ready.silver.dev/ #startup #tecnologiainformal #founderstory #gotech

Gente, los primeros dólares que recibís por tu negocio son los mejores del mundo.

—¿Te gusta el proyecto? Me decían, "¡está buenísimo!" ¡Pagáme! Pagáme la cuenta, si tenés la cuenta.


En el episodio de hoy vamos a hablar otra vez de una historia personal. Es un episodio bastante especial porque tiene que ver con un proyecto que hice yo. Y por ahí también es una buena historia para entender cómo puede ser que yo, con la carrera que tenía, haya llegado a trabajar en Estados Unidos.

Si lo pensamos un poco, entré tarde a la facultad, no la terminé, no avancé mucho. Después trabajé en consultoría un año y medio, más o menos. Y de ahí llegué a conseguir una oferta e irme a vivir a San Francisco. ¿Qué pasó en el medio? ¿Cómo se logra, con una experiencia laboral por ahí no tan espectacular y sin título, llegar a ese nivel?

Vamos a hablar un poco de la historia de Kaya.gs, que es un proyecto personal. Es una de las maneras, como hablé en el episodio de carreras experienciales, de cómo te saltás 3, 4 o 5 años de carrera y de trabajo haciendo algo propio, aprendiendo a altísima velocidad. Así que les voy a contar un poco de Kaya.gs.


Orígenes y primeros pasos

En el último episodio personal, que era "Origins", terminamos en 2005. Yo decidí no ser un profesional de Go, abandonar ese camino y volver a ser programador. Entre 2005 y 2009 fui a la facultad, tuve una novia, empecé a tener una vida más normal, siguiendo el mainstream de cómo se tomaban las decisiones en ese momento. Conseguí mi primer trabajo en IBM, medio tranquilo.

En 2009 conseguí mi primer trabajo en una startup web, en lo que hoy en día es Deviget. Empecé a trabajar en "productitos" y a amigarme otra vez con el Go. En 2009 dije: "Bueno, no soy un profesional, pero soy un amateur, me gustaría poder jugar otra vez". Volví al torneo argentino, lo gané en 2010 y 2011.

Quería volver a hacer algo con Go. Si no iba a ser un profesional del juego jugándolo, por ahí podía ser un profesional en el sentido monetario: hacer un producto para jugadores de Go.

Estaba armado con experiencia de programador, de Ruby, de Ruby on Rails, que era lo común de esa época. Leía los essays de Y Combinator y dije: "Me toca hacer un producto digital en serio. Voy a hacer un servidor de Go, donde la gente pueda jugar online con otros jugadores".

Leía mucho los essays de Paul Graham en esa época. Era lo más común de leer de esta pequeña incubadora llamada Y Combinator, que la gente no conocía. Había toda una sección donde él hablaba de cómo trabajar con founders. Decía: "La razón número uno por la que las startups se caen es porque te peleás con el co-founder. Tenés que buscar a alguien con quien sabés que vas a trabajar bien, con quien vas a tener una relación de largo plazo. No seas un solo founder, porque es muy difícil armar una startup solo".

En ese momento hablé con mi compañero de la facultad, Patricio Revoratti, llamado Poshi. Le dije: "Llevamos un par de años de facultad, nos conocemos, hicimos proyectos, TPs, hagamos algo". Le mencioné un artículo de Y Combinator sobre cómo armar el equity. Esta era mi idea, mi sueño, pero dije: "No, tenemos que tener el equity 50-50. No quiero problemas de equity tan temprano en un proyecto".

Empezamos a probar: nos juntábamos en casa, yo vivía solo en esa época. "Juntate, venite a casa, trabajamos un rato juntos y vamos viendo si tenemos fit".


Armando Kaya.gs

Me acuerdo lo que fue elegir el stack de esa época. Lo común era usar Ruby on Rails, pero había un contribuidor de Redis muy conocido en Argentina, Miguel Martens, que había hecho un micro framework llamado Cuba. Él era como un advisor técnico y me dijo: "Hacelo con Cuba". Lo hice con Cuba, que era como una especie de Express.js para Ruby. La base de datos era Redis, no había SQL, era solo Redis, una decisión heterodoxa para la época, pero funcionaba.

El setup tenía algo llamado Juggernaut, pero lo más importante es que el backend era Ruby y el frontend era Javascript vanilla con jQuery. Para manejar realtime, la comunicación entre servidor y clientes, iba a usar una librería popular llamada Socket.io.

Teníamos el stack armado, elegí el nombre: Kaya. Kaya es el árbol con el que se hacen los tableros de Go de más alta calidad del mundo. Lo llamé .gs porque en esa época nació la onda de que las startups no tengan .com, sino .ly, .io, etc. Quería ser contrarian y elegimos .gs, quedando como Kaya Go Server, Kaya.gs.

En esa época, Poshi hacía frontend y yo backend. Yo no sabía nada de frontend, solo programación abstracta, pero no CSS ni nada de eso. Todo el frontend lo hacía Poshi y yo el backend.

Nos juntábamos a tomar mate mientras programábamos, tipo hackatón tranqui. Hubo un día donde tuvimos el primer momento mágico de Kaya.gs: él tenía el tablero hecho, conectado con mi servicio, apretaba el tablero y aparecía la piedra en tiempo real. Fue un momento de total magia, sentí que era magia, que estábamos creando algo y funcionaba.

Corregimos algunas cosas y ya más o menos andaba, un sitio web, un prototipo. Lo mostré en el laburo y el jefe de la consultora vio eso y se le desfiguró la cara, como diciendo: "Este me va a renunciar en cualquier momento". A los tres meses renuncié, obviamente.


El desafío del cold start y la monetización

Antes de renunciar, el desafío era cómo nombrar un producto digital como este. Los servidores de juegos multiplayer sirven si tenés jugadores. Tenés que generar una audiencia porque si no hay jugadores, nadie juega. Teníamos el problema del cold start de un sistema PVP.

Además, teníamos un tema de plata. Yo tenía plata para vivir un año, pero también tenía que vivir mi socio. No podíamos hacerlo ad honorem por mucho tiempo. Necesitábamos monetización o fondeo temprano.

En esa época el furor era Kickstarter, que era más o menos nuevo. Palmer Luckey iba a sacar el Oculus un año después de que nosotros intentamos hacer Kickstarter. Kickstarter era tan nuevo que ni los pioneros lo habían usado todavía. Era la forma nueva de conseguir plata sin diluirte, sin temas de equity complejos. Era como una pre-venta para conseguir fondeo o gente que te compre el producto antes de que exista.

Pero Kickstarter solo funcionaba en Estados Unidos y no era como hoy que te hacés la LLC y listo. No era accesible. Surgió un Kickstarter local o regional llamado Ideame, que venía de la hermana de Batán (el de Murali). Ideame era como un Kickstarter regional.

La idea era: hacés un video, un pitch. Armamos el video muy inspirado en Y Combinator, mezclando el concepto de preventa con equity. Hicimos el pitch de Kaya.gs, el Social Go Server, porque "social" era la buzzword de la época, como hoy sería "AI Go Server".

Fuimos parte del set de pioneros de Ideame, uno de los primeros siete proyectos. Esto es antes de que el proyecto sea público, faltaba mucho para que salga terminado. La onda de la época, y que sigue siendo así, es que para juegos juntás plata primero y lo armás después.


Monetización digital y el proto-NFT

Queríamos salir en Ideame, pero teníamos un par de temas. Nuestra audiencia era principalmente internacional (Estados Unidos, Europa) y los Kickstarter de la época daban remeras, cuadros, cosas físicas, pero eso nos mataba porque había que mandarlo a distintas partes del mundo. No queríamos hacer eso.

Queríamos algo bien digital. No podíamos ni dar un producto porque iba a ser principalmente gratuito, ni algo físico. Inventamos las cuentas: un conjunto de kanjis (lectura japonesa) que indicaban la categoría de tu cuenta. Podías tener la de supporter (USD 20) o la de founding user (USD 100), y con eso tenías un simbolito en la cuenta.

Siempre digo que estuvo buenísima esa idea porque era como un proto-NFT. Lo único que comprabas era el acceso digital a la cuenta, no te daba ningún beneficio concreto, era más chapa que otra cosa.

Hablamos mucho de pricing. Teníamos una cuenta de USD 25, una de USD 100. Yo decía: "¿No es mucho USD 100?" Pero la estrategia de pricing es poner un producto muy caro para que lo otro parezca barato. Puse una categoría de USD 1.000: si pagabas eso, te mandaba el tablero con el que aprendí a jugar Go (yo era influyente en el mundo de Go). Lo gracioso es que alguien me compró el tablero de Go, un alemán que me dijo: "Me encanta lo que estás haciendo, por favor, seguilo". Por suerte me dijo que no le interesaba el tablero, que me lo podía quedar, pero pagó USD 1.000 solo para apoyar el proyecto.


Armando la audiencia y el hype

Íbamos a salir en Ideame, levantar plata, teníamos una audiencia. ¿Cómo la armamos? Empezamos a trabajar en un foro de Go, donde participaban 500.000 jugadores de Go, era como un r/devsarg de Go. Esto es época pre-Reddit, existía Reddit pero no era lo que es hoy. Todas las comunidades iban alrededor de foros, como Taringa.

Fui armando hype, mostrando screenshots, contando features, enganchando a la comunidad que tenía muchas ganas de una opción nueva. Armamos audiencia, el launch, la idea de monetización: vender cuentas digitales fáciles de manejar.

Preparando el contenido para este podcast, vi un email re manija del 11 de agosto de 2011: "Estamos por salir a pedir plata, somos lo más grosso del universo". Teníamos la magia de algo que andaba en web, real time, que no existía en esa época. Estábamos innovando con un producto que era mi sentido de propósito. Teníamos audiencia, todas las fichitas ordenadas para salir.

Salimos el 12 de agosto, Ideame lanza con los proyectos pioneros. Me acuerdo que había uno que era una cabeza de muñeco para tirar las llaves por el balcón si el portero no andaba, y Kaya.gs, nada que ver.

Lo anuncio en el foro, cruzamos los dedos y entra la primera compra de una cuenta: ¡ting! USD 25. Gente, los primeros dólares que recibís por tu negocio son los mejores del mundo, es la mejor experiencia del mundo recibir plata de otra persona. Esa energía de estar creando algo y que alguien lo quiera. Locura total con Poshi, un abrazo, llorando. Tengo un mail donde digo: "Hoy nos ponemos en pedo, ya está, era la meta".

Pero la emoción no duró mucho: a los 10 segundos me llega el mail de Customer Support: "Che, no puedo pagar, no me anda". Empiezan a llegar mails internacionales de Alemania, Francia, Estados Unidos: "No puedo pagar en Ideame". Voy a Ideame y les digo: "Me están rebotando los pagos de todas las personas". El bounce rate era como 60%. Me dicen: "Estos pagos de afuera no estamos ni preparados para estas cosas. No van a funcionar bien". Mercado Pago no podía cobrar a los de afuera, así que se caía todo el fundraising.


Crisis y solución: el botón de PayPal

Hablamos con Poshi: ya hicimos el hype en el foro, la gente quiere pagar, validamos que nos quieren pagar y no pueden. ¿Qué hacemos? Alternativas: pongamos un botón de PayPal y listo, cobramos por PayPal y después a mano les creamos la cuenta.

Ese día nos quedamos toda la noche en casa. Yo hacía Customer Support, hablaba con la gente, mantenía el hype, les explicaba lo que pasaba. Poshi armaba una landing page en PHP, subiéndola por FTP. No existía Vercel, era todo por FTP, armando los hooks para que ande el pago de PayPal.

Era la sesión de Crisis Management. Tuvimos que pensar cómo comunicarlo, el messaging. Kickstarter siempre mezclaba si era un pago o una donación, era confuso. Si recibís algo a cambio es un detalle, pero no estás pre-comprando. Si pagabas para comprar un juego y el juego no se materializaba, la gente se sentía estafada.

Como dábamos algo tan digital que todavía no existía, siempre estaba la duda de si era un prepago que genera una deuda comercial o una donación. Debatimos media hora y en un momento dije: "¿Sabés qué? Si vamos a poner cualquier cosa, ponele Candy y se acabó". Nos cagamos de risa, 15 minutos de ese chiste y le pusimos Candy. La página salió, decía Candy, estaba rosa con un corazoncito.

Cuando sacamos la página, fue una locura. Levantamos más de USD 3.000 en 24 horas. La gente le encantó, venía y me decía: "No puedo creer que lo llamaste Candy". Les causaba gracia. Funcionó, levantamos USD 3.000. Ya está, renunciado completamente al laburo, mi vida iba a ser Kaya.gs.


El desafío técnico y el lanzamiento

Levantamos la plata, pero el producto no existía todavía. Teníamos una demo, un prototipo, pero le faltaba. Los juegos no tienen un MVP donde salís rápido: lo primero jugable tiene que tener un alto grado de calidad. Teníamos que tener un tablero armado que entienda todas las reglas del Go, que son mucho más complicadas que el ajedrez. En Go, los resultados son resultado de una negociación, no es que mirás el tablero y ya sabés quién ganó.

Había que hacer el tablero, las reglas, contar los puntos, algoritmos que hacían DFS y chequeaban los territorios, reconocían patrones de vida o muerte. Teníamos que salir con chat privado, chat grupal, todo real time. Además, el software de la época no es el de hoy: no existía React, ni la explosión de paquetes públicos. Todo era artesanal.

Por ejemplo, la lista de conectados: se actualiza varias veces por segundo. Cuando llegamos a 100 usuarios en vivo, la página hacía tantos re-renders que teníamos problemas de performance. Bacheamos los eventos para que el re-render sea cada tantos ciclos, e hicimos un delta: en vez de redibujar toda la columna, solo borrábamos y agregábamos los usuarios que faltaban. ¿Les suena a una tecnología que se resuelve así? Bueno, pero eso con jQuery y Javascript vanilla.

Tomó mucho tiempo. Levantamos la plata en agosto, pero no sacamos el proyecto hasta diciembre.


El viaje a Corea y el día del cepo

Antes de diciembre, en noviembre de 2011, me tocó representar a Argentina en un torneo de Corea. Fui mostrando el proyecto a los jugadores de Go, todos amateurs, muy influyentes. Era como influencer marketing: quería que los jugadores fuertes jueguen en mi servicio y recomienden el producto.

Vendía en persona: "¿Te gusta el proyecto?" —"¡Está buenísimo!" —"Pagáme la cuenta, así tenés la cuenta". Les sacaba plata en efectivo para un producto digital que todavía no existía. Se puede vender sin nada en la mano.

Lo más gracioso de ese viaje fue cuando volví. Volví a fines de noviembre de 2011. Cuando cobramos de Ideame, iba al banco y le traía la mitad de la plata a Poshi y la otra mitad para mí. Vuelvo de Corea y le digo: "La semana que viene voy al banco y traigo la plata". Me mira y me dice: "No se puede más". —"¿Cómo que no se puede más?" —"Sí, hay cepo". —"¿Qué es un cepo?" —"No se pueden sacar más dólares del banco". Me quería morir.


El lanzamiento del alfa y los problemas técnicos

Para diciembre de 2011 tenía que salir. En vez de salir como beta, lo llamé alfa porque estaba muy despreparado. Había cosas que andaban y cosas que no. Nunca le hicimos un montón de cosas que ahora sé que hay que hacer, pero no sabía nada de programación en la época.

Salimos el viernes 23 de diciembre, un día antes de Navidad, con un alfa rotísimo. No tenía cuentas para generarse, la gente que había comprado las cuentas se las creaba a mano. No había página de create, de login, nada. No existía Clerk, tenías que hacer tu autenticación a mano, guardar el hash y el token, mandarles un mail (que tampoco andaba porque no había servicios de email).

Soportar cuentas nos tomó una semana más. Pero tenía que salir ese año. El servidor subió y se cayó inmediatamente porque nunca le había hecho un stress test. Salí con la Micro One de AWS, la más barata. Salimos del launch, entraron 100 jugadores, empezó a triggerear todos los eventos de real time y el CPU se fue al 100% y se caía todo el tiempo. Welcome to the real world. Tuve que subir a small y ahí anduvo mucho mejor. Semanas después descubrí que AWS te decía que no uses la micro para producción.

Salimos y se podía jugar. Teníamos problemas de reliability, pero cuando no se caían los servidores, andaba bastante bien la experiencia.


Competencia y diferenciación

Ahora teníamos un producto, usuarios, ingresos. Estábamos en el mercado, listos para competir. PVP es parecido a marketplaces: tenés network effect. Mientras más jugadores tenés, más jugadores atraés.

En esa época había dos servidores: IGS (Internet Go Server), manejado por un soviético intolerante que baneaba a la gente, pero tenía un protocolo abierto. Había 50 clientes, todos malos. Decidimos que Kaya.gs iba a tener un cliente muy bueno, no un servicio API.

El otro era KGS, un servidor mucho mejor que IGS, mejor cultura, más orientado a la charla y la comunidad, hecho por un dev part-time. Pero KGS era un Java Applet. Si no sabés lo que es un Java Applet, te envidio. Era tecnología arcana, ya vieja para la época. Tenías que instalar Java en tu computadora para correrlo.

La dirección de la tecnología era hacer todo en HTML. Era la época de HTML5, de WebSockets. Hacer algo en HTML era lo más innovador. Kaya.gs tenía el objetivo de reemplazar a estos dos. Había un guiño de que nosotros también éramos KGS.

Nuestra posición era irreverente, experimental. Ellos eran servicios amateuros, les iba bien, pero eran muy amateuros. Yo estaba full time en esto, podía hacer experimentación rápida. Éramos talibanes de la experimentación: sacábamos features todas las semanas, deployábamos los viernes. Los usuarios se juntaban los viernes en nuestro servidor, era el pico de tráfico para ver el nuevo feature.

Inventamos una forma de visualizar variaciones de Go, compartirlas en forma de link HTML. Algunos servidores lo agregaron 10 años después. Inventamos la partida broadcast, ver un video de streaming tipo YouTube embebido mientras mirabas una partida. Inventamos materiales educativos, nuevos sistemas de relojes, rating, torneos. Creamos OpenKaia, la pata open source de Kaya, donde la gente podía contribuir.

Teníamos features divertidos: el muzzle (bozal), donde si el 50% de un canal te decía muzzle, no podías hablar por 15 minutos. Inventamos la Twiki, una wiki interactiva desde la consola del chat. Teníamos un sentido estético único. Hicimos un splash fuerte en la comunidad.

Andábamos en iPad, WebSocket, tecnología nueva, plata, mística. Los primeros seis meses de Kaya.gs trabajé 14 horas por día, de lunes a sábados. Me despertaba un lunes diciendo: "Qué lindo día, se viene una semana de grind". No era trabajo para mí, era cumplir mi rol en el universo. Los domingos hacía solo comunidad y jugaba partidas en Kaya.gs. Fácil, 70-80 horas por semana los primeros seis meses.


Problemas y aprendizajes

Obviamente, no todo era bueno. Técnicamente teníamos problemas. Me acuerdo del primer escándalo: en un chat público me quejé de un usuario como argentino ("ah, qué boludo ese") y puse "MFER". Uno sacó un screenshot y lo puso en el foro, fue un escándalo. Me di cuenta que ahora tenía un porte distinto, había expectativas sobre mí como founder.

Lo que más me dolió fue que le hacía daño a Poshi. Aprendí que tengo que ser solo founder, para sentirme libre de opinar y tener tweets que molestan a la gente, decir lo que quiero. En esa época no lo entendía y sentí que tenía que comportarme como un corporate CEO.


Promo: Interview Ready

Tengo una carrera de pasar las entrevistas técnicas más difíciles del mercado y una empresa de recruiting donde ayudo a startups a filtrar a cientos de candidatos. Y ahora te voy a ayudar a vos.

Creé Interview Ready, un programa de preparación de entrevistas para que veas cómo yo doy y hago entrevistas y aprendas a pasarlas. Descubrí más en ready.silver.dev.


El declive: revenue, funding y conflictos

Con el tiempo, teníamos tracción, usuarios, interés, pero no mucho revenue porque vendíamos cuentas, pero no era revenue recurrente. Si se cae Kaya.gs otra vez, haría revenue recurrente, pero es el problema de los marketplaces: si cobrás, no conseguís usuarios, y necesitás usuarios para conseguir usuarios.

Teníamos un revenue de USD 800 por mes, que no es terrible, pero no era bueno. Necesitábamos funding. Nuestra idea era levantar plata, muy inocente. Me acuerdo que estaba Huayra como incubadora, pero plata no nos dieron. Había grants del gobierno, pero no aplicamos porque no me cerraba la idea. Después descubrí que si ganabas el grant, tardaban como 3 años en pagarte.

Un estudio de juegos nos dijo que si hacíamos una versión de iPad, la usaban como demo, pero no quedó en nada. Todo fracaso.

Mi hermano me hizo la gamba y me introdujo con Emiliano Kargieman (el de Satellogic, antes de Satellogic, fundador de Core Security). Me reuní con él, le mostré el proyecto y le dije que necesitaba USD 15.000 para pagarle a un diseñador, a otro programador y darme un año para iterar. Ahora pienso: "Qué papelón pedirle a alguien USD 15.000, tenía que pedir USD 200.000". Él me miró y me dijo: "Andá y volvé otro día". Lo que necesitaba no era plata, era un mentor.

Recibí otro favor local de Javier Otaegui, de una empresa de juegos. Tenía una oficina gigante y la usábamos con Poshi. Trabajábamos dos o tres días en mi casa y dos o tres en la oficina.


Comunidad, conferencias y casi una venta

Usábamos Socket.io, que era nuevo. Cuando hicimos la demo en agosto de 2011, no andaba en Firefox WebSockets. Socket.io hacía fallback en polling, cubría todos los browsers.

Mandamos una propuesta a una conferencia nueva, JSConf, en el polo tecnológico de Barracas. Era organizada por un emprendedor argentino joven, autor de Socket.io: nada menos que Guillermo Rauch. Ahí lo conocí, tenía 22 años. Me contó que dejó la secundaria para irse a Estados Unidos, había hecho Socket.io como parte de LearnBoost y Mongoose.

Otra cosa que nos pasó es que casi nos compran. Apareció un tipo con plata en serio, cientos de miles de dólares, haciendo un servidor de Go nuevo en Asia. Tenían plata pero no visión. Se patinaron USD 50.000 en pagarle a profesionales para que jueguen partidas, pero el servidor era aburrido. Casi nos compran o nos pagan como advisors, pero yo me adelanté y les dije: "Por USD 100.000 te vendo Kaya.gs". El tipo dijo: "No es la etapa de hablar de plata" y se pinchó todo.

No conseguimos levantar plata, no teníamos muchos ingresos. En un momento dije: "Voy a poner apuestas en el sitio web". Busqué si había algún servicio que te deje poner apuestas como una API, y encontré Bitcoin. Decía: "Bienvenido a la plata del futuro". Pero cada transacción tardaba 15 minutos, no me servía. Después apareció alguien que quería comprar la cuenta de USD 100 y me pagó en Bitcoin: 15 bitcoins por USD 100.


El desgaste y el final

Después de 6 meses, el runway era corto, 6-8 meses más. Empezaron los problemas: no teníamos más la manija de "nos vamos a comer el mundo", porque no éramos los mejores. Teníamos 100 jugadores, KGS tenía 4.000 activos. Muy pocas partidas simultáneas.

No solo no teníamos tracción, tampoco crecimiento ni momentum. Además, problemas de calidad: site reliability no andaba bien. Tenía una instancia para WebSockets, otra para API, a veces se caía una u otra, no tenía failovers, ni autorréplica. No sabía cómo armarlo y no era la época donde eso estaba resuelto.

Los números de ventas cada vez peor, los early adopters ya habían comprado, el revenue caía, no había runway, no había momentum, el producto no andaba bien. Cuando se juntan todos esos problemas, empieza el peor: la moral y la energía del equipo.

A los 6-7 meses del lanzamiento, empezó a afectarle más a mi co-founder que a mí, pero a los dos nos pegó. Empezó el primer conflicto con Poshi: el horario laboral. Yo laburaba 14 horas por día, él tenía horario normal de 10 a 6, o 9 a 5. No podía esperar que él haga 14 horas, porque el Go era mi sueño, para él era un proyecto copado nada más.

Pero cuando empezó a fallar el 10 a 6 y bajó a semanas de 20 horas, eso no lo tolero. No me gusta que la gente trate así el trabajo. La pasión te deja hacer cualquier cosa, la disciplina te deja hacer las cosas cuando no querés. Empecé a resentirlo, bajé mi ritmo, y cuando bajé yo, decayó todo.

Cometí un error fatal: le dije a Poshi que si iba a trabajar menos, tenía que tener menos ownership. "Yo soy 75% y vos 25%". Eso fue un error fatal, transformó una relación colaborativa en una confrontativa. Ahora discutíamos quién aportaba más, quién cumplía. La productividad desapareció, ninguno quería trabajar, teníamos que lidiar con el problema del otro. Tuvimos el problema fatal de founders, como dice YC.

Los últimos 3 meses de 2012 la productividad estaba por el piso, modo mantenimiento. Me acuerdo que lo último que implementé era el sistema de apuestas digital (sin plata de verdad), contraté a AeroLab para un diseño, pero no llegó a vivir.

Para diciembre de 2012 tratábamos de mantener el proyecto vivo, con la esperanza de arreglar el problema interno. Dijimos: "Por ahí vos hacés tu freelance y yo consigo un trabajo, y mantenemos el proyecto vivo hasta revivirlo". Ese plan no puede funcionar, era la negación de todo el esfuerzo.


El cierre y el salto a Estados Unidos

Fue la época donde creo que fue Teracode o una similar que me entrevistó como Ruby Developer, me ofrecieron USD 800 por mes, mucho menos de lo que cobraba antes, pero no podía pagar el alquiler. El mes de febrero de 2012 lo pagué tarde, no tenía plata.

Acepté la propuesta de Teracode, me mandaron a hacer el preocupacional y me ghostearon. En esa desesperación, voy con Miguel Martens (el de Cuba) y le digo: "¿Y ahora qué hago?" Me dice: "Probá en Hacker News, mandá unos currículums a ver si te anda".

No había hecho currículums antes, armé 5 y los mandé. Uno fue para script.com, donde terminé entrando. Todavía tengo el resume en Google Drive y les quiero contar la magia de ese currículum: tenía un año y medio de experiencia laboral y un año y medio de un proyecto que estaba fracasando, pero en el currículum puse arriba de todo:

Why should Scribd hire me over other candidates?

I have built a real-time multiplayer game server for the game of Go, with weekly XP-style launches, never missing a week in over 52 weeks. The entire architecture is based on a rich client, and performance was key to drawing hundreds of interactive animated objects updated in real time. The project was funded and sponsored, and I handled everything. I am totally willing.

Como recruiter hoy, leo ese pitch y me emociono. Es buenísimo. Un tipo con dos años de experiencia laboral te arma esto, era una locura. No sabía en ese momento que eso era realmente único: nadie se arriesgaba a hacer un producto propio, juntar la plata, hacer ventas, infraestructura, frontend, todo.

En Scribd, cuando entré, fui uno de los entrevistadores más frecuentes. Siempre me daban el currículum impreso. En cuatro años jamás vi un currículum con un pitch así, era así de raro.

Cuando Scribd vio mi currículum, me dieron la entrevista y me invitaron a la on-site en San Francisco, donde tuve una behavioral con Jared Friedman (CTO y fundador). Le hice una presentación de PPT de Kaya.gs, con métricas de uso, revenue, testing, frameworks, herramientas.

La experiencia de haber hecho algo propio de principio a fin es irreemplazable. Me acuerdo que durante la entrevista de Scribd, en la on-site, tenía una técnica de live coding y por ahí tenía un recreo de 30 minutos: volvía a Kaya.gs a ver si estaba bien el servidor, corregir algo, hacer bug fixing.

Al final del día de la entrevista, me hicieron una oferta de USD 100.000 anuales y que me iba a mudar a San Francisco. Ese mismo día lo acepté. Muy poco tiempo después haría el anuncio público: se cierra Kaya.gs.


Espero que les haya gustado. Si les gustó el podcast, denle follow para saber de los nuevos episodios y síganme en Twitter en @Conanbatt.