Application work sample · Celeste Deng

Hi Jason,

I read your post as: Sub2API is a strong technical project that needs someone to turn it into a product surface overseas users can actually understand and use. So I skipped the polished marketing demo and broke out what I'd really own in Week 1.

My read after quick research

  • Sub2API is an account-pool gateway — API keys, billing, routing, admin ops, and compliance pressure layered together. This is more than a proxy.
  • The hard early surface is developer trust: deployment clarity, OpenAI-compatible contract, sticky sessions, request attribution, transparent usage. These matter more than a pretty page.
  • Community posts are useful demand signals, but the truth source for product and ops decisions lives in the official docs, releases, and GitHub issues.
  • So Week 1 becomes a validation sprint — run the deployment, read the issues, write the runbook, and only then commit to page details or distribution claims.
Day 1

Validate the repo truth source and positioning boundary

Don't start with pages. Day 1 is about nailing a few things: what Sub2API can do now, what it can't overclaim. Who the first overseas users would be. Which use cases are safe to talk about publicly and which aren't.

Reference links

Day 2

Run a controlled self-hosted deployment and write the runbook

Before writing any public copy, get the boring path working: prerequisites, PostgreSQL, Redis, Docker, reverse proxy quirks, secrets, health checks — and a post-launch verification checklist. Public copy comes after deployment is understood.

Reference links

Day 3

Write integration docs from real compatibility needs

Don't design docs in a vacuum. Dig into how people actually integrate with Sub2API — x-video-translator's approach, model listing gaps, endpoint quirks — and use those signals to structure the docs. Less guessing, more signal.

Reference links

Day 4

Map usage, billing, payment, and account lifecycle risks

Billing isn't just UI. I need to map the real operating model: how credits are calculated, where top-ups go, per-request costs, upstream account ownership, refresh-token locking, and sticky session behavior. These are where production incidents happen.

Reference links

Day 5

Prioritize the dashboard around operations, not decoration

A dashboard skeleton shouldn't start from UI ideas. Start from real operator pain — real client IP, env drift, DB health, multi-instance limits, API keys, and usage at a glance. Source these from the actual GitHub issues.

Reference links

Day 6

Only then write the public site and SEO-safe explanation

Once the tech and risk boundaries are clear, the public page knows where the sharp edges are. Self-hosting, private use, admin compliance acknowledgement, upstream ToS risk — explain these. Stay away from over-promising language like 'fully legal' or 'risk-free'.

Reference links

Day 7

Start the feedback loop with community signals

Community posts are demand signals, not technical truth. The patterns worth paying attention to: self-hosting, multi-account setups, external access, tool integration, and multi-service operator stacks — these map to real production scenarios.

Reference links

I also wrote an API contract sample — a demonstration of the endpoint design, billing fields, error model, and developer surface I'd deliver.

Read the API contract →

Additional reference signals

These didn't make it into a specific day, but helped me understand the surrounding ecosystem and what can go wrong.

Available full-time from early July · WeChat: DM me anytime, or I'll reach out for a 20-minute call.

中文版  ·  ← Back to resume