The One-Man Company Theory

Toản and I have spent five months building magic-manager — a system that runs YouTube channels on autopilot: content creation, dubbing, posting, scraping, the whole pipeline. It's genuinely good software. Hundreds of channels, tens of thousands of jobs, deployed across four GPU boxes. Technically it's the best thing either of us has built.

And in one sentence, Toản summed up the whole situation yesterday: "We've spent 5–6 months building this without real profit."

We were sitting across from a potential partner (H) who runs a network of monetized channels. He was impressed. He was paying. But the payment was about half a month's salary — a one-time amount for work that represents half a year. And that gap, between the value of the tool and the value we've captured from it, is what the conversation was really about.

The conversation, distilled

We talked about treating the tool like a business instead of a project:

• Subscriptions, not one-offs. A one-time payment is a transaction. A subscription is a relationship — recurring revenue that scales with the value the tool keeps producing, not the effort we put in once.
• A revenue split, not a flat fee. H's channels earn from the tool every month. Why would we sell the thing that makes him money for the price of a nice dinner? The honest answer is we wouldn't — we'd structure it so his success is our success.
• The "one-man company" idea. The real ambition underneath: could one person, leaning hard on AI, run a company that's mostly software? Build the tool once, have agents maintain it, collect subscriptions. The company isn't a headcount — it's a set of systems.

That last one is the part I keep circling. Because the tools I've built — magic-manager, this blog, the home-lab — were all built with a lot of AI assistance. The output per human-hour is absurd compared to five years ago. So the question stops being "can I build it?" and becomes "can I package and sell it?"

The part that's uncomfortable

Here's the uncomfortable truth that kept the whole conversation honest: we built the tool for five months without thinking about the business model. The engineering was the easy, fun part. The part we skipped — pricing, packaging, distribution, sales, support — is precisely the part that turns software into income. And it's the part neither of us is naturally drawn to.

The one-man company theory has a corollary: AI makes the building cheap, but it doesn't make the selling easy. An agent can maintain the codebase. An agent cannot, yet, do the thing that makes a stranger trust you enough to pay. That's still human work, and it's the bottleneck.

Also worth being honest about: the numbers only work if the tool genuinely produces value for the customer. H's channels are the product; magic-manager is the factory. If the factory produces a channel that earns $13k/month, then a subscription that takes a small cut of that is both fair and large. If the factory produces nothing, no pricing model saves you.

The pricing pivot that changed the shape of the company

The most useful product decision came out of a later, blunter conversation about support — and it upended how we'd planned to sell everything.

We'd assumed the deliverable was an app: a voice tool for Windows, the video manager, install it, use it, done. Then we priced out what supporting an app actually costs. Every app customer eventually needs help — reinstalls, license issues, a machine that changed, "where did my templates go." Each one is a hand-holding session, and hand-holding doesn't scale to a hundred customers run by one person and some agents.

So the strategy flipped: sell the API, not the app. With an API, the customer integrates and leaves you alone — your only job is keeping the endpoint alive and logged in. You still have users, but the relationship is asynchronous: they call, you answer, nobody screenshares. Selling an app means holding hands all day; selling an API means maintaining infrastructure.

The pricing lessons that survived, in no particular order:

• Sell the outcome, not the tool. A subscription is really a license to keep benefiting from a machine that runs without you. Anchor to that, not to the hours you put in.
• Free fixes, paid features. Everything that's broken gets fixed free — that's the relationship. Anything new and substantial is a separate paid arrangement. It's a surprisingly clean line, and customers respect it.
• Recurring beats one-off, always. A monthly or lifetime tier is a bet; a subscription is a commitment. Structure it so their success funds your recurring revenue.
• Feature-flag what a client sees. Ship the latest code but keep new features disabled until you deliberately switch them on. You control the rollout; a half-baked feature never reaches their production.
• A hundred small customers beats one big one. If the tool earns its keep for ~100 people at a modest monthly price, that's stable, defensible revenue — versus one whale who can leave and take your income with them.

And the one-man-company framing gets sharper with each of these: the goal isn't "build an app people buy." It's "build a system that earns while I configure it." The app is a means; the API is a business.

What I'm taking away

1. Price for recurring value, not sunk effort. A subscription with a revenue share is the correct shape for a tool that keeps making money for its user. Don't apologize for it.
2. Sell the API, not the app. If you can make your tool callable over HTTP, you've traded a support job for an infrastructure job — the only trade that scales to one person.
3. The business model is a feature you have to design early. Next project, the pricing conversation happens in week one, not month five.
4. AI changes the cost structure, not the sales job. The one-man company is real, but its scarce resource isn't engineering anymore — it's distribution, trust, and the discipline to charge.
5. Leverage in the negotiation is a real thing. We intentionally kept some features back while opening most of the tool, so the partnership conversation had somewhere to go. That felt transactional; it also felt necessary.

We didn't close the deal that night. But the shape of the deal got clear: recurring, revenue-linked, and structured so the tool's success and our partner's success are the same thing. For five months we were building a better piece of software. That night we started trying to build a better business — which is a different project entirely, and honestly the more interesting one.