DEV Community: Neo Teng

One Draft, Eight Platforms, One Command

Neo Teng — Thu, 13 Aug 2026 03:23:10 +0000

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.

Writing isn't the bottleneck. Distribution is.

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."

A central dispatcher plus plug-in channels

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.

The part where it nearly lied to me

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.

The takeaway

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

You'll Feel PMF Six Months Before You Can Measure It

Neo Teng — Wed, 12 Aug 2026 04:37:26 +0000

Have you ever had this moment?

You open your dashboard and stare at the retention curve for a long time, trying to read an answer out of it: has this product actually clicked, or not?

You look and look. The curve is still the same curve. You're still not sure.

I want to argue the exact opposite of that moment: whether your product has clicked is not something you should be looking for in the numbers. By the time you can see PMF clearly in retention and conversion, you should have felt it six months earlier.

The numbers are always the last to arrive

Whether a product has clicked, the dashboard is the last to know.

The real signals show up much earlier — and none of them live in your analytics:

A customer is furious because your thing broke, and comes at you angry. Someone willing to get mad about a product actually depends on it. Nobody gets worked up over something they could take or leave.

Someone mentions you and recommends you, completely unprompted. Spontaneous word of mouth can't be bought. It means your thing has entered someone else's vocabulary.

You yourself can't go a day without it. You're the first user. You know better than anyone whether it actually solves the pain.

Once those three signals appear, PMF is already there. And it takes months for them to slowly surface in the numbers.

Waiting for the numbers is choosing, on purpose, to learn the answer six months late.

Why we'd rather wait for the late number

This is the part I really want to get at.

If feeling is earlier and more accurate, why do most people still stare fixated at the numbers?

Because looking at the numbers means you don't have to be responsible.

"I think this thing has clicked" — the moment you say it out loud, you own it. You made the call. If it's wrong, it's on you.

"The data shows this thing has clicked" — that sentence is so much more comfortable. You're just a narrator. You point at the curve; responsibility sits with the data, not with you.

Hiding inside the data is, at its core, quietly swapping "I think" for "the data thinks" — outsourcing your judgment to a spreadsheet so that if it's wrong, it's not your fault.

But at the earliest stage, you might have only a few dozen users. Any single number can be thrown off by one random fluctuation. The only thing that can save you then is exactly that judgment — "as the person who understands this pain best, do I feel it has clicked?"

Hand that judgment away in exchange for a report that looks objective, and you're switching off your own perception at the moment you need it most.

So when should you look at the numbers?

I'm not saying numbers are useless.

After you scale — thousands, tens of thousands of users — personal feel can't cover it all, and numbers become invaluable. They show you the whole picture that one person can't see.

But that's the "already clicked, now grow it" stage.

At the "has it clicked or not" stage, the numbers can't give you the answer — only you can. Use the wrong tool for the stage and you get in trouble: worship numbers too early and you'll dare to decide six months late, or get fooled by small-sample noise into the wrong direction; rely only on feel too late and you'll miss the real problems that live at scale.

The skill worth training isn't "numbers or no numbers." It's telling the difference: is this product right now in the stage that needs feel, or the stage that needs numbers?

Finally

In my own experience building things, every time a product truly took off, the order was the same: I felt it first, and the numbers caught up to confirm it later. Never the other way around.

Whether something still in its cradle is worth betting on — that's not a call the data can make for you.

It can only be made by the person closest to it, who understands the pain best.

That person is you. Don't hand that judgment to a spreadsheet that shows up six months late.

The Time Hiring Saves You Won't Cover What You Lose

Neo Teng — Wed, 12 Aug 2026 04:36:35 +0000

Let's do the math first.

A product takes off. One person is a little overwhelmed. By conventional wisdom, this is when you hire — bring on one or two people, double your output, move faster. It's the advice almost everyone gives.

What I want to say is: most people only do half of this math. Add the other half, and the conclusion can flip.

The first ledger: how much faster does hiring make you?

Let's do the obvious math first.

