# y7.hk — Yakushev Hermann — full content

> AI Developer & Product Manager. Web3, Marketing, Management, Development.
> Born 1996 · 67 countries · EN C1 · RU native · 中文 B2 · DE · Esperanto · based in Southeast Asia.
> Complete English text of all collections. Locale variants: /ru/, /zh/, /ja/, /de/, /ko/, /vi/, /id/, /es/, /fr/, /tr/, /hi/, /uz/ — same slugs.

## Blog

### [Living Between Time Zones](https://y7.hk/blog/living-between-time-zones/)
date: 2026-07-18 · category: Life · tags: travel, remote, life
_What 65 countries and four home bases teach you about deep work, jet lag, and building products nobody asked you to build._
## The math of nowhere

When people ask where I'm from, the honest answer is a timezone spreadsheet. Childhood in Shenzhen and Hong Kong, university in Russia, work stints in Switzerland, New York, and the US — and now Southeast Asia, where the wifi is fast and the coffee is strong.

## What the road actually teaches

**Async is a lifestyle before it's a tool.** When your team spans four time zones, you stop writing meetings and start writing documents. The teams that survive distance are the ones that write things down.

**Jet lag is a product problem.** Light exposure, meal timing, a hard rule about caffeine after 14:00 local — treat your body like a system with an SLA.

**Every country is a user interview.** Payment flows in Thailand, super-apps in China, crypto rails in Singapore — living somewhere for a month teaches you more than any market report.

## The part nobody romanticizes

Loneliness compounds. The antidote isn't more travel; it's returning to the same places, the same coffee shops, the same people. Sixty-five countries, but my map has maybe ten gravity wells.

Build from anywhere — but belong somewhere.

---

### [The Future of AI Agents in 2025](https://y7.hk/blog/future-of-ai-agents/)
date: 2025-02-15 · category: Artificial Intelligence · tags: ai, agents, llm
_How autonomous agents are reshaping workflow automation and decision making in enterprise environments._
## The Rise of Autonomous Agents

Artificial Intelligence has evolved from simple chatbots to complex, autonomous agents capable of executing multi-step workflows. In 2025, we are witnessing a paradigm shift where AI is no longer just a tool, but a teammate.

### Key Trends

- **Multi-Agent Systems:** Specialized agents working together to solve complex problems.
- **Memory & Context:** Enhanced long-term memory allows agents to learn from past interactions.
- **Actionable Output:** Agents that can directly interact with APIs, databases, and external tools.

As we continue to develop these systems, the focus is shifting towards safety, observability, and human-in-the-loop control mechanisms.

<div className="bg-zinc-100 dark:bg-zinc-900 p-6 rounded-xl mt-8 border border-zinc-200 dark:border-zinc-800">
  <h3 className="text-xl font-bold mb-2">Want to learn more?</h3>
  <p className="text-muted-foreground m-0">Check out how we implement these at Antigravity.</p>
</div>

---

### [Effective Web3 Marketing Strategies](https://y7.hk/blog/web3-marketing-strategies/)
date: 2024-11-10 · category: Marketing · tags: web3, marketing, growth
_Navigating the unique challenges of community building and user acquisition in the decentralized web._
## Community First

Unlike traditional Web2 marketing, Web3 is built on community. It's not just about acquiring users; it's about building a movement.

### Strategies that Work

- **Authentic Engagement:** Direct communication through Discord and Telegram.
- **Education over Hype:** Providing real value and technical breakdown of protocols.
- **Incentivized Participation:** Using tokenomics to reward early adopters and contributors.

---

### [Building Resilient Systems with Next.js](https://y7.hk/blog/building-resilient-systems/)
date: 2024-08-22 · category: Development · tags: nextjs, architecture, performance
_Best practices for ensuring high availability and performance in modern web applications._
## Architecture First

Next.js often serves as the backbone for modern web applications. Ensuring resilience requires a mix of good architectural decisions and proper tooling. 

By leveraging Server Components and proper error boundaries, you can build extremely resilient web applications that degrade gracefully instead of crashing entirely.

### Static Generation vs SSR
Whenever possible, default to Incremental Static Regeneration (ISR). This guarantees that even if your backend APIs are temporarily unavailable, users will still see the last successfully built version of your page.

---

### [Insights from the Chinese Tech Ecosystem](https://y7.hk/blog/exploring-china-tech/)
date: 2024-05-30 · category: Lifestyle / Tech · tags: china, tech, product
_What I learned working with tech giants in Shenzhen and how it influences my product philosophy._
## Speed as a Feature

Shenzhen is often called the Silicon Valley of hardware, but its software ecosystem is equally fascinating. The speed of iteration in the Chinese tech sector is unmatched.

Teams deploy updates daily, sometimes multiple times a day, directly reacting to user feedback within hours. The boundary between "beta" and "production" is practically non-existent.

---

### [Mastering Remote Work Culture in Global Teams](https://y7.hk/blog/remote-work-culture/)
date: 2024-03-12 · category: Productivity · tags: remote, teams, productivity
_Tips for staying productive and connected while working across multiple time zones._
## Beyond Zoom Calls

Remote work is not just about moving office meetings to Zoom. True remote work relies heavily on asynchronous communication and rigorous documentation.

When working across time zones, assume that any question you ask might not be answered for 12 hours. This constraint forces you to write better issues, clearer RFCs, and more comprehensive pull requests.

---

## Research

