Your tech stack is the frameworks and components you use to build your digital product. These include your front-end, back-end and database as well as many other frameworks, components, plug-ins and services you might need for deploying, managing, testing and analytics.
What you select isn’t always clear as there are many options, and those vary widely depending on the stage you are in, and what you are trying to accomplish. Sometimes startups pick complex, highly engineered solutions because they anticipate that they are going to be scaling rapidly. However, the cost for building on such a stack isn’t warranted if you are still trying to build a quick and simple MVP to validate your product.
The opposite is also true. If you are well past an MVP and have market proof that requires you to scale rapidly, you want to make sure that the architecture supports that.
So, let’s look at the various stages of your product journey, from ideation to full product deployment, and how you make good decisions on the tech stack based on the needs of those stages, the vision for your product, the goals of the organization, and the capabilities and capacities of the development team.
Idea Stage / Pre-MVP
At this stage you should not be building anything complex because you likely haven’t found Problem / Solution fit, let alone ready to build an MVP, much less your full product. If you have done your homework and done extensive customer interviews and research, this is where prototyping, testing, and iteration are done to validate your ideas.
The reason I think this phase of your product journey is relevant is because these tools and techniques should be part of your overall product development cycle, forever. It’s also where you start crafting the beginnings of your product roadmap and value roadmap, and that vision will help you make better choices on your development tech stack later.
Wireframes
Simple low-fidelity sketches that allow you to quickly brainstorm UX/UI for an application. For superfast wireframing, maybe start with a whiteboard or even paper to quickly outline key workflows and layouts. Or use wireframing tools like Axure, Balsamiq, Sketch, or Figma to build screens and simulate workflows and interactions. This is a great place to start, and doing this as a team builds consensus on what the product will be before you start spending time creating something more complex. Our team will often whiteboard extensively in brainstorming meetings, then distil them into digital wireframes.
Prototypes
With prototypes you are starting to create something that begins to look and feel much like your vision of a working product. The goal is to simulate a real application’s interface, workflows, outputs, and other key interactions. Gone are the days of simple graphical mockups presented as a PowerPoint deck. Now tools like Figma allow teams to build highly interactive and functional prototypes that actually look and feel like the real application and can accept input, grids and tables, modals, popups, controls like drop downs and check boxes, and conditional outputs.
MVP
The purpose of the MVP is to validate your product idea with real customers and to make sure that your solution has value. The tech that supports that essentially answers this question: “What do I need to test this product idea as quickly and efficiently as possible at the lowest cost?”
There are two broad options for how to develop your MVP – either build it with the idea that you will extend your MVP’s technology to the full product version or build a disposable version.
Personally, I like the disposable option a great deal. The only goal at the MVP stage is to validate your product – nothing more. Deciding to dispose of your MVP once you have done that validation frees you from the constraints of having to figure out what your tech stack should be in your full version and trying to build the foundation for that in the MVP. It doesn’t matter what you select if it accomplishes the goal of getting the product into user hands and validating your solution.
Now you have the option of using tools like low-code / no-code tools like Bubble and Appian, and rapid application development (RAD) frameworks like Zoho Creator and Kissflow, allow you to build concepts quickly and inexpensively, and test concepts and workflows.
Custom e-commerce systems are also expensive to build and maintain, but launching an MVP using something like Shopify or BigCommerce can allow you test your product in the marketplace first, and then build something more complex and scalable later.
Another reason for considering a disposable MVP is if you fail to get traction and you decide to abandon your project, you will have likely spent a lot less time and money getting to that point than if you had architected with a more robust platform. There is nothing worse than building a full-blown, costly, complex application that doesn’t get traction in the marketplace, and it happens all the time.
So, when is a disposable MVP not the best option? Sometimes an MVP is not needed at all, such as in digital transformation projects and other process improvement software used by internal teams. You probably should indeed go through prototyping, but if you have a clear mandate on the project, wasting time on a disposable MVP doesn’t make sense, and building an architecture that suits the needs of the project is the way to go.
Building Your Full Product
The decisions you make when selecting the elements of your tech stack are not always the easiest to make. Pick the wrong stack and you will have to refactor later. Do too much, and you spend more money on your technology than you need to for the foreseeable future.
For startups, this decision is even more complicated. If you have a limited budget, do you really need a high availability architecture with Kubernetes cluster and geo-distributed data centers? Almost certainly the cost for that stack would not be justified for both the cost and time to get a product launched. And remember, the maintenance cost and ongoing development time increases as the complexity of the platform increases.
The software plugins and frameworks you select to build your products can have huge impacts, positive and negative. For example, one of our clients has a very complex user interface that didn’t have the budget for a custom build, so a plugin that did 90% of what they needed was licensed. Another dev team prior to us had selected the wrong framework and after months of trying fit a square peg into a round hole, it had to be rebuilt costing them time and money. It was an avoidable error that set them back about a year.
How Do You Decide?
Ultimately, choosing the right technology stack can be a dizzying decision, and not without risks.
Requirements
Select a stack that not only aligns with your first version but can also support your vision. This is where your Product Roadmap can help you make a good decision. How big that time box is will depend on your budget, time to market, and other factors.
Scalability
Can you scale both vertically and horizontally? Vertical scalability is about supporting new features, and horizontal scalability is about supporting more users. For niche products with smaller user bases, horizontal scalability might not be as critical as mass market B2C ecommerce and social platforms with potentially huge numbers of users.
Extensibility
API-first, headless and cloud-native architectures offer greater extensibility and flexibility. For example, if your app was API-first, all functionality is exposed through the API. With this architecture, you could update the front end without touching the back end, and vice versa.
Security
Your needs might vary depending on the type of product you are building. Fintech and healthcare platforms usually require higher levels of security than other applications. Even so, security is always important regardless of the sensitivity of the data you collect.
Team Skills
The skills of your team is a factor too. Picking a stack that aligns with your team’s experience could be a big plus, but it can’t be the overriding factor. If your team, or vendor, has a preferred stack that isn’t perfectly aligned with your requirements, you need to reassess the team.
Conclusion
There is no single one-size-fits all-tech stack, and every project has its own unique requirements and considerations. Choosing which technologies to use to build your digital product has a lot of factors, and it needs to be considered carefully. And what you select will depend on the stage of your project, the immediate and future requirements, and security and scalability considerations.
