This is an installment in the What Biz People Need to Know About Tech series. It’s aim is to help non-technical business people to communicate better with engineers and provide better feedback about the value they want them to deliver.
I was recently approached by someone who’s company is struggling to make a technical decision. They are a large organization who has multiple brands under a single umbrella. All of these brands make similar products at different price points and levels of quality. Let’s say they make dishwashers, just for the sake of this post.
The decision this company was wrestling with was whether each of their brands should build separate iPhone apps to interface via bluetooth with their dishwashers, or if they should build one app that can be customized per brand.
This post aims to show what questions a good CTO (or other tech leader) would ask, and how they would use the answers to those questions to make this decision.
The answer to this one is not usually as simple as a single value on a scale from 1-10. The ways in which the apps are going to vary matter.
Here’s some examples of variations that are easily supported by a single configurable codebase:
- Needing to change colors, fonts, and logos to match each brand.
- Needing different copy / content in various places.
- Excluding features from some versions of the app. For example, if the lower price point brands don’t have certain features and we want to exlude them from their apps.
- Needing to change the order or layout of components.
- Using different accounts to authenticate (brand A website accounts vs brand B website accounts)
Here’s some examples of variations that are harder to support with a single codebase.
- Needing a totally different control structure for the flow. For example, if one brand wants to use a bottom tabbar based layout and another wants to use a more custom wizard-like flow.
- There are wildly different legal requirements. If one want app needs to have special review from a 3rd party agency but another does not, you may not want to tangle both apps up in the regulatory restrictions.
- There’s simply no shared functionality at all. If that’s the case, there’s no reason to spend time building the configuration to use a single codebase.
By building on a single codebase, you are increasing the amount of communication and agreeance that is needed between the different brand owners.
A good CTO would know to keep an eye out for binding divisions together who are unlikely to work well together over time.
If there’s one brand that needs to get the app to market much sooner than the others, it may make sense to launch that brand as a stand alone project. You can graft on the configurable elements later to launch the other products.
It requires more engineering talent to build many apps out of one configurable project. If the team doesn’t have budget for at least a few experienced engineers to guide the development of such a system, it might be wise to build them as seperate apps.
In many cases though, this would indicate the budget is simply not sufficient to set this project up for success.
There’s significant long term value in building the apps out of a single configurable codebase. So I would say that if the answers to 2 out of 4 of those questions are indicating it should be built in that manner, it’s the right way to go.
If you have less than 2 of them pointing in that direction, it’s probably worth spending some time trying to get them moving in that direction.
If there’s no way that can happen, you’re best to go with individual apps. However, it should be made very clear that there are serious drawbacks to that approach over the long haul. Praticularly in maintainablity and long term efficiency.
Self care is a hot topic these days, and I’m not just talking about face masks. There is a growing movement that underscores the importance of taking time to take care of yourself (in addition to all the other things that you already take time for). You can prevent problems down the road by taking proactive steps to ensure your health and happiness.