Strimo Director

We had the workweek we later named Recursor. During the workweek we learned how powerful cursor really was, as Bjørn has been using it in a way more powerful way than others might. Once we learned that, we had to go down to first principles and reconsider everything that has been common startup advice for the last decades:

• Why not build for scale if it takes a few hours to do so?
• Why have 2 week long sprints building when we can build the same features in hours?
• What do we focus on now that building isn't the activity that takes up most of our time?
• How can we gain even more of an edge by building AI tools that make us even faster?
• How can we leverage AI not just on building, but also research, sales, marketing, customer insights, analytics?

We discussed these questions and more during the workweek, and came up with good bets.

Superhuman’s PMF Engine – Core Summary

I dug into Superhuman’s product-market fit engine, which is basically a recurring process for measuring PMF as the company grows. The main tool is this question: "How would you feel if you could no longer use Strimo?" Options: Very disappointed / Somewhat disappointed / Not disappointed.

Core process

Survey users with the Ellis question, and segment responses, for example:

Very disappointed

• Fly fishing (Club Leader)
• Surfing (Enthusiast)
• Extreme sports (Athlete)
• Uphill running competition (Race Director)

Somewhat disappointed

• Slalom (Coach)
• Influencer (Creator)
• Skydiving (Instructor)
• Conference organizer (Event Host)
• Online course (Teacher)
• Concerts by a band (Tour Manager)

Not disappointed

• Hunting (Club Member)
• Hot air balloon competition (Organizer)
• Podcast producer (Indie Podcaster)
• Video game streamer (Twitch User)
• Church service (Pastor)
• Local theater (Stage Manager)

Focus on the users who answer “very disappointed” as they’re the real customers

In this example:

• Fly fishing (Club Leader)
• Surfing (Enthusiast)
• Extreme sports (Athlete)
• Uphill running competition (Race Director)

Deeply analyze what those users love. Prioritize building more for them.

For example:

• We want to legitimize our niche sport, and to do that we need to make our streams look professional. But since we don't have the budget to do that, we love using Strimo instead.

Figure out what holds others back, and experiment with changes to increase the “very disappointed” segment.

Example:

• The director interface is too small
• The sound interface is confusing
• I want to stream to my own platform instead of youtube

I keep coming back to this, but if we nail the core product this summer, the next semester will be very fun and creative. I’ll only have two courses in my AI bachelor next semester, and if Director is in people’s hands, we can finally start building out all the things we’ve been talking about for 2 years—automatic bug reporting, AI issue fixing, custom dashboards, devtools, etc.

But everything depends on us actually shipping a working, stable app now. Not perfect, just working. If we get Director into the App Store (even a basic version), we unlock a whole new level of freedom to experiment and iterate. If we don’t, we’re stuck in crunch mode all fall, with everyone waiting and expecting a finished product - customers, partners, investors, ourselves.

So my priority for this summer: trust that Bjørn’s got the Streambridge under control, do whatever it takes to get Director over the finish line. Ship the thing, then have fun building all the fun stuff we actually want to build.

If we succeed, the next semester will be fun and explorative. If not, I'm setting myself up for burnout.

Update 2 weeks before intensive workweek

Now we are finally starting to develop the app, hopefully a shippable version this time! 8th time's the charm!

The streambridge feels robust now, so I'm praying we can get an IOS (and maybe android) release out.

When we release the IOS version, we'll set up a smooth development pipeline so we can ship features and patches after every sprint. After that we can start talking to the people that have previously showed interest in Director. Then we need to work with their feedback and do tons of user tests for maybe 3 or 4 iterations, and finally deploy some sort of marketing for this product.

But I honestly think it's only a question of time this product will blow up. Especially with the final version we have imagined.

I think we have a really good strategy where we focus on the foundation first, making sure the quality, stability and robustness of both the app and the streambridge are close to perfect. THEN we can add features. Without a killer base product, additional features have very little value.

I will focus on creating a custom WHIP client library for javascript. But I am unsure of what the specifications for this library is. Customizable and general? Or specifically built for our streambridge? I need to have a talk with Bjørn so I understand what to build.

Summer 2025 Roadmap

I'm thinking of separating this into clear phases, each with a specific purpose and a test that shows we’re ready to move forward to the next phase.

1. Pipeline

The basic multi-cam product. Just the core pipeline with multiple phones in and one RTMP out. We don’t need working buttons in the app yet. If it takes command line hacks to switch cameras, that’s fine.

Test Run: We do a ~2 hour YouTube stream where we switch cameras every minute or so. If it runs stable the whole time, looks good (720p+, 30fps), and doesn’t crash or break, we’re done with this phase. This is the core product, so if this step isn't done, none of the other phases have any value. We really need to show restraint not to move to the next phase before we have this. We can't keep making the same mistakes over and over. I need to be unbudging about this requirement to the others on the team.

2. Director

Here we add actual controls to the app — buttons, previews, swipe between camera and director view. This is the basic UI needed to run a stream properly from inside the app.

Test Run: We stream for 2 hours using just the Director app. We switch cameras, swipe between views, and everything works through the interface — no command line or backend interaction.

3. Packaging

This phase is packaging this into a product with:

• Stripe payments
• Maybe some basic auth or access tokens
• Clear limits on the server unless you're paying

Then what we do with releasing it on appstore, or only early adopters, funding, whatever, doesn't really matter to me. Because we will have a way better picture of what to do when we have finished all 3 steps.

Two years in

What started as a freezing, last-minute hack to livestream a ski competition in Voss has turned into a full-fledged mobile livestreaming app. We’ve gone from laptop prototypes and feature bloat to a clean, phone-first experience that actually gets used in the wild.

We’ve streamed political debates, joined an innovation program, redesigned the product multiple times, burned out, and kept going. Now we have real users after a ton of feedback and failed prototypes, and a clear direction: simple, mobile, multi-cam livestreams.

Created a cool spinning logo for Strimo