How Product Decisions Change As A Software Company Grows

When I first started building video editors, I thought the hard part was the timeline. Dragging clips around, snapping them to the playhead, making sure the audio didn’t drift out of sync when you trimmed a frame off the front. That was the puzzle I wanted to solve.

So I built my first editor around a transcript. The idea was simple: you edit a video by editing the text. Delete a sentence, and the corresponding clip disappears. Drag a paragraph, and the scene moves with it. For a certain kind of video — a talking-head explainer, a podcast with a camera running, a lecture capture — this was magical. It felt like cheating the complexity of non-linear editing. Instead of wrestling with a hundred tracks and razor tools, you just fixed the words and the timeline fixed itself.

But there was a ceiling I didn’t see until I hit it. Transcript-based editing works beautifully when the video is essentially a person talking. What happens when someone drops in a b-roll sequence? What happens when the video is mostly music and motion graphics with only a few lines of voiceover? The transcript stops being the spine of the project. It becomes a sidebar. And the editor, which was built around the assumption that the words were the primary structure, starts to fight you. I hadn’t designed a tool for editing video. I’d designed a tool for editing spoken audio that happened to have pictures attached. The product decision — “make the transcript the core” — was also an architectural decision. And when the product needed to stretch, the architecture wouldn’t let it.

That was the first lesson. It sounds obvious in retrospect: the way you structure your code is a product decision. The transcript editor worked until it didn’t, not because the idea was bad, but because the underlying model of what a video is was too narrow. I had optimized for speed of development and elegance of the core interaction, which is exactly what you should do when you’re trying to find out if a product has legs. But when the answer was “yes, but for a wider range of inputs than I expected,” the architecture couldn’t follow.

---

The C++ Detour

My second attempt was a non-linear editor written in C++. I wanted flexibility. A proper timeline with multiple tracks. Keyframes. The ability to handle any kind of content, not just transcriptions. This time, the product vision was broader, and the architecture was built to match. C++ gives you performance. For video, performance matters. Scrubbing through 4K footage can bring a machine to its knees if the decoding pipeline is sloppy. I wanted control.

What I got was a different kind of ceiling. Building a non-linear editor is already hard. Building it in C++ means you’re doing all the hard things manually. Memory management. Rendering pipelines. Audio graph handling. Cross-platform UI toolkits. I spent weeks implementing a single panel of the interface — a panel that I could have built in an afternoon using web technologies. Every feature I wanted to add required threading through three layers of custom infrastructure before I could even see it on screen.

The product decisions were still there, but they were buried under engineering. I found myself making trade-offs not based on what users needed, but on what I could afford to build given the time cost of the stack. Want to try a different layout for the inspector? That’s a day of work in C++ with a toolkit I barely understand. Want to add a text overlay tool with rich formatting? Better to skip it and keep the feature set minimal. The architecture wasn’t just slow to develop in — it was actively shaping the product roadmap by making certain paths too expensive to even consider.

Here’s the thing nobody tells you about technical debt in early-stage products: the most expensive debt isn’t the code you write poorly. It’s the code you write well, but in the wrong direction. The C++ editor had clean architecture. It was performant. It was also a tar pit that soaked up every hour I threw at it. I wasn’t building a video editor anymore. I was building infrastructure for a video editor that might exist someday.

---

Choosing Electron for TrailStudio

When I started TrailStudio, I made a different call. I chose Electron and web technologies. Not because Electron is the best platform for video editing — it isn’t, if you’re measuring raw performance. But it is the best platform for me to iterate quickly on UI and interactions. The bottleneck in my previous attempts wasn’t user feedback. It wasn’t ideas. It was the translation lag between “I want to try this” and “I can see it on screen.”

With Electron, that lag dropped from days to minutes. I could build a new panel, wire it up, and test it in the time it used to take me to compile a build. This changed the way I made product decisions. I stopped asking “what’s worth the engineering cost?” and started asking “what would make this feel better to use?” The cost had dropped low enough that I could afford to be wrong. And being able to afford to be wrong is, in practice, one of the most important capabilities a small team can have.

The trade-off is real, and I don’t want to hand-wave it. Electron apps are heavier. They use more memory. There are performance challenges around decoding high-resolution video that you’d handle more gracefully in a native stack. But for a product in the early stages of finding its shape, the ability to change that shape quickly matters more than the efficiency of the final form. I can always optimize later. What I can’t do is recapture months spent building infrastructure that turns out not to matter.

---

From Speed to Stability

