Six months ago, I published a Dev.to article called "How I built a 100% offline Second Brain for engineering docs using Docker + Llama 3 (No OpenAI)."
It worked.
- 380 reads on day one
- 7 bookmarks, 11 reactions, the works
- Top Docker Author Badge of the week 🏆
- A comment thread that actually went somewhere — someone suggested docling, someone else brought up the EU AI Act
For a brand-new Dev.to account with two articles to its name, this is the kind of result that makes you think you've cracked something.
The product it linked to — a $59 Dockerized RAG toolkit on Gumroad — has sold 1 copy in the six months since.
This isn't a "how I failed" post. The article didn't fail. The product didn't really fail either — it just didn't do what the article suggested it would. The gap between those two outcomes is the entire post.
How the article went viral
Looking back, the article hit three buzzwords that the Dev.to algorithm loves stacked together: Llama 3, Docker, and "No OpenAI." Add #python, #ai, #docker, #automation as tags and you're hitting four high-traffic feeds at once.
The contrarian framing helped. "No OpenAI" isn't a neutral technical choice — it's a position. Positions get bookmarks.
The structure was clean: a relatable pain (you can't paste NDA-protected schematics into ChatGPT), a clear stack (Ollama + ChromaDB + Streamlit), a docker-compose snippet that looked copy-pasteable, and an honest section about the hard parts (PDF parsing, context window limits, Docker networking on GPU).
I'm not going to pretend the article was lucky. It was structurally good content. The reads were earned.
What I want to talk about is what I thought those reads meant.
Here's the part most "building in public" posts skip
I didn't start with a problem. I started with a market.
As an indie maker with a full-time job and two kids, I have maybe 8–12 hours a week for side projects. I needed a product that could actually sell. I noticed Local LLM tutorials were getting strong traction on Dev.to, and I made what felt like an obvious assumption:
Engineers handle sensitive datasheets every day. Privacy must be a real pain point. So a self-hosted RAG with no cloud dependency must be something they'd pay for.
That assumption felt obvious. It wasn't.
I want to be specific about what was wrong with it, because the error wasn't "Local LLM is a bad market" — it might be a fine market for someone else. The error was that I confused a problem I could imagine engineers having with a problem engineers actually pay to solve.
Those aren't the same thing.
Three signals I missed at the time
Signal 1: I wasn't using my own product
The first signal I should have noticed was the most embarrassing one. I built a Local RAG to keep engineering datasheets off the cloud. My own company has zero IT restrictions. We paste datasheets into ChatGPT every day. Nobody cares.
If I had genuinely needed the product, I would have used it for six months and refined it from real friction. I didn't. After the initial demos, the Docker stack sat there.
This is the founder version of writing a recipe you've never cooked.
Signal 2: Six months, one sale
The product launched alongside the article. Six months later: one paying customer at $59.
One.
Not "low-conversion-funnel" one. Just one.
Signal 3: The feedback from that one customer was sharper than the badge
A few months in, that customer sent me an email. Two points, paraphrased but accurate to his original frustration:
- The demo video shows a Mandarin UI, but the Python product is in English. They don't match up.
- "Enterprise-grade"? I assumed it included auth and permission management. It doesn't. This is just for solo / small-office use, right?
Now, here's the thing: I never literally used the word "enterprise-grade" in the title. The product is called "Local AI Knowledge Base: Dockerized RAG — Lite Edition."
But "Knowledge Base" + "Lite Edition" implies a Pro / Enterprise tier exists. He's not wrong to expect that. The naming wrote a check the product couldn't cash.
He wasn't being hostile. He was correcting me. And he was right on both counts:
- A Mandarin demo video for a product sold globally on Gumroad is a localization gap I never even thought about.
- "Lite Edition" implies a ladder. There was no ladder. There was just one rung labeled "Lite."
That email taught me more about my product than the Top Docker Author Badge did.
What the data actually says
Let me lay both metrics side by side, because once you see them together the lesson is hard to miss:
| Metric | Result |
|---|---|
| Reads | 380+ (day one), still trickling |
| Reactions | 11 (7 bookmarks) |
| Top Docker Author Badge | Yes |
| Reading list saves | 11 logged readers |
| Paying customers | 1 |
| That customer's price point | $59 |
| That customer's feedback | Naming was misleading, localization was off |
The first five rows measure how good the article is. The last three measure whether the product is worth paying for.
These are unrelated experiments. Bookmarks don't predict sales. Badges don't predict sales. Reading list saves don't predict sales. A great article can sit on top of a product nobody wants, and a mediocre article can promote a product people actually need.
I knew this in theory before I wrote the article. I didn't know it know it until I had six months of data showing the gap.
The cognitive trap I want to name
Here is the trap, stated plainly, so the next indie maker writing a Local LLM Dev.to article can skip it:
Content engagement validates that the article resonates. It does not validate that the product solves a problem people pay for.
What would have actually validated the product? A few things I didn't do:
- Pre-sell before building. Post the landing page and a waitlist before writing a line of code. If 50 engineers from the article's traffic don't drop their email, the demand probably isn't there.
- Watch for unprompted referrals. Did any of the 11 bookmarkers share the product with a colleague without me asking? No. That's the cleanest demand signal you can get, and it was silent.
- Talk to the one customer who bought. I waited until he emailed me. I should have reached out the day his receipt was opened.
None of these are clever. They're standard indie-maker advice. I skipped them because the article numbers felt like enough validation. They weren't.
What I'm doing differently now
I'm not pulling the product down. The one paying customer is still using it, and the article still brings in occasional reads that send the right people to my Gumroad. It's a small, real, working channel.
But the next product won't start from "what's trending on Dev.to." It'll start from a problem I personally hit at work, often enough that I'd pay $59 to make it go away.
My latest tool, an IIoT Alarm Engine, came out of that filter. I needed real-time alerts from Modbus and MQTT devices, routed to Slack and Telegram. I built it because I was missing the feature myself, not because the tag was trending. It's too early to say whether it will sell better. But at least the assumption it's built on is one I can verify by using it.
If you take one thing from this post
Reads, bookmarks, and badges measure your writing.
Sales measure your product.
They aren't the same axis. Don't read one and feel validated about the other.
That's a six-month, one-sale lesson written down so you can have it for free.
By Phil Yeh — Senior Automation Engineer specializing in Industrial Python and developer tools. I publish post-mortems and engineering case studies on real problems shipping to factories — not the hype. If you want future post-mortems in your inbox: Phil's Industrial Notes. If you've made the same mistake, the comments are open.
Tools I've built since: IIoT Alarm Engine, J1939 Decoder GUI, Modbus Logger. Browse the rest: philyeh.gumroad.com.
Top comments (0)