I once read an excellent quote which nails it and which read as follows: “It’s not the tools you use that have to be cutting-edge, it is the product you build.”
Published on Tue, January 27, 2015
One thing that sucks about large and established companies is that they often get stuck within their toolchain. If a product has a lifetime of 5-10 years, you usually don’t swap essential parts of your stack in the middle of that timeline just because of new trends on Hacker News.
In contrast, starting a new venture often seems a good starting point to play with new technologies.
Especially if your team members are developers by heart, using new libraries, frameworks, or even programming languages is in your nature. Using stuff you already know often feels dull, and you usually look for what’s coming next.
Combined with the big dreams of entrepreneurs and all the news on fast-growing companies and all these nice posts on how they managed to achieve their hyper-growth out there, this leads to a toxic cocktail.
Instead of focussing on your user’s needs and building a product that everybody wants, you’re wasting your time and burn money by exploring and introducing new technologies.
When I started to think about the core technologies of my latest product, I thought I knew we had to be able to scale fast. And that the database I had more than a decade of experience with wouldn’t do the job. So I never thought a second of using Microsoft SQL Server but immediately asked one of my team members to figure out which NoSQL database we could go with.
We started with RavenDB because it felt natural to go with a system that fits in our own ecosystem (we were building our product on top of ASP.NET MVC, ASP.NET Web API and Xamarin).
A few weeks later, a new team member joined us, highly recommending MongoDB – so we switched to MongoDB.
After running in some odd things which we couldn’t figure out (today I know we should have been just trying harder as the solution is now obvious to me), we switched back to RavenDB as it seemed to bring us all the features we were looking for.
But as we all know, there is no such thing as free lunch. I am not mentioning the expensive license I bought, but all the bugs and quirks of the product that drove us nuts. We invested weeks of work in figuring out how things should work and how they eventually worked, just to end in a dead-end road.
Eventually, I sat down for two weeks and rewrote our whole data layer and migrated the application to PostgreSQL. And if you now think “Holy Shit!”, the best is yet to come.
We never worked with PostgreSQL before. We did just chose it because it seemed mature (one thing that RavenDB clearly wasn’t), and it had no licensing costs attached. Our goal still was to be able to scale …
To be honest: Installing and running PostgreSQL was and is a pleasure. Compared to our journey before, the settling-in period was short. But we still needed to learn a lot of things we already knew from more than 10 years of experience with SQL Server – especially regarding security.
At the end of the day, the free version of Microsoft SQL Server would have been enough. Our product eventually didn’t meet the needs of our users and never became successful.
We learned a lot in the space of NoSQL databases, migrations, and with PostgreSQL, we could even add a new open-source RDBMS to our toolbox. But our product did not benefit from our experiences a single second.
When building a product, at the end of the day, it’s not about technology. It’s about this thing you want to build to make your user’s life easier, more entertaining, or whatever your goal may be.
And if you’re not building something wholly new and patentable, not a single of your (potential) investors will ever care about the latest fancy JavaScript framework, database, or programming language you’re using.
So stop experimenting, start doing.