Left Side Escalator (電扶梯走左邊) is a Taiwanese personal-growth podcast focused on helping listeners step outside their comfort zones and become better versions of themselves. Its Discord community brings together listeners who want to exchange ideas, take action, and connect with people who share similar values.

After noticing that members had no easy way to find people with similar interests, I proactively proposed, designed, and built an AI matchmaking bot for the community.

A member simply tags @AI Matchmaker and writes a request such as:

“I’m looking for friends who like yoga.”

The bot interprets the request, searches the community’s member data, and returns relevant matches within seconds.

Built independently with Discord.js, OpenAI GPT-4o, Node.js, and Express, the bot went from proposal in December 2024 to public launch in February 2025.

What Problem Did I Solve?​

As the community grew, finding people with similar interests required members to search introduction posts manually or ask an administrator for help.

I turned this manual process into a self-service experience: members can describe who they want to meet in natural language and receive relevant matches within seconds.

Who Uses It?​

The bot launched publicly in the Left Side Escalator (電扶梯走左邊) Discord community on February 20, 2025. Members can tag @AI Matchmaker and type a natural-language request to find people with shared interests or birthdays. Usage logs show that members continued to use the bot for matchmaking through at least June 2025, with queries ranging from yoga and hiking to psychology.

Results​

• Replaced manual searching and admin-assisted matching with a one-sentence query.
• Reduced the barrier to starting conversations with like-minded members.
• Continued receiving real community usage for months after launch.

What key decisions did you own?​

1. Splitting the architecture into three layers. I deliberately split the system into a Discord bot (interaction layer), an Express API (data layer), and OpenAI (natural-language-to-query translation layer), instead of putting all logic inside the bot — so the data service could be deployed and verified independently.
2. Using the LLM as a query compiler, not a semantic search engine. I skipped embeddings and a vector database, and instead wrote a strict system prompt (openaiSystemMessage.js) that constrains GPT-4o to translate user input into exactly two fixed API path formats (/find?birthday= or /find?hobbies=). Few-shot examples in the prompt hard-code date-format handling (Chinese/English) and interest-synonym expansion (e.g. "爬山" expands to a dozen-plus synonyms like "登山, 百岳, 爬百岳...") to keep match rates high.
3. Choosing CSV over a database for storage. Given the member count and low update frequency, I used a CSV file as the MVP data source (csvLoader.js loads it into memory once on startup) — deliberately skipping a database and an admin UI, to put engineering effort into query quality instead.
4. API security. The Express server has a Bearer-token authMiddleware, so member data can't be accessed without authorization or scraped externally.
5. Discord embed pagination. I wrote generateEmbeds.js to handle Discord's three hard embed limits (field length, total embed length, field count), so a result set with many matches automatically splits across embeds instead of erroring out (full discussion below).
6. Operational trade-offs. Since the bot was expected to run on a memory-constrained free tier (Render, 512MB), I added scheduled GC cleanup and a /healthz health-check endpoint for UptimeRobot to hit, so the bot wouldn't get marked offline due to idling or cold starts.

What constraints did you face, and how did you trade off?​

• Match accuracy depends entirely on prompt quality. Because interest matching on the Express side is a simple string.includes(), not semantic search, all the "fuzzy matching" capability comes from the synonym lists hand-written into the OpenAI system prompt. That means adding a new interest category requires manually extending the synonym list — a known, accepted maintenance cost, since the community's interest categories are limited and this is far cheaper than adding vector search.

• Data updates are a manual process. When a new member joins, their data has to be manually added to data.csv and the service restarted. This is called out explicitly as a known limitation in the proposal deck ("Update database (CSV) manually if there are new friends"). The trade-off: the community doesn't grow fast enough to justify building an admin CMS for this.

