Keep, kill, or shelve: a structural "no" as a product filter

Most advice about killing projects focuses on the ones that did not work — the feature nobody used, the app that never found traction. That is the easy case. The harder and more honest case is killing a project that works fine but cannot exist cheaply within how you operate. We recently shelved two of those: an AI-agent ecosystem we had been developing, and a sports-odds project. Neither failed technically. Both were structural nos. This post is about why a structural no is a complete and honest reason to stop, not a failure of execution.

The whole operation runs on a simple economic premise — apps that run almost for free on just hosting and a database, with the heavy lifting done on the user's own device. That premise is not a preference; it is the thing that makes a solo, free, ad-supported portfolio viable at all. So anything that violates it is not a product we are choosing not to finish. It is a product that cannot fit, and recognizing that early is a feature of the process, not a bug.

The sports-odds project was shelved on unit economics. Keeping odds fresh to the minute meant an always-on database reading and writing constantly, plus an external data-feed bill — costs that exist whether or not a single person is watching. That is the exact opposite of the model. A tool that runs almost for free is one whose costs scale with use and approach zero at idle; a tool that bills you around the clock to stay current is a standing liability that the ad revenue of a small project cannot reliably cover.

The project might have been genuinely good. That was never the question. The question was whether it could exist within an operating model built on near-zero idle cost, and the answer was structurally no. No amount of execution polish changes an always-on cost into an on-demand one.

The shelved AI-agent ecosystem failed the same test from a different direction. It leaned on heavy third-party and paid-API usage, which runs directly counter to how we want to build. The entire reason the apps can be free and private is that the expensive computation happens on the user's own device, not on metered services we pay for per call. An ecosystem whose core depended on heavy external API usage would have inverted that — every user action a cost we absorb, the margin structure of a thing we cannot afford to give away.

Shelving it promoted the underlying principle to an explicit filter: avoid heavy third-party and paid-API dependencies. That is now a rule the next idea has to pass, the same rule that screened out the sports project. Naming the constraint turned a painful one-off decision into a reusable test, which is the real value of going through it.

There is a temptation to frame every shelved project as a failure — we tried, it did not work out, chalk it up. That framing is inaccurate and unhelpful here. These projects did not fail; they were correctly identified as not fitting the model, ideally before pouring more time into them. A structural no — a product that cannot exist cheaply within how you operate — is a complete reason to stop, and treating it as such is what keeps an operating model coherent instead of letting it drift into things it cannot sustain.

The backlog records the things we have tried, including the ones we stopped, precisely because stopping for the right reason is part of operating well. A portfolio that only ever adds is a portfolio that eventually collapses under commitments it cannot fund. The discipline to say "this is a structural no" is what protects the things that do fit.

Most advice about discontinuing projects addresses the easy case: the thing that failed, the feature nobody used, the app that never found traction. Cutting those is straightforward because the evidence is obvious and the decision barely feels like a loss. The genuinely hard case, and the one this filter is built for, is killing something that works perfectly well but cannot exist cheaply within how you operate. Both shelved projects — the sports tool and the AI-agent ecosystem — were in that harder category: not failures of execution, but successes that failed a structural test. Stopping them required overriding the natural reluctance to abandon something functional.

That reluctance is exactly why a filter, rather than case-by-case judgment, is necessary. In the moment, a working project generates every reason to keep going — the effort already spent, the visible functionality, the sense that abandoning it wastes the work. Those feelings are real and they are precisely what leads operations to accumulate commitments they cannot sustain. A structural filter applied up front cuts through them by reframing the question from "is this good?" — to which a working project always answers yes — to "can this exist within how we operate?", which has an honest answer independent of how much you like the result. The filter exists to make the hard cut on principle rather than on mood.

The filter rests on a specific economic shape worth defining exactly, because vagueness would make it unenforceable. "Runs almost for free" means an application whose costs scale with use and approach zero when no one is using it — it sits on hosting and a database, and the heavy computational work happens on the user's own device rather than on metered infrastructure the operator pays for. The marginal cost of one more user, or one more idle hour, is near nothing. That shape is what makes a free, ad-supported portfolio viable for a solo operation: revenue can be modest because cost is structurally low, especially at idle.

The sports project violated this with an always-on bill — a database reading and writing constantly plus an external feed, costs that accrue around the clock whether or not anyone is watching — and the AI-agent ecosystem violated it with heavy per-action paid-API usage, a cost absorbed on every user interaction. Both inverted the economic shape the whole operation depends on. Defining the shape precisely is what lets the filter be applied without argument: a candidate either fits the "costs approach zero at idle, heavy work on the device" pattern or it does not, and that is a factual question rather than a matter of enthusiasm. Precision in the definition is what gives the filter its teeth.

The deeper value of asking the structural question at the start is that it neutralizes sunk cost, the bias that keeps failing-to-fit projects alive long past the point they should have been stopped. Once significant time has gone into something, the instinct is to protect that investment by continuing, even when the honest assessment is that it cannot work within your constraints — and the more you have invested, the stronger the pull. Discovering a structural mismatch only at the end, after heavy investment, is the worst case, because that is when sunk cost screams loudest and the temptation to push through a fundamentally unfit project is greatest.

Asking "can this run almost for free?" before building, rather than after, is how the filter sidesteps that trap entirely. A structural no identified up front costs almost nothing to act on — there is little investment to feel attached to — whereas the same no discovered after months of work is agonizing precisely because of everything already spent. The discipline is therefore not just to have the filter but to apply it early, at the candidate stage, when the answer can change the decision cheaply. Used that way, the filter converts a painful late abandonment into a quick early pass, which is the difference between a clean operating process and a graveyard of half-built projects nobody wanted to kill.

