The notion that a non-technical entrepreneur can start an internet-based company without writing any code is no longer in its infancy. Back in 2015, when I started WithoutCode with my colleague Tara Reed, it still was, though.
At that time, there were already a bunch of apps integrated into "codeless ecosystems"--apps such as Gmail and Twitter, and ecosystems such as Zapier. But it seemed as though few non-technical founders knew about them, and that even fewer founders were actually building businesses around them.
Tara might have been the only non-technical founder I knew who had actually raised venture capital with an app built exclusively without writing any code. I had long been working on a legal service to help people get out of contracts quickly and efficiently, but I had only recently discovered the magic of trading the expense and risk of programmers for the speed and control of no-code.
In fact, that's basically why we decided to start WithoutCode: we knew that if other non-technical entrepreneurs knew what we knew, the game would change for everybody--not just non-technical founders, but also any user/customer of something a "codeless founder" might build.
Having grown up in the church, I'm reminded of a "Sunday school" song we used to sing, in exclusively high pitches, about not being able to contain your excitement when you know something that other people should know. That was me. So we launched WithoutCode and became, I think, the first dedicated place on the internet you could go to learn exactly how to build companies without having write any code.
"Software is hard."
No doubt, he was talking to an audience of computer programmers about computer programming. He was not talking about the practical challenges non-technical entrepreneurs used to face when they wanted to build an app company. Yet the quote resonated with me.
For me, it was more like:
- Yes, software is hard.
- But it's because non-technical entrepreneurs who wanted to build web-based company had two options, both dubious.
- Option 1 - Convince someone who could write code to leave behind his/her comfortable, high-paying programming job to write the code for your puny startup.
- Option 2 - Convince some investor to give you enough money that you could go out and compete with larger, well-resourced companies in attracting computer programmers to work for your company on a salary.
Both of those options proved dead-ends for me, just as they have also proven for literally thousands and thousands of non-technical entrepreneurs who had a "great idea for an app."
There was also this other thing I noticed. The saying that, "when all you have is a hammer, everything looks like a nail," isn't just about what happens when you only have one tool. It's also about the sunk-cost effect of having accomplished either option 1 or 2 (in bullet points above) and then organizing all of your efforts around "maximizing" that windfall resource. In other words, when you finally convince a programmer to join your startup, it's hard to justify assenting to any execution plan that does not ask your technical co-founder to be constantly writing code. Similarly, once you've raised venture capital--which you most likely did by promising to VCs to do specific things with that money--it's hard to not feel compelled to put that rare resource to work producing some leverage-able asset. In the latter case, you might see technical founders go on a hiring spree to bring on salespeople, but in the case of the non-technical founder, you feel compelled to finally get the product built.
One obvious hazard of suddenly becoming obsessed with pumping out a product is that you could quietly lose sight of all of the gritty, nuts-and-bolts things that got you to that point:
- You start talking to customers less so that you can attend product meetings more.
- You delude yourself into thinking that the market will immediately embrace whatever the early version of your new product is.
- So you neglect market-testing during this period and fail to design a transition plan to go from pre-product to product with your existing customers.
For example, nowadays, you can commonly find articles that purport to show you exactly how to build certain kinds of apps--sometimes without writing code and sometimes with code. When you land on those articles as a non-technical founder, it's easy to feel like you've just struck oil, because, if it's a no-code build plan, then you think you might be able to do it on your own; and if it's a coded build plan, then you're happy that it takes a lot of the mystery out of what exactly you need to find a programmer to build. But then you start reading some of them, and your non-technical skills come in real handy. Exhibit A...
"Between Uber, Instacart, Postmates and the like, we can have anything we want delivered to our doorsteps. This, consequently, puts high demand on food delivery apps and means top-notch potential for profitability."
I pulled the above quote from from a MindStudios article called "How to Create an App Like Postmates for a Food Delivery Business." It's thorough article that includes a breakdown of some of the technical components of a coded app. If you were a non-technical founder trawling the internet, obsessed with figuring out how to quickly productize your idea, then you may overlook an obvious flaw with the article.
Look again at the quote above. If you happen to know anything about the food delivery space right now, then you know it is ruthlessly competitive. Hundreds of millions of dollars of investment and valuations have been lost due to it. Knowing this, you should first question the author's conclusion that it is a profitable space. It's not--at least, not right now. It could be in the future, once all of the challengers die out, and only a few winners remain. But that winner is probably not going to be you, or anyone else who might read this article and then, only now, go enter the space. Second, the conclusion does not necessarily follow from the premise: high demand does not by itself result in high profit potential. You don't need to be technical to understand how business works.
This was just one example of what I mean when I say that non-technical founders should continue to find ways to play to their strengths, and if you're the one starting the company, then you have the perfect opportunity to design it this way.
Yes, I get it. I know what it's like to hustle for years to try to wrangle the resources you need to finally "productize" your idea. But those non-product things that got you here--therein lies your ability to be resilient.
Never allow anyone--yourself, your technical co-founders, or your investors--to write that our of your business plan. That's your superpower--because when you're a non-technical entrepreneur running a tech company, the code that you can count on the most is no code.