How long does it take to publish one article?
If you run a one-person company, the honest answer isn't "the few hours of writing." It's everything that comes after — moving it into your newsletter, copying it to one dev community, pasting it into another, translating it for an English audience, cutting a short version for X, dropping a note somewhere else. That relay of copy-paste-reformat costs more energy than the writing itself. This week I killed that chore. Now I finish a draft, drop it into a single spreadsheet, run one command, and it fans out to eight platforms on its own.
But I don't want to talk about "I built an automation tool." That's the small part. I want to talk about three judgments that are worth far more: where a solo founder's real bottleneck lives, how this machine should actually be built — and how it nearly lied to me.
Most people assume the hardest thing about a one-person company is content output. It isn't.
AI has already crushed the marginal cost of writing to the floor. What actually eats your time is the repetitive labor of pushing the same piece across a dozen platforms: log in, paste, fix formatting, upload the cover, edit the tags, publish, log it. Five minutes per platform, eight platforms, forty minutes — every single day.
This labor has one especially miserable property: it creates no new value. It's pure hauling of things that already exist from one place to another. And yet you can't skip it — no distribution means even great writing goes unread.
So when you work alone, the first thing to industrialize isn't "write faster." It's "hand the entire distribution chore — the certain, repetitive, judgment-free part — over to the machine."
I didn't build one giant "fully automatic publisher" for this. Those look great in a demo, but they're a nightmare to change — adding a single platform means touching the whole flow.
Instead I split it into two layers.
Layer one is a central dispatcher. I use a single spreadsheet as the control desk: each row is one piece of pending content — title, body path, which platforms to hit, publish time, status, all in the table. I don't touch code; I fill in the table. When the time comes, the dispatcher scans the table and picks out what's due.
Layer two is a set of plug-in channels. Each platform is a small, independent function that knows nothing about the others. Want to add a new platform? Just write a new function and hook it on — the core dispatch logic doesn't change by a single line. This week I added a new channel and only had to touch one function.
The beauty of this structure is that it flattens "many platforms" — a problem that grows exponentially — into "a pile of non-interfering single-platform problems." A one-person shop can't afford to maintain a complex system, so you have to pin complexity to the floor from day one.
This is the part I actually want to tell.
One of the channels finished running and returned success — exit code zero, no errors at all. I assumed the drafts were sitting safely on the other end.
I went to check. The draft box was empty.
The machine told me it was done. It had published nothing. The tool doing the syncing would, without ever truly connecting to the thing it needed, still exit as "success." It smiled at me and said "all set" — with empty hands.
So I rewrote the entire success check. No longer "did the command return an error?" but "let me parse what it actually reported" — the real signals had to be present, and the count of successes had to equal the count of platforms. One short, and it's a failure, written back to the table.
Here's the trap that automation makes easiest to fall into: you assume "no error" equals "success" — but a machine's silence and a machine's lie look exactly alike. The more work you hand to the machine, the more you need a "did you actually do it?" verification bolted onto every step, instead of trusting its self-report.
After building this, my understanding of "automation" shifted.
It was never the fantasy of "one click solves everything." Good automation is a discipline: outsource the certain, the repetitive, the judgment-free to the machine — and keep the judgment firmly in your own hands.
Distribution is certain. Give it to the machine. What's worth writing, whether what you shipped actually landed, whether the machine is lying to you — those are judgment. Keep them.
One person can do the work of a team not by turning themselves into a machine, but by getting clear on one thing: what to hand off, and what to never let go of.
Neo Teng · practitioner of the one-person company