Application work sample · Celeste Deng
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.
Product and competitor research
My current hypothesis: Sub2API should not position itself like ZenMux or OpenRouter on Day 1. Its sharper wedge is self-hosted subscription-to-API infrastructure for technical operators who care about cost control, account control, and OpenAI-compatible integration.
Good reference for trust signals and doc structure. But Sub2API Day 1 shouldn't copy their positioning — the ops model hasn't been validated overseas yet, and overclaiming costs trust, not builds it.
This feels like the sharper entry point. The users here already feel the pain of account pools, costs, and compatibility — they're either DIY-ing or looking for something ready.
Useful for reading demand signals and messaging. Dangerous as a truth source — reliability and support vary wildly, and some disappear overnight.
User research translation
The strongest early wedge is not "one API for everyone." It is serving technical operators who already feel the pain of account pools, cost control, OpenAI-compatible integration, and unreliable middlemen.
Pain: Official API cost feels high, third-party relays can fail suddenly, and self-hosting Sub2API/new-api is not trivial.
Need: A low-cost, controllable path with clear deployment steps and realistic failure expectations.
→ If the first product surface sells a dream without explaining deployment, account setup, health checks, and common failure modes, this person bounces.
Pain: Multiple providers means multiple keys, bills, dashboards, owners, and random 2am failure points.
Need: One entry point, per-person or per-key usage visibility, key rotation, and fallback behavior.
→ If the dashboard opens with decorative admin UI instead of usage, keys, logs, health, and fallback state — this team won't stick around.
Pain: Account pools, token-level billing, concurrency limits, upstream instability, balances, logs, and alerts are the real work.
Need: A mature operations system for account scheduling, billing, rate limits, monitoring, and audit trails.
→ These people are probably not starting with a demo. They're reading the runbook. Slogans don't work on them.
Pain: Cursor, Cline, Claude Code, Aider, chat UIs, and agent frameworks should not each need separate provider configs.
Need: A stable OpenAI-compatible Base URL, clean /models behavior, predictable errors, and minimal setup.
→ If the docs lead with a feature list instead of Base URL, auth, /models, chat completions, error model, and compatibility limits — the page is useless to them.
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
Community view: cliproxyapi, sub2api, and new2api are compared; Sub2API looks more suitable for scaled proxy/share scenarios, while personal lightweight use may choose a smaller tool.
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
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
Real integration case: an Edge extension plus local backend for X video subtitle translation supports Sub2API or other OpenAI-compatible APIs.
Concrete integration caveat: xAI /models did not return Grok Composer 2.5 Fast, but directly specifying the model name worked through a hermes-proxy style setup.
How are credits calculated? Where do top-ups go? What does a single request cost? Who owns the upstream account? Refresh-token locking, sticky session behavior — these aren't UI concerns, they're where production incidents happen. Map the operating model first, then design the display surface.
Reference links
Flip through the GitHub issues and pull out the real operational pain points: real client IP not showing up, env drift, DB init failures, unclear multi-instance limits. The dashboard skeleton should solve these, not look good. Start with the issue that has the most people stepping on it.
Reference links
By now we've run the deployment, read the issues, and mapped the billing. The public page that comes out of this isn't speculation — it knows where the boundaries are. Self-hosting, private-use scenarios, admin compliance acknowledgement, upstream ToS risk. Not the 'safe and fully compliant' marketing version.
Reference links
Latest community signal: Sub2API added a deployment and operations compliance acknowledgement, which matters for overseas/share scenarios.
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
Production-style self-hosting signal: after OpenAI account risk, Sub2API was used to turn subscriptions into API access on a Mac Mini with multiple accounts and external access through Surge Ponte.
Multi-service operations signal: Sub2API can coexist with new-api and cc-switch, which also means operator complexity grows quickly.
Real integration case: an Edge extension plus local backend for X video subtitle translation supports Sub2API or other OpenAI-compatible APIs.
I also wrote an API contract sample — a demonstration of the endpoint design, billing fields, error model, and developer surface I'd deliver.
These didn't make it into a specific day, but helped me understand the surrounding ecosystem and what can go wrong.
Sub2API-derived gateway direction; useful as ecosystem signal, not official Sub2API truth.
Session conversion utility; useful for understanding import needs and token-expiry risk.
Available full-time from early July · WeChat: DM me anytime, or I'll reach out for a 20-minute call.