How APAX Chooses the Best Tech for You

David V.
David Vanderhaar, Developer
8 min read

What’s a Tech Stack?

APAX aims to solve your unique problems with custom solutions. We say custom solutions because we aren’t merely looking to be innovative in solving a problem. Where time and budget can be saved, we avoid reinventing the technological wheel by aggregating the best tools we can find to work towards your goals. Every application we deploy requires what developers call the tech stack. This tech stack is made of various layers, and each layer we integrate comes with a host of decisions to be made, the outcomes of which can be quite varied from project to project.

This is where the custom solution comes in. Though we could build each layer of your software from scratch, we prefer to incorporate tried-and-true tools that help get the job done. How do we choose the right tools, and can you count on them being the best for you?

 

The Tech Stack is Complex

Each tool or solution we incorporate deserves analysis and even questioning. Minimally, we should be asking ourselves: how much will this solution cost to implement? How much will it cost to upkeep? Do we need to consider special security and compliance requirements? Is there existing code or architecture we need to integrate or update? Does there need to be a mobile-friendly solution? Is the scalability of the application important? Does our implementation offer the right level of flexibility pending change requests from you? 

To get a better view of the problem at hand, we’ll need to complicate things a little further. The questions above are powerful and discerning, but they aren’t enough. The end solution to your problem is comprised of several layers, as defined by the tech stack. Examining each piece of the stack offers an even broader sense of all the decisions our team and yours must juggle. Though the stack can be broken down in many ways, we often break it down into four components: the frontend, the backend, the database, and the deployment process. Each layer of the stack deserves its own boatload of questions and communication between our team and yours. 

 

Frontend

The frontend is one piece of a larger structure we call the application layer. The frontend is responsible for taking user input and communicating it to the rest of our tech stack. Most commonly, the user is requesting access to data or for permission to change it. The frontend is often made up of several tools and technologies that give software developers a reliable way to create dependable and friendly user experiences. At this point, we need to ask a few more questions: What is the core content of this site/app? How much of this content will change? Why does this content need to change? How often will this content change? Who will be managing content? Will there be a mobile experience?

Backend

The backend is another piece of a larger structure we call the application layer. The backend is not viewed by the user. It is responsible for storing and retrieving data from the database and then sending that back to the frontend so that the user can continue interacting with it. At this point, we ask even more questions: Will there be non-standard data models? What level of data processing will there be (ex. search functionalities, analysis)? How often will data models change after development starts? Will there need to be frequent security, compatibility, or compliance updates?

Database

The database is responsible for storing data and maintaining the organization and relationships we define on the backend of our solution. At this point, we must ask a few more questions: Will the application be search intensive? Will the application be scaled in the future? How much data will the application be dealing with? 

Deployment

The deployment pipeline is the process in which we take our code and deliver it to the users in the form of new functionality. This process ranges from simple file transfers from one computer to another to automatic distribution across multiple servers complete with automated tests and fallback protocols in case the site goes down. Additional questions at this stage include: do you have a deployment strategy in place already? Are you currently paying for enterprise services such as Azure, Amazon Web Services, or Aquia? Will there be a mobile app? Is automated testing important to you? Do you have network administrators in place? What sort of user load do you expect?

APAX is always asking and evaluating our solutions based on questions like these. We want you to be able to ask these pointed questions with us.

 

A Recent Experience

Aquatic Remedies

In 2019 we completed a project for a company we’ll call Aquatic Remedies. This company, though based locally, has employees traveling all over the east coast. They didn’t have an easy way to keep everyone up to date with the latest information on company policy, worksite procedures, onboardings practices, etc. They needed a better way to disseminate information to everyone at once, all from one place. This project provided several exciting challenges. During the estimation process, we knew we would have to build their application in two distinct phases pending the success of the first phase. The challenge was to help meet the company’s budget goals while building a minimum viable product that could be easily expanded in later stages. 

