A mistake in Histoline, an idea for the board, a thought about the site. No name needed.

About This site Something else Message Name optional Email or handle optional, if you would like a reply

Website

Send →

My Role

Product Lead

• Cross-Functional Collaboration: Worked with 2 Designers, 6 Engineers, and 1 Data Analyst
• Roadmapping & Vision: Established and maintained the consumer-facing app product roadmap, aligning priorities with overall business objectives, and guiding feature development
• User Research & Validation: Led user interviews and testing
• Stakeholder Alignment: Communicated strategy and progress across departments and executive teams
• Release Management: Planned releases from concept to launch; managing sprints and collaborating cross-departments
• Data-Driven Experimentation: Setup and trained data analytics team. Defined key metrics and dashboards to measure outcomes. Leveraged insights for continuous improvement

Growth & Marketing Lead

• Team Leadership: Managed a growth squad of 3 and marketing team of 6, setting goals and processes for initiatives
• Growth & Marketing Strategy: Led growth and marketing strategies focused on user acquisition and retention
• Data-Informed Experimentation: Established a culture of rapid, data-informed testing
• Managed Rebrand: Led collaboration with an external agency to manage Plum's rebranding

Championed Vision Company-wide

• Evangelized "critic-rated meals delivered daily," ensuring alignment company-wide across teams including logistics, menu selection and marketing
• Conducted company-wide workshops and interdepartmental strategy sessions
• Authored the company culture handbook, codifying values and aligning them with key business drivers

Context

Plum, a nascent 3-month old, 30-person company, aimed to disrupt the food delivery landscape in Hong Kong, a market dominated by well-established players like Food Panda and Deliveroo. The founder's vision involved delivering a daily rotating menu of five dishes from a variety of restaurants around the city to working professionals in key business districts.

Main Challenge

Despite the initial strategy of acquiring users by offering free meals, Plum struggled to convert users into paying customers. At peak, the team had 1,000 unpaid daily orders and negligible paid orders.

What I Did

#1 Crack product-market fit

Recognizing the local foodie culture's preference for exclusive and high-quality meals, I proposed a pivot towards a gourmet-focused value proposition. This involved sourcing critic-rated dishes, which differentiated Plum from competitors.

We tested this idea by changing the messaging on our flyers and immediately saw an increase in paid orders. Following this success, we modified our meal sourcing strategy to focus on critic-rated dishes.

Within 2 months, Plum achieved product-market fit, scaling from 1,000 daily unpaid orders at peak to 10,000 daily paid orders and boosting retention from a stagnated 17% to 46%.

#2 Ensure strategic vision is executed company-wide

Executing on the strategic vision of "critic-rated meals delivered daily" required coordination across the entire organization, from menu selection to product development to operations.

To ensure company-wide alignment, I regularly organized workshops and departmental strategy sessions.

For example, I led our menu selection team in developing a data-driven methodology that guided dish selection in support of specific business goals such as acquisition, retention, and branding. I also created a company culture handbook, which helped both new and existing employees embody our values and deliver on our promise at every touchpoint, from delivery to customer service.

#3 Product development, growth and branding

As product and growth lead, as well as advisor to the marketing team, I mentored team members and ran weekly strategy review meetings.

Key product initiatives:

• Collaborating with design and engineering on development of mobile app
• Labelling Michelin-recommended dishes with Michelin logo, resulting in 237% increase in orders
• Conceived and championed a menu selection strategy, driving over 11.8% month-over-month growth in orders
• Became the first food delivery app in Hong Kong to implement a feature allowing users to select their desired tip amount and opt out of receiving cutlery
• Set up and trained first data analytics team member, guiding team on which metrics to track and how. Defined company OKRs and analytics dashboard. Created retention cohort charts.

Key growth initiatives:

• Loyalty program
• Referrals program
• Daily notifications to place orders
• Notifications for wishlisted items

Additionally, I managed Plum's rebrand in partnership with an external agency.

Overview

