Shoot Once, Get Both Landscape and Vertical: The Product Tradeoffs Behind Duovid

One Video, Two Platforms, One Headache

Last week I recorded something I wanted to post to both Bilibili and Douyin. The problem showed up immediately: Bilibili wants landscape 16:9, Douyin wants vertical 9:16.

All I had was a single landscape clip, so I opened my editor to crop a vertical version. Partway through, I realized the subject had drifted out of frame—I’d leaned slightly to the right while talking, and the vertical crop left me with half a face. Twenty minutes of re-adjusting keyframes and tracking the focal point followed. And if I’d done it the other way—shoot vertical first, then backfill landscape—both sides would have been empty and I’d have had to rebuild the background.

Shoot twice, or crop twice. Both paths eat time, and both make it easy to fix one thing while breaking another.

I’ve hit this more than once, and everyone I know who makes content goes through the same motions. It’s not a big problem, but it’s real, frequent, and annoying. So I started building Duovid.

It Only Wants to Do One Thing

Duovid’s positioning fits in a single sentence: a mobile tool that captures one take and outputs both a landscape (16:9) and a vertical (9:16) video at the same time.

(Its predecessor—and a version I explored in parallel—was called DualViewX, then doubleview. The name changed a few times, but the idea ran on a single thread.)

It’s not an editor, not a creation platform. It just makes “one input, two outputs” feel smooth at the moment of capture. Both frames—landscape and vertical—exist while you’re filming, the subject stays inside both, and when you’re done you walk away with both aspect ratios. No going back to crop a second time.

Why This Project, and Not Something Else

I have more than one idea I could be building. I chose Duovid because it matches a standard I set for myself: small, validatable, monetizable tool-shaped products.

Platform-type projects sound sexier, but they’re too heavy for a solo developer—long validation cycles, hard cold starts, fuzzy paths to revenue. Tool-shaped products are the opposite: the user’s problem is concrete, whether the value holds up becomes clear fast, and willingness to pay is easy to test.

I don’t need to build an ecosystem first. I just need to answer one question: will anyone pay for “landscape and vertical, shot in one take”?

That’s the soul of the whole thing. Not “how many features,” but “will anyone pay.”

The Biggest Enemy Is Scope Creep

The mistake indie developers fall into most easily—and the one I’m most prone to myself—is turning a small tool into a big platform.

Add filters, add templates, add cloud collaboration, add an account system, add one-tap distribution to every platform… each one looks “reasonable” on its own, but after you’ve added them all, the product gets heavy, the timeline stretches, the core value gets diluted, and you end up reaching neither shore.

So I gave Duovid a rule: validate the core first, and keep fighting off scope creep. Until “users will pay for dual-format output” is proven, no platform-style capabilities get built. Even when it itches, they don’t get built.

The restraint isn’t because I can’t build those features. It’s because building them now means spending a known cost to bet on a direction that hasn’t been validated yet.

Tech Choice: Native iOS Isn’t a Burden

A lot of people hear “native iOS” and immediately assume it’s expensive, defaulting to cross-platform. That logic doesn’t hold for me.

I do native iOS development on a Mac (Apple Silicon M4), and the friction is low: Swift / SwiftUI feel good to write, AVFoundation is first-party for handling the camera and video codecs, and the on-device debugging and TestFlight distribution pipeline is complete end to end. Duovid’s heavy lifting happens precisely in camera capture and dual-stream video encoding—and for that kind of work, the native path is actually the most direct and stable. Cross-platform frameworks tend to take a detour at this layer and step on a pile of landmines along the way.

So for me, native iOS is a genuinely viable—and actually less troublesome—option, not something you write off because “it sounds expensive.” Tech choices should follow the cards in your own hand, not the stereotype.

The Minimum Loop Already Works

This idea is not just sitting in a concept mockup. I have broken the core path down into a few engineering checkpoints that can be verified:

• show landscape and vertical framing guides in the camera preview instead of guessing the crop area after shooting;
• export both landscape and vertical photo variants right after capture, so the user does not have to reopen an editor for a second crop;
• after recording, use AVFoundation to produce two video outputs while mostly applying crop / transform, preserving audio and original quality as much as possible;
• connect the app library with system Photos, so the result is ready to publish rather than trapped inside the app.

These details look small, but they decide whether the product really saves the user those twenty minutes. Duovid’s validation target is not “does this look like a camera app”; it is “from pressing record to getting two publishable assets, are there any unnecessary steps left.”

It Hasn’t Worked Yet—Here’s What I’m Unsure About

I don’t want to pretend this is already a success. It’s still in the validation phase, and I don’t have answers to the following:

• Whether the core capture experience is stable. Dual-frame composition, focus, and stabilization—whether they hold up in real handheld use—is something I’m still polishing.
• Whether dual-stream output is reliable in quality and sync. Whether both streams hit the mark on resolution, frame rate, and audio-video sync. This is the floor for the product to exist, and the hardest technical gate.
• Whether the minimum paid scenario is something I can articulate. At which step, why, and how much users are willing to pay—if I can’t explain that, every tradeoff above is hollow.

If any one of these three collapses, Duovid may not stand. I accept that outcome. That’s exactly the point of running a tool-shaped experiment: spend the smallest possible cost to get to a clear “yes or no” as early as you can.

The “shoot both at once” pain point is real. But a “real pain point” isn’t the same as “a real business.” That middle step has to be answered by the product itself.