This manifested in several areas; first, we had to build a system that worked across most mobile devices with the potential to expand that to web browsers. The first major decision was how to handle the frontend. Their employees use both Android and iOS devices. Should we maintain two sets of tools for each operating system, offering more stability while sacrificing flexibility and upkeep cost? Should we use a single toolset that allows us to maintain both operating systems with a single codebase, offering high flexibility while sacrificing ultra-robust functionality? The next major decision was choosing the right backend. APAX developers have preferences and goto technologies for sure, but at the end of the day, it has to be the right fit for the project at hand. In that spirit, we considered many options. We knew that the company needed a way to update information and resources regularly and restructure the presentation of said data at the drop of a hat. So, do we build a improve and modify the tools we are comfortable with to match the functionality necessary? Do we find a tool better suited for dynamic structural changes?

In the end, we decided to use two toolsets we were less familiar with but promised the greatest flexibility. For the frontend, we used a mobile app framework called Expo. It allowed us to write a single codebase for both iOS and Android devices. It even helped smooth out our deployment process because the app could be dynamically updated without accessing the Google Play or Apple App stores. Where we would typically use a tool called Django, the backend was ultimately powered by Drupal. Drupal is a popular content management system (CMS) built for applications that require users to update content frequently. We could have certainly done this using Django, but it would have taken much longer. These two decisions produced a piece of software that works across most mobile devices and, with just a small amount of work, can be extended to web browsers like Chrome and Edge.

 

Help Us Choose the Best Tech

In our experience, it’s easy to make a tech stack that will work for you, but it takes some elbow grease to create the best stack for your needs. The question remains, how can we work with you to make the right decisions. There isn’t a one-size-fits-all answer, but we’d like to offer you a series of questions that you can refer back to at any time during the development process. These are the very questions we ask ourselves. By listing them here, we effectively put more eyes on a problem and its solution, where vision is often obscured behind technical jargon.

 

General Questions

  • What is the tech stack? 
  • What tools are you planning to use for this project? Why?
  • Are there any other tools you considered? Why not use those?
  • Does this stack come with additional upkeep costs? Are there alternatives?
  • Have you solved problems like this before? Did you use a similar tech stack? Why?
  • Do you have experience with these tools?
  • Will this technology scale to our needs?
  • Is this technology well-known or commonly used by software developers?
  • Do we already pay for tools that solve parts of the problem we’re addressing? (e.x. Slack, Microsoft OneDrive, Azure, Google Cloud, Trello, Zoho)

Frontend Questions

  • What is the core content of this site/app? 
  • How much of this content will change? 
  • Why does this content need to change? 
  • How often will this content change? 
  • Who will be managing content? 
  • Will there be a mobile experience?

Backend Questions

  • Will there be non-standard data models? 
  • What level of data processing will there be (ex. search functionalities, analysis)? 
  • How often will data models change after development starts? 
  • Will there need to be frequent security, compatibility, or compliance updates?

Database Questions

  • Will the application be search intensive? 
  • Will the application be scaled in the future? 
  • How much data will the application be dealing with? 

Deployment Questions

  • Do you have a deployment strategy in place already? 
  • Are you currently paying for enterprise services such as Azure, Amazon Web Services, or Aquia? 
  • Will there be a mobile app? Which Devices? 
  • Is automated testing important to you? 
  • Do you have network administrators in place? 
  • What sort of user load do you expect?

 

Conclusion

Of course, our job is to ask these questions and to ask them consistently. But we believe that clueing you into our numerous technical decisions will produce solutions that everyone is proud of. Not all of these questions will apply to each situation, and if your problem is unique, our approach may be as well. The primary goal is to choose the best tech stack for you. It will undoubtedly change and evolve as new requirements are discovered, and for each of those inflections points, we can refer back to the general questions above to make sure all parties on the same page.

Food for thought

What questions would you add to this list? Are there any that don’t make sense?