Led research and discovery for a global luxury retailer seeking operational efficiency improvements post-COVID-19, uncovering 18 innovation opportunities.

WhatsApp for Business

Associates estimated saving roughly 60–90 mins a week on manual note-taking and organization. The solution centralized client conversations with features like labels and internal notes. Status: added to development roadmap.

Digital Queue Ticketing

Prototyping revealed potential for a 40–50% cut in median wait time, from ~60 min to ~35 min. Predicted 10–15% improvement in customer satisfaction. Status: added to roadmap.

Centralized Product Styling Hub

Testing showed styling resources usage increased from 60% to 80% of interactions, with location time dropping from ~6 mins to ~3 mins. Associates gained better product knowledge access.

System Integration

Workflow analysis identified staff spending about 3.5 hours per week on duplicate data entry and error correction. Integration projected to reduce this by ~57%, to around 1.5 hours per week, plus 10–25% revenue uplift potential.

Employee Feedback Platform

A 2-week pilot produced 22 actionable issues versus historical 5–7 monthly. Staff reduced reporting time from 1-hour weekly meetings to just 5–10 minutes per person per week.

Predictive Personalization

Research showed 80% customer interest in personalized recommendations. Recommendation was escalated to headquarters for evaluation.

Challenge

The client team faced a high volume of feature requests from other departments and had difficulty prioritizing these alongside their own initiatives. They also struggled with rationalizing their prioritization decisions and quantifying their impacts for management.

What I Did

Phase 1: Research

• Led stakeholder interviews and cross-functional workshops to map pain points and define success metrics
• Conducted job shadowing to document as-is workflows and bottlenecks
• Key Insight: 60% of "urgent" requests lacked measurable outcomes or conflicted with annual OKRs

Phase 2: Framework Design

• Architected a RICE-based prioritization framework that measured impact based on strategic team and organizational goals

Phase 3: Operationalization

• Trained 11 analysts in hypothesis development and A/B test design, standardizing experimentation practices
• Implemented and facilitated bi-weekly standups, bi-monthly triages, and quarterly sessions for ideation workshops, roadmap reviews, and retrospectives to compare projected versus actual outcomes for continuous refinement
• Built lightweight tracking via automated Jira scoring

Overview

Collaborito is an AI-enabled platform that connects individuals with shared interests to collaborate on passion projects. Backed by the Hong Kong Science and Technology Parks (HKSTP), it currently has 263 registered users with 21% WAU.

My Role

• Team Building: Recruited a full-stack AI engineer from Nvidia as CTO, plus a UI/UX designer and two software engineering interns
• Strategic Direction: Established product vision, business model, and roadmap
• Fundraising: Created investor-facing pitch deck and financial projections
• Product Design: Led product design with iterative user feedback sessions
• Go-to-Market: Planned and executed go-to-market strategy with zero marketing spend

Key Design Decisions

Avatar Size

Smaller avatars prioritize text-based user information (skills, roles) over profile pictures.

Information Architecture

Users took 57% less time to read text presented in bordered text boxes versus continuous blocks, with a 33% increase in testers describing the layout as straightforward and easy to navigate.

Color Strategy

Multi-color profile cards enhance engagement and help users distinguish individual contributors in the text-heavy interface.

Content Prioritization

Deprioritized user-generated content and newsfeed features to focus on core matching functionality given the small initial user base.

Opportunity

Private equity due diligence is a manual, time-consuming and inefficient process that can take around three analysts one to two months to perform depending on the deal size.

My Role

• Established lean startup methodology
• Conducted 5 interviews with PE analysts and 5 with executives
• Analyzed competing AI due diligence tools
• Designed product
• Prompt engineering for LLM accuracy

Key Design Decisions

Navigation

Top navigation preferred (vs. sidebar) to dedicate sidebar to deal-related navigation.

Chatbot Placement

Pop-up chat window for analysts; standalone tab for executives — reflecting the different depth of interaction each role needs.

Overview

