I build the frontend platform other teams ship on.

A design system five squads actually adopted

One of the initiating engineers on the company design system, from the token layer up to the components now running across internal and customer-facing apps.

The problem

Flights, hotels, trains and events each carried their own buttons, date pickers and form patterns. Every new surface restarted the same interface decisions, and the drift between squads was permanent rather than occasional.

What I did

• Settled the token layer first — colour, type and spacing as the contract — so components had something stable to compose against.
• Designed the component API surface before writing components, treating it as a public interface that would be expensive to change later.
• Documented everything in Storybook with strict typing and visual regression, so adoption did not depend on me being in the room to explain it.
• Ran the migration alongside product delivery rather than asking for a freeze, which meant accepting a long tail of legacy patterns.

Where it landed

Reusable components adopted across multiple internal and customer-facing applications. New surfaces now start from the system instead of from scratch.

• React
• TypeScript
• Storybook
• SCSS

Letting five teams deploy without a release train

A micro-frontend architecture on Webpack Module Federation, drawn around product domains rather than technical layers.

The problem

A single frontend deployment coupled every team to the same release. One squad running late held everyone else back, and the cost of that coordination grew with each team added.

What I did

• Split on product domain boundaries rather than technical layers, so a team owns a whole user journey instead of a slice of the stack.
• Built a shared shell that owns routing, auth and the design system runtime, keeping the seams invisible to users.
• Pinned and shared the heavy dependencies so five independently built bundles do not ship five copies of React.
• Accepted a slightly larger total payload in exchange for release independence, then put a performance budget in CI to keep that trade honest.

Where it landed

Five product teams build, version and release their areas of the app independently.

• Webpack 5
• Module Federation
• React
• Next.js
• Docker

Taking roughly 40% off load time on a booking funnel

Platform-wide performance work on a flow that is data heavy by nature and mostly used on mid-range Android over mobile data.

The problem

Travel search is expensive: large result sets, third-party scripts, and a funnel where every extra second costs conversion. The slow paths were spread across the platform rather than concentrated in one bad page.

What I did

• Server-rendered what mattered above the fold and deferred the rest, so the funnel became useful before it became complete.
• Split bundles at the route level and lazy loaded everything below the fold.
• Audited the bundle for duplicated and oversized dependencies, which is usually where the easy weight hides.
• Tracked Core Web Vitals in the field rather than lab scores, because the lab never sees a mid-range phone on a bad connection.

Where it landed

Around 40% reduction in page load time, with Core Web Vitals improving across the platform.

• Next.js
• Webpack
• React

LRT Jabodebek Route & Schedule

A web app for checking the next LRT Jabodebek departure, plus full schedules, routes and fares. Built because working out when the next train actually leaves was harder than it needed to be. Small, fast, and the one piece of my work anyone can open.

• Next.js
• TypeScript
• Tailwind CSS