
Oficialmente, en 2004, cuando trabajaba en una agencia y tuve la idea original de Webflow: se trataba de eliminar la necesidad de un codificador en medio de un diseñador y el cliente.
Estaba trabajando con una agencia que tenía clientes muy grandes como Apple, HP, Quicksilver, etc. Y un día, vi la factura de uno de esos clientes, ¡y era tan astronómica! Y pensé, está bien, aquí hay una oportunidad en la que podemos eliminar la barrera entre lo que los diseñadores quieren y lo que realmente termina publicándose en el sitio web.
Sabes, durante mucho tiempo, cuando empezamos Zapier, sin código no era una cosa. ¿No? Ningún código ha sido realmente una cosa que como "término" ha existido desde, ¿qué, 2018? 2017? Tal vez es bastante nuevo y por lo que, ya sabes, empezamos Zapier en 2011. Y en ese momento, tratamos de resolver lo que parecía un problema algo simple, pero bastante generalizado, que es que hay todas estas nuevas aplicaciones que están apareciendo a diestra y siniestra, y todos los clientes, todos los usuarios finales de estas herramientas, quieren que funcionen con todo lo demás que utilizan.
Ahora, casi una década más tarde, nuestro trabajo en ese momento era como, bueno, tal vez si lo hiciéramos un poco más fácil para el usuario final ser capaz de configurar una integración entre las herramientas que podrían ser útiles. Y resultó que con el tiempo, es más que útil porque todos estos proveedores finales, ya sabes, el MailChimp, el Salesforce, el G Suite del mundo, es muy difícil para ellos construir un gran ecosistema de integraciones, es sólo una cosa difícil de hacer. Incluso si usted es un negocio muy exitoso.
Con el tiempo nos dimos cuenta de que Zapier tenía un valor mucho mayor. No solo ayudaba con estas pequeñas integraciones puntuales, sino que actuaba como una herramienta de flujo de trabajo que ayudaba a la gente a conectar estas herramientas, pero de una forma que se parecía más a la creación de flujos de trabajo. Se sentía más como la lógica. Se sentía más como la codificación, en cierto sentido. De alguna manera, a pesar de que la mayoría de las personas que utilizan Zapier no saben cómo codificar, muchos de ellos ni siquiera saben lo que son las API y por lo que sólo la capacidad de ayudar a las personas a conectar los bloques de construcción de la web juntos de una manera que crea una cosa ha sido algo que creo que cuando no hay código se convirtió en un término y una cosa, era como, bueno, Zapier es la cosa que proporciona toda la lógica para todas estas herramientas.
Empecé a crear sin código probablemente en 2014. Tenía una idea para una aplicación que ayudaría a la gente a encontrar obras de arte asequibles para sus hogares. Y esto fue realmente antes de que existieran muchas de las herramientas sin código que hay hoy en día. Así que mi primera experiencia creando código fue utilizar herramientas que no estaban pensadas para crear aplicaciones y, en cierto modo, hackearlas para crear una experiencia similar a la de una aplicación.
Así que, cada vez que alguien se registraba en la aplicación, nos decía qué tipo de arte le gustaba, por ejemplo, la fotografía o la pintura. Y luego le preguntábamos por sus gustos. Pero utilizábamos el software de encuestas para mostrar y ocultar diferentes cosas en función de su respuesta anterior. Esa fue mi primera experiencia sin código: realizar una encuesta y hackearla para crear una experiencia similar a la de una aplicación para mis clientes, y utilizarla de forma dinámica para mostrarles recomendaciones artísticas. La gente me respondía por correo electrónico y me decía: «¡Vaya, tu aplicación es genial!». Ganamos nuestros primeros 35 000 dólares con esa encuesta modificada.
Creo que hace unos seis o siete años, justo antes de unirme a Product Hunt, estaba intentando crear cosas y buscando formas de hacerlo sin tener que aprender a programar. Y lo hacía un poco con herramientas sin código. Lo que no me daba cuenta era que lo que realmente le interesaba a la gente no eran mis ideas, porque todas eran malas. En realidad, lo que les interesaba era la capacidad de crearlas muy rápidamente y hacer que parecieran software. Y todo se creaba sin código. Todo el mundo me preguntaba cómo creaba esas cosas sin código. Así que pensé: «Vale, os enseñaré cómo se hace».
Creo que siempre he trabajado sin código. Cuando empecé como ingeniero, una de las cosas que siempre me propuse fue crear software y productos que no obligaran a los operadores comerciales a estar llamándome todo el día para pedirme cambios. Por eso, como ingeniero, el «no-code» siempre me ha llamado la atención desde el punto de vista de la arquitectura y desde la perspectiva del diseño y el producto. De esta manera, la tecnología puede ser más un facilitador. Así que creo que, fundamentalmente, lo he tenido desde que empecé en el comercio electrónico como ingeniero, allá por 2009.
Me introduje en el no-código antes de que fuera tan popular como lo es hoy. Pero eso fue en 2017 y realmente vi el auge de las herramientas de diseño con Figma, Sketch e Invision, todas ellas muy populares. Pero en realidad no había nada que tomara lo que construías y lo tradujera en un producto real. Así que lo que quería hacer era básicamente tomar eso y construir un producto que te permitiera construir una aplicación móvil totalmente funcional, pero sin tener que saber cómo codificar.
Llevo un tiempo trabajando con alguna versión de no-code. He trabajado en muchos sectores diferentes y en todos ellos hemos utilizado alguna versión de herramientas no-code o low-code. Si echo la vista atrás, cuando empecé en el mundo de la tecnología, creaba sitios web con Dreamweaver o Visual Basic.
Empezamos a crear Draftbit después de intentar crear otro negocio: una aplicación móvil. Estábamos un poco frustrados, incluso con unos cofundadores estupendos, por lo difícil que resultaba sacar la primera versión de nuestra aplicación móvil. Nos dimos cuenta de que lo que realmente nos apasionaba era facilitar, tanto a nosotros como a cualquier otra persona, el lanzamiento de la primera versión y su iteración.
Creo que me inicié en el no-code antes de saber realmente qué era, simplemente jugando con herramientas no-code hace unos cinco o seis años. Mi introducción fue Zapier, el santo grial de las integraciones. Siempre he estado en esa intersección entre lo técnico y lo no técnico, y siempre he considerado el no-code como una hermosa mezcla de ambas cosas.
El «no-code» es realmente parte del conjunto de tecnologías que utilizo a diario y que enseño incluso a mi propio equipo, así que pensé: ¿por qué no unirme a una empresa como Voiceflow, que va a tener un gran impacto en el ámbito de la voz y el «no-code»?
En cuanto a empezar sin código, en lo que respecta al diseño, en su día Dreamweaver fue mi primera experiencia sin código.
Supongo que mi entusiasmo por el ámbito del «no-code» se ha reavivado recientemente, obviamente, con la creación de 8020. Tuve la oportunidad de unirme oficialmente y, en cierto modo, dirigir el barco. Obviamente, volver a satisfacer esa necesidad desde el punto de vista del diseño ha sido genial, pero también lo es, en un sentido más amplio, empezar a ayudar, junto con todos los demás, a descubrir lo que esto significa, que es lo más emocionante.
[Ben] Tengo experiencia en la creación con código y comencé simplemente creando mis propios sitios, HTML, CSS, y luego realmente me metí en WordPress y desarrollé temas personalizados de WordPress. Y luego comencé a trabajar en un proyecto en el que tenía recursos limitados y estaba tratando de construir muchos sitios y es como, "Tiene que haber una mejor manera de hacer esto. Esto es tan, tan difícil" Y entonces encontré Webflow, y pensé: "¡Oh, cariño, vamos a intentarlo!"
[Mat] En términos de Visual Dev FM, originalmente se formó en torno a la idea de que Ben y yo tomáramos café todos los viernes solo para hablar sin código y fuera nerd, y simplemente comenzamos diciendo que deberíamos, el pensamiento más básico de todos, deberíamos comenzar un podcast sobre esto. Y así lo hicimos, y luego conocimos a Lacey y el podcast mejoró mucho.
