https://deltavelocity.in/

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 & Design System

My Role : Product Designer

Wesbite : https://deltavelocity.in/

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.

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.

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.

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.

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.

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.