Building a Scalable Digital Product Ecosystem for Complex Logistics
Delta Velocity
Delta Velocity helps D2C brands, dropshippers, and e-commerce sellers manage the messy middle of logistics - order management, courier allocation, SKU-box mapping, and reconciling COD and prepaid payments - so brands don't have to juggle five different tools to ship a single order. When I joined, none of that had a design behind it yet. The company hadn't launched, and it was just a founder, a co-founder, and a lean 5 person team figuring things out as we went. There was no design system, no landing page, and the SaaS product that existed was half-built, with no research behind it and no flow that actually worked start to finish. I was the only designer in the room - working directly with the founders and the engineering teams, with no PM.
Industry
B2B | Supply Chain
Platform
SAAS & Landing page
My Role
Product Designer
Timeline
Dec 2024 - May 2026
01.
The core - the SaaS product, end to end
This is where most of the work lived. What existed when I joined was broken - no complete flows, nothing grounded in real user behavior. I rebuilt it, starting from scratch: competitor research, user interviews, flow mapping, IA, card sorting, then into UI, iteration, prototyping, handoff, launch, and testing after it went live. It wasn't a set of screens I handed off - it was a product built to actually be sold.
02.
The front door - a landing page
This wasn't built to convert traffic or run campaigns. Its whole job was simpler: help someone land on the page and actually understand what Delta Velocity does, in a space where "logistics aggregator" can mean five different things depending on who you ask.
03.
The foundation - a design system
Before this existed, design and development were basically working in two different languages. Handoff was inconsistent, and things got rebuilt that didn't need to be. I built a unified design system in Figma that covered both the SaaS product and the landing page. Once the dev team started using it, a lot of that friction just disappeared - fewer duplicate components, faster handoff, and a shared language between design and code instead of a back-and-forth every time.
Making Calls With No Playbook - The challenge
Honestly, the hardest part wasn't the design work - it was the ground constantly shifting underneath it. Scope changed almost daily, and most of the friction wasn't really about whether a design was good, it was about people remembering things differently. So I started writing down decisions as they were made, dated, day by day. It felt almost bureaucratic at the time, but it's what stopped us from re-arguing the same decision three weeks later. That habit probably saved the project more time than any single design choice did.
Outcomes
The product launched and started making money. As of now: 10,000+ order shipments processed, and real feedback coming back from actual users that we've been folding into the product as we go, rather than waiting for some future release. The design system paid off exactly where you'd hope - once it existed, design and engineering stopped negotiating over every button and started building from the same source.
Reflection
If I could go back, I'd change how I sequenced the SaaS build. I worked on multiple modules in parallel instead of one at a time, which felt efficient in the moment but made decision-making harder than it needed to be — the engineering team ended up feeling stretched thin across too many fronts at once. Looking back, going more linear after a certain point — finishing and stabilizing one module before fully diving into the next - would have made the whole process smoother for everyone, not just me.