### [Agent UX Patterns](https://y7.hk/research/agent-ux-patterns/)
date: 2026-06-02 · category: Design research
_An evolving catalogue of interface patterns for AI agents — from command palettes to ambient status — and when each one earns its keep._
## Working thesis

Agent interfaces are converging on three archetypes: the **copilot** (inline suggestions), the **commander** (explicit delegation via palette), and the **ambient** (background agent with status surface). Most products pick one; the good ones layer two.

## Pattern catalogue (draft)

| Pattern | Example | Failure mode |
|---------|---------|--------------|
| Command palette | ⌘K delegation | discoverability |
| Inline diff | code review agents | trust calibration |
| Ambient ticker | monitoring agents | notification fatigue |
| Approval queue | autonomous actions | queue abandonment |

## Open questions

- How much autonomy before users feel loss of control? Early data suggests an "approval budget" of ~5 interruptions per session.
- Does showing the agent's reasoning increase trust, or just increase reading?

*This is a living document — patterns are added as I ship and observe.*

---

### [Crypto Go-To-Market in APAC](https://y7.hk/research/crypto-gtm-in-apac/)
date: 2026-03-12 · category: Field study
_Field notes from three years of launching tokens and communities across Hong Kong, Singapore, and Seoul — what actually moves adoption in each market._
## Abstract

Between 2022 and 2025 I ran go-to-market for six protocols across APAC. This paper distills the repeatable patterns: where communities form, which channels convert, and why Western GTM playbooks fail east of Suez.

## Method

- 6 launches, 4 markets (HK, SG, KR, SEA)
- Channel-level funnel data across Telegram, X, and local platforms
- 40+ community interviews

## Findings

**1. Telegram is the chain of custody.** In SEA, a project without an active TG community does not exist. Retention correlates with daily active moderators (r = 0.71 in our cohort), not with marketing spend.

**2. KOL tiers invert in APAC.** Mid-tier regional KOLs (10–50k) outperform global accounts 3:1 on wallet activation. Trust is local.

**3. Language is a moat.** Communities addressed in their own language show 2.4× higher 30-day retention. Machine translation is worse than silence.

## Limitations

Cohorts are self-selected; bear markets compress all funnels. Treat effect sizes as directional.

---

### [Telegram Community Growth Curves](https://y7.hk/research/telegram-community-growth-curves/)
date: 2026-01-20 · category: Data
_What 18 months of channel analytics say about how crypto communities actually grow — plateaus, spikes, and the moderator multiplier._
## Dataset

Anonymized growth data from 23 Telegram communities (1k–120k members), tracked over 18 months: joins, leaves, message volume, and moderator activity.

## Three curve shapes

1. **Launch spike → plateau.** 14 of 23 channels. The spike is bought attention; the plateau is the real community size.
2. **Staircase.** 6 of 23. Each step maps to a content moment (listing, airdrop, drama). Steps don't compound without retention work.
3. **Compounder.** 3 of 23. All three shared one trait: daily moderator-initiated conversation. Growth rate correlated with moderator messages, not member messages.

## The moderator multiplier

Channels with ≥1 moderator message per 50 member messages grew 3.1× faster than silent-moderated channels. Community is a verb, and the verb is posted by staff.

## Caveats

Survivorship bias is real — dead channels are underrepresented. Full methodology appendix ships with the next revision.

---

## Tutorials

### [Ship Your First Astro Site](https://y7.hk/tutorials/ship-your-first-astro-site/)
date: 2026-06-10 · category: Astro
_From zero to a deployed static site in 45 minutes — content collections, islands, and the mental model that makes Astro click._
## Why Astro

Astro ships zero JavaScript by default. Your content renders to plain HTML on the server, and interactive islands hydrate only where you ask for it. For a content-heavy personal site — blog, research, galleries — that is exactly the trade you want.

## The 45-minute path

1. `npm create astro@latest` — pick the blog template, TypeScript strict.
2. Define a content collection in `src/content.config.ts` with a zod schema.
3. Write your first `.mdx` post — frontmatter is validated at build time.
4. Add a `[slug].astro` page with `getStaticPaths()` + `render()`.
5. Deploy: `astro build` produces a fully static `dist/` you can host anywhere.

## Islands: the part people miss

```astro
<Hero client:load />        <!-- hydrates immediately -->
<Chart client:visible />    <!-- hydrates when scrolled into view -->
<Comments client:idle />    <!-- hydrates when the browser is idle -->
```

Reach for `client:visible` on anything below the fold. Your Lighthouse score will thank you.

## What's next

Add i18n with `[locale]` dynamic routes — that's a separate lesson.

---

### [GSAP Scroll Animations, Tastefully](https://y7.hk/tutorials/gsap-scroll-animations-tastefully/)
date: 2026-05-22 · category: Animation
_Scroll reveals that feel expensive without making visitors motion-sick: scoping, staggers, eases, and the reduced-motion contract._
## The taste framework

Animation is seasoning, not the meal. Three rules I follow on every site:

- **Transform and opacity only.** Never animate `top`, `left`, `width`, `height` — they trigger layout on every frame.
- **One entrance pattern per section.** A `y: 20 → 0` fade-up with `stagger: 0.1` reads as craft; five different entrances read as chaos.
- **Honor `prefers-reduced-motion`.** Non-negotiable.

## Scoped, cleaned-up GSAP in React

