TL;DR Interview with Trevor
What’s interesting about it?
✅Why he chose no-code tools to start his next startup
✅No-code isn’t just about creating fancy web pages. See how using tools like Parabola allow you to add complexity around your core value prop. These aren’t info products.
✅How do you decide where to start when creating something?
I’ve started a few companies so this isn’t my first rodeo. But no matter how many times you go through the fundraising process, it’s always a grind. There are SO many things you have to juggle at the same time when starting up. The hardest aspect is trying to do all the CEO parts, while simultaneously being the ops guy running your company, dealing with customers, generating revenue, building the product, doing all the legal stuff, etc. No one part is that hard if you focus only on that one thing, but there are just so many things that demand your attention all at the same time.
My first company (years ago) was a web app for amateur athletes. You can think of it like “ESPN for high school sports.” I had played college football at Cornell, and among other use cases this app was geared toward helping make college recruiting more efficient.
My next company was a product in the HR tech market that allowed employers to evaluate job candidates without asking for a resume by instead having them complete a job tryout. As the term implies, a tryout is a demonstration of capability to do the job in question, and our software allowed companies to create these tryouts, deploy them, and manage the process.
In 2018 I had the idea for a service that would essentially make it easy for people who were moving from one place to the next to not move their stuff at all and instead rent great looking and well designed furnishings. I had moved a lot as a kid, so the hassle of moving is a problem I was familiar with. That company, Moovin, raised some early funding and was building a great product and service with repeat customer usage and great results when COVID hit.
Was there an itch to scratch or problem you recognized. How did you spot the problem and then decide to make something to help solve it.
My motivation for building Intro2 came from personal experience of how frustrating the fundraising process can be. Recently, I was running a company called Moovin, the relocation company for the 21st century. Moovin had a great startup story, impressive margins, and 6 figures of revenue, but despite all that I was struggling to find investors. I observed again and again how inefficient the startup fundraising process can be, and for no objectively good reason.
I was still working on getting funding for Moovin when COVID hit. Very quickly, the entire value proposition of living in a city, and along with it the narrative of renting high-end interior design to urbanites, was dashed—essentially Moovin’s entire startup thesis went away. Rather than lament what might have been, I decided now was the time to act. I sold off the furnishings inventory I had for Moovin and threw every ounce of energy into building this idea I had for Intro2. A steady supply of coffee and beer helped matters considerably 🙂
I had the idea that no matter how bad the ill-effects of COVID may be, there would always be startups and those startups would always be looking for a better way to connect with investors and vice-versa. After all, this was a problem I had acutely experienced and knew a lot about, and in a weird way I realized that because of those experiences I was in the perfect position to solve it. So I got to work.
Some years ago, I was one of the earliest adopters of NoCode tools, even before that term became en vogue. I had previously used tools like Webflow, Airtable and Zapier for many years, and while each is great in its own way, there are limitations to how far you can go with those tools. For this project, I realized I was going to have to go beyond building a website with some automation… I was going to have to build a full-on web app. And, I had never done that before. I played around with a number of other NoCode tools, and eventually I chose Bubble. What impressed me the most about Bubble is that it allows you to structurally build a web app in a very similar same way as you would if you coded it, but without needing to write any syntax where missing a single character can cause the app not to function properly or render in weird ways. More than any other NoCode tool, Bubble seems to have adopted the philosophy that you should be able to build without any limitations on what they can make vs the “coding it” way. Since it uses the same concepts of coding—from database design to workflows, etc—whatever you can imagine, you can build it in Bubble. I’m not a software engineer by training, but in today’s world, background and experience are far less important than raw desire to build something. If you’re hungry, committed and tenacious, you can teach yourself how to build anything.
What is your stack to create Intro2?
The stack simplified as I was building. I started out with more services and slowly brought some of them “in house” within Bubble.
I figured out the original matching algorithms and the data science parts of Intro2 using Airtable. My previous company Moovin’s original product used Airtable as the backbone of the entire tech product, and in the course of building it I developed a lot of expertise in using it. People who work at Airtable even commented that only a few people/companies they’ve seen had pushed their product as far. Moovin’s Airtable had 73 tables, and the largest of those had 363 fields of calculations!! Some tables had 20+ views, and I was using more than 15 folders of blocks. All of this was necessary to run the complexity of Moovin’s logistics business, but I had absolutely taken Airtable as far as it could go.
One of the best complements to Airtable is Zapier. Airtable is great for storing and manipulating data to do things like run complex calculations, and Zapier moves that data around to Airtable and back out to other destinations.
Since I had previously used Airtable and Zapier (along with Webflow) to build Moovin, I started with that stack in mind. But pretty quickly I realized I’d need something more powerful to build an actual web app, and that’s where Bubble came in. It seemed a lot harder from where I was coming from as a non-engineer, but I reasoned that I had taught myself these other tools so why not Bubble?
My first step in getting the data science to work was to automate the matching algorithm I had created. That model involved a many-to-many type of matching between startups and investors. How it works is you need to create a score for the relationship of each startup to each investor, and you have to update that score and add scoring of new relationships as each new startup and investor joins the platform, and when data and preferences change within a startup or investor record. While Zapier is great for working on a single thing at a time, it’s not suited to performing operations on lots of things at the same time. That’s exactly where Parabola shines. It’s great for manipulating data at scale. So if you want to perform a calculation on a 100 rows of data in your database and transform them all using the same process, Parabola is great for that, whereas if you want to perform a calculation for just one thing at a time, that’s where Zapier is better. With Intro2, there was this many-to-many relationship so Parabola was the clear winner.
I’m new to Mixpanel, but I’m really liking how easy it was to connect my Bubble app and send sign up and other user interactions over to Mixpanel to track. It was trivially easy to do—much easier than Google Analytics for example.
Stripe is really easy to use within Bubble (and overall). You just give Bubble your stripe API key and that’s it. Stripe has become so much a fabric of the web that it’s tough to remember what payments looked like prior to it. I’m old enough to remember when “getting payment set up” for your app meant figuring out how you build a system to take payment from users. Now it’s as easy as signing up for Stripe and providing your API key.
Think less. Build More. I suppose this is my way of saying that no amount of reading a book or watching a video will teach you as much as getting your hands dirty and building something yourself. It’s through the act of building that you learn. I can attest to having screwed up a great number of things many times while building. But each time I did, I’ve gotten better at the tools, and faster at using them.
Help is online. I benefited a lot from watching videos on youtube posted by people who had built something related to what I was doing in some way. I found these videos to be instrumental in piecing together what I needed to do to build Intro2 and it’s fair to say I could never have taught myself all of what I needed to learn without all the help I got online through many people I’ve never even met.
Don’t copy something else. Think of something new-ish. I see a lot of suggestions for people to get into becoming a maker by building something simple like a todo list app. While that may be good training, the point isn’t so much to build a new todo list app, but to apply the learnings from that experience to build something else that’s more unique.
I see too many people copy something else that’s already been done, throw on a new coat of paint on it, or a token new feature and think they’re ready to become a founder. This misses a hard reality about switching costs. In order for someone to switch from how they’re currently solving a problem to your solution, it needs to be a LOT better, otherwise the hassle factor and switching costs are too high. Now, if you’re passionate about todo lists and think you have a 10x improvement on how they should work then by all means go for it. But one of my biggest gripes is when people are getting started sometimes they copy existing stuff vs taking big swings at building something new. This is Peter Thiel’s Zero to One thesis. Going from 1 to X is easier because what you’re doing is known and you’re improving upon it. Going from 0 to 1 is harder because what you’re doing is more unknown. But it’s solving the problems with unknown solutions that can often be so transformative. In my observation, it’s the big swings (even when you have no idea how it might work at the beginning) that lead to real breakthroughs. The apps we use every day were big swings, and if you want yours to be a breakthrough, you should swing big too.
Honestly, I think the space is growing so much lately. As of a year ago, I hadn’t even heard the term NoCode despite actually having been “doing it” for many years. Today, there is a much better understanding of what NoCode is, how to use it to create unique solutions, etc.
I suppose what is still missing is more acceptance from the rest of the tech industry of the value of NoCoders, Makers or whatever term we end up being known by. It comes down to where do we fit within an organization… are we engineers? product managers? There really isn’t a clear definition of our capabilities.
As NoCode has gained in power and popularity, I think we’ve crossed a chasm where most companies should think to build their products and services using NoCode tools first and leverage custom code only where necessary. Fast forward 3 years and that approach will definitely be the “conventional wisdom”, but right now, the rest of the tech industry is behind the curve and still trying to figure out where NoCode and NoCoders fit within their organizations, both from a usage perspective and from a staffing and hiring perspective.
APIs. It’s ironic because the entire NoCode space leverages APIs as the foundational concept of moving data from service A to service B. This gets a bit into the weeds, but within Bubble, there is a concept called “API workflows” that can perform actions on your data within Bubble. I had gotten so used to the idea of using APIs to send data from one service to the next that it took me a while to wrap my head around the concept of using an API to perform
actions on my own data within one service. Most engineers are probably scoffing at the naivete of what I just said, but as a non-expert at this stuff, this wasn’t exactly obvious.
I’d love for Intro2 to help everyone get the funding they’re looking for to build their side project into a full time project. It’s an amazing feeling when you “get to” work on something you love doing vs “having to” work on something you’re not that into. In order to turn a side project into a full time project, many companies need funding to start, and solving that problem easily, efficiently, and at scale is why I built Intro2. It’s the tool I’ve been looking for as a founder, so I hope it’s helpful to other people to go from side-project to full time. We’re still in Private Beta, but I’d encourage everyone to sign up so you can get in as soon as we open it up to more companies.
I spent 1,000+ hours talking with 150+ No-code Founders, who have generated millions of dollars with their businesses without actually writing code.
How are they doing it?
I spent years researching and building on what they do. I wrote The Lean Side Project so you can build and launch your product.
I started Side Project Stack to help Makers reduce the time and effort to make stuff with no-code.I launched Get Stackd. A former #1 Product of the Day on Product Hunt. It helps Makers find the best no-code tools to use to make something. It's a 100% automated web app built with no-code.
What's interesting about it? Get Stackd take's the data from over dozens and dozens successfully made no-code projects to recommend the best starting point of tools to use to make your idea. I hope that you try it out. It's perfect for just starting out.Ill be adding more to the no-code space.
If you'd like to stay updated you can sign up for the newsletter and join over 3,000+ Makers getting the best insights on no-code and product management. Thanks for reading.
Once a week, valuable and actionable insights, no bs -- promised.