banner

case study

Stella & Dot

Client

Stella & Dot Family Brands - social selling company specializing in jewelry accessories and skin care. Stella & Dot Family Brands has $300m estimated in annual revenue and has reportedly paid out more than $300m in commissions to it’s 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.

stack

Pain points

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 horizontal expansion of the business to new markets with launch of new brands.

Project kick-off (Inception)

We had 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 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
💡

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

We need a social selling platform that scales with our business

Also, around that time 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 implementation of existing platform of Stella & Dot or build new multi-brand platform, that will allow to seamlessly add more brands in the future. Stella & Dot decided to create a new multi-brand platform.

Benefits of multi-tenant platform:
  • Despite significant short-term costs, it allows to scale business in the desired areas mid and long-term
  • Reduce 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 that are releasing on 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 - small, but well-structured team. Tech Lead was responsible for successful delivery, execution and establishing repeatable and scalable process that could be handed off.

stack

Technology Stack

Team had expertise with Ruby and Javascript. So we decided to use Ruby on Rails for developing first few REST services. Early on we decided to optimize our approach for faster delivery of the product. When you have to launch something really quick and under tight deadlines, choosing the stack you're comfortable and confident in is always a good choice.

stack

One of the first principles we established was "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 existing API platform (i.e. web clients, mobile, etc).

We used "thin client" principle where frontend only renders results returned by the backend, without containing any business logic. To implement frontend we used single-page app approach which was new at the time (and uncommon in pre-React era) that worked out really well for us. We were able to save on development cost by re-using codebases between multiple clients via generating multiple targets (one per tenant) out of single code base with custom theming and custom user experience.

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 risk of slipping the timeline.

stack

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 feature development cycle into 2 stages: development and adoption. One brand, that is sponsor of the feature, builds the feature to completion and rolls out to it's customer base. Other brands may choose to adopt the feature at their own cost (usually insignificant, i.e. few days or a sprint, depending on context) or ignore it. This allows for brands to use same features and save money on development.

Benefits: Developing feature may take from a sprint to several sprints, while adoption takes something between a day and a couple of weeks, depending on extra configuration / implementation that adopting brand wants to put it.

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 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 architecture sprint outlined the direction of the development effort. Allowed the whole team be on the same page and understand how we can deliver product in the most efficient way. So we created user stories and agreed on the roadmap, 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 first 2 services talking to each other as well as 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 "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 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 number of decisions a particular developer need to make during implementation. Also it helps all team members to have an understanding 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.

As a user, I want to 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

Add link to the website "Reset password"
Clicking link should open form with input for email

Example Tech Notes for frontend

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 captures 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 platform scalable to millions of customers.

Rapid delivery and iteration

After successful and "frictionless" launch of KEEP Collective brand on a new platform we continued to build more features to reduce feature gap with existing platform — Magento-based shop and prepare new platform to host multiple brands.

Whilst continuously releasing new features, we identified 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 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
  • established patterns of configuration: build-time vs runtime
  • 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!

Prorgessive rollout

Following success of KEEP Collective, next step for the platform was to support the expansion of Stella & Dot Family Brands to new market with EVER Skincare brand.

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 feature flags technique along with implementation and lifecycle guidelines.

Prior to 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 to test new features in production prior to launch to verify quality.

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 issue, 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

stack
💡

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

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 full product and rolled out across engineering org within 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

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 able to provision independent and isolated environments with production-like sanitized data, changes isolated to production version AND their own version for the app they worked on. This project resulted in a straightforward and improved developer experience and workflow

💡

deep dive

Read technical details of this approach that allowed us to deploy software on a daily basis with high level of confidence.

Conclusion

In the end, after reaching feature parity with legacy Magento-based system, we successfully migrated Stella & Dot brand to use 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 opportunity. 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 changed since our productive multi-year long engagement with Stella & Dot came to an end.

Today we focus on following technologies:

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

Subscribe to Brilliant Consulting updates