stella

Stella & Dot Family Brands

Social selling company specializing in jewelry accessories, bags and skincare.

Client

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

Challenge

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.

Project plan

Pain points

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.

Project kick-off (Inception)

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:

To support a growing number of brands
To serve customers around the world with no impact
To support multiple development teams working alongside each other to allow for rapid iteration

“We need a social selling platform that scales with our business”

Deep Dive

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

New multi-brand platform

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.

Benefits of the multi-tenant platform:

Despite significant short-term costs, it allows to scale business in the desired areas mid and long-term
Reduce the cost of adding new features and functionality to the platform. They are developed once but then all brands running on the platform benefit them
It allows experimenting with products delivered to the market to attract new customers
Predictable and well-understood scalability

Team

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

illustration

Technology Stack

illustration

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).

Architecture sprint

1 week

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.

architecture

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.

Work with product to build MVP roadmap

Spent 1 week

We quickly identified the most important features for MVP:

Onboarding of DSRs
Catalog
Shopping cart
Admin interface for Customer Support
Integration with the warehouse for sending orders, listing available inventory
Integration for sending email offers to customers
Integration with commissions system

Proof of Concept for first 2 services

Spent 2 weeks

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.

Start of the MVP development

Spent 6 sprints (3 months total)

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:

First implemented all wiring between services and external systems to get mechanics of integration working
As soon as interfaces are defined and integrated. We can get the simplest possible use case working. And then progressively adding more functionality to complete user stories

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

user_service:

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

email_service:

Add password reset email template

Send to user's email address via SendGrid email integration

Example Tech Notes for backend

Our development process consisted of:

Daily standups - every day, each scrum team member gave his status
Bi-weekly sprint planning
Weekly backlog grooming - product selects several user stories for discussion. Dev team has a discussion on how to implement and capture implementation details as part of Tech Notes
Bi-weekly Sprint Retrospective
Bi-weekly Sprint Review

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.

Rapid delivery and iteration

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:

separated "platform" team from product teams and applied product management approach to the internal delivery platform
implemented robust production-ready CI/CD pipeline
implemented zero-downtime deployment approach (including database schema changes)
established guidelines for new applications to be developed
treated developers of the company as our customers to ensure high-speed velocity for developing new features, reliable and straightforward security updates, automation of mundane day-to-day tasks
defined and aligned teams on using standardized entry points for services, as well as README file
created developer-specific tools to ensure non-frustrating day-to-day operations. Happy developers build better products!

Progressive rollout

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.

Feature flags

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

flags

Deep Dive

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

illustration

Dynamic environments

dynamic environments

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

Conclusion

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.

Next stage

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.

Today we focus on the following technologies:

Typescript / Javascript (React, NodeJS)
Go (microservices, grpc, tooling)
Kubernetes, Docker