Estel is an AI-powered relationship communication coach app.

My Role

• Defined product vision and business strategy
• Developed pitch deck
• Led product design

Status

Customer development interviews with therapists in-progress.

Watch the demo on YouTube →

GoodFinds turns restaurant recommendations from people you trust – influencers, guides, chefs and friends – into a live map.

Open GoodFinds →

The problem

I kept losing good recommendations in screenshots and group chats, and a star average never says who is behind it or why. GoodFinds pulls the places out of wherever you saved them – an article, a list, a screenshot, or a bulk export of your Instagram saves – matches each one to its real listing, and ranks what you've actually been to by comparing it against your other visits, never by typing a number.

Key decisions

Ranked, not rated

Logging a place asks for a verdict first – loved it, it was fine, not for me – then one or two "which did you prefer" comparisons against your other visits in that same bucket and cuisine, which places it into one ordered list. I rejected a five-star or ten-point score: absolute numbers cluster near the top no matter who is scoring, don't compare from one person to the next, and force a verdict when comparing two places is what people are actually reliable at.

A curator layer instead of a smarter score

Rather than blend outside ratings into one algorithmic number, GoodFinds makes the people behind a recommendation followable: publications like Michelin and Time Out, and food creators like Fork Lore and Uncle K, whose picks filter the map as a layer and carry their own words on the place card. I chose this over a single blended score because a named opinion is legible in a way an algorithm's output isn't, and it works before anyone has rated anything – the exact problem an empty app has on day one.

Import-led discovery, not manual search-and-add

You paste a link, hand over a screenshot, or import your Instagram saves in bulk, and GoodFinds pulls the place names out, matches each to its real Google listing, and waits for you to confirm before anything is added. I rejected a search-and-add-only flow because recommendations already live in screenshots and group chats, not in a search bar people remember to open.

One global catalogue, no Hong Kong default

GoodFinds launched Hong Kong first, and for a while the map's opening view, the search backend and even onboarding quietly assumed everyone was there. The catalogue had already outgrown that – it holds places across Hong Kong, the US, Europe and East and Southeast Asia – so I removed the Hong Kong default everywhere it hid: place search now falls back to a user's own home market or current location rather than one city, and the map opens on wherever someone actually lives. Hong Kong's coordinates load only for someone whose home market is Hong Kong.

What I learned

An aggregate score that blends Google's rating, Michelin and GoodFinds' own ratings into one number is designed but not shipped – the map still sorts by Google's rating, labelled plainly as Google's, until enough of the app's own ratings exist for a blended number to mean anything different from it. I also don't yet track whether someone opens a curator's layer or just scrolls past it. Both are next, before another city or curator.

Someone posts an outfit and I want the actual jacket, not something close enough. Acquisitions is the app I built so a screenshot can shop itself.

Open Acquisitions →

The problem

Outfits show up in feeds with no way to buy them, short of scrolling comments hoping someone named the brand. Acquisitions is a mobile-first social shopping app: follow tastemakers, scroll their outfit posts, and search by photo or text for the exact piece, or an affordable alternative. It started under the name Fitted. Underneath: Groq's llama-4-scout reads a photo's category, SigLIP2 embeds it, and Postgres with pgvector finds the closest match by cosine similarity.

Key decisions

Text search hits Postgres before it reaches the GPU

Most searches are typed words, not photos, so those run through Postgres full-text search first. Modal, the GPU service behind the embeddings, is only called for image searches. Routing every query through Modal instead would mean a GPU call for what a keyword index answers just as well.

Tap the garment instead of cropping it yourself

The app detects the separate garments in a photo and lets you tap the one you mean, instead of drawing a crop box. A free crop let people catch an extra item, like a worn bag, which threw off the search.

An explicit "Find similar" button, not a hidden gesture

An earlier version searched from a long-press on a feed product and let you toggle straight from browsing into buying. Both were dropped: a visible button is clearer than a hidden gesture, and the buy toggle competed with the wardrobe feature it was meant to shortcut.

