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
Top comments (6)
Love the build-from-West-Africa angle, the walls you hit are usually invisible to people building from a US-centric default: latency to model APIs, payment rails that assume Stripe-everywhere, and bandwidth costs that make heavy frontends a real barrier for your users. Those constraints actually make you a better engineer because you can't paper over them with money. The unglamorous middle (auth, payments, deploy) is exactly where solo builders stall, and it's harder when the defaults don't fit your region. That gap is what I built Moonshift to close. Which of the 5 walls cost you the most time, the technical one or the go-to-market one?
The go-to-market one — by a wide margin. The technical walls were frustrating but bounded: you hit the bug, you dig, you find the workaround. The IPv6 hang took a weekend. The Gumroad PUT-wipes-files disaster took an afternoon once I finally read the API response carefully. The GTM wall has no stack trace. No equivalent of "check line 47." You're pricing in USD on a continent where most of your potential users don't have a Stripe-compatible card, pitching to a developer audience that's learned to distrust bootstrapped products, and trying to build credibility without a recognizable brand behind you. That's still unresolved for me — I'm two weeks in, 0 sales, fully honest about it in the article. The "can't paper over with money" framing hits exactly right. I'd add: it also means you can't paper over the GTM gap with growth hacking. You actually have to earn it.
Curious what you ran into with Moonshift — "unglamorous middle for builders outside US" sounds like exactly the same surface. Was payments the deepest part for you?
Payments was the single deepest part, yeah, your stack-trace-less GTM wall but with a technical floor under it. The technical side was bounded the way you describe: each integration had a bug you could dig out (the IPv6 hang, a provider that silently wiped files on a PUT, webhook signatures that didn't match the docs). The unbounded part was getting money in from outside the US/EU rails, your no-Stripe-compatible-card point is the whole thing. You build the checkout, it works in test, and then the actual users can't pay with what they have, and there's no line 47 to fix because the problem is the rails, not the code. The bitter lesson I took: payments isn't a feature you finish, it's a market-access problem disguised as an integration, and you re-solve it per region. Two weeks in at 0 sales and being honest about it in the post is the right move, that credibility is worth more than a fake traction number. The GTM-can't-be-papered-over-with-growth-hacking line is exactly it. Curious which rail you're betting on for the West Africa audience, mobile money, or trying to bridge to card anyway?
Honest answer: both, but split by audience. For the global dev product (the ebook + the template) I lean on Gumroad as merchant-of-record — it eats the card/tax/VAT complexity so a buyer in Berlin or São Paulo just pays, and I never touch a Stripe account I couldn't open from here anyway. That's the "bridge to card" path, and it only works because someone else is the MoR.For the local audience — med students in Ouaga on the edtech platform — it's mobile money, full stop. Orange Money / Moov, not card. Nobody's reaching for a Visa to pay for study tools here.Your "re-solve it per region" line is exactly the scar. The painful part is they're not one product with one checkout — they're two completely different payment realities wearing the same codebase. What did you land on for Moonshift — did you abstract the rail, or pick one and commit?
This is one of the most practical AI product-building posts we've read recently. The lessons around SSE streaming, infrastructure quirks, and validating the entire user journey before launch are especially valuable. We also appreciate the point about distribution, many founders focus on building and forget that documenting the journey is often the most authentic form of marketing. Thanks for sharing the real-world challenges behind shipping an AI product.
Thanks — the "document the journey is the marketing" point is the one I keep relearning. Appreciate you reading it.