Why we shelved Novus Stream Studio: a second-screen idea that was really several apps

An app testing lab only works if it is willing to kill things, and the honest accounting of what got killed is more useful than another launch announcement. This is the first of three retrospectives on products Novus built and then retired, written plainly because the reasoning is the valuable part. Novus Stream Studio was a second-screen workflow for creators — a companion surface meant to sit alongside a stream and handle the things a creator juggles while live. It was a genuinely appealing idea, it got built, and then it got shelved. The reason it was shelved is the interesting part, and it is not the reason you might guess.

The product did not fail because the idea was bad or because nobody wanted it. It failed a different and more important test: it was not actually one product. What looked, from the outside and on the roadmap, like a single coherent app was, underneath, several distinct applications bundled under one name — and that structural fact, combined with the bandwidth reality of a one-person operation, is what made continuing to build it the wrong call. This is a post about recognizing when a single product is secretly a portfolio, and why that recognition is a valid reason to stop.

The concept behind Studio was the "second screen" — the idea that a creator working live is managing a whole set of tasks that do not belong on the main screen the audience sees. Monitoring the stream's health, keeping an eye on the things that need attention during a session, managing the workflow of going live and staying live: all of that is real work that happens on the side, and the pitch for Studio was to give it a dedicated, calm home rather than a sprawl of browser tabs and windows. As a description of a problem creators have, it held up. The fragmentation of the live-creator workflow is real, and a tool that reduced it would be worth using.

The trouble started in the gap between that clean description and what building it actually required. A "second-screen workflow" sounds like one thing, but a workflow is a sequence of distinct jobs, and each job in Studio's sequence was, on inspection, its own application-sized problem. The piece that handled one part of the live workflow had little in common, technically or in its design, with the piece that handled another part. They shared a name and a goal and almost nothing else. The single product was a container for several products that happened to be adjacent.

There is a specific trap in product design where a unifying concept hides a lack of unity underneath. "Studio" was that concept — a word broad enough to cover several different tools, which made them feel like one product when they were not. The cost of that hidden multiplicity is that you do not get the efficiencies of building one thing. Each component needed its own design thinking, its own engineering, its own testing, and its own maintenance, because they were genuinely different. The shared name bought coherence in the marketing and nothing in the building. Underneath, the team — which is to say, one person — was being asked to build and maintain several apps at once while telling itself it was building one.

This is different from a single app that has several features. A well-scoped app has features that share a core, reinforce each other, and are cheaper to build together than apart. Studio's pieces did not share a core; they shared a customer moment. Bundling them did not make them cheaper to build — it made the bundle as expensive as the sum of its parts, with the added cost of stitching them into something that felt unified. The "one product" framing was hiding the fact that the real commitment was to a small portfolio of apps, each of which deserved to be evaluated on its own merits and none of which was getting the focused attention a standalone app would need.

The reason "it is secretly several apps" was fatal rather than merely inconvenient comes down to bandwidth. A larger team can absorb a product that is really several apps by putting different people on different parts. A one-person operation cannot. When the apps inside Studio each needed real, focused time — the kind of sustained attention that turns a rough component into a reliable one — there was only one person to give that time, and that person could not give several apps the depth each required without every one of them staying shallow. The honest assessment was that Studio would need substantially more of my own time than I had to give it, not because of any single hard problem, but because it was several medium problems demanding attention in parallel.

That is a different failure mode than "we could not figure out how to build it." Every individual piece of Studio was buildable. The issue was that building all of them well, and maintaining all of them, exceeded what one person could sustain alongside the rest of the portfolio. A product that demands more founder-hours than exist is not a product you are going to ship well; it is a product you are going to ship thinly across several fronts, which is worse than not shipping it. Recognizing that the constraint was bandwidth rather than feasibility is what turned "keep pushing" into "this is the wrong shape for who is building it."

It is worth understanding why the disguised-portfolio trap is so easy to fall into, because the mechanism is a genuinely appealing idea rather than an obvious mistake. A unifying concept — "second screen," "studio," a single word that wraps several capabilities into one story — is seductive precisely because it feels coherent and ambitious. It gives a product a clear identity, a clean pitch, and the sense of building something substantial rather than a scattering of small tools. The concept does real work in making the product feel like a product, which is exactly what makes it dangerous: the coherence is in the framing, not necessarily in the underlying software, and the framing can paper over a lack of unity that the building will eventually expose.

This is why the trap catches thoughtful people rather than careless ones. A careless builder ships a random pile of features; a thoughtful one finds a unifying concept that ties features together, which feels like good product thinking and often is. The problem arises when the unifying concept ties together things that do not actually share an underlying core — when the unity is a story about a customer moment rather than a shared technical and design foundation. The concept feels like it is organizing real coherence when it is sometimes only organizing adjacency. The seduction is that good-product-thinking and disguised-portfolio look identical from the framing level, and you only discover which one you have when you start building and find the pieces share a name and little else. The appeal of the concept is what makes the disguise convincing, including to the person building it.

The practical value of this retrospective is a test that can catch the disguise before the building commits you: ask whether the pieces of your product share a core that makes them cheaper to build together, or whether they merely share a customer and a name. A genuine single product has components that reinforce each other and reuse a common foundation, so building them together is meaningfully cheaper than building them apart — the shared core is real leverage. A disguised portfolio has components that happen to serve the same user moment but are technically and conceptually distinct, so bundling them buys coherence in the marketing and no efficiency in the building. The test is about shared foundation, not shared purpose.

