Strategizing Your App’s Technology Platform Selection
In the initial stages of launching a technology project or company, two categories of decisions are crucial: team selection and technology stack choice. These decisions create long-lasting, often irreversible consequences that shape the trajectory of your startup or team. Generally, the decision-making process for selecting a technology stack unfolds in three phases: discovery, elimination, and consensus-building.
Discovery
The Discovery phase is an expansive search for technologies suitable for building an application with functionalities similar to your envisioned project. This phase aims to answer the question: what technology stacks are viable options? Any competent developer should be able to suggest at least two stacks that could be used to construct the application. A typical technology stack includes a back-end server, front-end clients, database, and deployment infrastructure.
A prevalent error during this stage is overemphasizing familiar technologies. Limiting yourself to two or three known stacks or staying in your comfort zone undermines the purpose of the Discovery phase. The focus should instead be on choosing a technology stack tailored to solve specific challenges. For example, a messaging app should prioritize the reliability of real-time communication, while a finance app should focus on robust security measures. Addressing these priorities will help mitigate significant risks such as service outages, performance issues, and legal complications.
While the Discovery phase is inherently about exploration, this essential aspect is often overlooked—many, including developers and technologists, default to what they already know. By the end of this stage, you should have identified 3–5 viable technology stacks contingent upon your project’s goals and scope.
Often, when you seek advice in online forums like Stack Overflow on the merits of a specific technology, you’ll encounter the term “depends” used ambiguously and excessively, without much elucidation. In the following phase—Elimination—we will delve deeper into the factors determining an appropriate technology selection.
Elimination: Deciding What Not to Use
Several metrics and characteristics often serve as benchmarks for evaluating the success of a technology project or product, one of the most notable being time-to-market. How quickly can the project be completed? When time-to-market is a high priority, it often supersedes other considerations such as production cost, maintenance overhead, and technical debt. The objective of the Elimination phase is to align the selected technologies with the project’s overall vision. Do you aim to build quickly and iterate later or strive for a meticulously crafted, scalable technology platform?
Many startups opt for the “build fast, fix later” approach, achieving varying degrees of success. In contrast, some organizations emphasize product excellence over speed, investing in custom-built elements of the technology stack tailored to the project’s unique requirements. Notable examples include Apple’s first iPhone and several of Google’s web products, where hardware, software, and even programming languages like Objective-C for Apple and JavaScript for Google were customized. Such projects often take longer but stand a better chance at market success, as complexity is a natural barrier to competition.
The key is identifying a position within these two extremes that aligns with your objectives. Surprisingly, the most challenging course often lies in the middle ground, as ambiguous strategies like “build slow and never fix” or “build fast and outsource fixes” will likely yield mediocre results. Therefore, choose tools and methodologies that align with your philosophical stance on time-to-market and potential for market success.
Consensus Building
Interestingly, most well-known technology frameworks align with one of the abovementioned extremes, making consensus-building relatively straightforward. For instance, the leading JavaScript libraries in web development—jQuery and React—fall on opposite ends of the spectrum. jQuery caters to the “build fast, fix later” approach, while React is more aligned with “build slow, but build right.” This dichotomy is consistently observed across various facets of web and mobile development.
Challenges in consensus-building arise when the technology best suited for your problem has yet to be mainstream. For example, advocating for a Node.js server for a messaging application in 2012 would have required a compelling argument. Now, the landscape has evolved, reducing the need for such justifications. However, the ultimate challenge in consensus-building is making the correct choice—something inherently uncertain. While I can offer no silver bullet for ensuring success, the upcoming guidance may improve your odds.
Growth Rates and Areas Under Curves: A Calculus Perspective
Calculus is an invaluable mathematical tool for comprehending the intricacies of our world, much like statistics. While its applications might escape the notice of most people, our canine friends are an exception! To briefly recap, the first significant calculus concept is growth rates, also known as derivatives. The second core concept is the area under a function’s curve, representing the function’s accumulated “history.”
One effective way to internalize these principles is to equate them with income and assets. Income can be seen as your current rate of money inflow, effectively the derivative of your financial worth over time. In contrast, assets represent the sum of your income over time, affecting both you and your family. Similarly, technology products and platforms possess tangible assets such as their codebase, adaptability of the underlying technology, and applicability across various platforms. These assets may be hard to quantify but can be indicated by leading metrics.
To illustrate, let’s examine two JavaScript-based app development frameworks: React Native and Ionic. React Native displays a faster growth rate, but Ionic boasts more substantial “technology assets,” benefiting from its longevity and the supportive ecosystem of Angular (both AngularJS and the newer Angular version). Having worked with both frameworks, I can attest to Ionic’s technological maturity. The UI components are stable across multiple devices, and the framework shows few breaking changes between versions. The development experience is consistently predictable, regardless of the platform you are on. This is not the case with React Native, which forces developers to choose among at least five navigation libraries, ten UI component libraries, and three storage libraries before making significant progress.
While React Native might be more user-friendly regarding its foundational framework, the end product often seems to be precariously held together by its package.json file—akin to glue and tape for stability. In other words, React Native aligns more closely with the “build fast, fix later” philosophy, whereas Ionic seems tailored for a “build slow but produce high-quality products” approach.
Conclusion: Aligning Technology and Project Goals
In summary, while there may not be a single “right” answer, there are leading indicators that can guide our understanding of a technology and its surrounding ecosystem. For instance, Ionic adheres to a ‘write once, run anywhere’ philosophy. At the same time, React Native espouses a ‘learn once, write anywhere’ ethos—a more diplomatic way of saying “learn once, then copy and paste.”
It’s crucial to remember that a framework is merely a tool for software development; its efficacy largely depends on the team utilizing it for a specific purpose. Alongside time-to-market considerations and product quality, there’s also the equilibrium between accumulating technical debt and maintaining the software properly. For some teams, the benefits of short-term technical debt outweigh long-term maintenance costs. However, these long-term costs could stifle growth and innovation for resource-constrained groups. This underscores the importance of aligning the framework’s objectives with your vision.
It’s worth noting that technology is seldom to blame when a project fails. The failure often stems from the project’s need for a precise, achievable, innovative vision compounded by challenging market conditions. Addressing these issues proves more difficult than solving engineering problems. Unlike engineering, there’s scant documentation covering the more nebulous aspects of technology—such as selecting the right team the appropriate frameworks, and securing stakeholder approval and funding. As we move forward, expanding the dialogue around these less-defined yet equally crucial challenges is essential despite our natural inclination as engineers to focus on the latest and most advanced technologies, features, or frameworks.