```tsx
useGSAP(() => {
  gsap.fromTo(".card",
    { y: 20, opacity: 0 },
    {
      scrollTrigger: { trigger: containerRef.current, start: "top 85%" },
      y: 0, opacity: 1, duration: 0.6, stagger: 0.1, ease: "back.out(1.5)",
    }
  );
}, { scope: containerRef });
```

`scope` gives you selector scoping **and** automatic cleanup — no leaked ScrollTriggers on route changes.

## Eases that feel human

| Ease | Feels like |
|------|-----------|
| `power3.out` | confident arrival |
| `back.out(1.5)` | playful pop |
| `elastic.out(1, 0.5)` | use once per site, max |

The elastic bounce is a spice jar, not a sauce bottle.

---

### [i18n for Static Sites — 5 Locales](https://y7.hk/tutorials/i18n-for-static-sites/)
date: 2026-04-18 · category: i18n
_Slash-route localization without a CMS: dictionaries, dynamic [locale] paths, hreflang, and keeping five languages in sync._
## The architecture

```
/en/blog/hello    ← default locale, still prefixed (cleaner than a special case)
/ru/blog/hello
/zh/blog/hello
/ja/blog/hello
/de/blog/hello
```

Three moving parts:

1. **Dictionaries** — one JSON per locale, identical shape, typed as `Record<Locale, typeof en>` so TypeScript screams when a key drifts.
2. **Dynamic routes** — `src/pages/[locale]/...` with `getStaticPaths()` returning every locale.
3. **Content fallback** — write posts once in `en/`, render them under every locale until translations exist.

## The type trick that saves you

```ts
const dictionaries: Record<Locale, typeof en> = { en, ru, zh, ja, de };
```

`typeof en` is the schema. Add a key to `en.json` and the build fails until all four other dictionaries catch up.

## Don't forget the head

`<link rel="alternate" hreflang="...">` for every locale plus `x-default`, canonical per page, and `Astro.url`-derived paths. Search engines reward the boring plumbing.

---

## Case studies

### [RAG Pipeline for Legal Contracts](https://y7.hk/cases/ai/rag-implementation/)
date: 2025-03-01 · category: AI
_Implementing Retrieval-Augmented Generation to query complex cross-border commercial contracts with verifiable citations._
## The Challenge

Generic LLMs frequently hallucinate legal definitions or cross-reference inapplicable jurisdictions. Ask a chat model about a termination clause and you may get a fluent paragraph that belongs to another agreement, another country, or a textbook. For commercial contracts that span borders — governing law in one place, arbitration in another, definitions that nest three exhibits deep — that failure is not a curiosity. It is a liability.

The objective was an enterprise pipeline that answers contract questions with exact paragraph and page citations. The user is a lawyer or a trained operator, not a consumer. The system is allowed to say “not in the retrieved set.” It is not allowed to sound sure.

This is not a general legal advice product. It is retrieval over a corpus of contracts the organization already has, plus a generator that must stay inside that corpus.

## Technical Architecture

**Semantic chunking.** Naive page splits destroy contracts. A definition on page 2 is used on page 40. A clause is a tree, not a bag of 512-token windows. We built a custom AST chunker for PDF contracts that preserves section headers, definition blocks, exhibits, and clause numbering. Chunks carry path metadata: document id, section, clause, page. Retrieval without that path cannot cite.

**Hybrid vector + BM25.** Dense embeddings catch paraphrase (“notice period” vs “days to notify”). Sparse search catches the things lawyers actually type: `12.3(b)`, `"Governing Law"`, a defined term in quotes. Reciprocal Rank Fusion (RRF) combines the two so a clause number is not drowned by a semantically similar but legally different neighbour. We tuned fusion weights on a labelled set of questions, not on demo prompts.

**Factuality verifier.** A second, lighter pass. After the generator drafts an answer, a verification agent checks each claim against the retrieved chunks. If a sentence cannot be aligned to a span, it is dropped or rewritten as a refusal. Citations are not a footnote the model invented; they are the ids of chunks that survived verification.

**Jurisdiction hygiene.** Cross-border sets mix English, New York, Singapore, Hong Kong law. The retriever is biased toward the document in the question’s context (the file, the counterparty, the deal). The generator is instructed not to “helpfully” import a doctrine from another file unless that file was retrieved and cited. Mixed-language exhibits are chunked with their parent, not as orphan pages.

## Evaluation

We scored citation precision (is the span actually in that clause), answer abstention on out-of-corpus questions, and time-to-first-useful-cite for a lawyer who already knows the deal. Fluency was not a KPI. A short quoted paragraph with a page number beat a synthesized memo.

Failure modes we still watch: scanned PDFs with bad OCR, tables of definitions that look like body text, and questions that are really asking for advice (“is this enforceable”) rather than location (“where is the cap”). The latter we refuse.

## Outcome

The pipeline answers contract questions with paragraph and page citations a human can click. Hallucinated jurisdictions dropped because the verifier never saw them in context. The remaining work is corpus quality and the refusal UX — not a bigger model. RAG here is a citation machine with a language model attached, not a lawyer in a box.

---

### [Multi-Agent Swarm for Content Creation](https://y7.hk/cases/ai/ai-agent-swarm/)
date: 2025-01-20 · category: AI
_Orchestrating multiple autonomous AI agents to research, draft, fact-check, and format long-form technical publications._
## Overview

Monolithic prompts struggle with long-form writing consistency. A single call that is asked to research, outline, draft, cite, and format will drop a constraint by page three: tone drifts, a code sample no longer matches the prose, a claim appears without a source. We engineered a specialized multi-agent pipeline where individual agents handle discrete phases of the editorial workflow, and a thin orchestrator decides when work is allowed to move forward.