The zero-shot category router got rolled back

I tried letting SigLIP pick a query's category on its own, with no separate classifier call. It scored no better than the version it replaced, and failed silently whenever the vision call it still depended on timed out. Search now runs on Groq's category call plus a k-nearest-neighbours consensus, which degrades instead of breaking.

Cut Modal's idle window, not its accuracy

Modal billed for a model sitting warm between requests. Instead of shrinking the embeddings, I cut how long the GPU stays warm from ten minutes to three, with a light ping to stop it cooling: same model, same accuracy, less idle cost.

What I learned

The decisions worth keeping were about cost and failure: idle time, a fallback for when a model times out, a router that looked cleverer but scored no better. AI coding tools wrote much of the code; deciding what to cut, and what still had to work when a model failed, was mine.

I wanted to write for different audiences from one account, so posts in Homeweb file into journals instead of one shared feed.

Open the demo →

The problem

Most social apps give you one feed and one audience. Homeweb is a mobile-first journaling app: you write posts and file them into journals, themed collections that each carry their own privacy, so what you write for close friends never sits next to what is public. Discovery works by topic, not an engagement feed.

Key decisions

Privacy set per journal, not per post

Every post belongs to at least one journal, and the journal, not the post, carries the privacy: private, followers or public. The alternative was a per-post toggle, more flexible but meaning a decision on every single post. Setting privacy once, on the journal, means everything filed there inherits it.

Journals capped at 20, with a tunable escape hatch

Accounts hold up to 20 journals. The alternative, no limit, is what the README still promises, but a shorter list is easier to actually keep organised. The cap is a constant rather than a rule fixed in the schema, and setting it to zero switches the limit off, so it can change later without a migration.

AI features shipped as heuristic placeholders

Tag suggestions, query understanding, moderation and result re-ranking all run on keyword maps, stopword lists and regex behind feature flags, each commented with the real model it stands in for. The alternative was waiting to wire up an actual model before shipping any of it. The choice was to ship the interface now and swap the heuristic for a model later; moderation is built the same way, but its flag is switched off. The one feature calling a real model is embeddings, OpenAI's text-embedding-3-small stored with pgvector, behind semantic search.

The "For You" feed as arithmetic, not a model

Ranking is recency half-life, engagement and tag overlap added into a score, not a trained model. Homeweb's own line is follow topics, not algorithms, and an explicit formula keeps that literal: you can see why a post ranks where it does, rather than trust a model's read of you.

What I learned

The README says Next.js 16 and unlimited journals; the code runs on 14.2.35 with a cap of 20. Both are true in their own way, one records an intention and the other what shipped, but the gap only shows up if someone reads both. Writing quickly with AI tools makes it easy to generate a doc that matches the plan rather than the code it is describing. The habit I am carrying forward is checking documentation against the running code before calling something done.

History is taught one civilization at a time, so the question I always had, what else was happening right then, never had an answer on one page.

Open Histoline →

The problem

Every history book I have read runs down one lane. Ming China, then the Ottomans, then the Renaissance, each in its own chapter, each with its own dates. Nothing tells you that Michelangelo was painting the Sistine Chapel while Henry VIII was breaking with Rome and Ming China was banning sea trade to keep pirates, and the newly arrived Portuguese, off its coast. The timelines I found show either too many events or too few, cannot zoom to the level of detail I want, and are not something you can ask a question of.

What I wanted: pin any year and see what every part of the world was doing at that moment, at a high level first, with the detail one zoom away.

Key decisions

Trust is the product, so check everything against an outside source

A timeline that is mostly right is worse than useless, because you cannot tell which parts to believe. Once the range grew to 3500 BC through 2026, I had every dated item cross-checked against Wikidata's structured records. For the original eleven lanes, 981 empires, reigns, wars, eras, people and events found a match. About 700 agreed within Wikidata's own stated precision. Twelve were corrected. Forty-eight differ only by which standard periodisation you prefer, such as whether the Roman Empire ends in 395 or 476, and those stay as they are with the reasoning noted. The lanes added later went through the same pass on arrival.

