July 1, 2026

Vision — 11:39

Before I let myself plan a single course of action on the live service, I needed to see where it was actually going. That’s the rule: envision before you converge — you have to know the destination before you pick the road. So today, fresh off the team meeting, I sat with the end state instead of the backlog.

At the start it looked like a feature. Live video. A broadcast MVP. Something good enough to run our own team calls on. Get GetStream wired, get multi-host working, ship it. That was the framing walking in — a piece of infrastructure to build.

But when I imagined it finished — spring 2027, real, in people’s hands — what came into focus surprised me. The video isn’t the point. What I saw was an abundance of broadcasts and group calls running smoothly at any scale: huge events, small gatherings, and our own internal work calls whose transcripts quietly become tickets and executed work. I saw a customer drop into a coach’s peptide broadcast and walk away with the coach’s exact protocol saved to their profile and the item already in their cart, converting the moment the call ends. Artifacts and assets flowing to attendees afterward. Best-in-class conferencing that happens to drive sales and productivity.

And underneath all of it — the real point. It’s not video, and it’s not even the conversion. It’s that live is what makes Loop a genuinely safe, close, deeply engaging community. Face to face, not just text. A place where people can talk openly about peptides, biohacking, and their health — the things they don’t feel safe saying on public socials that crack down, censor, and ban them. A close community where those conversations are welcome.

The smooth calls, the protocol-to-cart loop, the transcript engine — those are all how. The why is the safe room. That’s where I’m headed.

Converge — 11:44

With the destination clear, I went looking for the first move — and immediately felt the pull toward the impressive work. Multi-host broadcasting. The recording pipeline. The transcript-to-tickets engine that would let our own team calls drive development. The whole battle-tested internal engine I’d just described. That’s where my head wanted to start: build the thing that proves the vision.

But that’s the same trap I always fall into — starting with the sophisticated piece. Every one of those depends on an assumption nobody has actually checked. William replicated the GetStream streaming into the platform, but he never ran it there. The parity read confirmed it: the synchronous call surface is ported, but multi-host isn’t even wired, recording is never captured, and the webhook path writes to a table nothing reads. If I start building multi-host, I’d be stacking real work on top of something that may not stand up at all.

So the sophistication collapsed to something almost embarrassingly small. I don’t need multi-host yet. I don’t need recording or the transcript engine. I need to know a single live call even runs in the platform — stand one up on dev, and get my own face on camera. Prove the ground is solid before I build the house on it. Everything after that has somewhere to stand.

That’s my ONE Thing. Prove the migrated live call runs end-to-end in the platform on dev — one call, on camera. Everything else can wait.

Converge — 12:28

Chasing the live-call proof led me straight into a wall: deploying a single service to dev was taking over ten minutes. Unacceptable when I need to iterate. My instinct fired immediately toward the impressive fix — Turbo remote caching, bigger CI runners, parallelize the build graph. Make the build 10x faster. That’s the kind of infrastructure work that feels like real engineering.

But when I pulled the actual step timings, the build wasn’t even the worst offender. A step called “run database migrations + seed brands” had been running for over five minutes — on a deploy of two services. That stopped me. Why is it migrating anything? I’m not changing the schema. And the honest answer, once I read the script, was almost embarrassing: the pipeline runs the full from-scratch stage bring-up — every migration for all twenty-seven services, plus a complete re-seed of the entire content catalog through Payload — unconditionally, on every deploy. Nobody gated it. On an already-provisioned dev it’s pure redundancy: idempotent no-ops and re-seeding data that’s already there.

So the real lever was never a faster build. It was to stop doing five minutes of work that produces nothing. If I’d gone chasing remote caching, I’d have shaved the wrong three minutes and left the wasted five untouched. The build optimization was the sophisticated distraction; the redundant migrate step was the thing hiding in plain sight.

That’s my ONE Thing. Gate the migrate+seed step so an incremental single-service deploy runs zero migration work — and scope it to the changed service when it does need to run. Everything else can wait.

Vision — 15:35

I’d just watched real video come up in a browser — proof the live layer works — and clocked that the consumer live UI already lives in loop-health. Which raised the question I didn’t expect to care about: should our internal team calls be their own thing? The more I sat with it, the more obvious it got — yes. Consumer broadcasts and our own work meetings look alike (video on GetStream) but they’re different products with different clocks. Ours should ship on my schedule and let us dogfood the live backend before members ever touch it.

But when I imagined the team app finished, the surprise was that it wasn’t really about the call. Getting in has to be Meet/Zoom-easy — a share link you click and you’re in, no ceremony — but that’s table stakes. The thing I kept circling back to was meeting history. A lobby where you spin up a call or browse past ones. And every meeting reviewable: rewatch the whole thing, read the transcript, click around to jump to any moment, copy it out. Our meetings today evaporate the second we hang up; in this version they don’t.

That’s the real point. Not another video tool — a way to stop losing what we say to each other. The meeting becomes a record I can actually mine: paste the transcript into my work, pull the decisions out, turn talk into tickets. Build the UI first, wire the backend behind it, host it with CI/CD so it’s just always there.

That’s where I’m headed.

Converge — 15:39

With the team-app vision fresh, my pull was straight toward the good parts — the lobby, the reviewable history, the transcript-mining I actually care about. And hanging over it was the hosting question I’d flagged: after the day I just had fighting deploys, “where does this even go?” felt like a wall I’d slam into again.

That was the avoidance. Agonizing over the host, or diving into the shiny features, when neither is the first move. The research collapsed the fear in one line: every app in this repo is sst.aws.Nextjs, and a Next.js app deploys through CloudFront — not the shared ALB that tortured me all day. The blocker I was bracing for doesn’t even apply to an app. The paved road is right there.

So the real first move is embarrassingly small again. Don’t build the lobby. Don’t build history. Don’t overthink hosting. Just create apps/loop-team as a bare Next.js app and get one URL to resolve. The second that URL loads, every feature after it is pure iteration on a live thing — which is exactly what I said I wanted.

That’s my ONE Thing. Scaffold apps/loop-team and deploy it to a live dev URL. Everything else can wait.