Super apps, as a one-stop portal that integrates multiple products and services, normally start with a core product and then integrate more services to give customers a seamless experience. Regardless of which industry it belongs to or what services it wants to integrate, building platforms is always the key step on the path to becoming a super app.
When we say the platforms, we don’t just mean the platform business model, but also business capabilities platforms and the infrastructure platforms.
Infrastructure platforms pave the way to production. When mapped to super apps, that generally means developing an efficient integration and release strategy that can improve time to market and reduce the cognitive load of developer teams.
Business capability platforms capture and expose existing business capabilities, making it easier to integrate new products. When it comes to super apps, it typically means leveraging existing capabilities and increasing reusability, to enable internal and external services and accelerate business growth.
Platform business models are built upon the other two. Super apps serve as the frontend and interfaces for all products and services, facilitating interactions among all parties, and being the most direct way to reach customers.
With a focus on the business capability and infrastructure platforms, this article will look into the top three pain points we’ve faced when helping our clients build super apps.
Platforms are built in silos
In some organizations, platforms are built by completely separate teams or even different departments, with separate delivery plans, processes, and investment budgets. This silo platform development model frequently results in misalignment with business priorities. Business needs aren’t met timely. The functions built by platforms may be technically important, but they can’t receive immediate feedback because these functions are not used in actual products and services fast enough.
Collaboration between the platform team and the feature teams is an evolving process. In the early stages of app development, the platform team must collaborate closely with the feature teams to determine platform priorities based on business requirements, or even sit in one team. As the business grows, the platform team should adjust its collaboration with the feature teams. They should see feature teams as the customers and focus on effectively providing capabilities as services internally and externally from the entire super app perspective.
The essence of the platforms is to provide support for businesses and ultimately provide value for the app's users. You cannot simply create the platforms for the sake of creating the platforms.
Poor organization of parallelized products and services development
It is common to split the business into multiple teams for parallel development to speed up delivery and solicit user feedback as soon as possible. However, poorly organized parallel development models pose various issues. Unavoidable interactions between business features result in complex communication costs; missing cross-team guidelines result in messy code and unclear dependencies; similar features and functionalities are repeatedly developed in different teams, resulting in a lack of reuse, etc.
There are mature tools and practices in the web frontend to address similar problems, such as micro frontend and monorepo, but in mobile, those practices are still in trial. With practical experience in real projects, we discovered that, regardless of the strategy and tools, a development model based on contracts and APIs can reduce problems to some extent.
Every business module defines its capability as APIs, and others should only interact with it via the exposed interfaces. This way sets constraints on business-to-business dependencies, requiring the team to align on the contract before plunging into development.
Feature teams and platform teams work together to capture the common components and existing business capabilities from a global perspective, and automatically visualize those APIs in a shared space, allowing the team to use it as a quick reference, therefore reducing the potential duplicated effort.
The encapsulated APIs could also remove friction and hide complexity from other teams, allowing them to focus on delivering products and services faster to customers.
Set team contracts such as API-based interaction and ownership boundaries, with the same ground rules in mind, so that cross-team collaboration becomes more efficient.
Business integrations are always prioritized over infrastructure
Because of its direct value, the development of business features is always given higher priority than technical tasks such as improving development efficiency and quality. The pain points associated with this prioritization are amplified when developing super apps, especially when it comes to building infrastructure.
One of the main distinctions between mobile apps and other platforms is that no matter how many products and services an app integrates with, they must all be packaged together and released to the Apple store and Google Play store for users to download. As more services are integrated into the app, we notice that the development team devotes a significant amount of time to integration and distribution. It often takes time to generate test packages due to dependencies and conflicts among services. Services integration takes time during release, and problems with any service during the process can endanger the entire app's on-time release.
Building an efficient and automated app infrastructure is the most critical foundation for improving development efficiency and quality, and allowing the app to be released to the market quickly.
Design a multi-layered testing strategy, introduce automation at the appropriate stage to detect problems with specific business features in a timely manner.
Automate the integration of all products and services to quickly identify dependencies and conflicts. And automate the app packaging process, to facilitate timely testing.
Set a fixed release cycle and automate the release process to reduce the burden of frequent releases and the potential risk for human control.
Automatically collect app data such as crash rate, error logs, and so on to facilitate data analysis, monitor app performance, and quickly resolve serious issues.
Building a super app is an evolutionary journey, and platforms serve as the foundation to support the evolution of business, technical, and team topologies. We should always create success metrics and evolve the platforms along the way.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