Hiring someone to write code and get work done is genuinely faster. But not as much faster as you'd imagine.

You still have to review what they build. You still have to fill in the context they lack. The back-and-forth of communication eats up most of the time you saved. Net it out, and yes it's faster — but only a little faster, nowhere near double.

Most people, doing the math up to here, say: still faster, and a little faster is still faster.

If this were the only ledger, hiring would be fine. The real problem is the second ledger — one most people never enter into the books at all.

The second ledger: what hiring kills

If you're a solo operator and you build in public — showing where you got stuck, how you solved it, what you figured out today — then that process itself is your best marketing material.

You don't need to do marketing on the side. The process of doing the work is the marketing.

But the moment you hire, a lot of the work is done by someone else. Work someone else did, you can't tell as "my process."

That content thread — the one steadily bringing you attention and trust — snaps.

So the second ledger looks like this: how much is the little bit of time hiring saved worth? And the content thread you lost because of it — how much is that worth?

My answer: the loss on the second ledger far outweighs the gain on the first.

It's not that I can't afford to hire. It's that I did the math: hiring loses money.

Why most people get this math wrong

At a normal company, the math doesn't work this way.

A normal company runs on division of labor: you do product, they do marketing, each owns a piece, and together you're stronger. In that model, hiring is a given — more people, more output — and the second ledger simply doesn't exist, because marketing was someone else's job to begin with.

But the math of solo work runs the other way.

You are the brand. How you think, how you work, how you get stuck and then get unstuck — that real process is the core reason people follow you, trust you, and eventually pay you.

In this model, "the process" is not a cost. It's an asset. And hiring is precisely cutting into that asset — what you hand off isn't just that slice of work, it's that slice of "the tellable you."

So for the same act of hiring, a normal company pays only the first ledger (salary minus output). A solo operator pays two (salary + the slice of "you yourself" that got cut away).

Most people lose money because they only counted the first ledger, never the second. They applied a normal company's accounting.

So should you never hire?

No.

The key is to tell them apart: which work can be outsourced without losing value, and which work, once outsourced, takes "what makes you you" with it.

Pure execution unrelated to you personally — some support, some ops, some repetitive labor that never enters your narrative — is completely fine to outsource. That's the domain of the first ledger, where hiring really does save time.

But your judgment, your taste, your building in public — these belong to the second ledger. Outsource them and they lose value, precisely because their worth comes from "it's you doing it."

Before hiring, sort out which kind of work you're about to hand off.

Finally

I've seen too many people rush to expand the moment things pick up — hiring, building teams, renting offices.

And then they become a small company, instead of themselves.

The biggest moat for a solo operator was never output. It's that "you yourself" can't be copied and can't be replaced.

Hiring is trading a piece of "you" for a piece of "speed."

Before you make that trade, get both ledgers straight. You'll find the "you" in your hands is worth far more than you thought.

The Internet Is Growing Countless Little Paid Doors

Neo Teng — Wed, 12 Aug 2026 03:59:36 +0000

Cloudflare shipped something recently, and most people scrolled right past it.

It lets websites charge AI crawlers. The headlines mostly framed it as "publishers can finally bill the robots."

Framed that way, it really is just a minor news item.

But charging crawlers is only round one. What's actually happening is far bigger.

The old contract of the web is breaking

Start with the old deal.

For twenty years, you had a website, and you let search engines crawl it — because they sent you people.

Google read your page, indexed it, someone searched, your page surfaced, and a real human clicked through.

Once that person landed on your site, you monetized their attention. Ads, email capture, subscriptions, affiliate links.

The crawler took your content, your site got the visitor, the visitor got their answer. That accounting propped up half the internet.

Now the AI agent has snapped that chain.

It reads your page, extracts the useful answer, and feeds it straight to the user. The user may never visit your site at all.

The content still created value. But the site lost the visit.

Lose the visit, and the ads are gone, the email capture is gone, the affiliate click is gone.

So publishers are up in arms. But that's only round one.

The human web sells attention; the machine web sells resources

