DEV Community: Harvey He

"Your first 100 users are reading your launch post. This one mistake loses most of them."

Harvey He — Thu, 17 Sep 2026 22:04:32 +0000

I shipped a product last year and got 12 users from my launch post. Twelve. Not because the product was bad. Because the post read like the model that wrote it.

Three months later I rewrote it like a person would talk, kept the same product, same link. Got 140. Same traffic, ten times the pull.

Here's the mistake, and how to fix it without spending a day.

The mistake: you described the product, not the reader

Most launch posts open with what the thing does. "An AI tool that helps you write better copy." That sentence is true and useless. The reader's brain files it under "another AI tool" and scrolls.

The posts that converted for me did the opposite. They opened with a moment the reader already lived through:

"You spent two hours writing your Product Hunt draft and it still sounds like a press release."

That line got replies. Because someone read it and thought "yeah, that was this morning."

The fix is smaller than you think

You don't need a copywriter. You need to move one sentence.

Take your current first paragraph. If it mentions your product name or what it does, that's the problem.
Replace it with a specific thing your user does badly, in their own words. Pick the most annoying one.
Keep the rest. Don't rewrite the whole thing.

That's it. One sentence moved. The rest of your post was probably fine.

Where non-native English founders get stuck

If English isn't your first language, this is harder, not because you write badly, but because the AI draft you start from is smooth and wrong in the same way every time. It uses words like "leverage" and "seamless" that mark you as a template instantly.

The trick isn't better English. It's fewer impressive words. "Our tool helps you" beats "Our robust solution empowers." Every time.

I got tired of doing this by hand on every post, email, and reply, so I built a small thing, ShipCopy, that takes the draft and returns the human version. Paste, get it back, ten free uses, no card. It won't write your product. It just takes the robot edges off what you already wrote.

launchcraft.io

What's the launch post you're stuck on right now? Link it in the comments, I'll tell you which sentence to move.

"Streaming through an OpenAI-compatible proxy: 6 bugs that only show up in production"

Harvey He — Thu, 17 Sep 2026 03:16:10 +0000

I run a small OpenAI-compatible gateway. Non-streaming requests worked on day one. Getting streaming right took me about three weeks of bug reports from my own tools.

The annoying part: every bug below passes unit tests. They only show up with a real client, a real network, and a model that thinks for 30 seconds before saying anything.

Here's what broke, and the code that fixed it.

1. `chunk["choices"][0]` throws IndexError

If you pass stream_options: {"include_usage": true}, OpenAI sends a final chunk that carries token counts and an empty choices array:

{"choices":[],"usage":{"prompt_tokens":412,"completion_tokens":88,"total_tokens":500}}

Any code that assumes choices[0] exists dies right there, at the very end of the stream, after the user already read the full answer. Worst possible moment to 500.

async for chunk in upstream:
    if not chunk.get("choices"):
        if chunk.get("usage"):
            record_usage(user, chunk["usage"])
        continue
    delta = chunk["choices"][0].get("delta", {})

Second half of this bug: not every upstream supports include_usage. SiliconFlow honors it, some others accept the field and silently drop it. If billing depends on that final chunk, you need a fallback. I run tiktoken on the accumulated text when no usage chunk shows up, and mark the record as estimated.

2. TCP doesn't care about your event boundaries

An SSE event is data: {...}\n\n. A single read() gives you half an event, or three events glued together. If you do line.split("data: ")[1], sooner or later you hand truncated JSON to json.loads and the whole stream dies on one packet boundary.

Buffer until you see the blank line:

buf = ""
async for raw in upstream.content.iter_any():
    buf += raw.decode("utf-8", "ignore")
    while "\n\n" in buf:
        event, buf = buf.split("\n\n", 1)
        for line in event.splitlines():
            if not line.startswith("data:"):
                continue
            payload = line[5:].strip()
            if payload == "[DONE]":
                return
            yield json.loads(payload)

That buf variable is the entire trick. Two details: some upstreams send [DONE] without a trailing newline, so flush the leftover buffer on exit; and decode on a raw bytes chunk can split a multi-byte UTF-8 character in half. Use an incremental decoder or accept "ignore" and lose the occasional character in a Chinese or emoji response. I lost a few characters before switching to codecs.getincrementaldecoder("utf-8")().

