Shipping a feature got cheap. Deciding to delete one didn't.
We've got 111 one click apps in Arteza across six studios. Building them was the easy part. With an agent you can take a prompt template to a shipped, working app in an afternoon, so adding one feels free and you stop asking whether it earns its place.
The bill arrives later. A menu nobody can scan. Support load for things almost nobody opens. And every model swap underneath means retesting all of it, because 111 apps sitting on 30+ models is a test matrix, not a feature list.
The mistake wasn't building them. It was not writing the kill rule first. If I'd set a number up front, opened by this many distinct people in 30 days or it goes, removal would be a rule instead of an argument. Now every deletion is a conversation with someone who liked that one.
Vibe coding collapsed the build cost and did nothing to the maintenance cost, so the ratio is worse than it has ever been. Most of the feature bloat I see right now isn't ambition, it's just that saying no got expensive relative to saying yes.
If you've shipped fast with an agent, do you have a deletion rule, or are you accumulating?
Replies
tried deleting a fix, reverted code, test still passed. test was never asserting bug in first place ) when generated code comes with tests that pass by accident you can never safely delete anything, no way to know what is actually holding system up
@konstantin_tikhaev That's worse than the dead feature, because a test passing for the wrong reason votes against every deletion you'll ever propose. The only check I've found is breaking the thing on purpose before you trust the suite, and if nothing goes red the test wasn't holding anything up. I've started doing that on anything an agent wrote the tests for, which is most of it now. Green is a claim, not evidence.
@asadmalik901Â Manual mutation testing became only real sanity check. Falsifying every generated test takes more time than writing assertions ourselves)
Softorino 💻📲
My changelog is the thing that gave this away for me. I write copy for 5 apps on a small team, and every quick add still needs a QA pass across macOS versions, so the afternoon build never stays an afternoon. I like the number-of-users trigger, I've never written one down and probably should.
@yelyzaveta_kibets The QA pass is the honest cost and it never makes it into the estimate, which is exactly why the afternoon build feels free. If you do write a trigger down, write it before the thing ships, because afterwards there's always someone attached to it and the number turns into a negotiation. Ours is distinct users in 30 days. Set it low enough that you'd actually pull the trigger, a rule you flinch at is the same as no rule.
Softorino 💻📲
@asadmalik901Â Distinct users in 30 days beats general opens, since it points at a real audience instead of a curiosity click. I'll write the number down before the next thing ships instead of after, so it isn't a negotiation with whoever likes it. Appreciate the QA-pass reframe, that's the cost that never makes the estimate.
For me deleting the code was the cheap part
The expensive part was everything that still described it: FAQ, docs, pricing page, whatever an AI assistant indexed last month...
I had a FAQ telling people to install a third-party add-on for audio after the product had started generating the audio itself. Nobody noticed, because nothing failed.
So now when a claim goes, the phrase goes into a test that scans the site copy and fails the build if it shows up again
@siarheihamanovich The copy is worse than the code because nothing throws. We audited 38 modals in Arteza and the one that actually cost us was a sign-in gate still promising a credit amount we'd changed months before. No error, no ticket, people just arrived expecting more than they got. Your build-failing copy test is the right shape, I'd only add that the worst offenders aren't docs, they're the small transactional surfaces nobody files under copy.
@asadmalik901Â hey. That's exactly the case that was hardest for me too, so the check doesn't look for phrases there, it looks for numbers. The test walks every .ts/.tsx file in src - modals, emails, the sign-in gate plus the product document, and any "N free credits" has to equal the one constant the billing code actually uses. Same for the language count and the card limits. Change the constant and every stale surface fails the build on the same commit, including the ones nobody would ever file under copy.
Curious whether your 38 modals audit turned into anything automated, or stayed a one-off pass?