Low-tech solutions make it easy to go fast and break stuff, and that’s a problem
If you’re going to use low-tech solutions within your business, in any capacity, whether it’s building an app from scratch on a no-code platform or integrating a pre-built credit card form into your order flow, there’s one golden rule you need to stick to:
Just because you can do something doesn’t mean you will do it right.
Tech can be tough to do right–ask any developer. And starting and scaling a company means operating at breakneck speed. So whether you’re building your own software or just using a small amount of off-the-shelf tech to gain a competitive edge, implementing that technology properly can slow you down.
But poorly or hastily implemented tech can leave you in the worst position imaginable.
I re-learned that lesson the hard way last month when a single hacker almost took my entire business down. And I couldn’t stop it.
Low-Tech Is a Startup Enabler
Why does it happen? Why do entrepreneurs, even experienced technical entrepreneurs, get the tech wrong?
The short answer is that it’s so easy to make the trade-off to get to market quickly.
As I said, getting the tech right takes time that a scaling startup doesn’t always have. Furthermore, getting the tech right also costs a ton of money, because developers — the good ones anyway — aren’t cheap.
This is why I love no-code and low-code solutions. They’ve evolved to a point that I can dream up whatever I want and implement it, even go to market with it, in a matter of days for a matter of a few dollars.
However, even when you solve the time and cost problems, technology always seems to lead down paths that wind up with your building too much functionality too quickly. When you’re living by the mantra of “crawl-walk-run,” there’s always the temptation with technology to try to walk before you’re ready. Then you fall on your face.
This is natural. It’s par for the course. It’s go-fast-and-break-stuff. That’s fine. But sometimes it leads you to bring a stripped-down version of a feature to market and tell yourself you’ll come back to it later.
Being a former developer, I’m very familiar with the golden rule of tech: Do it quick, but do it right. But being a long-time entrepreneur, I go fast, break stuff, and almost always come back to fix it later.
There’s just one critical area where low-tech can destroy your business if you don’t do it right or you wait too long to come back and fix it. It’s usually not a flaw in the tool; it’s almost always a flaw in the implementation. And it can sneak up on you and strike quickly and irreversibly.
It’s security.
Your eyes just glazed over, right?
Good Developers Obsess Over Security
Good entrepreneurs do not. Most of them want to do it right, but they don’t want to obsess over it.
This is the primary reason why startup tech gets done wrong outside of straight incompetence. And it almost always rears its head at a point where the company allows the customer to enter data into the system — something you have to do if you’re going to implement most tech.
I’m not going to get into too much detail about how I screwed up. For one thing, I don’t want to make my weaknesses public and invite more threats, and for another, to truly get into it I either have to write 10,000 words or more posts, and I’m choosing the latter. And anyway, it’s kind of immaterial. The thing that happened to me is likely not the thing that’s going to happen to you.
But you’re going to have to fix it as I fixed it, so I’ll start by telling you what I did right, even before it happened:
-
I obsessed over understanding how the low-tech tools I was using handled security, including but not limited to app access, data access, and privacy.
-
I followed all the rules to make sure I was correctly implementing the built-in security measures, which were quite robust.
-
I added a layer of my own security measures at every public input point, except one.
That last point is something I did in the name of removing friction. In other words, the more secure I made that specific entry point, the more clicks and steps I was adding, the more I was pushing away current and prospective customers.
If it became a problem in the future, I’d come back and fix it.
Then it became a problem. A big problem. And then I realized I couldn’t fix it.
If Your Tech Enabler Can’t Do It, You Can’t Do It
That’s the fallout. It wasn’t that I didn’t know how to fix it. It’s just that the tools I had implemented, and the way I had implemented them, didn’t have the means for me to fix the gaping hole in my architecture that would expose me to precarious financial liability.
For the record, this had nothing to do with the security of my current customers. They were fine, thanks to the things I did right. The liability was all on me and it was enough liability for me to have to either find a fix — now — or shut down the entire thing.
It seems so stupid a choice to have to make, but that’s what you’re left with when you rely on someone else’s tech to frame your business. Find your own fix, or shut the business down.
Surely, Google had a workaround for its thing I was using? Nope.
Surely, Bubble had a workaround for its thing I was using? Nope.
Surely, Stripe had a workaround for its thing I was using? Nope.
But the words I need to add to all of those statements is: Not the way I implemented it.
In my defense, what I was implementing was pretty straightforward, just done quickly and frictionless. This could and will happen to a bunch of other people, and I’ve notified the low-tech providers as to how it can happen.
The Moral of the Story: Don’t Get Creative With Security
This is not a super happy ending. It kinda is for me, at least in the short term. Although I’m not 100 percent in love with the fix I came up with, it does the trick for now. The problem is, while I didn’t have to write code to make the fix, I did have to rely on a lot of what I’d learned as a developer, including experience coding around the same issues in the past.
It also took me probably 80 hours over 30 days.
This is not an answer that non-developer customers of low-tech, no-code, off-the-shelf solutions want to hear.
So if you don’t want to face the fix, prevent the error.
I got myself onto the wrong track when I tried to extend the standard use cases of what those solutions did. This works fine in almost every area, and is in fact the very definition of how those solutions have evolved. The possibilities for what you can do with them are nearly infinite.
But that doesn’t mean you’ll do them right, even with experience and knowledge on your side. So stay well within the lines of the provided security and privacy features when you work with low-tech tools. Take your time and protect your app, your data, and the access to it, at every point, and with all the added friction and costs.
Because if you’re at least a little successful, it’s not a matter of if you’ll be hacked, but when. If you’ve waited too long to come back and make your fixes, it might be too late.
