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.

Question 1: How Similar Are These Products Going To Be Across Brands?

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:

1. Needing to change colors, fonts, and logos to match each brand.
2. Needing different copy / content in various places.
3. 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.
4. Needing to change the order or layout of components.
5. 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.

1. 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.
2. 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.
3. 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.

Question 2: Are The Stake Holders For These Products Generally On The Same Page?

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.

Question 3: Are The Timelines Similar For Each Product?

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.

Question 4: What is the skill level of the team?

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.

Making the call

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.