Back in the pre-user-accounts era, Now I Get It! had a global daily processing limit: a shared cap of twenty PDFs per day across every visitor, enforced via an SSM parameter and a dedicated Lambda that scanned DynamoDB for today's job count. It was a safety valve -- a way to prevent one enthusiastic user (or one accidental script) from racking up hundreds of dollars in Anthropic API costs before I noticed.
With user accounts and credit-based pricing now in place, every user's spending is governed by their own credit balance. The shared cap has no job left to do: if a user runs out of credits, they stop. If an enthusiastic user buys a lot of credits and runs a lot of papers, that's what the credits are for.
So I deleted it.
Why a clean removal, not a "set it to 999"
The tempting shortcut was to set the limit to something absurdly high and leave the infrastructure in place. I try not to do that, because it leaves dead code that implies "this used to matter, maybe it still does," and the next person reading the code (me, three months from now) has to figure out whether the cap is load-bearing. Clean deletions communicate this is intentionally gone.
The quota subsystem touched five places: the CloudFormation template (an SSM parameter, a dedicated Lambda, an API Gateway route and integration and permission, an IAM ARN, and an environment variable on the confirmation Lambda), the handler itself, a local-dev endpoint in the Python backend, some "quota exceeded" styles on the drop zone in the frontend, and the deploy script's list of Lambdas to package. 173 lines deleted across those files, net -172.
One field on the job records -- a creation timestamp -- was preserved, because it's used by other DynamoDB indexes that aren't quota-specific. Removing it would have been a schema change I didn't need.
Two things I found while deleting
Two discoveries were worth knowing. First: the confirmation Lambda never actually enforced the daily quota server-side. The check only existed in the quota endpoint itself, and that endpoint was never called as part of the confirm flow -- only the frontend polled it to display a "we're full for today" banner. So the whole system was advisory, not a real cap. A motivated script could have bypassed it by skipping the frontend entirely.
Second: the "quota exceeded" styles in the frontend were dead code. No JavaScript path ever added that class to any element. They had probably worked at some point and stopped working after a frontend rewrite, and nobody had noticed because the quota never actually got hit.
Removing dead systems is easier when the system was already doing less than you thought it was.
The deploy
Deployed to test. CloudFormation updated without rollback, the old quota endpoint returns 404, health endpoint healthy, upload and processing unaffected. A short PR, a quiet deploy, and one fewer thing to think about before launch.