Our Take On Code vs. No-Code And Fears of Vendor Lock-in

Recently the “no-code” movement has taken off, as a growing number of software products have made it easier than ever before to build and launch businesses without knowing how to write code. In my opinion this is without question a good thing, but the code vs. no-code debate has taken on a life of its own.

Can you really build a serious digital business without writing code? Do no-code tools make developers less valuable? Is no-code only a solution for building a minimum viable product that will need to be rebuilt later? Is this whole thing just a fad?

I was recently privy to a wonderful conversation on the topic at an Indie Hackers of San Diego meetup, as Corey Gwin, Brandon Bayer, and Chris Spagnuolo (all developers) discussed the topic (shout out to Chris who is building no-code tools for Webflow at Jetboost.io).

Throughout this conversation and dozens of similar ones that I’ve witnessed online, I’ve remained mostly silent, happy just to listen in to developers’ perspectives. But my silence also boils down to the fact that Outseta very much sits at the center of the no-code discussion, and to be perfectly frank I haven’t really been sure how we should classify our product. I want to address that with this post as well as share some other key learnings that I think have been missing from this conversation altogether.

Three truths about no-code

Part of the impetus for this post was a recent Twitter update by Ben Tossell—the subsequent string of comments is worth a read.

Let me start by saying that I’m no expert on no-code tools—Ben is—but I do have experience with each of these tools and I agree that this is a super solid and common no-code tech stack. Ben’s tweet didn’t surprise me, but it did get me thinking again on this topic. At this point what would I say is undeniably true about no-code? I came up with three items:

1. Ben’s Makerpad is the educational hub of all things no-code
2. Zapier is the glue that holds most no-code stacks together
3. No-code is a good thing that should be celebrated. How can making entrepreneurship more accessible to people that don’t write code be seen as a bad thing?

Most of the conversation you’ll find following in the wake of Ben’s tweet is people bickering about the merits of particular no-code vendors. That’s not the point of this post, and the truth is there are tons of good no-code products out there—the challenge is finding the ones that work best for your specific context. But I do think there are some larger points in this conversation that have been swept under the rug, so let’s address them next.

Zapier is great, but comes with it’s own vulnerabilities

Zapier is awesome—as a non-technical marketer I’ve used it for the past 10 years. Outseta offers a Zapier integration too, so it’s not like I’m here to bad mouth Zapier. But something nobody seems to be discussing as part of this conversation is that Zapier, just like code, comes with its own points of vulnerability. 

“Zaps” break all the time, creating inefficiencies and periods of data drop out. I can’t tell you how much time I’ve spent identifying issues that were the result of broken zaps, waiting on those zaps to get fixed, and then updating data that was lost when the zap broke. It takes a significant amount of time to fix these issues, just as a developer might spend a significant amount of time integrating two tools or fixing broken code.

“Zapier is accessible to me in a way that code is not, which is great, but the more tools you’re zapping together the more points of failure you’ve introduced.”    

Zapier is accessible to me in a way that code is not, which is great, but the more tools you’re zapping together the more points of failure you’ve introduced. That’s something that you should be wary of—developers are quick to cite that one of the primary benefits of no-code is that it has fewer points of vulnerability than writing code, but it’s certainly not without its own set of vulnerabilities that scale up as you zap more tools together.

When in doubt, the correct answer is “low-code”

All of which leads me to the following conclusion—the whole code vs. no-code debate is really pretty silly and unnecessarily polarizing. Whatever it is that you’re building, I think it’s pretty safe to say that in the vast majority of cases the “correct” approach should be aiming to build products that are as “low code” as possible. 

If you can build a product or workflow with comparable functionality without code, great! You should probably do it as it will be likely be faster to execute on and less brittle. But there’s almost always functionality that simply can’t be built without code, or that will be significantly improved if built with code, so in those instances you should absolutely do some programming. Whatever you’re building, if you focus on speed and reducing vulnerabilities you’ll inevitably end up with a low-code product that’s really effective.

Where Outseta fits on the no-code spectrum

Circling back on Outseta and our context specifically, I spent much of 2019 wrestling with where Outseta fits in the no-code conversation. There are two realities that I keep coming back to as I consider this:

1. In almost every way, Outseta is just about the most no-code tool there is—it literally could be the posterboy for the no-code movement. We offer a billing system, a CRM, email, chat, and help desk tools that all work together out-of-the-box. Not a lick of code, not a single zap required. What’s more “no-code” than that?
2. We’re a mission critical piece of software for our customers and offer prebuilt sign-up and login (authentication) tools so our customers don’t have to build this functionality on their own. When a user authenticates and logs into a SaaS product, our authentication tools pass a JWT token that tells the product who the user is and what subscription option they’re on—so if a user signed up for the “Pro” plan they’ll see the “Pro” version of the product. If you want to use our authentication tools, this is the one aspect of Outseta that requires writing some code.

Going back to my first point, the marketer in me sees the growth of the no-code movement and would love to position Outseta as a no-code tool—which I maintain it is as much as any. On the flip side, there is that one integration point I mentioned that does sometimes require our customers to write a bit of code—so we can’t say every feature of our product is 100% no-code.

What we’ve learned marketing and selling to non-technical vs. technical founders

Over the course of 2019 we experimented with marketing and selling Outseta to both technical and no-code founders. What we found was that both the value proposition of our product and our customer interactions vary greatly depending on who we’re targeting. 