The numbers are published on the page itself, in the About panel. That was deliberate. If you are asking people to trust a history site made with AI, the audit has to be visible, not claimed.

An importance budget, not an importance score

Showing everything at once is unreadable, so every event is ranked 1, 2 or 3: a landmark that bent its civilization, something significant to that lane's story, or texture like daily life and curiosities. The trick is that rankings are relative to each lane, with a budget per lane per era. Without that, Rome and Greece would flood the screen and West Africa would vanish. Zoom in and the lower tiers appear.

Contested history is named in each community's own terms

Where two communities remember the same event differently, both names appear. 1948 is shown as both Israel's Declaration of Independence and the Nakba. Characterisations that are disputed are attributed rather than asserted, and casualty figures use scholarly ranges.

Strips for what no single region owns

A World strip carries what no single region owns, such as technologies, diseases and trade networks that crossed continents, and an Empires strip shows polities that genuinely begin and end, from the Akkadian Empire to the Soviet Union. Select one and every region it never reached dims.

A second view where thickness means people

The Streams view draws each region as a ribbon whose thickness follows population estimates from McEvedy and Jones and from HYDE, scaled by square root so small regions stay legible. It is a claim about relative size, and it is labelled as one.

What I learned

Building it took a weekend. Making it trustworthy took far longer, and that was the real work. The generation step is now cheap; the checking step is what turns a demo into something you might show a teacher.

I have no historians in my network, so the only thing that has checked the AI's work so far is AI. If you know the field and spot something wrong, tell me through the feedback form.

Next are the Prehistory and True Scale views, and a proper mobile treatment, since on a phone the timeline currently shows markers rather than labels.

I am not a historian and have no training in the field. Working with AI still let me build a timeline that may be close to accurate, which says something about what one person can now take on outside their own field.

I had more ideas than I could build and no honest way to see which ones deserved a weekend. So I built the board first.

Open the board →

The problem

My hobby is turning small annoyances into things I can use: an app that finds where chefs actually eat, a timeline that answers what else was happening in 1492.

I built this board while taking one idea, GoodFinds, through the slow work of finding customers and product-market fit. With AI, building got cheap, so the list of things I could make got long, from a reminder that reads my inbox before a subscription renews to a language app that retells a story you already know. It grew faster than I could ship, and I had no way to decide what came next.

What it is

A kanban with six lanes, from Ideas through Up next, Building, Built, Demo recorded and Posted. Every card carries three ratings out of five, for how good it is, who it helps and how easy it is to copy, plus a separate rating for how well AI can build it, with the hardest part named in one line. Behind each card is a five-part case study: the problem and the evidence for it, the scope, the key design choice, the results or the metrics I would watch, and what I learned.

Key decisions

One address, two boards

Visitors and I go to the same link. The site checks for a sign-in and quietly serves a different page: visitors get the board with every card visible; I get the same board with every card and its priority editable.

No database. The repository is the store.

The obvious build was a database with an admin login. Instead, the board is generated from one file in a repository, and pressing Publish commits my edits back into that file. The site rebuilds itself a minute later. That gives me a full history of every change, nothing new to pay for or maintain, and one source of truth. The trade is a minute of delay between saving and seeing it live, which is fine for a board that changes a few times a week.

Drafts you edit, not boxes you fill

A draft to correct is far easier to finish than an empty field. Five fixed sections make sure every idea is checked against the same questions: is it useful to me and to others, and is it worth building.

It looks like the rest of my site

The board uses the same blush ground, the same single red and the same serif pairing as rubytang.com, rather than a dashboard look. It is a portfolio page that happens to be a working tool, and it should read that way.

Claude reads the board, writes to it, and builds from it

The plan, not yet run: everything is planned in the card. When I am ready, Claude builds it from the card, we iterate until I am happy, then it drafts the write-up for this site and a post about it.