As part of my marketing strategy, every week I make a point to go and participate in communities related to Command.
I answer questions, provide feedback, and try to be helpful however I can.
Earlier this week during one of my morning check-ins, I saw an interesting question about "Why would you NOT use Firebase?" Unexpectedly, my response became the top post in the thread.
This got me thinking about how this seems to be a recurring stress-point for developer-entrepreneur types. I shared in that same struggle early on in my work and I thought it'd be a good idea to outline how I've grown to think about the role of technology in a product.
In this post, I'm going to share a few of the mental models I keep in mind when making choices about technology in a product.
Be extra-cautious with vendors
As part of my teaching work at my other business, Clever Beagle, I routinely come across developers who have been burned by vendor lock-in.
If you're not familiar with the phrase, vendor lock-in describes being in a situation where you're so dependent on a third-party's technology that you can't function without it.
In other word's: you're stuck in quicksand.
Everything that vendor does, you have to do. Every mandatory API change they make, you have to follow suit. Every price change they make, you have to fork over the cash. If they decide to close up shop? Sorry dude! At least we had a great journey!
The problem with this is that your product's underlying technology inadvertently steers your product's roadmap (and distracts you and your team from moving forward). And sometimes it can steer it right off a cliff.
This is why I avoid basing my core technology on third-party tools. They may be convenient, but they can also be deadly. One of my core maxims never trade control for convenience.
Ideally, the things you want to look for when choosing technology for your product:
Control of data. Your data is essentially your product. Without control of that, you don't have control of anything. If you can't export it easily or map it to another database technology: put down that cookie and panic.
Flexibility and portability. How similar is the code you're writing to other APIs and technologies? How easily can you move it around (e.g., changing hosting services to save costs)? Is it just a framework built on top of another technology, or a proprietary system with no escape hatches?
Learning opportunities. One of the least talked about downsides of betting your stack on a third-party is that it limits your worldview and skillset. Because you're missing out on the challenge convenience displaces, you fail to cultivate valuable problem solving skills.
While taking the DIY approach can be more time-consuming, if your goal is to build a product long-term (beyond a prototype or MVP), you'd be foolish not to make that investment.
Trust the battle-hardened tech
One of the more interesting aspects of software development—and arguably, life—is that nothing lasts forever.
No matter how much time you invest, no matter how good something is, eventually it will decay and wither.
That said, there's an important thing to understand here: the longer a technology has been around, the more likely it is to stay around. More things are built with it, more time is invested in its iteration, and less uncertainty surrounds its best practices and purpose.
There's a theory for this known as The Lindy effect:
The Lindy effect is a theory that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining life expectancy.
This is why I always chuckle at the "X is dead!" type of statements coming from inexperienced developers. A technology may not be as popular or revered as it once was, but as long as it still works as intended when it was first created, it's not dead—at best it's just out of favor.
When you're building a product, you want to select technology for functionality, not fashion.
The more fashionable the tools you rely on, the more you should be cautious as these are the tools most likely to change or go away. What you want is staying power so that your focus remains on your product as much as possible.
PHP or Ruby on Rails might not be "cool" to some people now, but hell if they don't work. And it's worth saying, too: all technology can scale if you know what you're doing—avoid the "but X doesn't scale!" trap at all costs.
Delivering value has nothing to do with technology
This is the key to this entire issue.
Early on in my career, I wasted significant amounts of time and energy chasing technology. Worrying about what others were using, whether or not something was going to stick around, constantly jumping ship between technologies.
A harsh truth is that there is no perfect technology that's going to make your product better.
That's up to you.
Very rarely if ever does a product's value have anything to do with the technology its created with. Rather, it's about the product itself and what it can help others to do that they couldn't do before.
Here's The Godfather laying it out:
As long as their problem is being solved, no customer will ever ask "but wait, did they build this with _____?"
The only caveat to this is how well a technology enables your ability to move quickly. And more often than not, this isn't really a feature of the technology as much as it is your level of experience with it.
More than anything, when choosing technology focus on enabling value creation. Don't get stuck in the tech echo chamber and distract yourself from doing the work.
A world of trade-offs
When you work with technology, you're working in an environment that is all about trade-offs.
There is no perfect technology.
No matter how hard you look, no matter how hard you try, you will struggle to find the thing that's going to magically solve every technical problem your product has perfectly.
This is where your own skillset comes in. This is where your own experience comes in. If you intend to build products long-term, you have to learn to deal with this reality.
The only way I've found to make constructive use of this truth is to just pick a technology and stick with it. Don't panic when it falls out of favor, but instead, really learn it. Understand how it works and why it works that way. Know what it gets right as well as what it gets wrong (and how to right those wrongs yourself).
With that knowledge and experience you start to understand that most of the drama around technology is unfounded.
That the thing most likely to mess up your product isn't technology: it's you.