When we target technical founders, many of them want to build everything themselves and plan to integrate a handful of software products simply because they can. But developers are also without question our best customers—many of them immediately “get it” when they are introduced to Outseta and see it as a way for them to get their products to market much more quickly. They want to focus on building their core product, not all of the other stuff required to support their business. These developers excel and often implement Outseta without any hand holding.

This contrasts pretty directly with the experiences we’ve had selling to no-code founders, most of whom immediately love the idea of Outseta. “This is exactly what I’ve been looking for! Why would I buy 5-10 tools when I can use Outseta to manage all aspects of my business?” is a common sentiment. 

While that’s the case, what we’ve found is no-code founders in most cases simply aren’t familiar with running a SaaS business. They usually have domain expertise in a particular industry rather than a background in SaaS. The challenge here is not that these founders can’t write code, it’s much more so that they simply don’t know what’s involved or required to run a SaaS business—particularly from a technology perspective. As a result, these founders require more education and support throughout the onboarding process.

Neither of the above is the “right” or “wrong” audience for us to target, they just come with a different set of challenges.

All-in-one tech stacks and concerns about vendor lock-in

Now that we’ve discussed where Outseta fits in this discussion, I want to return to Ben’s tweet. He calls Webflow, Zapier, Airtable, and Memberstack the dominant no-code stack, before adding “there’s all-in-one tools too.”

This tweet ultimately caught my attention for two reasons:

• Outseta is an “all-in-one” tool
• We’re increasingly being asked to migrate customers off of the no-code stack that Ben mentions

As we’ve dug in and started handling these migrations, the reasons for the move have been quite consistent. First, while this stack is flexible it still requires logging into a series of different tools to manage your business, which is inefficient and often a bit chaotic. Zaps between these tools breaking down has also been a common point of frustration.

Outseta is also purpose built for SaaS and comes with a series of other tools and functionality that all SaaS businesses require, so the decision to migrate to Outseta has largely come down to the product offers more robust functionality at a lower price with fewer points of vulnerability. That’s the upside that’s been driving new customers our way so far.

The number one concern that we hear from customers who are considering moving away from their no-code tech stack and towards an all-in-one solution like Outseta is that they’re worried about vendor lock-in. This is a very valid concern—it’s the idea that a business shouldn’t be overly reliant on a single piece of software. If Outseta went out of business or had major performance issues, that would be a show stopper for our customers (and our own business too). Frankly, I would have the same concern.

There are some ways that we address this with our customers that are specific to us—our team has built mission critical business software before (at Buildium, which 17,000+ businesses are completely reliant on) and we take this responsibility very seriously. We’ve also written before about how we’ve intentionally designed all aspects of our business (particularly the financial ones) so that we’re insulated from the common killers of SaaS start-ups and don’t need to worry about our runway. 

But these points aside, the concerns about vendor lock-in are again a bit one-sided—in some ways an all-in-one product is actually a more fail-safe solution than assembling a tech stack of a series of point solutions.

First, as I’ve already pointed out more tools introduce more points of vulnerability. If you’re using 5-10 different tools, whether they’re code or no-code tools, chances are several of them are somewhat mission critical to your business. If your authentication solution breaks down, users won’t be able to login to your product. If your CRM provider goes off-line, your sales team will grind to a halt. As for your billing system, any issues here directly impact customers and your ability to make money. As you stitch all of these tools together you’ve got just as many—and in reality likely more points of vulnerability that could impact your business.

Second, if you decide you want to migrate off of your current tech stack when you’re using a a bunch of different software tools the process quickly becomes something of a nightmare. You’ve got billing data in Stripe, customer records in your CRM, email templates and automations in your marketing software, past customer service interactions in your help desk, and knowledge base content that needs to be migrated elsewhere. Just to name a few.

I can tell you from first hand experience that even migrating customers from the no-code tech stack that Ben mentioned isn’t easy! There’s just a lot of moving parts when your data is strewn between a handful of different software tools. 

On the flip side, with an all-in-one solution like Outseta all of your customer data—CRM records, billing history, help desk interactions, etc—all lives in a single database. You can easily export a truly complete data record as opposed to needing to hop between tools that all store different data in different formats. Said more directly, if you want to migrate off of Outseta it’s far, far easier than it would be to migrate off of a handful of point solutions. 

Not only is data migration easier, but there’s actually less vendor lock-in and fewer points of vulnerability that could be truly disruptive to your business with an all-in-one solution than there is with a tech stack of point solutions cobbled together. The idea that having your business data split between different software tools somehow diversifies your risk profile is a bit misguided—the same functionality is mission critical to your business whether you’re working with one vendor or twenty.

“Not only is data migration easier, but there’s actually less vendor lock-in and fewer points of vulnerability that could be truly disruptive to your business with an all-in-one solution than there is with a tech stack of point solutions cobbled together.”    

Final Thoughts   

My point in all this is not to sell you on Outseta, although I did want to address how we fit in this conversation and point out some key points that I think have been missing from the code vs. no-code conversation. All things considered, no-code tools are offering a wider range of possibilities when it comes to how you build your start-up and that’s a good thing. 

As you make your technology decisions, you’ll be best served to aim for “low-code” solutions whenever possible—and make sure you’re doing an honest assessment of the potential vulnerabilities all options present that could impact your business.