What's really changing is what gets monetized.

On the human internet, you monetize attention. You hold people, then run ads or sell them things.

On the agent internet, you monetize useful resources. The agent doesn't watch ads. It asks one thing: does this resource help me finish the job?

If yes, it pays. If no, it leaves.

Here's the counter-intuitive part.

Ask a human to pay a fraction of a cent to view a web page and they'll close the laptop on the spot. Nobody's paying a micro-fee to see the sauce recipe before the actual recipe.

But the machine doesn't care. Small amount, paid automatically, data's useful — it just pays.

Micropayments failed on the human internet for twenty years. Move them to machines, and they work by default.

That's exactly the road Cloudflare is paving. Using HTTP 402 — the "payment required" status code — the agent sends a request, the server says here's the price, the agent pays and retries.

A single request becomes a transaction.

No checkout flow, no signup first, no sales call, none of the enterprise procurement dance.

The request is the transaction. That's a big deal.

A pile of tiny resources is turning into businesses

Once a request becomes a transaction, countless tiny things on the internet can become businesses.

A dataset can charge per query. An API can charge per successful call. A research archive can charge per answer. A product catalog can charge per price comparison.

Someone will say: agents don't have wallets.

But agents are growing wallets, and growing inboxes. It's already begun.

The moment they can pay, these small resources stop being content and become assets.

So the website becomes a resource layer, and content becomes an index. Expertise becomes something scalable, data becomes something meterable, tools become interfaces an agent can call.

A new stack is forming.

At the bottom is the messy internet: PDFs, pricing pages, old blogs, support docs, comparison sites.

Then someone cleans it into structured data. Then someone turns it into an interface an agent can read. Then someone adds pricing rules — some free to pull traffic, some paid, some locked down entirely. Finally someone adds trust and analytics: is the data fresh, is the source reliable, which requests are worth money.

That whole stack will grow thousands of companies.

One question is enough: what resource does an agent urgently need, frequently need, reliably need — and is willing to pay for?

You can cut in right now — no need to wait

Someone on X said startups are harder now: traffic's down, revenue's down.

I see it the opposite way.

What you shouldn't build is the kind of little tool that can be vibe-coded in an afternoon. That stuff genuinely has no future right now.

What you should build is a business that's profitable from day one, has a moat, and is redesigned for the agent era.

And you don't have to wait for Cloudflare's whole apparatus to mature.

Do the manual version first. Sell the human-powered version first. Accumulate the data first, package the thing first.

Concrete example. Pick a niche — say medical-aesthetic clinics in one city. An owner wants to know: what are competitors charging, what procedures do they offer, what are the bad reviews complaining about, who's hiring, which promotions actually work.

That information is scattered across review sites, official pages, job postings, ad libraries — and still inside the heads of owners and staff.

Your job is to clean it into one tank of clean fuel.

At first, your first customer isn't even the clinic owner. It's the people already selling to clinics — agencies, consultants, software vendors.

Because "agent-readable competitive analysis" means nothing to the owner. But an agency gets it instantly. It closes one more client off the back of your data, and it'll happily pay you a few hundred a month.

First a report, then a dashboard, then an API, then the agent pays per call. Crawl, walk, run.

Who wins, who loses

Lay the incentive structure bare.

People who start accumulating data now win. The agent internet is still small, competition hasn't arrived. You have six to eighteen months to clean one niche's dirty data into clean fuel — and by the time competition shows up, you're already inside the door.

People who wait for the trend to mature lose. By the time Cloudflare's apparatus is common knowledge and agent wallets are everywhere, these little doors are already taken. You'll be fighting over scraps.

People who only build vibe-coded toys lose too. That stuff has no moat and gets cloned the day it ships.

This isn't "another mildly interesting piece of tech news."

Agents are becoming buyers. Websites are becoming resources.

The next batch of great internet businesses may well be these unremarkable little paid doors that agents pass through all day long.

And right now, nobody has claimed them.

Neo Teng · building a company of one