What to consider when selecting a software stack

Matt Smith

So what’s a stack? And why should you care? A stack is a collection of software used in a project or application. You should care because each part of the stack should contribute to the priorities and values of your specific project.

Stacks are composed of the following parts:

Infrastructure
Largely refers to AWS (Amazon Web Services), Google Cloud, Digital Ocean, Microsoft Azure, or a myriad of other providers. This is the place your application will live. These providers also offer services that may change the way your application is deployed.

Language
Refers to the main language the project is developed in. You may have multiples these days with the rise of services and microservices. Language should be chosen based off of what is best for each individual project.

Framework
Refers to a “library” to be used under the particular language. There are usually a few choices. Like language, choose the best framework to support the project, they usually are positioned to be best in a certain category.

Another term to know is: Library
Refers to a versioned collection of code, often written by a community of developers or an organization. This code can be reused. Just like anything else, some libraries are better than others, and usually there is more than one library that does the same thing, with different preferences. A framework is usually an example of a library.

At Near Apogee, we generally use one of three stacks. We strategically chose our unique stacks to be complementary of each other. We have one for productivity, one for ubiquity, and one for performance.

We have four goals for our stacks:
  1. Longevity - We want projects to last for years without being forced to change out major parts of the application.
  2. Clarity of code - We want the application easy to read, which makes it easy to work on. Clear code is self-documenting (though we also document code)!
  3. Stability and ease of maintenance - New libraries can change major parts without notice causing the same issues as Longevity. Ease of maintenance allows projects to be updated and features to be added.
  4. Security - We want to keep intruders out and your data safe. Security is increasingly important.

We generally have 2 requirements of tools and libraries we use:
  1. They are “Open Source”
  2. They have significant usage

More on those below.

Preferences for quickly responding to changing business:
  1. Low-level opinionated tools over high-level opinionated tools - Low level tools are things all applications are required to do and customers have no concern over. We find customers get annoyed when they are told how to do business by high level tools.
  2. Minimal tools over complex tools - Complex things are expensive to maintain. Complex processes should have simple tools, to allow change.
  3. Agnostic tools - Choose these if you don’t want to be locked in. Technology grows so fast, it pays to be able to incorporate new tools.
  4. Solid design principles - Way beyond the scope of this document, but still important to mention. Some libraries and tools meet this standard, while others don’t

Let’s break down some of the nuanced parts of that!

We choose Open Source. Open Source is a good thing because development standards are governed by the community and open source projects usually follow the standards because they are also built in the community. One contrary example is Microsoft’s family of browsers. Internet Explorer had its own ideas on how the world should be. Browser code is still fragmented to this day because Microsoft decided to march to the beat of their own drum without the support of the community. Only now is Edge starting to adopt web standards.

Then we prefer widely used tools by other projects, organizations and individuals. We strive to use well maintained libraries which contribute to the longevity, stability, and maintenance of a project. Remember, after we build a project for you, eventually it will go into “maintenance” or a period where we just keep it up to date for security and new features that needs to be added. In this phase, we prefer none of the dependencies (or parts of the stack, i.e. language, framework, libraries) to disappear or not be supported. This greatly affects the security of a project, as well as longevity.

We generally don’t like opinionated high level tools as a foundation for a project. This generally eliminates most closed source and many frameworks or platforms that are the Swiss Army knives of software (Wordpress, Joomla, Wix, Shopify, etc). We will use them if they are the best tool for a portion of the job. But building an entire application on top of Wordpress a mess, for instance. Wordpress might be fine for content (blogging) or the simplest of ecommerce, but anything else starts to get into a grey area. We would rather use opinionated low level tools, to build an application that serves you in the way that you want it to. This way we get to capitalize on the work of others and reuse just as much code (largely for free) but get to choose how much and how the major pieces work together. Our customers love this!

We prefer agnostic tools at any level. It allows us to be flexible to changes in the infrastructure market and with development requirements. Perhaps you will want to switch to a different infrastructure provider for cost reasons. Agnostic applications can move and incorporate new technology. Our customers don’t like to be held down!

Additional Questions:
Why don’t you used closed source, proprietary, or commercial tools?
The truth is we do when we have to, but we don’t like them because companies can shut them off overnight. That risk just isn’t a thing in the open source world. Open source is open, so the community maintains it. And instead of one company owning it and keeping it closed, many companies contribute to it. The result is better rounded software that many people have a stake in making it better. This supports our goals of longevity, clarity, stability, and security.

Why minimal? Doesn’t that mean bare bones?
We like that for two reasons:
  1. It makes the project flexible, so change is easier as business logic changes. (Never make the assumption you will always be doing business the same way forever!
  2. It makes reading the code easy. If the benefits of that aren’t immediately clear, it means it is another source of documentation, intent can be gleaned, and it also supports change without dropping balls.
No, it doesn’t mean the application will be bare bones!

I hope this article has opened your mind to a few new concepts. If the goals and preferences we discussed are of interest to you, we would be happy to have a conversation with you to find out if we can help!

In summary:
  • Asking what the stack is behind a behind a project or proposal may help you know your future limitations.
  • Consider your priorities when you build an application to see if they match the strengths of your chosen stack.
  • Do you agree with our choices, preferences, and/or goals?
  • Our initial conversation is always free, so if you align with our principles we would love to meet you!

Matt Smith
Matt enjoys helping clients build applications that do more with less. He has been a part of teams building applications for startups, government entities, and commercial clients. He loves opening doors clients never knew existed.

Want to see how you business stacks up?

Take our Process Evaluation

Want to connect?

Schedule a Chat!