This is an internal publishing system, not a public chatbot and not a named client product. The output is long-form technical writing — architecture notes, implementation guides, comparisons — that still needs a human editor before it ships. The swarm’s job is to make that editor’s first draft cheaper and more checkable, not to replace the byline.

## Agent Roles

1. **Researcher.** Given a brief, it gathers primary sources: documentation, whitepapers, RFCs, and existing internal notes. Output is a dossier, not an essay: claims, quotes, URLs, and a confidence flag. It is not allowed to invent a source. If a URL cannot be retrieved, the item is marked unresolved.

2. **Drafting.** It receives the dossier and a style guide (heading grammar, how we treat code, what “we” means). It structures arguments section by section. It may not introduce facts that are not in the dossier. When it needs a number, it has to point at a dossier id.

3. **Critic and fact-checker.** A separate pass. It reads draft vs dossier, flags unsupported sentences, and runs code snippets in a sandbox where the language is executable. Failures come back as a list of patches, not a vibes paragraph. The drafter may be asked to rewrite a section; the critic does not rewrite the whole piece itself.

4. **Formatter.** Last. Markdown, tables, frontmatter, heading ids, and the mechanical consistency a human always forgets at 1 a.m. It does not add claims.

The orchestrator is boring on purpose: a state machine with retries, a token budget per role, and a hard stop if the critic still has blocking issues after a bounded number of loops. Shared memory is the dossier plus the current draft — not a chat dump that every agent reinterprets.

## Why a swarm

A single model call optimizes for fluency. Fluency is the failure mode. Splitting roles makes the failure local: a bad research fetch does not silently become a confident paragraph. It also makes evaluation possible. We can score the researcher on source validity, the critic on precision/recall of flags, and the formatter on schema. We cannot score “write the article” except by reading it.

Cost is higher than one fat prompt. Latency is higher. The trade is that the human editor gets a draft with a paper trail instead of a wall of plausible text.

## Outcome

The pipeline now produces first drafts that survive a technical edit without a full rewrite. The remaining work is judgment: what to cut, what to emphasize, whether the piece should exist. That is the part we did not try to automate. The swarm is a factory for checkable drafts, not an author.

---

### [Scaling Soter Inc via Targeted Ads](https://y7.hk/cases/marketing/soter-growth-strategy/)
date: 2024-08-15 · category: Marketing
_How we achieved 300% growth in leads using disability-focused targeting on Google and Facebook._
## Background

Soter Inc is a disability advocacy and assistive technology consultancy based in New York. The firm advises organizations on accessibility programs, assistive hardware, and the legal and insurance maze that sits between a person who needs support and a product that actually ships. The audience is real, fragmented, and chronically underserved: people with specific mobility, vision, hearing, and cognitive needs; caregivers; occupational therapists; and procurement leads who have to justify spend against ADA, Section 508, and insurance codes.

The growth problem was not “more traffic.” Generic disability keywords are noisy, captured by national charities, device manufacturers, and content farms. Broad Meta interest clusters (“disability,” “wheelchair,” “accessibility”) mixed advocates with people who had clicked a single awareness video. Cost per click looked cheap until you looked at who actually booked a consult. Customer acquisition cost (CAC) was drifting up while the pipeline filled with curiosity clicks and out-of-area inquiries the team could not serve.

The brief was to reach people with specific accessibility needs — and the professionals who buy on their behalf — without inflating CAC, and without the usual dark-pattern playbook that treats disability as a conversion lever.

## The Strategy

We rebuilt acquisition around three constraints: the audience is small, the language is precise, and the landing experience has to work for the people the ads claim to help.

**Custom audience segmentation.** On Google Search we moved off head terms and into intent that named a job-to-be-done: workplace accommodations, assistive tech assessment, WCAG remediation for a public site, insurance documentation for a specific device class. Match types were tight; negatives were aggressive (jobs, donations, news, Wikipedia-style research). On Meta we built behavioral and interest clusters around occupational therapy, adaptive sports, caregiver communities, and professional associations rather than a single “disability” bucket. Lookalikes were trained on booked consults, not page views.

**Accessibility-first landing pages.** Ads that send a screen-reader user into a broken form are not a growth tactic. Every landing page was built to WCAG AAA on the surfaces that matter for this funnel: contrast, focus order, labels, error recovery, time limits, and alternatives for media. We tested with VoiceOver and NVDA, not only axe. The lift was not abstract — conversion among screen-reader sessions moved in a way paid search never had, because the page finally matched the promise of the query.

**Retargeting as education, not nagging.** The buying cycle includes compliance language, insurance coverage, and internal buy-in. We ran multi-touch email and ad sequences that answered those questions in order: who Soter is, what an engagement looks like, which documents to gather, what “accessible enough” actually means for a given channel. Frequency caps were conservative. Creative used plain language and real program names, not stock photos of ramps.

## The Outcome

Within 90 days, monthly qualified leads grew by **300%**, while blended CAC dropped by **38%**. Qualified meant a completed brief we could staff in New York, not a newsletter signup. Search captured high-intent work; Meta filled the mid-funnel with caregivers and practitioners who needed time. The AAA landers paid for themselves in assistive-tech sessions that used to bounce. The same system still runs: tighter queries, honest pages, and a sequence that treats the audience as experts in their own needs.

