The hardest shutdown across all three startups was the one with revenue attached. Specifically, the $100K-annual-run-rate slice of Super AI that was working in 2025 even as the surrounding product was structurally failing. Killing a money-losing product is hard. Killing a revenue-positive one that still fails the framework is harder by an order of magnitude. This post is what that shutdown taught me, written carefully so the lesson generalises.

For founders reading this whose product currently makes money but might fail the framework: the post is for you. The discipline below is the one that makes "framework first, revenue second" binding instead of aspirational.

Why this was the hardest shutdown

MindWave shut down because the product never cleared the 10x bar; the decision was painful but the data was clear. Vibe AI shut down because the unit economics were broken; the decision was painful but the spreadsheet was clear. The Super AI revenue slice was different. The data was good. The customers were happy. Renewal rates were strong. The structural failures were elsewhere, in places the revenue line did not surface, and the framework demanded the call regardless.

Killing a money-losing product is, in some quiet way, a relief; the loss has been visible for months and the shutdown stops the bleeding. Killing a revenue-positive product is the opposite. There is no relief on shutdown day. There is only the discipline of the framework, the conversation with customers, and the long quiet of starting over.

The revenue was real

To be clear about scale: the revenue slice was a six-figure annual run rate, paid by real customers using the product for real work, with monthly renewal rates above industry norms for AI tools at that price point. There was no vanity in the metric. The customers were not free-trial users; they were paid, retained, and active.

That is the part that made the decision so much harder than the others. Closing the product meant closing real revenue, telling real users, refunding real money, and turning down what was, in absolute terms, a meaningful amount of cashflow for a bootstrapped operation. The framework's job is to make that decision possible without flinching. The framework worked.

The structural failures hidden by revenue

Revenue can hide three different structural failures at once.

Failure 1, eroding margin. The cost-of-inference per active session was rising slowly as users adopted longer prompts. The margin was positive at the headline level and turning negative on the heaviest cohort. Six months out the trend was extrapolating into a margin-negative state. Revenue today does not protect against margin tomorrow; the unit-economics curve goes where the underlying cost curve goes. This is the same failure mode I missed at Vibe AI (full reasoning at Vibe AI postmortem).

Failure 2, no defensible moat. The revenue slice was earning by being early, not by being defended. As the underlying foundation models commoditised the value, the moat narrowed monthly. Revenue does not create a moat; revenue is a result of having one or, in this case, of borrowing one temporarily. Read why I bet against workflow platforms in 2026 for the broader frame.

Failure 3, closing time-window. The category around the product was closing. ChatGPT Workspace Agents launched in April 2026, structurally absorbing the category Super AI had been competing in. Continuing the revenue slice would have meant being a slowly-declining wrapper inside a category that was being eaten by the substrate. This is the time-window read in the selection methodology at how I pick what to build next.

Revenue line vs framework health (Super AI revenue slice, illustrative) Revenue Margin per active Moat depth 0 mid high M1 M2 M3 M4 M5 M6 Source: Aryan Agarwal, Super AI revenue slice retrospective, 2025.
Revenue rising; margin and moat falling. The single-line view said healthy; the framework view said dead.

How the decision actually got made

The decision did not get made on a single day. It got made over six weeks of explicit framework checking. Three checks, on calendar, monthly. The revenue check passed. The margin check failed by month two. The moat check was failing slowly. The time-window read was already negative.

By the third check, the framework was failing two-of-three with revenue as the only positive. The framework's binding rule is that two-of-three is dead, just slower (the rule from three startups, three shutdowns). The framework was binding. The decision followed.

The hardest part was honoring the framework when the revenue line was the loudest signal in the room. Discipline is what you do when the easy answer says one thing and the framework says another. The framework saying "kill it" while revenue is rising is the test case for whether the framework is real.

Telling the customers

The shutdown email went out six weeks before the actual shutdown. The structure was: thank, explain honestly, provide migration path, refund unused balance, leave a personal email for follow-ups. The honest explanation was the part that took longest to write; "we are killing this because the structural framework says it cannot win" is correct but lands oddly. The version that worked: "we have data showing this product cannot be the right thing for you in twelve months, and we would rather move you to a working alternative now than wait for it to fail you slowly".

The conversations after were hard. Some customers asked us to keep it open. Some moved to the alternatives we recommended. A few wrote thoughtful long replies that I still keep. The discipline of writing a short, honest, generous shutdown email is one of the most useful things you can practice as a founder, because you will need it sooner or later regardless of how the company is doing.

What the shutdown taught me

Three lessons that shape Gravity directly.

Lesson 1, revenue does not exempt you from the framework. Every product, including revenue-positive ones, gets the same monthly framework check. No exceptions, no rationalisations, no "but it is making money".

Lesson 2, calendar-based checking is the only kind that works. Intuition-based checking allows the loudest signal (revenue) to drown out quieter signals (margin, moat). Calendar-based checking forces all three to be looked at on the same day, regardless of mood.

Lesson 3, generous shutdowns earn long-term trust. Customers who got a clean shutdown email and a refund are more likely to try the next product than customers who got a confusing churn experience. Generous shutdowns are an investment in the founder's next bet, not a cost.

Frequently asked questions

Why kill a product that is making money?

Revenue is a single check. The framework I now hold requires three: 10x value, scaling potential, sustainable margins. A product can be revenue-positive and still fail two of the three checks, which makes it a structural dead end with cashflow attached. Cashflow is not the same as a viable company. Killing on principle protects the next bet.

Was the revenue real or vanity?

Real. The product had paying customers using it for real work, with renewal patterns that were better than industry norms. The revenue was not a vanity metric. The structural failure was elsewhere: the cost-of-inference per active session was creeping up, the product had no defensible moat, and the time-window for the category was closing.

How do you tell paying customers you are shutting down?

Honestly, with notice, with a migration path, and with a refund policy that errs on generous. The hardest emails I have written are not to investors. They are to paying customers who are using the product for real work and now have to find an alternative. That is the part of shutdown that requires craft, not just decision-making.

Did you regret the decision?

Two months later, no. Two years later, definitely not. The revenue was real but the framework failure was real too. Continuing would have been compounding into a structural dead end with the cashflow as the rationalisation. The discipline of killing on principle, when the framework fails, is the only way to make the framework binding.

What is the lesson for other founders?

Revenue is necessary but not sufficient. A revenue-positive product that fails any of the three checks is a structural dead end. The check it fails is usually the one the founder is least comfortable confronting. Set the framework before the product ships and check it on calendar. Do not let revenue postpone the framework conversation.

Three takeaways before you close this tab

Sources