Homebase: Owning Your Own Platform Is Finally Realistic

My daughter Becca streams on TikTok. She’s 20, she’s good at it, and she has built a real community of people who turn up to watch her. Like a lot of fathers with a technical bent, I’ve watched it with a mixture of pride and slight unease. Not about her, but about the ground she’s standing on.
This post is about that ground, and about what we’ve been building to give her something firmer: a project called Homebase.
The problem: you’re renting, not owning
If you create on TikTok, YouTube or any of the big closed platforms, you are a tenant. A very welcome tenant while you bring in eyeballs, but a tenant all the same.
Accounts get restricted or banned, sometimes with little explanation and not much of an appeals process. Algorithms shift overnight, and a creator who was being shown to thousands of people can find themselves shown to hardly anyone, with no idea why. Gift and payout terms are opaque. You can see what lands in your account, but working out how it got there, and what was taken along the way, is another matter.
The uncomfortable truth is that the audience and the income belong to the platform. The creator does the work, builds the relationships and turns up night after night, but the list of who watches, the means of reaching them and the till they pay into all sit on someone else’s servers, under someone else’s rules.
None of this is a complaint about any particular incident. It’s simply how the model works. And having spent most of my working life in free software, it’s a model I find hard to watch my own daughter depend on.
The obvious answer, and why it used to be hard
The obvious answer is to own your own platform. Keep the big platforms for what they’re genuinely brilliant at, which is discovery, and give your community a home that you control.
Easy to say. Historically, very hard to do. Think about what a creator’s own streaming platform actually needs:
- Video ingest and transcoding: taking a live stream in and turning it into something that plays smoothly on a phone on 4G as well as a laptop on fibre.
- Bandwidth and CDN costs: video is heavy, and serving it to lots of people at once is where the money goes.
- Authentication: knowing who’s a member and who isn’t, without making people jump through hoops.
- Payments: taking subscriptions properly, legally and safely.
- Multi-tenancy: if more than one creator is going to use it, keeping each one’s space and data properly separate.
- Operations: backups, certificates, updates, monitoring, and someone to fix it at midnight.
And the killer: the creator, who is usually not technical, can’t run any of that. So historically it has meant a development team and a hosting budget that only established media businesses could justify. For an individual, the closed platforms won by default.
How we specified it and built it
Here’s the bit I actually want to tell you about, because the way this came together surprised even me.
I’ve been running a small team of AI agents through my company, Timmisun Limited. Freya is our developer agent. Becca De-Sanchez is our brand and CMO agent. I direct them, and I’m firm about one rule: the agents do the legwork, but I make every decision, and nothing merges without my review. Everything ran through GitLab, as issues, merge requests and reviews, exactly as it would with a human team.
From idea to a running MVP took two days.
Start with a page, not a prompt
I began the old-fashioned way, with a one-page spec. What is this thing, who is it for, what must it do and what must it never do. That page was filed as a GitLab milestone and broken down into eight issues.
The core idea is simple. TikTok stays the discovery engine. Homebase is the home base. We keep TikTok free of off-platform promotion and invite through Discord instead. Invites go out as QR codes. Scan the code and you get a one-click 30-day trial, straight into the live stream, with no sign-up form in the way. Login after that is passwordless, using email sign-in links and passkeys. Beyond the trial there are three membership tiers, designed so they can be extended later.
Homebase is multi-tenant from day one: one shared gateway, with an isolated space for each streamer. Becca is the first tenant, and a second streamer, Tyler, is planned as the second. Building for two from the start keeps us honest about isolation.
Decisions written down
Before any code, we wrote five architecture decision records. Each one set out the options, a recommendation and the open questions. I read them, answered the questions and made the calls. I can’t overstate how much this helped. It’s the difference between an AI producing code and an AI helping you think.
The stack we settled on is all open source:
- Owncast for the live streaming itself: RTMP in, HLS out, with built-in chat. We pass 1080p straight through and add a 720p variant for mobile viewers.
- A Python/FastAPI gateway that ties everything together.
- Postgres with row-level security, so tenant isolation is enforced by the database rather than by everyone remembering to add the right filter.
- Caddy as the reverse proxy, with per-host on-demand TLS, so each streamer’s space gets its certificate without anyone touching it.
- A gatekeeper doing forward-auth, so only members can watch. Non-members still see a public live or offline status and a thumbnail, which works nicely as a teaser.
- Docker Compose throughout.
Later on, the plan is to add PeerTube, PixelFed, Mastodon and a Luanti game server as shared community instances, with Zitadel providing single sign-on across the lot.
We also did a hardware plan. Sized for about 150 concurrent viewers, that comes out at roughly 510 Mbps at peak, around half of a 1 Gbps port, and a dedicated server in the UK at about £112 a month. That’s a number an individual creator can reason about, which is rather the point.
Meanwhile, Becca De-Sanchez produced a brand guide: a pink, soft, classy palette, and one that passes accessibility contrast checks. Pretty and readable is not too much to ask.
When research changed the design
The best story in the whole project is about payments, because it’s where research genuinely changed the plan.
My first idea was simple: Tide checkout links, which seemed the path of least resistance. The research came back and knocked that on the head. Tide has no API and no webhooks, so Homebase couldn’t know who had paid. On top of that, our reading of its payment-link terms is that they exclude live-streaming services with in-app currency and donations, which would have ruled out the gifting ideas we had for later.
Next up was Stripe Connect, the usual answer for platforms that take payments on behalf of others. More research: Stripe’s restricted businesses list includes “content creation platforms”. Another dead end, and one I’d much rather find on paper than after building it.
So the final design is different, and frankly better. Each streamer’s own company has its own ordinary Stripe account, and Homebase integrates with it through the API and webhooks. Homebase never touches the money. Homebase takes no cut; payments go straight to the creator’s own Stripe account. That’s not just a compliance workaround; it’s the whole philosophy of the project expressed in one decision. The creator owns the relationship and the revenue.
A running MVP
The result is an MVP that runs locally with a single command:
make up
It’s properly tested: about 98 gateway tests at 92% coverage, plus end-to-end tests that push a real test stream through the system and check that members receive it and non-members don’t. You can point OBS at it from a laptop and stream to it.
I want to be clear about what it isn’t, though. It’s an MVP running locally. It is not yet in production, and nobody is watching Becca on it yet. Getting it right before it’s live matters more than getting it live quickly.
What’s next
Three things. First, wiring up Stripe billing properly against that design, so membership tiers can actually be paid for. Second, the production server, based on the hardware plan. Third, and the one I’m most looking forward to: Becca’s first stream on her own platform.
Open source plus AI: owning your platform is now realistic
Eric S. Raymond, who wrote down much of the theory of open source thirty years ago, recently posted a thread on X that opens:
“The end of software secrecy is almost upon us. The death of closed source, and the final triumph of open source.” (@esrtweet on X)
His argument is about AI-assisted decompilation, and you don’t have to agree with all of it. But one line in his follow-up stuck with me. Apart from patents, he says the main place secrecy can still hide is “Software as a service with the executable hiding behind a network connection to the cloud” (thread, part 2). That is exactly where the big creator platforms live. You can’t decompile your way out of TikTok’s algorithm or YouTube’s payout terms.
What you can do is stop depending on them. In a separate post around the same time, writing about AI services, he put it even more simply: “The future will be decentralized and local.” (@esrtweet on X)
That, for me, is the real shift. Open source has given us the whole stack for years: streaming servers, databases, proxies, federated social tools, all free to own. What was missing was the labour to assemble it, and the cost of that labour put it out of reach for individuals. AI agents are changing that cost. Not by replacing judgement, because the direction and the reviews were mine, but by doing the legwork that used to need a team.
Put the two together and “own your platform” stops being a slogan for media companies and becomes something a dad, a couple of AI agents and a bit of determination can take from idea to a working MVP for a 20-year-old streamer in a couple of days.
TikTok can keep being the shop window. Becca’s community will have a home of its own.