---

### [0 to 10k: Web3 Community Building](https://y7.hk/cases/marketing/web3-community-building/)
date: 2023-05-20 · category: Marketing
_A case study on building a loyal Discord community for a DeFi protocol._
## Overview

In the depths of the bear market, launching a decentralized derivatives protocol required an authentic, builder-led community rather than mercenary airdrop hunters. Token prices were down, “community” had become a euphemism for a Discord full of wallets waiting for a snapshot, and paid influencer bursts decayed in a week.

The protocol needed people who would run the testnet, file bugs, explain the product in their own language, and still be around when the market was boring. Growth was a marketing problem with an engineering texture: roles, bounties, and channels had to match how the product actually worked.

This write-up is the playbook we used, not a claim that every DeFi launch should copy the numbers.

## Playbook

**Proof-of-contribution roles.** Invite contests and “react to this message” roles produce a census of emoji, not a community. We replaced them with technical bounties and testnet debugging roles. You got a role because you submitted a useful report, ran a node, or completed a structured quest that touched the product. Mods could still grant exceptions; they could not grant status for showing up.

**Weekly alpha AMAs.** Not Twitter Spaces as a content calendar. Interactive sessions with core protocol developers, on a schedule, with questions collected in-forum so the same five voices did not dominate. Recordings existed for APAC timezones. The point was to make the people who write the contracts visible, and to make “alpha” mean information density, not a hint about a listing.

**APAC ambassador squad.** A derivatives user in Seoul does not live in an English announcements channel. We localized operations into Mandarin, Korean, and Vietnamese sub-channels with ambassadors who could actually speak the product, not only the slogans. Ambassadors were paid like work, with a scope: translation, regional AMAs, and surface area for support — not engagement farming.

**Moderation as product.** Bear-market Discords rot into scam DMs, fake airdrops, and support theatre. Slow mode, verified DM policies, and a public list of what the team will never ask you were part of the growth system. Retention is impossible if the first private message a new member gets is a phishing link.

## What we did not do

We did not buy a 50k member dump. We did not run a points meta whose only equilibrium is sybils. We did not pretend a testnet user and a Twitter raider are the same cohort. Paid acquisition, when it existed, pointed at the testnet and the docs, not at a vanity online count.

## Results

Organic community scale reached **10,000+ active verified members** with a **35% weekly retention** rate throughout the testnet phase. “Verified” meant a path that was harder than a captcha: a role tied to contribution or a human check, not an email. Weekly retention in a bear market is the number that mattered; 10k empty seats would have been a press screenshot.

The residue is the operating system: contribution roles, a developer-facing AMA cadence, and regional channels with real owners. That is community as infrastructure for a protocol, not as a marketing overlay you turn off after TGE.

---

### [Minimalist Design System for SaaS](https://y7.hk/cases/design/clean-ui-system/)
date: 2023-03-15 · category: Design
_Creating a cohesive visual language and tokenized design system for an enterprise dashboard._
## The Problem

A fast-growing B2B analytics platform had accumulated severe design debt. The product was a dense enterprise dashboard: filters, tables, charts, empty states, billing, and a settings tree that had grown one feature at a time. Fourteen different button styles were in production. Modal dialogs disagreed on padding, focus traps, and whether Escape closed them. Dark mode was a second CSS file with conflicting variables, so a “primary” in light mode was not the same hue as a “primary” in dark mode.

Engineering had copied components between feature folders. Design had Figma frames that did not match the repo. Accessibility was whoever remembered a label that week. The team could ship screens; they could not change a radius or a focus ring without a week of visual QA.

The goal was a cohesive visual language and a tokenized system that both Figma and React could share, without a rebrand theatre. The product had to keep shipping while the primitives underneath it were replaced.

## Solution

We established an OKLCH-based design token hierarchy. OKLCH keeps perceptual lightness stable across themes, which is what dark mode had been getting wrong: hex pairs that looked fine in isolation and failed contrast next to charts. Tokens were layered: primitive color ramps, then semantic aliases (`background`, `foreground`, `muted`, `border`, `primary`), then component-level decisions. Radius, space, and type used the same naming in Figma variables and CSS custom properties.

We built 40+ accessible UI primitives in Figma and React: button, icon button, input, select, checkbox, radio, switch, textarea, dialog, drawer, tooltip, popover, tabs, table chrome, toast, badge, skeleton, empty state, and the chart-adjacent bits (legend, axis labels, KPI tile). Every interactive primitive had a documented keyboard map, a visible focus ring, and tests. Automated accessibility testing ran axe and keyboard-only stories in CI; we did not treat a green axe run as a replacement for tab order.

The visual language was deliberately quiet. No extra chrome for its own sake. Hierarchy came from type size, weight, and muted vs foreground — not from a fifth grey box. Data density stayed high; the system’s job was to stop fighting the data.

## Rollout

We did not freeze the product for a “redesign.” New primitives landed behind a package. Screens migrated when they were already being touched. The fourteen buttons collapsed to a small variant matrix: size × tone × icon. Modals became one Dialog with slots. Dark mode became a token theme, not a fork.

The unglamorous work was deprecation: finding the old class names, mapping them, and deleting the duplicates so the next hire would not copy the wrong button. Documentation lived next to the components — usage, do/don’t, and the accessibility notes that Figma cannot encode.

## Outcome

