How to choose a tech stack that reflects company culture

When choosing a tech stack, businesses can get caught up looking for “the one” — that instantly recognizable, know-it-when-I-see-it match. The process is not unlike choosing a wedding dress in that way. (Stay with me here!) Given that full stack rebuilds almost never happen, it’s essential to choose wisely. You want to pick a programming language, framework, databases, and server architecture that meet your functional and technical requirements — just the way a wedding dress should, theoretically, be clothing and signal who’s the bride.

But a tech stack is also an expression of a business’s individual style. Want something traditional and timeless? Then maybe you’ll want to go with java. Looking for something with a trendier vibe? Then Ruby might be the ticket.

Then there’s comfort. A wedding dress that’s stiff and ill-fitting will be a pain to wear for hours on end. Similarly, stack architecture misaligned with your business functions and practices will be a pain to work within — and that matters, given how many working hours your employees will spend in it.

Finally, choose something that you’re not going to look back on with regret. Everyone in your company has a stake in your tech stack, even if they don’t directly work with code. Your tech stack will affect your ability to scale and innovate, your integrations with third-party systems, and your business’s DevOps workflows.

Tech stacks tend to cluster by industry — education, for instance, was once dominated by .net solutions, although there are plenty of new java and node projects underway — so take into consideration which tech stacks tend to be common in your industry and even among existing competitors. This is a matter of strategy, not conformity: It will be much easier to find vertical-specific talent in a sector where particular programming languages dominate if your business works in that language, too.

Nevertheless, going with your industry’s established precedent isn’t a hard rule; it’s not uncommon to build with a stack that is intentionally differentiated from similar successful apps. It’s just one more way companies try to separate themselves from the pack.

Tech stack maturity, as in how long it’s been around, isn’t a perfect indicator of a tech stack’s quality, but it can point to the amount of engineering talent and community solutions that exist for a stack. That’s either a good or bad thing, depending on your company. Some stacks (such as java) have been around for decades; others like Ruby are newer and a little more stylish, as we noted above, but with shorter histories. The shorter the history, the smaller the communities and talent pools — which, yet again, gets back to ease of hiring and availability of support.

Ask yourself if building with the latest and greatest is really important to your business, or if it’s more important to have something dependable, with deep talent pools, despite convoluted code or stodgy communities.

Now that we’re in deep, this is the part where we come clean and tell you that OK, yes, some of this is vibes. That doesn’t mean it can’t be taken seriously, or have a serious effect on the business success of your product.

Maker culture might be hard to pin down, but it generally refers to the Silicon Valley-style interest in creating something new — and creating it fast, even if that means accruing some technical debt. If you value the community and the process of creating something new, you’ll find a similar mindset among the communities of the less mature stacks that promise cloud-enabled functionality (like Ruby) or frontend-to-backend engineering capabilities (like Node.js).

If all goes according to plan, where do you see your company going? Does it end with an IPO? An acquisition? Total world domination?

Thinking this far into the future might seem like a foolish exercise when your most immediate concern is getting an MVP off the ground, but taking the long view can be informative as you choose a stack. Technology requirements are heavily considered during mergers and acquisitions, and they can presage culture clashes between companies during such transactions. Likewise, tech stacks that encourage fast-moving maker cultures might end up accruing technical debt that will need to be righted down the road.

Ten years ago, tech stacks weren’t considered anything but a technical toolkit. Now, they’re not just tools but signals: They can hint to everyone, from your employees to industry peers and potential acquirers, exactly who you want to attract, and who you want to be.