Lessons From Building a Multi-Brand Web App

By: Eric Potter

Several years ago, I was a part of a development team that built a web application for one of Aptera's partners. It was a great collaborative effort and the project was very successful. The partner was one of the brands within a larger corporation. Because of both a broader move to consolidate resources in the corporation and the success of the initial site, the leadership decided to add products from the other brands into the site. They tasked the development team with taking an application built for one brand at four locations and growing it to be used by six brands spread across 19 locations. This led to some interesting challenges and some interesting lessons learned that I would like to share with you here.

Non-Technical Lessons

The first set of challenges I want to talk about are the ones that didn't involve technology. Programmers are often quick to jump to the technical side of the project. But for multibrand projects, it is important to have a solid non-technical foundation before the development begins.


The original web application was developed with a specific personnel and specific roles in mind. More generally it was designed to be used by people within the organization of the partner. Some of the functionality made assumptions about people being available in certain roles. The brands that were added to the site didn't all have people that slotted into those roles the way the original brand did. This presented some challenges up front.

In hindsight, I can see that we were trying to use software designed for one organization in a different organization. This wasn't insurmountable, but it did take some additional coordination between various teams before the software could provide value.


Marketing professionals work very hard to establish a brand identity. Working with 6 different marketing departments presented an interesting challenge of coming up with something that worked for all of them. For the developers, that meant that we needed to rename the site and come up with a new layout. It also meant that we changed much of the verbiage on the site.

Technical Lessons

In addition to the non-technical challenges, we had technical hurdles we had to jump over.


When the site only served one brand, it was obvious which backend systems we needed to integrate with. When we expanded the site to work with multiple brands, we had to discover all of the additional systems the application needs to integrate with. Some of the integration challenges had to do with physical connectivity since the systems were spread across the country. And there were obviously security concerns that we needed to address. With the connectivity established, we had to work through differences in data formats. Some of the backend integrations used a REST API, some used WCF with SOAP. Others simply used flat files that the application needs to move around. Beyond that, we had to make sure that the data met the system's expectations. For example, some of the systems expected to receive the lengths in feet and others expected to receive the lengths in inches.


One of the biggest challenges was modifying the database to hold data for all of the companies. While they all sell similar products, they all have subtle and important differences. One thing we did that worked particularly well was to have database schemas that are specific to some of the brands. This meant that when there was data that was unique to one of the brands, it was apparent to any developer because of the schema that it was in. I'm confident this prevented many bugs.

Something that took more time than I would have guessed was changing the division identifier from a single character code to a 5 character code. The original system used a single character code because there were only a few divisions. Because the expanded system had more than 26 divisions, we switched to a larger identifier. It wasn't hard to change the data type in the database. It was a lot of work to update all of the integration points to either work with the new codes or convert back to the appropriate older codes.


Some of the systems that the site integrates with are 20 years old. So updating these systems to work with the newer data formats was a special challenge. It was the first time I had worked with a COM application in a very long time.

Strategy Pattern

Because of the differences in how the different brands operate, there were times when the code had to behave differently depending on what brand was using the software. Using the Strategy pattern worked very well for these scenarios. We implemented the differences in behavior in strategy classes. We used a factory to instantiate the correct strategy object for a given brand. The resulting code cleanly separated the concerns of the different brands.

Decorator Pattern

The strategy pattern allowed us to encapsulate code that was specific to individual brands. But there were also times when the application needed to share some behaviors between a subset of the brands. In these cases, we utilized the decorator pattern. We wrote the shared behavior in a decorator class that we could apply to one of the strategy classes.

Summary of Lessons Learned

  • Applications are built with assumptions about the personnel in the organizations that will be using it. If you are going to expand an application to be used in a new organization, identify these assumptions and address them early.
  • When you are estimating the effort it will take to start using an existing application in a new organization, make sure the integrations are well understood and properly documented. Make sure you cover the physical connections and the data formats.
  • Identify behavior that will be different between the various organizations. Use design patterns appropriately to keep the code clean as you add functionality.
  • Businesses can get a lot of value out of using existing software applications in new ways. But it does present unique development challenges. You need to address these challenges properly to maximize the return on the investment in the additional development effort.
eric potter headshot

About Eric Potter

Eric is a Microsoft MVP and Software Architect for Aptera Software in Fort Wayne Indiana, working primarily in the .Net platform. He has been developing high quality custom software solutions since 2001. He is also an adjunct professor of computer science at Indiana Tech. He loves to dabble in new and exciting technologies.