We shipped 111 one click apps. 9 of them get used.
We built 111 one click apps for Arteza in about six weeks, mostly by describing each one and shipping whatever came back that ran. Felt incredible at the time. Then I pulled the usage. 9 of them cover roughly 80 percent of runs, and around 40 have never been opened by anyone outside the team.
The build time wasn't the cost. That was cheap, that's the whole point of working this way. The cost is that every one of those 111 is a surface that can break, and I now have a settings page nobody can scan and a support inbox where I often can't tell which app someone means. Cheap to write, expensive to own.
What I'd do differently is set a kill rule before building, something like an app gets deleted if it does nothing for 30 days. We didn't, so now deleting feels like admitting the sprint was a bit silly, which is a bad reason to keep code alive.
If you generate a lot of surface area this way, do you have an actual rule for killing what didn't land? I don't, and it's showing.
Replies
"Cheap to write, expensive to own" is the line. The trap is that shipping cost went to near zero but the ownership cost per surface didn't move at all — every one of those 111 still needs a support answer, an auth story, and someone to notice when it breaks. What worked for me was giving each thing an explicit expiry: if nobody touches it in 30 days it gets archived, not maintained. Sunsetting 100 of yours would probably do more for the support inbox than any consolidation.
@sagar_gupta36 Archive rather than maintain is the distinction I was missing. I kept framing it as delete, then flinching, because delete needs a decision and archive just needs a cron. Where it gets hard is the middle group, roughly 30 that have been opened once or twice by someone real. Those aren't dead, they're rare, and a surface with one user still owes that user an answer at 2am, so the rule probably has to be runs per month rather than ever touched.