Building a frontend and design practice from zero
Over five years at Tecsys, I went from the company’s first and only frontend developer to frontend tech lead of a nine-person UX team. Along the way, I brought modern UI into a legacy Java supply-chain platform without a rewrite, built its component library and design system, and helped grow a design culture in a backend-first company.
- Role
- First frontend hire, then frontend tech lead of the UX team
- Company
- Tecsys, supply-chain software including a WMS
- Stack
- Web components (Stencil, then Lit), Vue.js, Java platform, Figma
- Scope
- Frontend architecture, design system, UX/UI design, UX team creation, developer and agency enablement
9UX team, grown from one person
~30components, 100+ tokens
3products on the design system
01Context
Tecsys sold a supply-chain platform, including a warehouse management system (WMS), built on an old custom Java framework. A full backend team maintained it, but the company had no frontend developers and no designers. I was the first.
My mandate was to modernize the platform and improve its UI and user experience. The existing UI was largely table-based and constrained by what the Java platform could render.
02Challenges
The technology was the easy part; the people and the platform were not.
- 01
A team new to frontend
The platform team had little frontend experience and was resistant to change.
- 02
No room for a rewrite
They wanted to introduce a JavaScript framework, but would not accept a large refactor of the platform.
- 03
No design function
There were no designers, and no access to real end users.
03Approach
My goal was to deliver modern UI incrementally, inside the existing platform, with a learning curve the team could actually absorb. The work unfolded in three phases: proving it alone, building the team, then scaling beyond myself.
A component library that works anywhere
I built the foundation as native web components, so the same components could run inside the legacy Java platform and in any future frontend, whatever framework it used.
Why web components. A framework-specific library would have locked Tecsys into a choice the team wasn’t ready to make, and couldn’t be dropped into the Java views. Web components work anywhere the browser does.
Stencil, then Lit. I started with Stencil. Over time it proved too opinionated and sometimes restrictive, so I moved the library to Lit, which is lightweight and close to native JavaScript.
Built to shrink. Lit was also a long-term bet: as native web component standards mature, the library layer gets thinner, not heavier. That kept the system maintainable for a team with limited frontend depth.
Vue for the first product
The first real opportunity came from the WMS team: a new interface for warehouse package receivers. The platform’s table-based UI couldn’t support the experience they needed, so the app ran as a custom view inside the platform, bypassing those limits.
Chosen for the team, not the benchmark. I picked Vue.js because it adds the least on top of plain JavaScript, which the team was still learning, and its flexibility fit a restrictive platform. I accepted its lighter structure and made up for it with the component library and conventions.
I handled almost all of the development, with platform experts wiring up the data the app needed.
Designing without a designer
Tecsys had no designer, so I took on the UX and UI work myself. I learned Figma, which was still fairly new at the time, and produced the wireframes, UI design and interactive prototype. With no access to end users, I validated designs in review sessions with internal domain experts.
Built for the warehouse floor. Receivers used the app at a desk and on older mobile devices with built-in hardware scanners, so the UI had to adapt to their input methods, not just their smaller screens.
Every scan, every time. Receivers scanned packages back to back without touching the screen, so the app had to capture every scan whatever was on screen. Focus management became a core requirement.
The turning point. The app shipped and proved the new approach worked inside the platform. We never got field data, but it created real excitement internally. It also showed the limit: one person pushing the boundaries doesn’t change a company.
Building a UX function
A new manager joined with the goal of making UX part of Tecsys culture, and together we built the team from zero.
Shaping the vision. I worked side by side with him, often in person, to define what the UX team should be and how it would work with engineering.
Hiring. We searched for and hired the first UX designer, then a UI designer.
Levelling up. While we recruited, I deepened my UX practice: online training, design and prototyping tools, design sprint workshops, and design systems.
Selling and building the design system
By then I was convinced that a design system was the right UI foundation for the kind of product Tecsys offered.
I pitched it first to the new UX team, so design would own it with me rather than receive it. We then ran workshop days with senior leadership, including the VP and the technical architect, each covering a different topic: the UX team’s composition, the UI and technical value of a design system, how we chose the JavaScript framework, and why testing with real end users matters.
With buy-in secured, I partnered with the UI designer to build it, connecting Figma design decisions to tokens and the Lit component library.
Tokens: start simple. As our first system, the tokens were a single primitive layer, with no semantic layer and no theming yet. Theming was on the roadmap.
Scaling beyond one developer
A new external application, outside the main platform, raised the stakes. The system now had to support people other than me.
Growing the team. I recruited new frontend developers and coached them.
Enabling an agency. An external agency joined the project. I acted as their technical enabler, supporting them on our architecture and the design system.
Opening up the data. I worked with the platform team to introduce REST APIs so the external app could get the data it needed.
Evolving the system. Throughout, I kept improving the tokens and component library so every team could build UI faster.
04Outcome and adoption
By the end, the design system was a shared foundation across three products, with about 30 components and over 100 tokens, distributed as a versioned npm package and documented in an internal portal built with the system itself.
Adoption at each team’s pace. One app was built entirely on the system. The other two adopted it incrementally, replacing legacy UI with system components whenever an opportunity came up. Because it shipped as a versioned package, each team upgraded only when it was ready, so adoption never blocked delivery.
Governance: a hybrid model. The UX team owned the design system, while product teams could request changes or contribute directly through pull requests. In practice, most teams weren’t yet comfortable contributing regularly, so ownership stayed concentrated in the core team.
From one person to a team of nine. By the end, the UX team had a UX manager, a UX lead, two UX designers, two UI designers, two frontend developers, and me as frontend tech lead.
Changing the culture, one wall at a time. Teams resisted change and didn’t yet see the value of UX and UI. It took patience, repeated exposure, and picking the right opportunities. Over time, understanding grew, and some teams began asking us to get involved and improve their experiences.
05What I’d do differently
Most of my lessons are about getting closer to the people around the product: the teams who build it, and the users it’s built for.
Grow champions inside strategic teams early.
In a backend-first company, a central owner and open pull requests weren’t enough. Engineers who had seen the benefits firsthand could have made the case to their peers, in their own context and language.
Fight for access to end users.
They’re who we build the apps for. I designed for the warehouse floor without ever seeing it, and internal experts can’t fully stand in for the people doing the work.
Learn the platform from the inside.
A deeper understanding of how the Java platform worked under the hood would have let me drive change from within, and talk the same language as the platform developers.