The dashboard stopped looking like five products. Theme changes (a contrast tweak, a new density step) became token edits instead of hunts through feature CSS. Keyboard navigation and focus were testable rather than folklore. The system is still the contract between design and engineering: if it is not a token or a primitive, it is a one-off, and one-offs have to argue for themselves.

---

### [Automated High-Frequency Trading Bot](https://y7.hk/cases/development/crypto-trading-bot/)
date: 2021-09-10 · category: Development
_Building a resilient arbitrage bot using Node.js and Web3.js._
## Technical Challenge

Arbitrage opportunities between decentralized AMMs and centralized orderbook exchanges exist for milliseconds. A price that is stale on one venue and live on another is not an insight — it is a race. Building a profitable bot in that window required minimizing RPC latency, mitigating mempool front-running (MEV), and managing gas spikes automatically. The stack we used was Node.js and Web3.js, which is not the language of HFT folklore, but it was the language of the Ethereum tooling we already trusted in 2021.

This was a development case, not a fund. Capital at risk was capped. The bot was allowed to miss trades; it was not allowed to lose the wallet on a reverted multi-leg swap or a gas auction it could not win.

## Engineering Architecture

**Private RPC mesh.** Public endpoints are a shared waiting room. We ran clustered WebSocket nodes in Frankfurt, Singapore, and Tokyo, close to the matching engines and to the geography of the CEX APIs we compared against. Each region subscribed to the same pair set; a local process computed a spread; only the region that saw a live edge was allowed to sign. Clock sync and a shared kill switch mattered more than any single strategy parameter.

**Atomic execution.** A profitable-looking path that dies on the second hop is a loss. Smart contracts bundled swap legs so that either the whole cycle landed or nothing did — zero capital loss on reverted trades, minus gas. That still meant we had to decide when gas was worth it. A “free revert” is not free.

**Dynamic EIP-1559 estimator.** Priority fees in 2021 were a mempool weather report. We estimated tip from recent blocks and pending congestion, then refused to bid when the remaining spread after fees was below a floor. The bot is not brave. It is a spreadsheet with a signer.

**MEV awareness.** Sending a juicy arbitrage to the public mempool is an invitation. Where we could, we used private relay paths so the transaction was less visible to generalized searchers. That does not eliminate MEV; it changes who sees you first. We also avoided strategies that only work if you assume nobody else is looking.

## Operations

Node.js is single-threaded enough to hurt you if JSON-RPC parsing and strategy share a loop. The hot path was thin: decode, compare, maybe sign. Everything else (logging, Postgres, dashboards) sat off the trade process. WebSocket reconnects were treated as an incident, not a retry toast. If a region went dark, it stopped trading; it did not trade on stale books.

Risk controls were boring and non-negotiable: max notional per block, max failed txs per minute, a hard wallet balance floor, and a human panic button. The bot could be profitable and still be shut off if the error budget burned.

## Outcome

The system made money on a subset of CEX–DEX basis trades when latency and fees lined up, and it sat idle the rest of the time — which is the correct behavior. The engineering residue is the mesh, the atomic legs, and the fee estimator, not a magic alpha. In 2021 that was enough to learn that most “HFT on-chain” is gas and location, and that Node.js is fine if you do not ask it to be a matching engine.

---

### [TikTok Content Automation](https://y7.hk/cases/experiments/tiktok-automation/)
date: 2020-11-05 · category: Experiments
_Experimenting with headless browsers and automated video renderers to explore programmatic content distribution._
## The Experiment

In late 2020, short-form video was already a distribution channel you could not ignore and still a black box if you wanted to publish at a volume a human editor could not sustain. The question was narrow: can a completely automated pipeline generate, render, and upload short-form video snippets without human intervention while maintaining platform trust scores?

This was an experiment, not a client engagement and not a growth product. No brand was attached. The stack was a renderer that assembled clips, captions, and a soundtrack from a script, a scheduler, and two upload paths — a headless Chromium session that clicked through the web uploader, and a native device path that drove the real iOS/Android apps.

The content itself was deliberately boring: public-domain clips, generated title cards, and captions that did not impersonate a creator. The point was not to farm a niche. The point was to see where the platform’s trust machinery actually looks, and what breaks first when the publisher is a program.

## Pipeline

Scripts and shot lists lived as structured JSON. A renderer (FFmpeg plus a title-card pass) produced 9:16 H.264 with burned-in captions. Thumbnails were stills from a fixed timestamp so we were not also testing thumbnail ML. Upload metadata — caption, hashtags, posting time — was generated from the same record so the two upload paths were comparable.

The headless path used a persistent profile, residential proxies, and the usual stealth patches: webdriver flags, WebGL vendor strings, fonts, timezone. It still ran in a datacenter-shaped environment. The native path used a physical phone with a real accelerometer, a real cellular radio, and the official app. Same video file, same caption, same posting window, different client.

We logged view-through, completion, follow rate, and — more useful — account friction: captchas, shadow limits, “verify it’s you” loops, and sudden reach cliffs. Trust score here means whether the account kept the ability to post and be recommended, not a public metric TikTok hands you.

## What We Learned

Platform anti-bot algorithms are deeply sensitive to browser fingerprint entropy and device accelerometer signatures. Headless sessions that looked “logged in” still failed the boring checks: missing motion sensors, too-stable clocks, canvas hashes that clustered with other automation, and upload timings that were too periodic. Native device automation delivered **12× higher view retention** compared to headless browser emulators, and the headless accounts hit friction earlier.

