That's a wrap: Sunsetting a Two Year Project as the Technical Lead

Concept

In late 2019 I was hired as the Technical Lead for a small B2B startup called BetaFashion GmbH. BetaFashion aimed to optimize in-season management for fashion brands.

This optimization would occur as a machine-learning process that would analyze orders, deliveries, inventory (brand and retail), and sales. With these inputs, we would generate the following types of proposals for the brand to accept in our user interface.

Replenishment Proposal: This would trigger a re-stocking of an existing item in a retail store.
Additional Proposal: This would trigger a product that was identified as a potential best-seller based on similar retail locations but not currently sold at this particular retail location to be sent to the retailer.
Return Proposal: This would trigger the removal of a poor-performing product that could be sold in another retail location with better outcomes.
Exchange Proposal: This would trigger the combined effects of an additional proposal and a return proposal.

As larger brands began to use the system regularly we had to create Automation Rules that the brand could set up to automatically accept proposals if it passed the rules that they set up in our system. This allowed the brand to continue accepting proposals even if a brand merchandiser was sick or forgot to log into the system. But most importantly saved a user hundreds to thousands of repetitive clicks.

The other part of the product was an analytics solution for the brands to verify their data in our system was correct. This allowed brands a way to explore their data that many fashion brands who were largely using complex spreadsheets lacked and offered them near real-time filtering on their data.

User Workflows

Brand User

Log in to the application
Explore Analytics Dashboards
Navigate to daily generated Proposals
Accept a Proposal that would trigger an email to the Retailer if the retailer was not set to be automatically replenished
View Transactions (historically accepted or declined proposals) and the status of each one i.e. retailer opened the email, clicked the link, accepted/declined

Retail User

Check email inbox
See an email notifying them of a proposed delivery to their store. This email was aggregated i.e. multiple accepted proposals would only generate one email with a single link to view the pending proposals.
Using the link from the email would allow the user a secure way to interact with the app for a limited period of time to reduce user friction of having to set up accounts or log in.
View pending proposals and each one's respective KPIs and then accept/decline it.

Technology

We were primarily a small team maxing out around 20 people before the Covid lockdown took a toll on the retail fashion industry in Europe. Given our small team and complex problem space as a technical lead, I wanted to optimize for delivering rapidly without sacrificing quality. I wanted to avoid hiring Dev-Ops and overengineering our solution prematurely.

Backend App

Laravel
Laravel Vapor (Serverless environment for PHP)
AWS Lambda
AWS RDS
AWS SQS
Redis
Single Store (OLAP Database)
Inertia.js
React
Tailwind CSS
GitHub Actions for CI

Frontend App

React
Vercel
Tailwind CSS
Cypress
GitHub Actions for CI

Philosophy

Test-driven development was core to the work done. We were working on a system that required us to deliver correct KPIs that had to align with what the brand expected to see. Comprehensive test suites allowed the backend and frontend to rapidly iterate. Due to this bugs that surfaced could largely be pointed at the brand's data quality and avoid costly time for a small team to investigate. Serverless technology was another tenant to the project the business had burned through a lot of money on freelancers setting up costly infrastructure in the pursuit of best practices. But before we had even come close to delivering an MVP. Due to this, I decided to go all in on serverless which would let our costs scale as our company (hopefully) grew. Leveraging on these services such as Laravel Vapor also gave us zero downtime deployments something which the dev-ops had not delivered on.

Team

Co-Founders: Sebastian Reider & Stefan Voss

Technical Lead: Devon Mather

Frontend: Francesco Fortunati, Mehmet Isikli

Backend: Gianni Circelli, Benjamin Radigk, Martin Vetter

ETL: Payam Yousefi

Mathematics: Jan Went, Andrei Belitski

The Application

App Landing Page

The introduction to the app from login, to brand overview. Exploring the components and real-time filtering.

Brand Proposals

This video shows the user experience of a brand merchandiser accepting and declining the proposals that would be generated from the mathematics department.

Retailer Proposals

This video shows the user experience of a retail-based user accepting and declining the proposals that would be sent via a secure signed URL in an email after a brand has accepted proposals for their retail location.

Proposal Automation Rules

As brands engaged more with the system and trusted the solution. We needed a way to allow brands to set up rules to allow for proposals to be automatically accepted. This would allow the brand to accept proposals based on their desired rules and could work even when a brand merchandiser might be sick or on holiday.

Automatic Replenishments

Brands needed a way to mark products or retail locations as automatically replenished. This means that certain retailers that specified the retailer did not need to accept a proposal and would therefore not be notified by email to accept proposals. Instead, the retailer would just get a daily recap of proposals that they would receive in the coming days. Automatic replenishments could apply to the retail location, the whole product, or individual variants.

Retail Contacts

Brands needed a way to assign email addresses to retail locations. In the case that their ERP didn't have the functionality to send it to us we would have to build the UI for it. This was the driving factor behind building the UI for the Automatic Replenishments page.

Retailer Analytics

Here the brand could drill down into each retailer, branch and location (point of sale). Each index page offered the ability to toggle a CSV download of the data which they would receive as an email async.

Product Analytics

Here the brand could drill down into each product. The index page offered the ability to toggle a CSV download of the data which they would receive as an email async.

German Localization

Given we were operating largely in Germany we opted to localize our application in German as well as English. All localization from the backend and frontend was covered by integration tests.

Closing up Shop

During my time at BetaFashion, I got to wear many hats from recruiting great developers, managing the backend and frontend teams, sprint planning, developing the product with the founders, and sourcing and implementing new technologies like SingleStore etc.

The team built a solid and robust application for our target market. However, we faced challenges beyond the scope of our work.

In March 2022 we had multiple investors lined up and were ready to adapt to the easing of the covid situation. However, after one investor pulled out it set off a series of events that caused the funding to collapse causing the company to go bankrupt. The decline of BetaFashion was a slow burn from there with many companies pitching ideas for us to build after the administration demoed the product we had created to potential buyers. But ultimately the team was not ready to take on another project from the ground up. It was a great project and glad I was able to join for the ride.