I bet on self-hosting for an AI product. Here's why, and where I'm stuck
TL;DR: I'm building Simply.Editorial, a self-hosted system that runs the whole "news → post" pipeline for Telegram channels. It's in pilot. I made a deliberately unfashionable architecture choice — self-host instead of cloud SaaS — and I want to talk honestly about why, what it cost me, and the distribution problem I haven't solved.
The itch
I kept watching the same thing happen to people running content channels: the work doesn't scale with effort. One or two Telegram channels, a single editor can handle. At five or ten — agency territory, or a corporate media team covering an industry — the manual routine falls apart. Find the news, check it isn't a duplicate, verify it's true, write it in the channel's voice, publish on time. Every day. It's mostly mechanical, and it's exactly the kind of work that quietly breaks under deadline.
So I built a pipeline that does the mechanical 80% — discovery, deduplication (lexical + semantic), fact-checking across sources, drafting in a per-channel voice, scheduled publishing — and leaves the editorial judgment to a human. That framing ("automate the pipeline, not the judgment") became the whole product thesis.
The unfashionable bet: self-host
Here's the part other founders keep telling me is a mistake. Simply.Editorial isn't a cloud SaaS. You deploy it on your own infrastructure. Your API keys, your data, your model choice, your costs. I don't hold your content or your audience data on my servers.
The "smart" move is obviously the opposite: host everything, own the data, bill monthly, maximize lock-in. That's the SaaS playbook and it works.
I went the other way on purpose, because of who I kept talking to. Corporate media teams in regulated industries and agencies handling client data don't have a convenience problem — they have a "we're not allowed to put this in someone else's cloud" problem. For them, self-host isn't a downgrade. It's the only version they can actually buy.
What it cost me:
- Onboarding is heavier. "Deploy on your server" will never convert like "sign up with Google."
- No usage dashboard for me. I can't watch aggregate metrics across customers, because there is no aggregate — each install is theirs.
- Pricing had to change shape. It became a license + turnkey deployment + optional update subscription, not a simple per-seat monthly.
What I think I got:
- A real answer to the objection that kills most AI-content deals: "where does our data go?" Nowhere. It stays with you.
- A product a compliance-bound buyer can say yes to.
Where I actually am (no vanity metrics)
Pilot stage. Running on its own infrastructure, real pipeline, real drafts. I'm deliberately not going to quote user counts or revenue, because at this stage any number I gave would be theater. I'd rather be honest that it's early than dress it up.
The content approach so far: I've been writing platform-appropriate posts (a dev tutorial, an editorial newsletter, catalog listings) instead of spraying the same link everywhere. Slow, but it's the only distribution I trust myself to do without becoming spam.
Where I'm stuck, and what I'd ask you
The build isn't the problem. Distribution is. Two things I genuinely don't have figured out, and where I'd love this community's take:
-
How do you demo a self-hosted product? The whole pitch is "it runs on your infra," which makes a frictionless try-before-you-buy hard. A hosted demo undercuts the core promise; a "book a deployment call" gate kills momentum. If you've sold self-hosted or on-prem software, how did you let people feel it first?
-
Pricing a license vs. a subscription for a solo founder. License gives the buyer control (fits the self-host story) but caps recurring revenue. How have you balanced a one-time license against the recurring income a solo founder actually needs to survive?
If you want to see the thing, it's at red.investprosto.com/en — and I'll put up a product page here too. But honestly, the feedback on those two questions is worth more to me right now than a click. If you've walked this road, tell me what you'd do differently.
Disclosure: I used AI assistance to draft this post and reviewed it myself. The product, the decisions, and the mistakes are mine.
What part of your approval process takes the most time? Trying to understand if this is a universal pain.
Your self-hosting bet actually solves a distribution problem, not creates one. The compliance buyer who can't touch a SaaS solution? That's someone who otherwise says no to 100% of your pitches.
By making self-host the only version, you've turned an objection into a qualifier. You're not competing on frictionless onboarding - you're competing on being the only option. That's actually a narrower, more defensible market than chasing the "just sign up" crowd.
On pricing: look at how the compliance buyer actually buys. They're not buying "software." They're buying permission from their legal/security team. A license with a maintenance subscription (security updates, feature releases) might convert better than trying to sound like SaaS. The subscription justifies ongoing value, the license respects their buy-it-once preference.
What part of your approval process takes the most time? Trying to understand if this is a universal pain.
I like that you're treating self-hosting as a market-selection decision rather than a deployment decision.
Giving up SaaS-style convenience makes sense if it lets you serve buyers who otherwise couldn't buy at all. In that case, the question isn't whether self-hosting creates friction—it's whether it removes a bigger friction in the purchasing process.
you're not selling the features, you're selling where the data isn't. that's why a hosted sandbox feels wrong to you: it proves the product and disproves the pitch at the same time.
we're in the same bind (local-first, nothing leaves the machine) and what helped was to stop optimizing time-to-try and start optimizing time-to-first-real-output on their own box. one command, their data, a few minutes, and the receipt is an empty network tab. a compliance buyer doesn't really want to play with it. they want to watch it not phone home, on their hardware, with their stuff.
deployment friction isn't the enemy. a long gap before the first true output is.