It is important that a structural no is not a judgment about the quality of an idea or the skill of the person who had it — it is a statement about fit between the idea and a particular operating model. The sports tool might be an excellent product for an operation built to carry always-on infrastructure costs; the AI-agent ecosystem might thrive for a company structured to pay for heavy API usage. Their failing was not being bad, it was not fitting this specific model, which is a property of the relationship between the idea and the constraints, not a flaw in the idea itself. Framing it that way keeps the filter from feeling like a condemnation.

This framing matters for morale and for honesty in equal measure. Treating every shelved project as a failure is both inaccurate and demoralizing; treating a structural no as information — useful data about fit — keeps the process clear-eyed and keeps the operator willing to try things, knowing that stopping for the right reason is part of the method rather than a mark against them. The backlog records what was tried, including what was stopped, precisely because stopping on a structural mismatch is a complete and respectable reason. An idea that does not fit is not a defeat; it is a fit problem correctly identified, which is exactly the kind of clarity a coherent operating model is supposed to produce.

It is easy to read the filter as purely negative — a gate that rejects ideas — but its more valuable function is positive: it points toward the kind of product that fits, which is generative rather than merely restrictive. The "runs almost for free, heavy work on the device" shape is exactly the shape of the products that have succeeded in the portfolio — the in-browser tools that push computation to the user's machine and stay cheap to operate. So the filter does not just screen out the always-on and the API-heavy; it actively describes the design space where good candidates live, which is a guide for what to build, not only a test for what to reject.

Used as a lens, the filter shapes ideation toward its strengths. Knowing that a candidate must run almost for free pushes thinking toward client-side computation, toward capabilities that can live on the user's device, toward designs that stay cheap at idle — and those constraints have repeatedly produced the ecosystem's best work, because the constraint and the strength are the same thing. A filter that only said no would be a brake; one that also describes the fertile design space is a steering wheel. The structural no is the visible half of a rule whose more important half is the structural yes it points toward.

A large, well-funded company can afford to carry projects that do not pay their way, cross-subsidizing an always-on cost center with revenue from elsewhere, at least for a while. A solo operation cannot — there is no other revenue to absorb a standing infrastructure bill, so a single project that costs money around the clock whether or not anyone uses it is a direct, ongoing drain that the rest of the portfolio has to cover. The smaller the operation, the less slack there is to absorb a structural mismatch, which makes the discipline of the filter more important, not less, for a lean operator.

This is why the runs-almost-free constraint is not a stylistic preference but a survival rule at this scale. A portfolio of cheap-to-run apps can sustain itself on modest ad revenue precisely because none of them bleeds money at idle; introduce one that does, and it quietly taxes everything else. The filter protects the viability of the whole operation by keeping every component within the economic shape that makes the model work. For a small operator, saying a disciplined no to a structurally expensive project is not pessimism — it is the thing that keeps the lights on for the projects that do fit, which is the entire point of operating with a filter rather than on enthusiasm alone.

The structural filter is not a standalone rule but part of a larger operating loop — build, ship, measure, and decide whether to keep or kill — and it occupies a specific, valuable position in that loop: the very front. Most keep-or-kill decisions are made after shipping, on the evidence of how a product performs with real users, which is the right place for questions of demand and traction. But the runs-almost-free question is different, because it can and should be answered before building, on the structure of the idea rather than on its reception. Placing it at the front of the loop screens out structurally unfit ideas before they consume the build-ship-measure effort that should be reserved for ideas that could actually fit.

This front-loading is what keeps the measure-honestly stage focused on the questions it is good at. If a structurally expensive idea slips through to shipping, its eventual death gets entangled with traction data and sunk cost, muddying a decision that should have been clean. By contrast, catching the mismatch up front keeps the post-launch evaluation about the things only real usage can reveal — does anyone want this, does it earn its keep in attention and ad support — rather than about an economic flaw that was knowable from the start. The filter and the measure stage are complementary: one screens for structural fit before building, the other measures real performance after, and keeping them in their proper places makes both decisions cleaner.

A possible misreading is that a runs-almost-free constraint makes the operation timid — that it only builds small, safe, cheap things and avoids anything ambitious. That gets it backwards. The constraint is not a cap on ambition but a direction for it: the most ambitious work in the portfolio, like running real neural networks entirely in the browser, is exactly the kind of thing the constraint pushes toward, because pushing heavy computation onto the user's device is both how you stay cheap and how you do something technically impressive. The filter channels ambition into client-side capability rather than into expensive infrastructure, and client-side capability is a genuinely hard, genuinely ambitious place to work.

So what the filter rules out is not ambition but a particular expensive shape of it — the always-on service, the heavy-paid-API product — in favor of an equally ambitious but structurally sustainable shape. Building a ninety-tool AI suite that runs without a backend is not a modest goal; it is a demanding one that the constraint made necessary and therefore made happen. The discipline of "it must run almost for free" forces a kind of cleverness that an unlimited budget would let you skip, and that cleverness is where a lot of the ecosystem's most distinctive work comes from. The filter does not shrink the ambition; it points it at problems where being cheap to run and being technically impressive are the same achievement.

The practical upshot is that runs-almost-free is now a question asked at the start, not discovered at the end. Before building, the test is simple: can this exist on hosting and a database with the heavy work on the user's device, and does it avoid an always-on bill and heavy paid APIs? If yes, it is a candidate. If no, it is a structural no, and the kindest thing for everyone is to recognize that before investing further, not after.

Applied honestly, this filter is what lets a small operation keep shipping free, private, sustainable tools instead of accumulating expensive commitments. It is the same logic the keep-or-kill operating model runs on, and the same logic that makes the AdSense-supported, no-paywall revenue model work — all of it depends on the marginal cost of a user staying near zero. The overhead post covers the economics this protects, and the app-testing-lab post covers the wider keep-or-kill discipline it lives inside.