At Wolt, verifying analytics (telemetry) events in development was slow and cumbersome. Engineers relied on a full-screen in-app viewer with no search or filtering, which made instrumentation harder to trust.

The problem

This made it difficult for engineers and product teams to:

• validate new events
• debug issues
• confidently ship and evaluate instrumented features

Approach

I designed and built a telemetry viewer that streams events from the app to a local desktop client. The goal was not just a nicer viewer. It was a small leverage system for shortening the loop between product intent, instrumentation, and release confidence.

Key elements:

• local WebSocket-based streaming from the iOS app
• a desktop app with searchable, filterable event views
• full visibility into payloads sent to backend systems, in a form humans could inspect quickly

I introduced it gradually:

• first validating it with a small group of engineers
• then expanding usage through demos and internal sharing

I also supported cross-platform adoption by helping an Android engineer implement a similar solution.

Outcome

• Significantly improved speed and confidence when validating telemetry
• Adopted by multiple engineers across teams
• Enabled other initiatives, including privacy-related telemetry work

My role

Self-driven initiative that I discovered a need for and developed from concept to adoption across teams.

Wolt+ offered free delivery within a defined radius, but users outside that range saw limited benefit, reducing the product's appeal in certain markets.

The problem

We needed to extend the value of Wolt+ to users just outside the free delivery range by introducing discounted delivery, while keeping the experience consistent across discovery, venue pages, and checkout.

Approach

As client DRI, I led the iOS implementation and contributed to the overall API and product design.

Key areas I focused on:

• aligning frontend and backend on how delivery pricing and eligibility should be represented across surfaces
• working with the Discovery team to ensure consistent behavior across all venue lists
• designing a reusable bottom sheet for explaining delivery pricing and savings

I also led discussions around API structure and naming, coordinating across teams to reach a solution that worked for both backend and client constraints.

Outcome

• Strong positive impact in A/B tests
• Increased perceived value of Wolt+ in markets outside the core delivery radius
• Feature successfully rolled out across multiple surfaces in the app

My role

DRI, leading client-side implementation, RFC contributions, and cross-team coordination.

Wolt+ is Wolt’s subscription product, similar to Uber One or DashPass. A key growth lever is how and when users are prompted to subscribe during the ordering flow.

The problem

Subscription entry points were limited and required users to leave the order flow. We wanted to introduce new surfaces in cart and checkout, along with a faster “express” signup experience, but the initial plan bundled everything into a single release, increasing complexity and delaying validation.

Approach

I acted as client-side DRI across iOS, Web, and Android, driving RFCs and alignment with product, design, backend, and data science, while leading iOS implementation.

Early on, I pushed to split the work into independent experiments:

• launch and validate the cart entry point first
• follow with express signup as a separate iteration

This allowed us to ship sooner and learn faster instead of blocking on a more complex implementation.

For express signup, I worked through several UX and technical constraints:

• enabling multi-step flows inside a bottom sheet (not previously supported)
• simplifying transitions between “express” and full signup to reduce confusion
• coordinating with payments and backend teams on edge cases

I also worked closely with data science to validate instrumentation and debug misleading A/B test results, ensuring we were measuring the right signals.

Outcome

• Significant lift in Wolt+ signups and downstream order volume
• Both features successfully A/B tested and fully rolled out
• Cart entry point remains a core subscription growth surface

My role

Client-side DRI across iOS, Web, and Android, leading RFCs, stakeholder alignment, and experimentation strategy, with hands-on iOS implementation.

SmartNews renders millions of articles through its SmartView system. The existing extraction pipeline had accumulated technical debt and inconsistencies across publishers.

Replacing it outright was too risky. Any regression would directly impact content readability and user trust.

The problem

We needed to:

• introduce a new extraction pipeline
• improve HTML parsing and formatting reliability
• integrate with backend-driven rules (CSS, transformations)
• avoid breaking the existing rendering experience

All without disrupting a core product surface.

Approach

I built SmartHTMLExtractorV2 as a parallel implementation:

• Created a new Swift module (SmartHTML) wrapping SwiftSoup with a stable internal API
• Implemented a new extractor pipeline with:
  • HTML parsing and cleanup
  • CSS rule integration from backend services
  • structured formatting via internal models
• Introduced client-condition gating so v1 and v2 could coexist safely

To reduce operational risk:

• Added fallback logic (stage/prod URLs if client conditions failed)
• Ensured edition-aware proxying (US vs JP behavior)
• Handled iOS-version-specific behavior (e.g. image format selection like JPEG vs WebP)

Outcome

• Successfully shipped a parallel rendering system without regressions to the core experience
• Enabled incremental rollout and validation instead of a risky full switch
• Established a clean Swift-based foundation for future rendering improvements

What this demonstrates

• Designing safe rollouts for high-risk, high-impact systems
• Wrapping third-party libraries into stable internal abstractions
• Building modular architecture inside a legacy mixed Obj-C/Swift codebase
• Thinking beyond implementation, including operational safety and fallback behavior

SmartNews plays a major role in delivering election coverage. For the 2020 US election, the product included features aimed at presenting balanced perspectives across political content.

The timeline was fixed. Everything had to be ready for election day.

The problem

We needed to:

• present content from multiple political perspectives clearly
• build new UI patterns (not just reuse existing ones)
• support real-time election results
• handle US/JP edition differences correctly

Approach

I worked across several election-related features:

Political balancing experience

• Built a News Event view with a custom UISlider:
  • 3- or 5-position support for perspective selection
• Added onboarding, deep links, and action logging
• Enabled “News from all sides” entry points across surfaces

Candidate and results features

• Implemented:
  • candidate widgets and lists
  • election results widget with time-based visibility
• Added:
  • timestamp gating (start/end times)
  • edition-aware language rules (e.g. JP edition shows Japanese regardless of system locale)

Infrastructure

• Built API integrations with fallback behavior
• Used client conditions for controlled rollout
• Ensured telemetry coverage across interactions

Outcome

• Delivered multiple election features on a fixed deadline
• Enabled users to explore balanced political perspectives
• Handled complex requirements around time, localization, and data availability

What this demonstrates

• Shipping under non-negotiable deadlines
• Building custom UI for sensitive product areas
• Handling multi-edition, multi-locale product logic
• Delivering across multiple surfaces with consistent behavior