I'm a maxillofacial surgeon in Ouagadougou, Burkina Faso — and a self-taught builder who's been coding since medical school. Over evenings and weekends, I shipped Readium — a production AI reading app that lets you discuss books with Claude while you read them, in any language. Built AI-paired with Claude, reviewed and deployed by me.
Most "I shipped an AI app" write-ups cover the happy path: clone a starter, glue an LLM, deploy to Vercel. The walls I hit weren't there. They were in the spaces between the libraries.
Here are five of them — and what I'd tell myself a few weeks ago.

Wall 1 — SSE streaming broke at the seam between the LLM and the browser

I assumed streaming "just worked" once OpenRouter returned a stream. It does — until your server-side handler, your reverse proxy, or your browser code introduces a buffer somewhere along the path.
The chain has at least three places where buffering can silently kill streaming:
The LLM API (fine on its own)
Your Node server-side handler (fine if you forward chunks instead of accumulating them)
The reverse proxy / CDN (often buffers entire responses by default)
The failure mode is always the same: the UI looks exactly like the LLM is slow. It isn't — somewhere between OpenRouter and the browser, bytes are being withheld until the connection closes, then dumped in one chunk.
What I'd tell past-me: streaming isn't a feature of the LLM, it's a property of your entire request path. If you can't watch tokens land character-by-character in curl -N against your origin, you don't have streaming, you have a slow non-stream pretending. Set Cache-Control: no-transform and X-Accel-Buffering: no headers from your handler, disable response buffering on every layer in front of it, and verify with curl -N before you trust the UI.

Wall 2 — fetch hangs forever on certain hosts (and the fix isn't where you think)

I had a proxy route that fetched from an external API. Worked locally. Worked in staging. Deployed to production: the route would hang for ~60 seconds, then time out. No errors. No logs. Just silence.
I spent two days blaming my code. Two days.
The bug was in undici, Node's built-in fetch implementation. When the remote host's DNS returns both IPv6 and IPv4 records, undici picks IPv6, opens a TCP connection, and waits. If the route between your container and that IPv6 address is broken (which it commonly is on VPS networks), there's no timeout — undici just sits there.
The fix is to bypass fetch and use the lower-level node:https with family: 4 to force IPv4:
import https from "node:https";
https.get(url, { family: 4, timeout: 10_000 }, (res) => {
// ...
});

What I'd tell past-me: when a network call hangs silently in production and works locally, suspect IPv6 before suspecting your code. This has been a real, undocumented production issue across the JS ecosystem since undici became the default in Node 18.

Wall 3 — The platform shows "Published" while functionally serving empty receipts

I had two products live on Gumroad. The dashboard showed them as published. I almost moved on to writing the launch post.
Ran one final API audit before announcing. The products were returning file_info: {}, covers: [], custom_receipt: "", and published: False under the hood. Zero files attached for any actual buyer. The dashboard UI had been showing "Published" while the underlying flag had silently flipped.
It turned out that every PUT against /v2/products/{id} that touched the description was wiping the uploaded files, the custom receipt template, and the published flag. There was no notification, no email, no warning. If a paying customer had bought during that window, they'd have paid $29 and downloaded literally nothing.
The fix took five minutes. The "how is this not in their docs" moment took a full weekend.
What I'd tell past-me: a product can pass every UI signal of being shippable while being functionally broken. Run an end-to-end check (API audit or self-buy) the day before any launch — and after any "harmless" edit you didn't realize was destructive.

Wall 4 — The cover said "80 pages" — but pandoc kept making it 83
I'd designed my ebook cover in SVG with "80 pages" as a visible design element. By the time the final build came out it was 83 pages — pandoc adds frontmatter, LaTeX adds a titlepage, both of which sneak in.
I tried to fudge the markdown to land back at 80 pages. I tried adjusting LaTeX margins. Three iterations later I was at 81, then 84, then 82. The cover had become a tax on every future rebuild.
The fix was a one-line edit on the SVG: I replaced "80 pages" with "field manual". The cover became stable across page-count drift. I updated marketing copy from "80 pages" to "83 pages" and moved on.
What I'd tell past-me: don't put fragile facts on your cover. The cover should compress your positioning, not commit you to a number that drifts every time you rebuild.

Wall 5 — I built the product, then realized I didn't know how to be found

The product was live for weeks before anyone outside my immediate network heard about it.
I'd separated "engineering" (safe, virtuous, what I knew) from "marketing" (cringe, salesy, what I didn't). So I kept shipping features and writing nothing public. The distribution half of the loop simply wasn't there.
This week, a non-technical founder on Indie Hackers gave me a reframe I haven't been able to forget. She wrote:
They're the same thing if the engineering is honest enough.
She meant the line I'd been drawing between "writing about my technical decisions" and "marketing my product" doesn't actually exist when the engineering is being written about truthfully. I'd been spending months treating them as separate tracks — calling one "documenting" (safe, virtuous) and the other "selling" (cringe). That false dichotomy was the thing keeping me silent.
This article is me testing the reframe in public.
What I'd tell past-me: you don't need to add a separate marketing track on top of engineering. You need to publish what you already know, honestly, where people who care end up reading.

What I'd actually do differently

If I could redo the past few weeks, I'd do exactly two things differently:
Write the public technical posts from week one, not at the end.
Self-buy my own product after every change to it — including the changes I think can't possibly break it.
Everything else, including the painful parts, was load-bearing.
I packaged what I learned into a field manual called "Building AI-Native Reading Apps" — 83 pages, 10 chapters covering OpenRouter streaming, the undici IPv4 fix, entity extraction, Gutenberg bulk ingestion, and the rest of the walls above in code-level detail. AI-paired with Claude, reviewed and verified by me. If you're shipping your own AI app and want this in one place: limack.gumroad.com/l/ai-reading-apps. Free Chapter 1 sample (the SSE streaming pipeline) is on the page before you