The Calculus of choosing the right Technology Platform for Your App

Image source:

Among the dozens of decisions required when first starting a technology project or company, no two types of decisions are more important than decisions about who will join your team and which technologies you will use to build your product. These decisions have long term, irreversible impacts that are hard to change. They set a direction for your startup or team before you even get started. When technology managers, startup executives, and founders want to choose a technology stack for their next product, the decision-making process has roughly three stages: discovery, elimination, and consensus building.


The first phase, Discovery, is a broad-based search of technologies that have been used for building any application that has similar functionality to what you have in mind. The Discovery phase helps answer which technologies are possible to use? Most developers worth their salt should be able to come up with at least two stacks of technologies you can use to build the application. In general, a software application’s technology stack consists of a back-end server, front-end clients, database, and deployment infrastructure. The most common mistake when deciding on a technology stack is placing too much emphasis on technology that is already familiar. There is no need to limit yourself to just two or three stacks or to technologies you already know. Instead, it’s better to pick a technology stack specific to the problem you are trying to solve. For messaging apps, place a greater emphasis on reliability of the real-time communication. For finance apps, place a greater emphasis on security. This will mitigate high-risk issues that can occur like service outages, consistent performance degradation, and lawsuits.

The discovery phase is about discovery. It sounds like common sense but is easily looked over because most people (including developers and technologists) have a tendency to do what is familiar. By the end of this phase of discovery, you should have a list of 3–5 technology stacks that are feasible to use for your application depending on its goals and scope. Most of the time when you ask a question in online communities like Stack Overflow about the merits of a particular technology, the word “depends” is often thrown around to the point of overuse without really a satisfying explanation to what picking a technology framework depends on. So we will go into more depth about what that actually means in the next phase: Elimination.

Elimination: What not to Use

There are a few characteristics and metrics of success that a technology product or project is often judged on. One of the most common ones is time to market. How long will this project take to finish? If time to market is really important, it will take precedence over other goals like production cost, maintenance overhead, and technical debt. In other words, the goal of the elimination phase is to align the technology tools to the vision. Build fast and fix later? Or build right and maintain a scalable technology platform?

While many startups go the build-fast and fix later route to varying degrees of success, in some organizations, the outcome of the success of a product is given a greater emphasis over the time to market. In these scenarios, significant portions of the technology stack are built in-house; custom technologies are created specifically for the problem domain. A good example is the release of the first iPhone or even many of Google’s web products. The hardware, software, and even programming languages were customized to do more, like Objective C with Apple, and JavaScript for Google. These products often take years to build, but have a higher chance of success in the market because hard things act as their own filter.

Pick a spot within the above two extremes that you feel comfortable with. It’s important that you do not pick a spot between the above two extremes because those spots have the highest risk of leading to mediocrity. Examples of things that are between the above extremes include: build slow and never fix; build fast and fix now; build slow, then destroy; build slow, then release an incompatible version; build fast and outsource the fixing to someone else. You get the idea. Then, use tools that fall within the philosophical extremes of time to market and success in the market.

Consensus Building

Interestingly enough, most of the popular technology frameworks already fall within one of the two extremes above, so consensus building is actually the easy part. For example, with web development, the top two JavaScript libraries are jQuery and React. jQuery is within the “build fast fix later” side of the spectrum. React is on the “build slow and right” side of the spectrum. This pattern comes up repeatedly in all aspects of web and mobile development.

The hard part around consensus building occurs when you want to use a technology platform that is really good at solving your specific problem, but it’s not a mainstream technology platform yet. If you wanted to use a node.js server for a messaging application in 2012, you had to make a pretty strong case. Now, not so much. The other hard part is you have to be right, and there is nothing I can tell you that would improve your odds at it, except for the one thing I’m about to say next.

Growth Rates and Areas Under Curves

Calculus is a very powerful mathematical tool for understanding our world; it is just as useful as statistics but its applications overlook most of us, but not dogs :) As a quick refresher, the first major idea of Calculus is growth rates (aka derivatives). The second major idea is that functions leave behind traces of their path (the area under their curve).

Another way to think about the above two concepts is to compare income vs assets. Income is the rate of money flow happening to you now (the derivative of money over time), whereas assets are the accumulation of money flow over time into your life and your family’s life. Similar to monetary assets, there are aspects of technology products and platforms that are tangible assets. The codebase, the flexibility of the underlying technology and its applications to other platforms. These are hard to measure, but they have “leading indicators”. For example, let’s compare two JavaScript-based app development frameworks: React Native and Ionic. Here is a Trends chart comparing the two:

While the growth rate of React Native is clearly faster than Ionic, Ionic has a leading indicator of having more “technology assets” within its framework, both from having been around longer and also the support of Angular’s ecosystem (both AngularJS and the new Angular). Having used both frameworks, I’ve experienced the maturity of the technology assets first-hand with Ionic. The UI components are stable and look good on all devices, there are few breaking changes within the individual version, but overall the experience of developing UI’s is consistent and predictable across platforms. Not so with React Native, where one must choose from at least 5 navigation libraries, 10 UI component libraries, and 3 storage libraries before you even start delivering real value.

Although the underlying framework is easier to use with React Native, the end product feels like it’s held together by its package.json file with glue and tape. In other words, React Native is generally more suited for the “build fast fix later” route, whereas Ionic would be more suited for “build slow but make great products” path.

Conclusion — Aligning technology and project goals

All this to say, there’s no real “right” answer but there are leading indicators that we can follow for understanding the goal of a technology and its ecosystem. Ionic is known for its ‘write once, run anywhere’ philosophy whereas React Native is known for its ‘learn once, write anywhere’ philosophy (a gentler way of saying “learn once, and then copypasta”).

Ultimately, the most important thing to remember is that a framework is just a tool to build software. Its strength comes from the team using the framework for a particular cause. In addition to balancing time-to-market and quality, there is also the balance of technical debt accumulation versus proper maintenance. For some teams, the short-term technical debt may be worth the long-term maintenance cost. For other teams that are short on resources, the long-term maintenance costs could have a crippling effect on growth and innovation. This is what is meant by aligning the framework goals to your vision.

It’s usually not the technology’s fault if a project fails. It’s the project’s lack of a well-defined, achievable, innovative vision combined with harsh market forces. This is a much harder problem to deal with than the engineering problem. Unlike engineering problems, there is little documentation about the hard questions of technology, like choosing the right team, the right frameworks, and getting stakeholder approval and funding. Hopefully we can start having more conversations around these more loosely defined problems, despite our aversion to uncertainty as engineers and many of our desire to focus on the newest and shiniest technology / feature / framework.