3. `tool_calls` arrive in pieces and you merge by `index`, not `id`

This one cost me a weekend. When the model calls a function, arguments stream in as fragments:

{"delta":{"tool_calls":[{"index":0,"id":"call_a1","type":"function","function":{"name":"get_weather","arguments":""}}]}}
{"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"ci"}}]}}
{"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ty\":\"Xi"}}]}}
{"delta":{"tool_calls":[{"index":0,"function":{"arguments":"'an\"}"}}]}}

id and name appear only in the first fragment. Later fragments carry index and nothing else. Key your accumulator on id and you end up with one tool call whose id is None and a JSON string you can't parse.

Key on index:

calls = {}
for tc in delta.get("tool_calls", []):
    i = tc.get("index", 0)
    slot = calls.setdefault(i, {"id": "", "name": "", "arguments": ""})
    if tc.get("id"):
        slot["id"] = tc["id"]
    fn = tc.get("function") or {}
    if fn.get("name"):
        slot["name"] = fn["name"]
    slot["arguments"] += fn.get("arguments") or ""

Then json.loads(slot["arguments"]) once the stream ends. And note that parallel tool calls use index 0, 1, 2. If you keep a single slot you silently drop the second and third call. Coding agents hit this path constantly, which is why "the model said it edited the file but nothing changed" is usually a proxy bug, not a model bug.

4. You cannot retry after you've sent the headers

My failover logic originally retried on any error. But once you've written 200 OK and streamed 40 tokens to the client, there is no retry. The status line is already gone. You can drop the connection or emit a fake error event, and both look like a crash to the user.

So I added a first-token gate: don't commit the response until the first byte from upstream arrives.

async def open_upstream(body):
    for ep in (PRIMARY, FALLBACK):
        try:
            r = await client.post(ep, json=body, timeout=8)
            first = await asyncio.wait_for(r.content.__anext__(), timeout=8)
            return r, first          # now it's safe to send 200
        except Exception as e:
            log.warning("upstream %s died before first byte: %s", ep, e)
    raise HTTPException(502, "all upstreams down")

Before this, mid-stream failures ran around 1 in 300 requests. After, failures moved to the window before any user-visible output, which the OpenAI SDK retries on its own. Broken answers went to effectively zero.

One caveat. Reasoning models can sit quiet for 20 to 30 seconds while they think, so a flat 8-second gate kills them. I use 8s for models I know start fast and 30s for the reasoning ones. Measure yours, don't copy mine.

5. Idle connections get killed by whatever sits in front of you

Long think time with zero bytes on the wire means someone hangs up. Nginx defaults to a 60-second read timeout. Cloudflare is stricter. The user sees a truncated answer and blames your service.

Fix: send an SSE comment line every 15 seconds. It's a spec-valid no-op and the OpenAI SDK skips it.

HEARTBEAT = b": ping\n\n"

Race the upstream read against a 15s timer and write the comment when the timer wins. Also set X-Accel-Buffering: no on your own response. Without that header nginx buffers your carefully streamed chunks into one blob, and the user waits for the entire answer anyway. One header, and the stream suddenly feels fast.

6. When the client leaves, cancel the upstream

The user closes the tab halfway through. Starlette gives you await request.is_disconnected(), but while you're iterating the upstream body you never check it. The upstream keeps generating, you keep paying, and it holds a connection slot.

async for chunk in upstream_stream:
    if await request.is_disconnected():
        await upstream_stream.close()
        break
    yield chunk

I found a few hundred of these zombie reads in one day of logs, after a frontend bug spammed reconnects every second. Cheap to fix, real money at scale.

The 30-second way to see all of it yourself

Skip the SDK and look at raw bytes:

curl -N https://keheai.com/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-ai/DeepSeek-V3","stream":true,
       "stream_options":{"include_usage":true},
       "messages":[{"role":"user","content":"count from 1 to 5"}]}'

-N disables curl's own buffering. You'll see the chunk boundaries as they land, plus that empty-choices usage chunk at the end. Twenty seconds of this teaches more than a day of reading SDK source.

Every bug on this list lives in the gap between "OpenAI-compatible" and actually compatible. The spec is loose, the SDKs are forgiving, and failures only appear when someone's workflow depends on the stream finishing.

