You Should Build your Next App on a Boring Stack

Photograph courtesy of Michał Parzuchowski

Developers love new shiny things. And in technology the past few years, there has been no shortage of shinies. Depending on the ecosystem you are working in, there are new frameworks coming out at a rapid pace. Shiny things are nice, and using the latest and greatest technology in your applications is a great way to achieve technological advantage over your competition.

But no matter how nice shiny things are, I believe you should develop your next application on a strictly boring stack, unless you are prepared to get up in the middle of the night to fix a stack you barely know. I’ll tell you a story I’m not particularly proud of, but one that proved to be an invaluable lesson.

That one time it couldn’t fail

About four years ago, I was working for a small startup company as a software engineer. The company wasn’t doing particularly well, and the product my team was working on was going to be the tide turner.

We had that startup mentality of always building software using the latest and greatest technologies. Around that time, that meant leaving the old fashioned SQL databases behind and moving to a NoSQL data model. That choice made a fair amount of sense, since the data we were processing wasn’t strictly relational.

On top of that, we made the decision to launch the application in Docker containers. No one really had any experience or even knew what Docker was back then, but one of our team members read about it, and he was convinced it would give us a competitive edge further down.

After about six months of development, we were ready for our initial release. We had customers lined up, ready to dive in and give us feedback. They had been waiting a good while, and the company’s management was anxious to finally start generating some revenue. Paying customers and a new launch were about to make our dreams come true.

All was good, for the first couple of hours. We went home happy after a job well done, and we were convinced the tide was finally turning. That joy lasted until it was near midnight. One of our larger customers called, saying some of the information they entered just disappeared, and he was getting logged out of the application intermittently.

Suffice to say none of the team members got a lot of sleep that night. We were eventually able to trace the issues back to the database simply not storing what we threw at it, and the user being logged out was because the application had server affinity, and we were evenly balancing requests between pods. Something we didn’t consider at all. Go figure how little we knew about running containerized applications.

It took us a few weeks and a bunch of hacks to compensate for our lack of understanding. While it was relatively smooth sailing from there on in, our launch had been a complete disaster. Paying customers were demanding refunds, and chances of them coming back in the future were extremely small. We messed up. Big time.

While I can’t say with certainty our stack choice was the reason the company went belly up, it certainly didn’t help. We made the conscious choice to run technology we knew very little about in a production environment, and we paid dearly for it.

It took me a while to realize that especially during the initial offering period, it makes a lot more sense to use tried and tested technologies. You only get one chance to do your launch, and you better do it well. Recovering the loss of customer’s trust suffered during a poor launch is what doomed our product, and perhaps even our entire business.

Photograph courtesy of Philipp Sewing

Keeping your boat afloat

Especially during the first couple of months following the initial release, keeping your boat afloat is what you’ll spend most of your time doing. Usually, development is carried by a handful of developers over an extended period of time. No one sees the bigger design and implementation picture anymore. Even if you have the most skilled engineers and the most extensive test suite, there are going to be holes in your boat. What matters is: how fast can you fix them?

As a rule of thumb, the more experience you have with a specific piece of technology, the faster you’ll be able to plug those holes. When adding the cutting edge in technology to your stack, you inherently lack this experience. This means you’ll be spending an awful lot of time on every issue you encounter. On top of that, information is often scarce, and your options for sourcing expertise externally are limited.

While you’re busy figuring out what on earth is going on, your customers are already searching for alternatives. If getting seaworthy takes too long, customers will abandon ship, and they won’t be coming back.

Technology moves extremely fast

Some ecosystems are particularly guilty of this. And yes, I mean the JavaScript and Node ecosystem in particular. Frameworks are coming out on a daily basis, all heralded to be the next big evolution.

As time passes, the vast majority of these technologies fade into the void. In Dutch, there’s a thing called “Law of the handicap of a head start”. I don’t think it translates very well, but what it basically boils down to is that a head-start may result in a handicap in the long run.

In technology, a head start is a double edged sword. If your decisions turn out well, you could gain a competitive edge over your competition through technology. If it doesn’t, you end up being invested in a dead piece of technology.

Because migrating from cornerstones in your technology is extremely expensive in terms of development effort, you should avoid it where you can. Proven SQL database engines such as PostgreSQL and MySQL are relatively reliable. Sure, they’re not very exciting, but the risk of cutting yourself because they’re suddenly not supported anymore are extremely slim. They also come with ACID guarantees, something I personally found to be worth its weight in gold.

Taking risks and adopting new technology is fine. What you should avoid though is jumping the technology bandwagon. If that new shiny piece of tech is really as fantastic as people claim it is, it will still be great in a year or so. 
Keep an eye out for anything that could improve your stack, but make sure to vigilantly guard your stack and your sanity.

Photograph courtesy of Annie Spratt

Scaling beyond the initial launch

Considering you chose your stack responsibly, you’ll eventually make it beyond the initial launch. At this point your application is reasonably stable, you have a handful of customers, and revenue is trickling in. You’re now in the luxurious position of scaling your operation. To do that, chances are you’ll need more developers.

Assuming we can find developers who are looking for a job, it’s relatively easy to find one that is proficient in SQL and ASP.NET MVC, or whatever you are using. It’s far more difficult to find developers that are proficient in technologies that are barely even a year old. You may be able to find someone who has tinkered with it in a hobby project, but that’s not nearly the same as proficiency.

Developers who are proficient in their technology make better design decisions than developers who aren’t. Needless to say, they’re far more likely to be proficient in a boring stack than in a cutting edge one. This leads to fewer holes in our boat, which is still a good thing!

Does that mean you shouldn’t innovate?

Of course you should, but it should be a careful consideration. The takeaway from this article is that you should start a project on a reasonably stable, perhaps a little old-fashioned stack. Once you are familiar with what your customers are looking for in your product, you’ll be able to far better match technological decisions with their requirements. At that point, you’ll be innovating for the right reasons, instead of just for the sake of being innovative.

What failing to keep a leaky boat afloat has taught me is that you should always choose the technology that best serves your customers, whoever they are. They don’t exactly care that you’re using the latest and greatest, cutting edge technology. They care if the software they paid for helps them achieve their goals. Needless to say, software that doesn’t work doesn’t help them achieve anything.

The best stack is the one that works the best for you. One you know well enough to have your gut feeling point you in the right direction 90% of the time an error occurs. Because that is what will help you build reliable, working software. And in turn, earn your customer’s loyalty.

There’s only one reason technology gets boring; it’s because you know it inside out. And that is just the quality your next app requires to succeed.