Stella & Dot Family Brands has $300m estimated in annual revenue and has reportedly paid out more than $300m in commissions to its stylists during the lifetime of the company. Read the article in Forbes or watch Stella & Dot on the Today Show
Allow Stella & Dot to seamlessly expand to new markets, launching 2 new brands and then migrating the biggest brand onto a single platform. Align technology leadership on an approach and deliver on execution.
The existing e-commerce platform could not handle sales during peak season resulting in outages or delayed order processing times during the most important business days for the company. It was also not flexible enough to support the horizontal expansion of the business to new markets with the launch of new brands.
We had a few working sessions with technology and business leadership teams to define high-level goals and scope. We knew from the beginning that we needed a platform that scales well:
Learn more about our approach to inception. What is the goal of inception, value to the client and the team, what different stages it includes and how we tackle them
It allows us to seamlessly add more brands in the future. Also, around that time the company decided to expand into new markets and launch new brands "KEEP Collective" and "EVER Skincare & MakeUp". We had to select an approach: either replicate the implementation of the existing platform of Stella & Dot or build a new multi-brand platform, that allows us to seamlessly add more brands in the future. Stella & Dot decided to create a new multi-brand platform.
We had 6 engineers (4 developers, 2 QA), tech lead, product manager and scrum master - a small, but well-structured team. Tech Lead was responsible for successful delivery, execution and establishing a repeatable and scalable process that could be replicated and scaled up by adding more vertical and self-sufficient teams
We used the "thin client" principle where frontend-only renders results returned by the backend, without containing any business logic. To implement frontend we used a single-page app approach which was new at the time (and uncommon in the pre-React era) that worked out really well for us. We were able to save on development costs by re-using codebases between multiple clients via generating multiple targets (one per tenant) out of a single code base with custom theming and custom user experience.
One of the first principles we established was an "API-first platform". Where client applications of the platform always remain "thin" only keeping presentational logic, but all business logic remains within services. This would allow us to scale frontend independently as well as introduce any number of clients running against the existing API platform (i.e. web clients, mobile, etc).
Goal: Align senior product and engineering leadership on architecture and approach.
Next, we decided to run an "architecture sprint". We spent 1 week working closely with Stella & Dot product and engineering leadership to specify capabilities, limitations of the product and define points of integration of the system. And then produce a high-level roadmap to manage scope and reduce the risk of slipping the timeline.
Frontend: we chose the single-page application approach. It allowed us to use the same codebase among all the Stella & Dot Family Brands applications. The advantage of this approach is that when we develop features for one brand, other brands can adopt these features virtually for free.
This presented certain challenges in order to decide what is the configuration of a feature and what is an independent feature that will be adopted. But we were able to easily guide these decisions by establishing engineering practices within the team.
Over time we decided to split the feature development cycle into 2 stages: development and adoption. One brand, which is a sponsor of the feature, builds the feature to completion and rolls out to its customer base. Other brands may choose to adopt the feature at their own cost (usually insignificant, i.e. a few days or a sprint, depending on context) or ignore it. This allows for brands to use the same features and save money on development.
Benefits: Developing a feature may take from a sprint to several sprints, while adoption takes something between a day and a couple of weeks, depending on the extra configuration/implementation that adopting brand wants to put it free.
Backend: We chose microservices architecture, because we were familiar with the current domain model having plenty of experience in e-commerce. The challenge was to release MVP in 4 months. We didn't want to risk the trust of direct sales representatives that have signed up for the waitlist to participate in a new opportunity from Stella & Dot Family Brands.
The technical approach defined during the architecture sprint outlined the direction of the development effort. Allowed the whole team to be on the same page and understand how we can deliver the product in the most efficient way. So we created user stories, agreed on the roadmap and planned the release with timeline to release in 4 months.
The process for "validation" was a demo and thorough walkthrough of the codebase, deployment artifacts, development environment, development workflow for the first 2 services talking to each other as well as a demo for adding new API functionality, generating API client, etc.
At this point, we took roadmap, broke down work into 2-week sprints and kicked off the development. We optimized for the "common sense" approach in terms of feature delivery and organization:
This approach allowed us to identify any wiring and integration issues early on. During development, we used the Scrum methodology with small customization. We were diving deep into stories during backlog groomings writing down potential approaches for implementation to limit the number of decisions a particular developer needed to make during implementation. Also it helps all team members to have an understanding of not only WHAT we are building, but HOW we are building. And it goes hand in hand with our Transparency value.
In particular, empirically we quickly determined that for each User Story you need to add the so-called Tech Notes, which describes HOW the user story will be implemented. These Tech Notes were filled out by team members during Backlog Grooming.
Login - reset password
Example user story
Add reset_passsword_token column to users table
Add reset_password_token_expires_at column to users table
Add new endpoint that will create reset password token for a given email
If email is not found, let the user know that email is not found, return 422 response in the endpoint
Add password reset email template
Send to user's email address via SendGrid email integration
Example Tech Notes for backend
It took us 12 weeks (6 sprints) to get MVP out into the hands of customers. We applied cloud-native principles during application development from the beginning to make the platform scalable to millions of customers.
After the successful and "frictionless" launch of the KEEP Collective brand on a new platform we continued to build more features to reduce the feature gap with an existing platform — A Magento-based shop and prepare a new platform to host multiple brands.
Whilst continuously releasing new features, we identified a few principles to base our suite of microservices on. To simplify, standardize the approach and provide a solution to multiple dev teams we:
Following the success of KEEP Collective, the next step for the platform was to support the expansion of Stella & Dot Family Brands to a new market with EVER Skincare brand.
Prior to the introduction of feature flags the alternative was to time releases to feature launches which turned out to be super stressful and fragile as it didn’t allow testing new features in production prior to launch to verify quality.
As the number of development teams grew and platform complexity increased we had to find ways to ship features to customers continuously. To solve this problem we proposed leveraging the feature flags technique along with implementation and lifecycle guidelines.
The new approach allows for testing new features on a subset of loyal customers. No matter how much testing you do in lower environments, something unexpected usually comes up in production which you can’t prepare for due to volume issues, edge cases or environment issues so feature flags helped us a lot.
Pain: impossible to test new features in production on a subset of loyal customers making it hard to reliably ship new features and requires A LOT of testing in lower environments
Value: decoupled code deployment from feature release, supported testing of new features on a subset of real users in production
Feature flags can be different in their function: from helping to launch features to mitigating risks for platform operators. Read more about different types and use cases for feature flags
Scaling development across multiple teams is a hard challenge, one of the ways to keep developer velocity high as well as increase robustness of delivered software is to "shift testing left". Hence we established a new technique for working with platform called Dynamic environments.
Developers fell in love with the POC (yes, we built a really scrappy POC to win their opinions). We then implemented the full product and rolled it out across engineering org within the next 3 months and never looked back ever since.
Pain: long cycles of testing using traditional QA/stage environments didn't satisfy velocity requirements for dev teams at Stella & Dot Family of Brands. production
Goal: to develop and test features independently, get away from long testing cycles, ship changes to production continuously. Improve developer experience and productivity.
Value: developers and QA engineers are able to provide independent and isolated environments with production-like sanitized data, changes isolated to the production version AND their own version for the app they worked on. This project resulted in a straightforward and improved developer experience and workflow
In the end, after reaching feature parity with the legacy Magento-based system, we successfully migrated Stella & Dot brand to use a new social selling platform.
It was our privilege to stand in the very beginning of development and contribute to the architecture of the game-changing social selling platform that helped Stella & Dot to change womens' lives providing flexible income opportunities. At the same time it was a great opportunity to innovate and explore new approaches (as described above) to deliver even more business value to Stella & Dot.
Brilliant Consulting constantly seeks opportunities to deliver more value to their clients, hence quite a few things have changed since our productive multi-year-long engagement with Stella & Dot came to an end.