I’m building a startup with no code, and I’ve gotten pretty far. How do you know if a no-code solution is right for you? No-code is a pretty broad term for point-and-click solutions that let someone with no coding background do things that require code to do.
This is the shark-jumping moment for no-code — when we figure out whether the movement goes the way of Bitcoin (trend) or mobile apps (here to stay) — because the no-code use case has evolved from integrating software functions to allowing the creation of entire software applications.
However, in this post, I don’t want to restrict discussing no-code to just building and deploying apps. I want to talk about creating an entire company and product without writing much, or even any, code.
Three basic types and three general use-case families for no-code
There are three broad types of no-code solutions and three basic ways any of those solutions can be used. You can mix and match, and sure, there are outlier types and use cases, but these are the most general.
Let’s start with solution types first.
Tier 1: Widget builder: These are simple services that offer cloud-based functionality snippets. For example, if you need a form for data entry, you can use any number of services to create a simple widget that collects and hosts the data in the cloud.
Tier 2: Webhook builder: This is what Zapier does. It’s a user interface that accesses webhooks in applications to let one application talk to another. It’s like an API, but simpler. A lot of software products even offer built-in access to their own webhooks. For example, Stripe has a webhook you can configure in your Stripe account that will post a message to your Slack account when someone completes a transaction. No code required.
Tier 3: Application builder: Exactly what it sounds like, you can drag and drop your way to a complete web or mobile app. Again, not a new concept by any means, but today’s no-code solutions require a lot less low-level knowledge to be able to provide a lot more functionality.
Now, let’s talk about use cases.
Use Case 1: Building your company with no-code
I started building Teaching Startup nine months ago. A month into it, I decided to build it without writing any code. And again, I can code, but I have a million other things to do.
And that right there is the justification for building a company with no-code.
There are functions all across a company that can either be done manually, which is a huge time-suck as you grow, or they can be automated, which requires a huge investment to get started.
These functions exist at every point in the company from the tangential to the critical. For example, part of my product is a paid email, so I needed a bulk emailer with all sorts of customization options, and I needed credit card processing.
When I founded ExitEvent back in 2010, I needed almost the exact same thing. So I built it, and it took weeks, and it broke a lot. Plus, every time I needed a small change, I needed to build that and test it, which took time away from everything else I was doing.
On the other end of the spectrum, I could have used a third-party combined service to handle both of those functions for me, but those services were expensive and also limited. What’s more is the cost to integrate those services into the framework of my product was another upfront expense and another ongoing expense.
Instead, I chose a full-service email provider and a full-service credit card processor, and I used Zapier and several widgets to bind them together and integrate them into my product framework. This allowed me to do exactly what I needed to do for my use case, which the combined service provider could not, and was also 60% less expensive than the full-service provider.
The email provider does email very well. The credit card processor does credit cards very well. Zapier makes sure they talk to each other. They all do their thing better than the “full” service provider and are more robust than anything I could code in a couple weeks.
Now, there are indeed limitations, but here’s the thing. Those limitations are forcing me to stop thinking about all the options and pricing and packaging I want to do and just prove that the customer will pay for the product.
Use Case 2: No code and MVP
The reason it took me a month to decide to build a company without any code is because I originally intended to just build my Minimum Viable Product without any code. Once the MVP was finished, I realized that if I replaced the no-code solutions, I’d be replacing wheels that didn’t need replacing.
Yet.
No-code solutions are a perfect way to build infrastructure around an MVP to go out and determine product viability. If you don’t have to think about the viability of the integration of your core product with the components around that product, including other product functionality that might not be core, you can spend more time building a better core product.
I’ve said this a million times: The goal of an MVP is to test the viability of the core functionality of the product. The problem is that to get to that test, the machine that markets, sells, fulfills, and maintains that product has to work. If any of the components in that machine fail, you get noise in your test.
Furthermore, that machine is always expensive to build, so why waste thousands of dollars building the perfect infrastructure around a product with untested viability in the market?
Use Case 3: No code and product
The next steps for me will be to build all the extra functionality I want to build into something more than an email, which is already starting to bend under the weight of the functionality I’ve already thrown on top of it.
Again, I could code all this. I kind of want to. But then I kind of don’t. Because I need to spend my time creating more value for the customer.
And that right there is the justification for building a product with no-code.
There is a ton functionality on my product roadmap that I can’t wait to get to. I just don’t know if my customers want that functionality.
Yet.
I have an idea of what I think they want. So what if I could just try it out and prove the viability of that functionality like I proved the viability of my product?
Existing businesses have been using no-code solutions for years to offer custom functionality to their business users without adding technical debt. Today’s no-code application-builder solution lets us cut the middle-tier out of the equation, and offer the same kind of critical functionality directly to our customers, quickly, and without much expense or technical debt.
Yes, there will be limitations. Yes, that functionality will probably need to be replaced with a “real” solution at some point.
But those are the same caveats I went into my MVP with nine months ago. I saved myself a bunch of money and time just delaying replacing my no-code components, maybe indefinitely. I spent that money and time building a better core product.
Epilogue: No code vs product overload
I get this question a lot: Will the no-code trend produce an overload of crap products once anyone can build and deploy one?
Will there be crap products? Absolutely. Are there crap products out there today being built by lifelong coders and highly-touted IT departments? You bet. Will that turn into an overload?
Probably not.
There will be an increase in non-viable products on the market, sure. But we as consumers don’t buy the market, we buy the product. The benefits we will get in terms of allowing new creativity to solve old problems with different solutions, that will far outweigh the downside.
And that right there is the justification for no-code as more than just a trend.
This article was originally published on Medium by Joe Procopio
Joe Procopio is a multi-exit, multi-failure entrepreneur. He is currently the Chief Product Officer at Spiffy, on-demand vehicle care and maintenance startup. In 2015, he sold Automated Insights to Vista Equity Partners. In 2013, he sold ExitEvent to Capitol Broadcasting. Before that, he built Intrepid Media, the first social network for writers. You can read more and sign up for his newsletter at www.joeprocopio.com