I built this gateway into keheai.com. It's the same ~200 lines of Python, now serving a few small teams, free tier is 330k tokens if you want to poke at it.

"Your AI launch post reads like a robot. Here's the 10-minute fix."

Harvey He — Wed, 16 Sep 2026 16:06:33 +0000

You pasted your product into ChatGPT, asked for a launch post, and got something that starts with "In today's fast-paced digital landscape." Nobody reads past that line.

I've done this for every launch I ship. The model gives you smooth, correct, forgettable text. The fix isn't a better prompt. It's knowing the five habits that make AI writing sound like a person wrote it.

Here's what I actually change before anything goes live.

1. Kill the hedge words first

AI loves a certain vocabulary. These show up in almost every draft:

leverage, robust, seamless, delve, navigate, unlock, empower, supercharge, game-changer, in today's [X] landscape

They say nothing. Replace "leverage our robust API" with "our API handles it." One real verb beats three abstract nouns.

Before: "We leverage a robust, seamless pipeline to empower your team."
After: "Our pipeline does the work so your team doesn't have to."

2. Vary your sentence length

AI writes in the same rhythm: medium sentence, medium sentence, medium sentence. Human writing lurches. Short. Then a longer one that explains the short one.

Try this on any paragraph: make at least one sentence under six words. It changes how the whole thing feels.

3. One outcome, not a feature list

The draft will give you five bullet points. Pick the one thing the reader gets. The rest go in docs, not the pitch.

Bad: "Fast, secure, scalable, affordable, easy to integrate."
Good: "Ships in an afternoon, not a sprint."

4. Write like you're explaining it to a friend

Read the sentence out loud. If you'd never say it that way in a call, rewrite it. "Utilize" becomes "use." "Facilitate" becomes "help." This one habit removes most of the robot smell.

5. Specific numbers beat vague upside

"Improve your workflow" means nothing. "Cut deploy time from 40 minutes to 6" means everything.

If you don't have the number yet, say what you're measuring. Honesty reads as human.

The part that used to eat my time

Doing this by hand on every launch post, every email, every Product Hunt reply added up to real hours. So I built a small tool, ShipCopy, that takes the AI draft and returns copy that sounds like a person wrote it. Paste text in, get the human version back. Ten free uses, no card.

It won't write your product for you. It just takes the robot edges off what you already have.

If you want to try it: launchcraft.io

What's your go-to trick for de-roboting AI text? Drop it in the comments, I'm collecting them.

用 200 行 Python 搭一个 OpenAI 兼容网关（双上游自动容灾）

Harvey He — Mon, 31 Aug 2026 16:51:26 +0000

上周 DeepSeek 官方接口凌晨抖了 20 分钟，我一个跑批任务全红了。那天之后我决定不再把命系在单个供应商上。

如果你也用 OpenAI SDK 调 DeepSeek / Qwen，最省事的容灾方案不是重写代码，而是前面挡一层 OpenAI 兼容网关：换 base_url 就行，业务代码一行不动。

我是这么搭的（约 200 行 Python + FastAPI）：

统一 /v1/chat/completions 入口，把请求转给上游
配两个上游：硅基流动（主）+ DeepSeek 官方（备）
主上游超时 8 秒或返回 5xx，自动切备
每用户配额和日志落在本地 SQLite

核心切换就 20 行：

async def chat(request, user):
    for upstream in [PRIMARY, FALLBACK]:
        try:
            return await forward(upstream, request, timeout=8)
        except (TimeoutError, Upstream5xx):
            log(f"switch {upstream} -> next")
            continue
    raise HTTPException(502)

踩过的坑：

上游返回的 usage 字段名不一样，要统一成 OpenAI 格式，不然你的 tokenizer 算错
流式为 SSE，切上游时要保证已发出的 chunk 不被截断
配额别用 float 存，用整数 token 数，否则并发下会出现负额度

如果你不想自己维护这套，也可以用现成的 keheai.com —— 双上游容灾、免费 33 万 tokens 试用、自助发 key。我搭它就是为了自己用，顺手开放出来。

你想自己搭的话，上面这套够跑中小流量了。要压测脚本我也可以发。