That’s the early-stage trade-off in a nutshell: speed of iteration versus quality of infrastructure. When a software company is young, the product decisions are mostly about motion. Can we try this thing? Can we ship this feature? Can we see if this resonates before we run out of money? The architecture follows the product like a puppy chasing a car. You make decisions that would horrify an enterprise architect — singletons everywhere, state management duct-taped together, no test suite to speak of — because the alternative is building a cathedral when you need a pop-up stall.

But something shifts as a company grows. The tolerance for moving fast and breaking things narrows as the number of people relying on the product grows. A bug that would have been a minor annoyance to a hundred users becomes a support-crushing incident at ten thousand. A schema change that takes an afternoon when you’re the only developer becomes a coordinated migration when you have a team of twelve. The product decisions start to be about managing consequences rather than exploring possibilities.

I’ve watched this happen to companies that started the way I did. The early codebase, the one that let them ship features at a blistering pace, becomes the thing they’re terrified to touch. Every new feature has to navigate around the hacks and shortcuts that were sensible at the time. The team starts talking about “stabilizing the platform” or “paying down technical debt” — phrases that would have been meaningless in the early days, when the only person who had to live with the consequences was you.

---

Features Versus Infrastructure

The shift from features to infrastructure is one of the less glamorous parts of building a software company. Early on, features are the product. A feature is what gets a user to sign up, to recommend the tool, to pay. Infrastructure is the unglamorous thing that makes features possible — the API design, the database schema, the build pipeline, the testing framework. When you’re small, infrastructure is a means to an end. When you’re big, infrastructure is the product, in the sense that users feel its failures directly. A slow API is a product problem. An unreliable sync is a product problem. The user doesn’t care that the root cause is a database index that wasn’t designed for this scale. They just know the thing is slow.

So the product decisions change in character. Early-stage decisions are about capability: can we do this thing at all? Late-stage decisions are about reliability, performance, and maintainability: can we keep doing this thing for the next five years without it collapsing under its own weight? A young company might decide to use a third-party service for everything and focus on the core feature. A mature company might bring those services in-house because the third-party’s downtime is now their downtime. The decision is no longer about speed — it’s about control.

This is one of the reasons startups often stumble when they hit scale. The skills and instincts that serve you well in the early days — the bias toward action, the willingness to ship imperfect things, the impatience with process — start to become liabilities. The product manager who was great at shipping MVPs now has to think about migration strategies and deprecation policies. The engineer who could build a feature in a weekend now has to think about how that feature will be maintained by someone who joins the company two years from now. It’s a different discipline, and not everyone makes the transition.

---

The TrailStudio Approach

For TrailStudio, I’m trying to hold both of these modes in my head at once, even though I’m still in the early stage. The decision to use Electron was an early-stage decision — optimizing for iteration speed over long-term efficiency. But I’m also making bets that I think will serve me later. The editing engine is built around a data model that’s more flexible than what I need right now. I’ve spent time on the testing infrastructure that might feel like overkill for a team of one. I’m not building throwaway code; I’m building code that I want to live with.

But the key insight from the C++ editor is that you can’t optimize for the future at the expense of the present. If I’d chosen a stack that would theoretically scale beautifully but made it impossible to ship the first version, there would be no product to scale. The future only matters if you get there. And the only way to get there is to ship something, see who uses it, and let their behavior guide the next set of decisions.

What changes as a company grows isn’t just the decisions themselves. It’s the time horizon of the decision-making. Early on, you’re making decisions that only have to be right for the next few weeks. Later, you’re making decisions that have to be right for the next few years. The discipline isn’t about making better decisions — it’s about making decisions that are legible to the people who will have to live with them long after you’ve stopped working on that part of the codebase.

I think about that every time I open the TrailStudio codebase now. The decisions I’m making today, in the rush of building, are the architecture that future users will feel. They’ll feel it in the snappiness of the UI. They’ll feel it in the reliability of the timeline. They’ll feel it in the small ways the tool either gets out of their way or makes their life harder. The transcript editor failed because the architecture was too narrow. The C++ editor failed because the architecture was too expensive to build. The trick is finding the middle ground — a structure that’s broad enough to grow into, but cheap enough to change when you learn something new.

I’m still learning where that middle ground is. I suspect the answer is different for every product, and maybe for every team. But the process of finding it — that back-and-forth between what you want to build and what you can afford to build, between speed now and stability later — is the actual work of building a software company. The features are just the visible surface of those decisions. The product is the decisions themselves.