The First Step in Solo Dev Isn't Building a Product

Last Wednesday, past 10pm, I ran my WeChat auto-writing pipeline end to end again — pull source material, dedupe, draft, generate section images, push the draft, sync to the blog. At the dedupe step it threw an error: embeddings HTTP 404. The dedup endpoint was down, so I had to manually flip through the log and check for repeats by hand.

I built this pipeline in my spare time, mostly to save myself the hassle of writing a WeChat post every day. After running it for about a month, an idea crossed my mind: this thing now covers everything from pulling material to pushing a draft — maybe other content creators are stuck on the same problem. Should I package it up and sell it?

I didn't act on the idea that night. Instead I laid the pipeline out and looked at it piece by piece: which parts were generic, and which parts I'd just gotten used to doing my own way. What I found was that the dedupe step alone had been rewritten four or five times in the last few months — from keyword matching to vector search, and tonight, a manual fallback because the endpoint was down. This thing was nowhere near ready to hand to someone else.

I didn't decide on a whim. I sat down and went through every path I'd tried to monetize before: an arbitrage signal service, shut down last year, never proven to make money reliably over time; a lottery-prediction model, run through a three-year baseline that came out negative, with compliance risk on top; content ads, which had never produced revenue evidence solid enough to stand on. All three were dead ends. The only thing left worth anything was the automation pipeline itself.

So I decided: treat this "pull material, dedupe, draft, push" flow as a custom service sold to specific people, instead of packaging it as something anyone could use. I set myself a rule — find two or three people willing to pay first, let them push the pipeline against their own real use cases until it breaks, and only once the parts that keep recurring surface, consider turning it into a standard product with a subscription.

What's the actual difference between this and "build the platform first, find customers later"? Building a platform first means making decisions for a group of imagined users up front: where their material comes from, what their niche is, which step they'd actually pay for. You can't answer those questions yourself — you can only guess. Guess wrong on one piece and the whole design has to be torn up. Selling custom work first means the first person who actually pays answers those questions for you — wherever they're unhappy is exactly where the design was wrong.

The cost of this path is speed, and it doesn't make for a good story. "I built a platform anyone can use" sounds a lot more like a startup than "I did custom work for two or three people," which sounds like a job. Writing that line of code, I second-guessed myself — doing custom jobs felt like it was drifting from why I started tinkering with these tools in the first place.

But what you get back is real. Every version of the dedupe script over the past few months started from a real duplicate I actually ran into while writing — not from guessing what "someone out there" might need. If I'd designed dedupe around a "generic platform" from the start, I'd probably have built it around my own assumed usage and guessed at everyone else's case — and wouldn't even know where the guess went wrong.

When exactly the recurring parts should be pulled together into something sellable to more people, where that line gets drawn — I still don't have an answer. Getting this one job in front of me right, which is also the pipeline I use myself every day, is the only thing I'm sure of for now.