The JourneyApps Blog

The implementation of digital business apps has become part of mainstream IT strategy throughout the industrial sector. One of the biggest decisions facing companies when determining these strategies is whether to build apps on an app development platform, or put together their own technology stack.

If a company opts to put together its own technology stack from scratch, they need to be sure that they have very good reasons to do so, as this is a risky route to take. In Part 1 of 2 about whether or not to buy an app development platform, we take a look at those risks and what to consider when deciding to build your own technology stack.

Building Your Own Technology Stack

Some companies decide against buying a third party platform and to develop software in-house, even if the company is not primarily focused on software development. Three important factors should be considered when deciding to go this route:

1. The scope of the endeavor
2. Talent and bandwidth constraints
3. The risk involved

The Scope Of Creating An In-House Tech Stack

The magnitude of this exercise becomes apparent when you consider the many bases that will need to be covered on the way to assembling a full stack, including aspects such as design and architecture. These include:

1. Application structural architecture e.g. model-view-controller (MVC) pattern, and promoting code reuse while allowing for extensibility where needed.
2. Deployment architecture, including containerization, and application servers with redundancy and load balancing.
3. Database architecture with redundancy through replication, and high scalability through indexing and performance monitoring.
4. UI/UX framework and data binding to the UI.
5. Cross-platform compatibility for different mobile operating systems, as well as responsiveness across different form factors, including desktops, smartphones and tablets. Consider the total cost of cross-platform support: If the plan is to support iOS, Android, Windows and web, companies need to test each pre-release version of iOS, Android and Windows and all pre-release versions of the supported browsers.
6. Security architecture and features, including data encryption in all states.
7. User authentication and authorization / permissions framework, including SSO integration (e.g. ActiveDirectory).
8. Integration tooling, including point-to-point integrations as well as message queue based integration (and monitoring/alerting and scaling thereof).
9. DevOps tooling, including development environment automation, deployment automation and a version control system.
10. Testing automation, including unit testing frameworks, continuous integration, and functional testing.
11. Data synchronization to user devices for offline access to data, including conflict resolution and data partitioning.
12. Diagnostics and support tools for first-line support staff, including user error reporting, logging and log search functionality, and error alerting with stack traces and contextual debugging information.
13. Automated backups and disaster recovery, including monitoring of backup processes, and dry-runs of disaster recovery restore processes and timelines.
14. Auditing functionality, including data access and data modification audit trails.
15. Data analytics / BI integration.
16. System performance monitoring, including alerting of performance or load degradation events, and a pager duty system.
17. Security processes and practices, including monitoring security advisories for all parts of the stack and patching systems whenever advisories are released, and conducting regular security penetration testing with expert 3rd party cybersecurity consultants.
18. Regulatory and security compliance, including architecting for SOC 2 criteria compliance, as well as compliance with data privacy legislation such as GDPR and the California Consumer Privacy Act (e.g. data retention management tools).

Taking the route of developing an in-house technology stack instead of using an existing development platform requires you to build technology that already exists. Essentially, you will be “reinventing the wheel”.

Bandwidth & Talent Constraints

Many IT teams have a lack of bandwidth, with much time being taken up by projects such as system integrations and maintaining legacy systems (especially ERP systems). This often prevents IT teams from delivering on the constant stream of new projects that the business demands.

Research by Forrester shows that CIOs spend an average of 72 percent of their budgets on existing IT concerns, while only 28 percent goes to new projects and innovation.

This problem is exacerbated in the industrial space, where investment in development capacity to take on new technology domains like mobile and cloud have lagged behind other more consumer-facing industries.

One argument in favor of a self-built stack is that since digital technology is becoming a strategic competitive advantage, it is necessary to own the intellectual property for their entire stack. This argument conflates the strategic value of a specific product with that of the stack which it is built on: Airbnb doesn’t need to own the IP of Apple’s iOS operating system for them build a successful product that runs on iOS but is owned by Airbnb.

The same argument is sometimes used to counter the reality of a lack of IT bandwidth: Senior management may plan on investing millions of dollars (or even hundreds of millions) in building up a large digital “business unit” to take on the challenge.Yet even in this scenario, the challenge still exists that talented systems architects, software developers and DevOps engineers are scarce and in very high demand. Worse still, industrial companies may find themselves in a recruitment shoot-out not only with traditional competitors but also with tech companies who are drawing from the same limited talent pool on a large scale.

The Risk of Building Your Own Stack

Here we take a broader look at five significant risks of an in-house built stack.

1. Security: Security should be the most important consideration in a risk assessment. Cyber attackers are continuously becoming more sophisticated, and large corporations are some of their favorite targets. If a company is building their own technology stack for their digital business applications, they are creating a unique stack that has not yet been audited or penetration-tested for security vulnerabilities. The onus of ensuring that the stack is secure and remains secure, is a massive responsibility. It’s a responsibility that never goes away: Every time additional development is performed, there is maintenance or upkeep on the stack (or even on individual applications), it is potentially susceptible to new security vulnerabilities, and the stack then needs to be audited again.
2. Uptime: Modern-day cloud-ready infrastructure is incredibly complex, especially with the rise of containerization and technologies such as Kubernetes. Monitoring and continuously keeping a complex cloud system running is not trivial, and the risk of unplanned downtime is real.
3. Performance and scalability: Designing a system for high-scalability often takes many rounds of real-world performance measurement and optimization. When a company builds their own technology stack, there are significant risks that they will run into performance bottlenecks where the system fails to scale, and business-critical operations are interrupted as a result.
4. Team Bandwidth: If a company is building their own technology stack, maintenance and upkeep requirements are often an unknown factor, and it’s very likely that they will run into constraints on their team’s bandwidth that limit their ability to perform necessary maintenance on the system. Many development teams put off technical debt out of necessity, to the point where they have no choice but to address the technical debt as part of their short-term roadmap. This often means that development of updates or new features needed by the business needs to be put on hold for a considerable amount of time.
5. Technical Limitation: There is a significant risk that companies that build their own stack will run into hard technical challenges that are non-trivial to solve, that could derail the entire project. For example, in the industrial sector, users who work in the field are often offline, and offline data sync is often a critical requirement for apps used in the field. At JourneyApps, we have seen again and again that IT teams underestimate the complexity of solving offline data sync, and they spend millions of dollars and years of time of dozens of talented developers in trying to solve it, only to eventually abandon it in frustration.

In Conclusion

Each company is different, but we believe that in the vast majority of cases, the risks far outweigh the rewards of building your own technology stack for your digital business apps, rather than using an existing platform. When a company decides to build their technology stack in-house, they need to be sure to understand the scope of the undertaking, be aware that there may be bandwidth restriction and talent shortages and be willing to take the risks involved. In part two of this discussion we will take a look at the second option when deciding on a digital app strategy: Using a high-productivity app platform.