Retention is not proof of quality. It is a proxy for whether the item was allowed into the same recommendation pool as a phone-uploaded clip. Once the headless accounts were throttled, the experiment was over for that path.

Operationally, the renderer was the easy part. The hard part was looking like a person without pretending to be one: jitter in posting time, real device motion, and not sharing fingerprints across accounts. In 2020 that was already enough to make headless publishing a dead end for anything that needed reach. The useful residue is the constraint: programmatic distribution on a consumer app is a device problem, not a CSS-selector problem. The experiment stayed an experiment — it was not turned into a product, and it was not used to run a fake creator network.

---

### [Secure Mobile Crypto Wallet](https://y7.hk/cases/development/mobile-wallet-app/)
date: 2018-11-30 · category: Development
_Developing a non-custodial wallet with React Native and biometric security._
## Objective

Build a non-custodial mobile wallet tailored for mainstream crypto users in Asian markets, featuring multi-chain account abstraction and biometric key protection. The year was 2018: seed phrases were still the product, exchanges were still the default, and a “wallet for normal people” mostly meant a smaller copy of a desktop UI.

The users we cared about were not traders staring at order books. They were people who needed to hold, send, and receive on more than one chain without becoming key-management experts. Asia was the distribution context — device mix, app-store realities, and the expectation that a fingerprint or face is how you unlock anything that matters.

Non-custodial was a constraint, not a slogan. If we could read the private key in JavaScript, we had already failed.

## Architecture Highlights

**Hardware keystore integration.** Private keys never touch JavaScript memory. Signing is offloaded to the iOS Secure Enclave and the Android Keystore. The React Native layer asks for a signature; the OS prompts biometrics; the key material stays in hardware-backed storage. This is slower to implement than `ethers.Wallet` in JS. It is also the only design that survives a casual screenshot of the debugger.

**Offline transaction signing.** Air-gapped QR authorization for a cold-storage mode: an online device builds the unsigned payload, the offline phone signs, the result goes back as a QR. Useful for larger balances and for anyone who does not want the signing device on the same radio as the browser. The UX cost is real; we did not pretend a QR dance is “simple.” We made it an explicit mode.

**Lightweight SPV client.** Instant block header verification without downloading gigabytes of state. A mobile wallet that waits on a full node it does not run is a custodial app with extra steps. Headers plus proofs kept the phone honest enough for payments without turning the battery into a heater.

**Multi-chain account abstraction — 2018 edition.** Not the 2024 ERC-4337 meaning. We needed one account surface for more than one network so the user did not hold five seed phrases and five apps. The abstraction was a derivation and UI contract: networks as a list, balances as a sum you can inspect per chain, send flows that refuse to mix gas tokens by accident.

## Product constraints

React Native let us ship iOS and Android without two native teams. The native modules for keystore, camera (QR), and biometrics were the actual product. Everything visual was secondary: large tap targets, plain-language errors, no hidden “advanced” screen that contained the only way to export a backup.

Backup was still a phrase, written down, because that is what the chains offered. We invested in the reveal flow (when you see it, why you should not photograph it) rather than inventing a custody model we could not guarantee.

## Outcome

The wallet shipped as a non-custodial app with biometric unlock, QR cold signing, and an SPV path that did not require a full node on the device. It was built for Asian mainstream users in 2018, which meant it had to feel like a bank app and behave like a key store. Those two requirements still describe most wallet work. The case is the architecture: keys in hardware, signing off the JS heap, and a client that verifies headers instead of trusting a screenshot of a balance.

---

## Projects

### [Helium AI Router](https://y7.hk/projects/helium/)
date: 2026-10-01 · category: Infrastructure · tags: AI Gateway, Go, Rust, LLM Routing, MCP, Next.js
_High-throughput OpenAI-compatible LLM gateway, MCP SSE server, and multi-model consensus routing engine._
## Overview

Helium (`router.y7.hk`) is an enterprise-grade LLM API gateway and orchestration engine built to provide unified, resilient access to 40+ frontier AI models. Designed as a drop-in OpenAI-compatible proxy (`/v1`) and Model Context Protocol (MCP) SSE host, Helium unifies routing across Google Antigravity (Gemini 3.8 & Claude 4.6), Xiaomi MiMo, DeepSeek V4, Alibaba Qwen, and xAI Grok under a single authenticated interface.

## Key Architecture & Features

- **Antigravity Protocol Alignment:** Deep integration with Google Cloud Code internal APIs featuring singleton account pooling, thinking-budget auto-rescaling, and continuous 3-second SSE heartbeats.
- **Thinking Dropout Auto-Healing:** Proprietary stream interception that detects empty reasoning terminations (`STOP` with 0 content tokens) and auto-completes requests seamlessly in the same connection without client drops.
- **Wave Multi-Model Consensus Engine:** Orchestrates multi-expert parallel reasoning (up to 4 tiers including multi-stage pipelines) synthesized in real time into authoritative responses.
- **Native MCP Server:** Full SSE transport implementation exposing database metrics, latency benchmarking, and automated key lifecycle tools directly to AI coding agents.
- **High-Velocity Telemetry:** Nothing Phone-inspired telemetry dashboard built with Next.js 16 and GSAP, visualizing 10-second rolling token speed, live in-flight sessions, and token routing Sankey flows.

## Results & Impact

Helium acts as the central intelligence nervous system across all internal AI agents and coding tools, processing millions of tokens daily with sub-second failover recovery, automatic quota defense, and zero-downtime hot reloading.

---