• Discord's message-format limits (not fully solved). Discord embeds stack four hard limits — a single field's content ≤1024 characters, a single embed's total content ≤6000 characters, a max of 25 fields per embed, and a max of 10 embeds per message. generateEmbeds.js handles the first three (content over 1024 characters auto-splits into a new field marked (cont.); content over 6000 characters or more than 25 fields opens a new EmbedBuilder) — but not the fourth. The current implementation sends every embed transformDiscordEmbed() produces in a single message.edit({ embeds: transformDiscordEmbedResult }) call (see index.js). There's a commented-out earlier implementation still in the code that sent each embed as its own message (message.channel.send({ content: '<@...>', embeds: [embed] })), which would have sidestepped the 10-embed limit — but it flooded the channel and hurt the experience, so I switched to a single combined reply. This is a known, unresolved trade-off: it buys a clean single reply, at the cost that a query matching enough people (roughly 10+ embeds' worth) would theoretically get rejected outright by the Discord API — there's currently no guard or graceful degradation for that case.

• Free/low-cost deployment trade-offs. The proposal stage compared Vercel (cold starts), Zeabur (starting at $5/month), and AWS, and ultimately went with a free/low-cost tier constrained to 512MB of memory — which is why memory monitoring and manual GC exist, in exchange for zero or near-zero hosting cost.

• Deliberately narrow query scope. The bot only supports two query dimensions — birthday and interests — rather than open-ended full-text search, so that OpenAI's output format stays constrained and verifiable, avoiding natural-language translations that don't fit the API format.

• Cost is controlled but not built for future scale. GPT-4o usage cost ($2.50 / $10 per 1M tokens) is acceptable at the community's current size, so there's no caching or local embedding model. If usage grows significantly, the current architecture would need to be re-evaluated.

Other Notes​

This project went from an architecture proposal deck on 2024-12-29, to a public launch for the full community on 2025-02-20, to real, stable usage logs at least through 2025-06-02 — spanning roughly six months of continuous production operation, which demonstrates a full design-build-deploy-operate delivery cycle, not just a POC. The code also defends against failure cases (if OpenAI or the API call fails, the bot replies "Error generating response, please try again later" instead of crashing), showing production robustness was considered as part of delivery.

QR Digital Pass is a cross-platform mobile application built with React Native, designed to streamline attendee registration and check-in for exhibitions, conferences, and events.

What problem did you solve?​

Event organizers needed a faster way to manage participant entry than manual check-in lists — one that could handle high attendee volume at the door, confirm identity quickly, and still leave organizers with usable data afterward. The app uses QR code scanning with image recognition to check attendees in, with automatic event-specific login and real-time sync of check-in data to a backend that stores it for statistical analysis.

Who actually uses it?​

Event staff, at the door of exhibitions, conferences, and events, scanning attendee QR codes to manage entry — and event organizers afterward, who use the synced check-in data and backend statistics for post-event review and future marketing strategy. The app is live on the App Store.

What results did it produce?​

Not yet documented here — worth adding concrete numbers if available: number of events run through the app, attendee volume handled, or check-in speed compared to manual entry.

What key decisions did you own?​

• Cross-platform via React Native — one codebase covers both iOS and Android, so check-in coverage at the door isn't limited by which platform an event's staff or attendees carry.
• QR scanning paired with image recognition — rather than a bare QR decode, check-in combines QR code scanning with image recognition to confirm entry, aimed at holding up under high attendee volume at the door.
• Automatic event-specific login — login is scoped to the event automatically instead of requiring staff to manually authenticate per event, cutting a step out of the door workflow.
• Real-time sync to backend storage — check-in data syncs live rather than batching afterward, and is persisted specifically so organizers get statistical analysis for post-event review and future marketing strategy, not just a raw attendance log.

What constraints did you face, and how did you trade off?​

Not yet documented here — e.g. constraints around scanning reliability at high attendee volume, offline/connectivity handling at venues, or backend design trade-offs for real-time sync.

Project Details​

Foxconn's telehealth platform covers three parts — a patient app, an NHI-compliant physician reporting system, and a bedside tablet for clinical vitals. My contribution was the patient-facing app, which I built independently end-to-end with React Native + Redux-saga over a six-month project.

What I solved?​

Patients had no self-service way to actually use telemedicine — book a doctor, join a video consultation, pay for it, link family members' accounts, and, for select consultations, share live vitals like blood oxygen without a separate clinical device. I independently built the patient app that covers all of that.

Who actually uses it?​

Patients, through the app — for doctor appointment booking, video consultations, third-party login and payment, linking family member accounts via QR code, and real-time Bluetooth blood-oxygen monitoring during select consultations.

What results did it produce?​

The app shipped and the project generated over 8M+ in revenue across its six-month build.

What key decisions did you own?​

As the sole developer on the patient app, I owned the full frontend implementation:

• Built the doctor appointment calendar UI.
• Integrated the Jitsi React Native SDK for video consultations, using polling to control when a consultation ends.
• Integrated third-party login (Facebook, Google, Apple), third-party payment, and QR-code scanning to link family member accounts.
• Used React.memo to cut unnecessary re-renders on the appointment list.
• Integrated a Bluetooth blood-oxygen meter via react-native-ble-manager for real-time readings during consultations.

What constraints did you face, and how did you trade off?​

Working solo meant integrating several third-party SDKs — Jitsi for video, BLE for the blood-oxygen meter, three OAuth providers, and payment — into one coherent app rather than splitting that surface across a team. Ending a video consultation reliably was a specific problem: rather than trust SDK event callbacks alone to signal call-end, I used polling as a more robust source of truth, trading a small amount of latency for reliability. On the appointment list, I addressed rendering performance with React.memo at the component level instead of a heavier state-management restructure, since it solved the actual bottleneck without touching the rest of the data layer.

Project Details​

Rybit is a fleet-management platform supporting 2M+ riders and 40,000+ devices. It helps delivery and shared e-bike operators manage vehicles, payments, tracking, maintenance, and IoT controls.

What I solved?​

Fleet operators lacked an end-to-end workflow connecting service tickets, asset status, outstanding fees, and repair charges. The asset-management flow also made redundant API requests during quota adjustments, while the existing codebase needed stronger typing and testing.

My Contribution​

• Built the B2B service-ticket and billing workflow with React and RTK Query.
• Fixed a redundant API request caused by Ant Design Form remounting, while preserving all legitimate refetch triggers. (see the full debugging write-up)
• Introduced strict TypeScript, Vitest, Playwright, and Storybook incrementally without disrupting feature delivery.
• Helped maintain the rider-facing mobile app.

Who actually uses it?​

Fleet operators (B2B partners across food delivery, courier, and shared e-bike operations) and Rybit's own internal ops team, through the web CMS — the admin backend the whole platform runs on. Riders use the companion app I help maintain. The platform overall runs 2M+ riders and 40,000+ devices, so anything shipped into the CMS or app is operating at that scale.

What results did it produce?​

• The B2B service-ticket system now runs the full ticket-to-billing flow end-to-end — asset-status tracking, outstanding-fee calculation, and the resulting repair charge — instead of requiring manual reconciliation across those steps.
• The redundant API call fix eliminated an unnecessary server request that fired on every quota adjustment while preserving the three legitimate triggers (drawer open, asset removal, asset ID edit) — verified with a before/after network trace.
• Code-quality tooling (strict TypeScript, Vitest + Playwright, shared Storybook catalog) is now part of the day-to-day workflow across the codebase.

Project Details​

This is a debugging write-up from my time at cacdi. We were integrating with a partner's ("Compal") API, and that API authenticated every request with a session cookie instead of a bearer token.

The backend already had Access-Control-Allow-Origin configured, so the frontend wasn't blocked by CORS on a plain request. But calling the API from localhost during local development, the browser never sent the cookie along — even though Postman, given the same cookie, could call the API and get a valid response back. So the credential itself was fine. The question was purely about when a browser is willing to attach a cookie to a cross-origin request.

The Setup​

1. The partner's API authenticates via cookie.
2. The backend already sets Access-Control-Allow-Origin, so the frontend isn't blocked by CORS.
3. Open question: how do we get a cookie attached when calling that API from localhost?
4. Postman, given the cookie manually, calls the API successfully and gets a result back.
5. The frontend needs to set credentials, and the backend needs Access-Control-Allow-Credentials — but that alone didn't explain what was happening in the browser.

To isolate the cookie behavior from the rest of the app, I reproduced it directly in DevTools: manually insert a cookie in the Application panel, then see whether an outgoing request to the partner's domain actually carries it.

Reproducing It in DevTools​

Attempt 1 — name & value only​

Insert just Name and Value, leaving Domain, Secure, and SameSite untouched. Result: the outgoing GET request still doesn't carry the cookie. With none of the attributes explicitly set, the browser doesn't consider it valid for a cross-site request.

Attempt 2 — add SameSite=None​

Set SameSite to None. Result: DevTools refuses to save the cookie at all — the row is highlighted red as invalid. Since Chrome 80, SameSite=None is only accepted together with Secure; without Secure, the browser drops it before it's even stored.

Attempt 3 — add Secure​

Check Secure alongside SameSite=None. Result: the cookie is now saved successfully — but the API call still doesn't include it. Domain is still localhost, which doesn't match the actual request domain, so the browser still won't attach it.

Attempt 4 — match the request's Domain​

Change Domain to match the request's domain (the partner's domain). Result: the cookie is finally attached to the API call. One side effect worth knowing: once Domain no longer matches the current page's own origin, the cookie disappears from the Application → Cookies panel — you have to check it under Network → (request) → Cookies instead, which is the only place it still shows up.