Applying this test honestly requires looking past the appealing concept to the actual software underneath. Sketch the pieces, and for each pair ask: do these reuse the same core, or are they separate problems that I am choosing to build under one banner? If most pairs are separate problems, the unifying concept is a story rather than an architecture, and you are signing up to build several apps while telling yourself you are building one. Running this test at the concept stage — before the months of building that reveal the truth expensively — is what lets you either rescope the product to a genuine single core or recognize that it is a portfolio you cannot afford. The test is cheap to run and the disguise is expensive to discover the hard way, which is exactly why it is worth running deliberately on any product whose appeal rests on a broad unifying concept.

A natural assumption is that bundling several capabilities into one product saves effort through shared infrastructure and a unified codebase, and it is worth being precise about why that assumption failed for Studio. Bundling saves effort only when the bundled things share enough that building them together reuses substantial work — a common data model, shared components, overlapping logic. When the pieces are genuinely distinct, as Studio's were, there is little to reuse, so building them together costs essentially the same as building them separately, plus the additional cost of stitching them into something that feels unified. The bundle was as expensive as the sum of its parts, with a stitching tax on top, which is the opposite of the efficiency bundling is supposed to provide.

This is the crucial distinction between a feature and a sub-app. A feature added to a well-scoped product shares the product's core and is cheaper to build because of that sharing — the marginal cost of the feature is low because most of the foundation already exists. A sub-app bundled under a product name shares the name and the customer but not the core, so its marginal cost is nearly its full standalone cost, because there is no foundation to build on. Studio's pieces were sub-apps, not features, which meant the "single product" was carrying the full cost of several apps with none of the savings that genuine feature-sharing provides. Recognizing that bundling distinct things does not save effort — that it costs as much as building them apart plus integration — is what dispels the illusion that a disguised portfolio is more efficient than the separate apps it actually is. The bundle is not a discount; it is the full price plus assembly.

By the time the disguised-portfolio nature of Studio was clear, real work had already gone into it, which created exactly the sunk-cost pressure that keeps doomed projects alive — the sense that abandoning it wastes the effort already spent. This pressure is real and worth naming, because it is the main force arguing against the right decision. Having built several of Studio's pieces, the instinct was to push through and finish, to make the investment pay off rather than write it off. That instinct is precisely the trap, because the effort already spent is gone regardless of what happens next, and continuing only adds more effort to the loss if the product is fundamentally the wrong shape for the operation.

The discipline of the kill decision is to ignore the sunk cost and ask only the forward-looking question: given where things are now, is continuing to build and maintain this the best use of the scarce attention available. For Studio, the honest answer was no — finishing and maintaining several apps under one name would consume founder-time that fewer, focused products would use far better, and the work already done did not change that calculus. Recognizing that the sunk cost was already spent, and that honoring it by continuing would only spend more, is what allowed the shelving to be a clean decision rather than a reluctant one dragged out by attachment to past effort. The work that went into Studio was not wasted by shelving it; it was wasted by being the wrong shape, and shelving was how the operation stopped adding to that waste rather than the cause of it.

The clearest vindication of the shelving decision is what the freed attention produced. The time that would have gone into building and maintaining several loosely-related apps under the Studio banner went instead into fewer, focused products — the background remover and the visualizer — each of which is one coherent thing that one person can actually build and maintain to a real standard. Those products grew rich and reliable precisely because they received the focused, sustained attention that Studio would have fragmented across its several pieces. The contrast is instructive: spread thin across a disguised portfolio, nothing reaches depth; concentrated on a few genuine single products, each can become excellent.

This is the positive case for killing things, which the negative framing of "shelving a product" can obscure. Killing Studio was not just removing a liability; it was reallocating a scarce resource — founder attention — to where it could produce far more value. The lab model's willingness to cut is what makes its concentration possible, because attention is finite and every product kept alive is attention not available to the others. The products that thrived did so partly because the products that did not earn their place were cut, freeing the focus that depth requires. Shelving Studio was an investment in the products that remained, and their quality is the return on it. The decision looks like subtraction and is actually the precondition for the concentration that addition-by-focus requires, which is the whole logic of why a lab that kills well builds better than one that keeps everything.

So Studio was shelved, and within the app-testing-lab model that is the system working rather than failing. The lab's whole premise is that scarce attention should go to the things that earn it, and a product that would have required spreading one person thinly across several apps was, almost by definition, not the best use of that attention. Shelving it freed the time to do fewer things properly — the background remover and the visualizer, each of which is one focused product that one person can actually build and maintain well. The decision was not a verdict on the second-screen idea; it was a verdict on the match between that idea's real shape and the operation's real capacity.

The transferable lesson is to check whether your single product is secretly a portfolio before you commit to building it as one. The test is simple: do the pieces share a core that makes them cheaper to build together, or do they just share a customer and a name? If it is the latter, you are signing up to build several apps under the comfortable illusion of building one, and you should price that commitment honestly against your actual capacity to build and maintain apps. For a solo operation especially, the right number of apps to build at once is small, and a "single product" that violates that number in disguise is one of the easier ways to overcommit without noticing. Studio was the case that taught us to look for the disguise. The companion retrospectives cover a different failure — a product that was too generic to earn its place — and a third where the operating constraint was infrastructure cost rather than time.