### [Lab3 Web3 Studio](https://y7.hk/projects/lab3/)
date: 2024-11-01 · category: Agency · tags: Web3, Studio, GTM, Protocols
_A product studio shipping Web3 infrastructure and go-to-market for early-stage protocols._
## Overview

Lab3 is a specialized product and venture studio that partners with early-stage Web3 founders to design, build, and scale decentralized infrastructure from scratch. We combine battle-tested smart contract engineering with tokenomics advisory and localized go-to-market execution across key Asian and Western markets.

## What We Do

- **Full-Stack Protocol Engineering:** Custom EVM contracts, cross-chain messaging, and scalable backend indexers.
- **Go-to-Market & Launch Strategy:** Token launch mechanics, liquidity bootstrapping, and community architecture.
- **Security & Auditing Preparedness:** Rigorous testing pipelines, invariant testing, and audit facilitation with Tier-1 security firms.

## Case Highlight

When building out cross-chain settlement modules for liquidity providers, we reduced user transaction latency by 42% while retaining provable on-chain settlement guarantees.

---

### [Zuo Marketing 作营销](https://y7.hk/projects/zuo-marketing/)
date: 2024-08-15 · category: Marketing · tags: Marketing, APAC, Growth, Community
_Growth and community marketing for crypto projects across APAC markets._
## Overview

Zuo Marketing specializes in penetrating high-barrier APAC crypto markets including Hong Kong, Singapore, South Korea, and Southeast Asia. We bridge Western protocol teams with regional crypto communities through culturally tuned messaging, narrative distribution, and deep influencer relationships.

## Capabilities

- **Localized Narrative Strategy:** Adapting complex crypto mechanics into compelling, market-specific narratives for regional traders and builders.
- **KOL & Media Orchestration:** Direct relations with crypto Twitter KOLs, YouTube educators, and regional media outlets.
- **Telegram & Discord Community Operations:** 24/7 bilingual community management, engagement campaigns, and event hosting.

---

### [Loore Web3 Social Network](https://y7.hk/projects/loore/)
date: 2024-06-01 · category: Social · tags: Web3, Social, Identity, NFT
_Decentralized social platform where creators own their graph and monetize content._
## The Challenge

Traditional social networks own user data and monetize attention without fair compensation for creators. Loore was designed to solve this by building a protocol where users own their social graph and content creators receive diverse revenue streams directly from their audience.

## The Solution

We developed a robust architecture using Next.js for the frontend and Solidity smart contracts on the backend:

- **Decentralized Identity (DID):** Users retain sovereign control over their profiles, reputation, and data.
- **Token-Gated Communities:** Exclusive membership spaces for verified token and NFT holders.
- **Native Creator Monetization:** On-chain tips, subscriptions, and digital collectible showcases.
- **Privacy First:** Zero-knowledge primitives for selective profile disclosure.

## Results

The beta launch saw over 50,000 unique wallet connections in the first month. Community engagement increased by 300% compared to traditional benchmarks, proving that users value ownership and transparency.

---

### [TelegramLab](https://y7.hk/projects/telegramlab/)
date: 2024-05-10 · category: Toolability · tags: Telegram, Automation, Analytics, Bots
_Automation and analytics tooling for Telegram communities and channels._
## Overview

TelegramLab builds infrastructure-grade automation bots, moderation systems, and real-time analytical dashboards for high-throughput Telegram groups and channels. Built with Python and modern asynchronous architectures, it handles millions of events daily with sub-second response times.

## Key Features

- **Autonomous Anti-Spam & Fraud Shield:** Machine-learning powered spam filters that detect adversarial crypto scam scripts in real-time.
- **Member Funnel Analytics:** Cohort tracking, activity decay curves, and engagement scoring across multi-language communities.
- **Automated Air-Drops & Reward Routing:** Cryptographic verification and instant Telegram-native reward distributions.

---

### [Journal](https://y7.hk/projects/journal/)
date: 2024-03-01 · category: Personal · tags: Essays, Travel, Building, Life
_A long-form writing project on technology, travel, and building products._
## Overview

Journal is an open archive of essays, architectural breakdowns, and field notes written while living and working across four continents. It documents the real friction of building products, navigating Web3 cycles, and maintaining deep creative focus while traveling through 65 countries.

## Topics Explored

- **Systems Architecture & Agents:** Engineering reflections on durability, interface design, and agent coordination.
- **Cross-Cultural Product Design:** What building between Shenzhen, Hong Kong, and Southeast Asia teaches you about product mechanics.
- **Travel Notes & Living Without Borders:** Observations on global talent hubs, nomad infrastructure, and lifestyle design.

---

### [Oplata](https://y7.hk/projects/oplata/)
date: 2024-01-20 · category: Fintech · tags: Fintech, Payments, Crypto, Stablecoins
_Cross-border payments and settlement experiments for the crypto-native economy._
## Overview

Oplata explores payment rails for frictionless cross-border commerce, enabling instant stablecoin settlement directly into localized fiat rails across emerging markets. Built with security-first primitives and unified API interfaces.

## Key Focus Areas

- **Hybrid Settlement Rails:** Bridging on-chain USDT/USDC deposits with instant local clearing (FPS, PromptPay, Pix).
- **Merchant API & Webhooks:** Developer-friendly SDKs and idempotency-guaranteed webhooks for e-commerce platforms.
- **Compliance & AML Automation:** Real-time on-chain transaction monitoring and automated wallet risk scoring.

---