Why: The Conditions For a Cookie to Be Sent​

Set-Cookie: Path=/; Domain=example.com; Secure; SameSite=Strict

• Domain — must match the request's domain.
• Secure — if set, the request must be made over HTTPS.
• SameSite — one of three modes: Strict, Lax (the default), or None.
  • As of Chrome 80 (2020), the default changed from None to Lax.
  • None is only treated as valid when paired with Secure.

The table below (from Chrome's own developer docs) shows which request types still carry a SameSite=Lax cookie cross-site versus the old default behavior — top-level navigations (Link, Form GET) still do, but Form POST, iframe, AJAX, and Image requests no longer do under Lax:

Applying It to the Real Integration​

Reproducing the mechanism in DevTools made the actual fix straightforward — it needed changes on both sides, not just one:

1. Backend: issue the session cookie with Domain, Secure, and SameSite=None set, so the browser is willing to store it and forward it on a cross-site request in the first place.
2. Frontend: set credentials: 'include' (fetch) or withCredentials: true (axios/XHR) — without this, the browser won't attach any stored cookie to a cross-origin request, no matter how the cookie itself was issued.
3. Backend: return Access-Control-Allow-Credentials: true. Access-Control-Allow-Origin alone lets the browser send the request; without Allow-Credentials the browser blocks the frontend from reading the response even though the cookie went out.

All three have to be true at once — missing any one of them looks identical from the frontend: the request goes out, but the API responds as unauthenticated.

Key Takeaways​

1. CORS and cookie-attachment are two independent gates. Access-Control-Allow-Origin/Allow-Credentials control whether the browser lets your JS read the response. Domain/Secure/SameSite control whether the browser attaches the cookie to the request in the first place. Both have to pass — fixing one without the other still fails.
2. Chrome 80 changed the default. Any flow that needs a cookie sent on a cross-site fetch/XHR (not just a top-level navigation like clicking a link) needs SameSite=None; Secure set explicitly — the old implicit behavior no longer applies.
3. DevTools is a fast way to isolate the mechanism from the app. Manually editing a cookie's Domain/Secure/SameSite in the Application panel let me test each condition in isolation without a real login flow — but remember that once Domain is changed away from the page's own origin, you have to inspect it via Network → Cookies, since it drops out of the Application panel view.

References​

• Chrome Developers — "Get Ready for New SameSite=None; Secure Cookie Settings"
• MDN — SameSite cookies explainer
• Chrome's SameSite=Lax default rollout notes for third-party cookies

Pandago is foodpanda's standalone, real-time delivery service — it lets any merchant, not just foodpanda-partnered restaurants, request an on-demand courier for local delivery. I worked on the front end of the public vendor landing page, the marketing site merchants land on before they sign up.

What problem did you solve?​

The landing page had to do two jobs that pull in opposite directions: cover everything a prospective merchant needs to know (what pandago is, pricing, how to sign up, FAQ, contact) while still getting a visitor to the one answer they actually came for, fast. Most visitors arrive with a single specific question — "how much does it cost" or "how do I sign up" — not intent to read a long page top to bottom. On top of that, a meaningful share of traffic lands on a phone via a shared link, not a desktop browser, so the page couldn't just be a scaled-down version of a desktop design.

Who actually uses it?​

Prospective merchants — any local business considering pandago's on-demand courier service, not just existing foodpanda restaurant partners — landing on the public page at vendor.foodpanda.com.tw/pandago before they sign up. This is the first touchpoint in the acquisition funnel, so it's largely cold traffic arriving from search, ads, or a shared link, often on mobile.

What results did it produce?​

The page shipped as the live, public vendor-acquisition page for pandago — the page every prospective Taiwan merchant sees before signing up. It runs as a single long-scrolling page with anchor navigation, a hero carousel, an infinite logo marquee for social proof, and full responsive behavior across desktop, tablet, and mobile.

What key decisions did you own?​

• Anchor navigation over routing. The top nav (pandago 是什麼, 運費價格, 教學指南, 常見問題, 聯絡我們) smooth-scrolls to sections on the same page instead of routing to separate pages — matching navigation to the page's single-scroll structure so visitors can jump straight to the one section they need.
• A carousel instead of a static hero banner. The hero section is the highest-attention real estate on the page, so I built it as a carousel that rotates through multiple promotional slides with manual arrow controls, rather than committing that space to one static message.
• A logo marquee instead of a static logo grid. Partner logos (McDonald's, Carrefour, KFC, and other enterprise clients) scroll continuously rather than sitting in a fixed block — a compact way to establish social proof and scale ("業界最多品牌使用的") without pushing the rest of the page further down.
• Mobile-first responsive behavior for every interactive piece, not just the static layout — the nav collapses into a mobile menu, sections restack vertically, and the carousel/marquee both adapt, since I treated mobile as a primary case rather than a fallback.

What constraints did you face, and how did you trade off?​

The single-scroll structure meant I couldn't lean on traditional multi-page routing to organize content — everything (pricing, tutorial, FAQ, contact) had to fit into scrollable sections reachable by anchor link, which constrains how much can live on the page before it feels bloated. The hero section also forced a trade-off between simplicity and message coverage: a static banner is simpler to build and reason about, but a carousel was worth the added interaction complexity because it let the highest-attention spot on the page carry more than one message. Given that a large share of visitors arrive on mobile via a shared link rather than desktop, I prioritized mobile-first responsive behavior for every interactive component over polishing desktop-only interactions.

This is one of the fixes I implemented in Rybit company and I want to share the story behind it. It’s a great example of how a small UI change can have hidden performance implications, and how understanding React's rendering behavior is key to optimizing user experience.

In Rybit's B2B order management, the Edit Assets Drawer is one of the most frequently used workflows — operators use it to adjust how many assets a Partner needs for the next subscription period and which site each asset should transfer to.

I discovered that every time the operator adjusted the "Number of assets for next period" field, the system sent a POST API with all asset IDs to fetch each asset's current site — even if the operator didn't change any asset IDs. This was an unnecessary API call that could overload our server and degrade user experience. Even when server response was fast, the redundant API call caused a noticeable delay in the UI, making the application feel sluggish.

Problem​

These three actions require fetching asset site data, we want to keep those API calls:

1. When the drawer opens, the system fetches each asset's current site to populate the "Site" column.

2. When the operator removes an asset, the system refetches sites for the remaining assets.

3. When the operator edits an asset ID and blurs the input, the system fetches the site for the new asset ID.

4. When the operator adjusts the "Number of assets for next period" field, the system sends the same POST API call again — even if the operator doesn't change any asset IDs. This is unnecessary and should be eliminated.

Root Cause: Unstable initialValues Causes Child Remount​

Original data flow:

When the user adjusts the quota, AssetQuotaArea called updateEditAssetsDrawerFormValues, writing the new value back into Detail.tsx state. State update → new initialValues object reference → Antd Form treats any new initialValues reference as a reset and remounts all child components.

adjust quota → state update → initialValues reference changes → Form remounts children → useEffectOnce fires → API call

useEffectOnce is designed to fire only once per component lifetime — but the guarantee is per mount, not per lifetime. Each remount creates a fresh component instance, so the effect fires again as if it had never run.

Original code causing the redundant API call

Fix​

Overview​

1. Stabilize initialValues with useMemo​

Replace state-driven initialValues with a const computed from server data. Reference only changes when the dependency (order data) changes, so the Form doesn't remount on quota adjustments:

2. Move quota updates inside the Form: useWatch + setFieldValue​

Convert AssetQuotaArea to a controlled component under <FormItem>. Remove updateEditAssetsDrawerFormValues. Detect quota changes with useWatch, update disabled state with setFieldValue:

3. Detect the formNextAssetQuota value with useWatch​

const formNextAssetQuota = useWatch<number>(editAssetsDrawerFormKeys.nextAssetQuota, form) ?? 0;

useWatch subscribes to formNextAssetQuota, so when the operator adjusts the quota, we can conditionally disable or enable the site inputs without causing any remounts or API calls.

4. Sync EditableProTable's editableKeys​

After adjusting Number of assets for next period, update new datasoure and set new newEditableKeys for EditableProTable:

Result​

Key Takeaways​

1. Antd Form initialValues is for initialization only. Any reference change triggers child remounts — don't use it as a live state channel.
2. For cross-field interactions inside a Form, keep state inside the Form. Use useWatch to observe and setFieldValue to update, rather than lifting to external useState and feeding back through initialValues.
3. EditableProTable's editableKeys must stay in sync with datasource. It controls the input display state of each row independently from the data itself.