Frontend development focuses on the visual aspects of an app, the parts that your users will see and interact with. When building apps for companies with multiple brands, the ability to personalize each app for its respective brand is key. Our frontend approach puts customization capabilities at the forefront while thoughtfully reducing efforts where the apps’ look and feel and features overlap — starting with the use of SDKs, or software development kits.
SDKs help software developers create applications for a specific platform. Think of SDKs like the flat-packed Ikea dresser you bring home in a box to assemble yourself, only for app development. SDKs make building fairly standard app components faster and easier and allow developers to build applications without writing the code from scratch, streamlining and simplifying — and therefore speeding up — the app building process when multiple apps with similar functionalities need to be built.
Apple, for instance, has an iOS SDK that helps developers create native apps for iOS devices and platforms without having to build them entirely from the ground up. By creating an SDK, Apple standardizes their apps for all developers. New versions of the SDK accompany new versions of the iOS operating system and its new features. At Heady, we create custom SDKs in order to more quickly and easily build apps for clients with multiple brands. A custom SDK allows developers to more easily incorporate precoded functionalities in each app, expediting development and getting your apps to market faster.
While significantly reducing both cost and time to market for apps, the SDKs we build also provide the flexibility to tailor each app to its respective brand and users. This ensures each app provides a unique user experience and never feels cookie-cutter, particularly when used in conjunction with a headless CMS.
Utilizing a headless CMS is an important building block for our streamlined approach to building apps for multi-brand companies. A headless CMS is a content management system that separates where content is stored from where it’s presented, allowing you to reuse and remix content across platforms — whether it’s a brand’s website and mobile app, or multiple mobile apps from the same company.
A headless CMS can work in tandem with an SDK to pull in distinct branding elements and assets for each of the apps. This enables you to tailor the individual apps to each brand’s personality and look and provide a unified experience across the apps while also reducing work for developers, resulting in significant cost savings.
Heady’s own Application Management System (AMS) is a SaaS platform that combines a headless CMS with other tools that makes managing mobile apps and other frontend applications simple. When managing content in a mobile app, utilizing a system like AMS means you won’t have to constantly be pushing updates to the app stores. AMS can be customized for any frontend, whether it’s a mobile app, website, or another digital platform.
Backend development refers to the structure, system, data, and logic that underpins each of your apps. When considering how to approach backend development for multi-brand companies, speed and efficiency are key to ensure a great user experience for larger operations. Meanwhile, we also look for opportunities to avoid duplicating efforts in order to create additional time and cost savings.
When it comes to backend development for multiple apps under one roof, here are the essential building blocks we use at Heady.
Think of a code repository as a box that holds all the code that a team of developers is working on. In addition to storing code, a repository can also hold other important information like notes, documentation, and web pages, making it a one-stop shop for all the information the team needs to make their apps work.
When building custom SDKs and multiple apps, a code repository is especially crucial to keep everything organized. To make sure everything goes smoothly, each SDK (and each app that uses the SDK) needs its own code repository. This is important because the way the SDK is built and released is different from the way the app is built and released.
The code repository will automatically start the build process whenever a new release of the SDK is ready, saving developers time and reducing errors. Automating this process can cut back on delays when releasing multiple apps, ensuring they get to market more quickly.
Middleware refers to software and cloud services that sit between a mobile app and the backend systems or third-party services it interacts with. Middleware serves as a connector, enabling the app to communicate and exchange data with other systems.
Middleware can provide a range of common services and capabilities to mobile apps, such as security, data storage, authentication, and push notifications. It can also help to streamline and combine requests across various systems, improving the app's performance and scalability.
When building multiple apps, we use middleware to centralize and standardize how the apps connect to backend and third-party services, simplifying development and reducing ongoing maintenance costs. Additionally, by incorporating a content delivery network (CDN), all middleware requests can be cached, improving performance and global distribution while minimizing server and hosting costs on the backend.
At Heady we build custom middleware for frontend mobile applications and websites, often implementing a CDN and memory-based cache for the caching layer. Redis is a great option for in-memory cache, while third-party providers such as Akamai, CloudFront, or CloudFlare are solid choices for CDNs.
While the aforementioned SDK will handle shared features of multiple apps, the SDK utilizes a configuration file or service that allows the frontend to customize the experience of each app, including its features, look and feel, and third-party services and integrations. Heady’s proprietary App and Content Management System (AMS) can manage the configuration file for the mobile apps, interpreted by the SDK. AMS also provides a host of other app management features, including a kill switch, force update, bad versions, and more.
When configuring the SDK, it is important to know what services and platforms will be required for each app/brand. These services may not be required for every brand, and in some cases, the provider may be different from app to app.
Heady’s custom-built SDKs can manage the look and feel of multiple brands across different apps, as well as the various third-party services required by each app. At Heady, we’re dedicated to helping our partners find the right tools and building quality custom integrations to ensure they all work together seamlessly. Here are some platforms and services that we can configure for multi-brand companies across all their apps:
Ecommerce & Payments
Reporting & Analytics/Crashlytics
Customer Relationship Management (CRM)
Personalization / Experience Management
Buy Online Pickup in Store/Reserve Online Pickup in Store (BOPIS/ROPIS)
Email Signups & List Management
Systems Monitoring / Logging / Infrastructure Health
Customer Service & Feedback
Since apps are delivered to a user's device, they can hypothetically be reengineered and secrets can be exposed, leaving backend services and customer data at risk. That’s why when building mobile apps — or any software for that matter — it’s crucial to obscure and protect API keys and secrets.
Developers used to store these secrets and keys directly in an app’s code, which made them easy to find and exploit. Now, with the help of key managers like Heady's AMS or Amazon Web Services' Secrets Manager, app developers can keep the secrets and keys hidden and secure.
When building multiple apps, each one has keys and secrets that are needed to access APIs and third-party systems; more apps means more keys and secrets that need to be managed and protected. Heady encrypts all secrets and keys, storing them in a key manager and injecting them into the apps during the build process to ensure they’re never compromised. Not even our engineers or our clients ever see the keys, ensuring they remain top-secret.
Whether you’re building one app or ten apps, behind the scenes there’s a ton of data and information stored in proprietary systems, databases, CRMs, analytics, third-party tools, and so on. Many of these systems have separate connections and credentials and keeping up with all of them can be complicated, especially when multiple apps are in play.
Heady's approach to developing mobile apps with SDKs involves using document storage systems that are connected to the middleware. This allows us to store information in a format (JSON) that closely matches how the app communicates with the middleware. This approach avoids complex joins and data conversions across multiple tables, improving the performance of the app as well as making it easier and faster to develop.
MongoDB is our database of preference, but we’re platform agnostic and can recommend one that best suits your company’s needs.
Many organizations have separate authentication systems that manage users’ logins and passwords. These systems are usually referred to as Identity and Access Management (IAM). IAM tools have features that help manage user login, passwords and access. They also offer services and connections to the authentication process of frontend applications. Frontend applications use these tools to verify the user session and access the middleware and backend systems.
Centralizing IAM makes managing multiple apps and frontends much easier, reducing engineering overhead as well as strengthening security. Okta, AWS Cognito, and Auth0 are a few IAM platforms worth considering.
What happens if you create multiple apps using your custom SDK, but not all features are supported by each app? And what if you deploy a new version of one of your apps and a certain feature isn’t working correctly? Feature flags can help.
Feature flags are a way to turn on or off a certain feature in an app without having to change the app's code or update the entire app. Feature flags are also known as feature toggles, release toggles, or feature flippers. Feature flags decide which parts of the app are turned on or off when the app is running. This means that developers can release new features without making them visible to all users or only make them visible to a specific group of users. The use of feature flags is essential when building a family of separate-but-related apps in order to ensure each one can have its own unique features and functionalities.
Feature flags can be provided by several vendors, including Heady’s own AMS as well as LaunchDarkly, Taplytics, and Flagship.io — and while we may be slightly partial to our product, we’re dedicated to helping you find the right software for your needs.
A CI/CD pipeline automates your software delivery process. The pipeline builds code, runs tests (CI), and safely deploys a new version of the application (CD). Automated pipelines remove manual errors, provide standardized feedback loops to developers, and enable fast product iterations, getting your apps to market more quickly.
When building multiple apps under the same umbrella, each app will need its own CI/CD pipeline, which are usually integrated with your code repository. Your SDK will need its own CI/CD as well. Isolating the SDK from the rest of the app means you can make the desired changes once in the SDK, then deploy the new version of the SDK in all the apps in order for them to receive the updated code, meaning devs no longer have to write the same code change in every app individually.
While creating an SDK is an excellent approach to managing multiple brands and apps that rely on similar functionality, a shared platform, and similar third-party integrations, it’s also a complex setup with many moving parts. If your organization wants to build multiple apps under the same umbrella while keeping budget and timeline in check, our approach can help you achieve exactly that — and it’s crucial to have an experienced tech partner like Heady on your side.
When it comes to choosing a strategy for building mobile apps for multi-brand companies, it’s important to take a long-term view. Are each of the brands in question in it for the long haul? If a brand seems likely to be sold in the near future, it may make more sense to build that app solo with its own separate frontend and backend systems. Conversely, an acquisition-heavy company may find that this approach allows them to spin up new apps quickly when they add a new brand to their portfolio.
A robust discovery phase is essential to determining if this is the right approach for your brands’ apps — one where product owners, developers, designers, and other key stakeholders sit at the same table to discuss the many potential scenarios in order to devise a mobile app strategy that will best meet business needs.
While this approach to building multi-brand apps requires spending more time and effort in the early stages of the project, the long-term payoffs are a significant savings of time and money. And those savings don’t just factor into the initial build: This approach also simplifies and streamlines ongoing maintenance and new feature development for each of the multiple brands’ apps, making the product life cycle more efficient and less resource-intensive.
Based on our experience working with multi-brand companies, we believe this is a great way to maintain consistency across multiple brands while preserving each app’s independence and flexibility, and keeping costs and timeline in check.
Looking to build mobile apps for multiple brands under the same umbrella? If you want to ensure each brand maintains its unique identity and provides a stellar user experience while also reducing costs and time to market, Heady can help.
Determining the right approach for your company’s needs starts with a robust discovery process. We’ll take a holistic look at your business in order to determine the best path forward and help you decide what’s right for your brands — and even more importantly, your users. If you’re ready to take your multi-brand mobile app strategy to the next level, let’s chat.