The monthly check-up: security, performance, and cost

You own an asset you can't personally inspect. That's not a crisis — it's the normal condition of owning almost anything. People own buildings without being structural engineers; what makes it safe is not learning engineering, it's commissioning inspections on a schedule.

Your inspector is the same AI that built the app. That sounds circular, but it works, for one reason: the prompts below ask it to look for problems and report them — not to fix anything. An AI asked to build is agreeable and moves fast. An AI asked to audit, with specific things to check, is genuinely good at finding the corners its faster self cut. You just have to ask, and almost nobody does.

Here's what not asking costs. This month we discovered Groundwork had been paying about $41 a month to keep its database awake — for an app in private preview, with a handful of users. A monitoring service had auto-created a check that pinged our homepage every sixty seconds; every ping queried the database; the database bills for time spent awake, and it never once got to sleep. No error anywhere. Every dashboard green. The only symptom was a line on an invoice, and it took a deliberate cost investigation to find it. The cost prompt below asks exactly the questions that would have surfaced it in minutes.

Ground rules for every pass

• Put them in the calendar, monthly. These find slow problems — the kind that are invisible until the day they aren't. No signal will ever tell you it's time.
• Run each in a fresh session. An audit shouldn't inherit the optimism of the conversation that built the thing being audited.
• Report first, fix separately. Keep the roles apart: today it's the inspector. Fixing comes after you've read the report.
• Keep the reports. Ask the AI to save each one as a dated file in the project. Next month's pass can compare, and "new since last month" is the most useful column there is.

The security pass

Do a security review of this app, as its auditor rather than its author.

Check at least:
- Secrets: are any passwords, API keys, or tokens written into the code or
  saved into version-control history, rather than kept in environment files?
- Doors: list every way data can get in or out (pages, APIs, webhooks, file
  uploads, scheduled jobs). For each: who can reach it, and does it verify
  the person is allowed to do what it does?
- Personal data: what do we store about users, where, and is any of it data
  we don't actually use? What would a leak of it mean?
- Dependencies: confirm the vulnerability check on our third-party
  packages really runs at every save (it should be one of our standing
  rules), and explain anything it is currently reporting.
- Money and email: could anyone trigger a charge, a refund, or outgoing
  email in a way we didn't intend?

Report in plain language for someone who will never read the code, ordered
by how bad each item would be if it went wrong. Save the report as a dated
file in the project. Do not change anything yet.

The performance pass

Do a performance review of this app.

Check at least:
- The slowest pages and actions today, and which ones get slower as data
  and users grow.
- Database access: anything reading far more than it needs, running
  repeatedly in a loop, or heading for trouble at 100x today's data.
- Page weight: oversized images, or libraries we barely use that every
  visitor downloads anyway.
- Anything recomputed on every request that could be computed once and
  reused.

For each finding: what a user would actually notice, when it starts to
matter (now / at 10x users / probably never), and roughly what fixing it
involves. Plain language, save the report as a dated file, change nothing
yet.

The cost pass

Do a cost review of this app.

Check at least:
- Every paid service this project touches — hosting, database, AI models,
  email, file storage, monitoring. Find them from the code and configuration
  rather than asking me. For each: what actually drives the bill (per
  request, per user, per gigabyte, per token, per hour awake)?
- Everything that runs on a schedule, in a loop, or automatically — could
  any of it run more often than intended, or keep a paid resource busy
  around the clock?
- AI usage: anything calling a paid model more often than needed, sending
  more context than needed, or somewhere the answer could be reused?
- If traffic grew 100x tomorrow, which bill moves first? Could one user, or
  one bot, make any of these spike?

Tell me the three most likely ways this app surprises me on an invoice.
Plain language, dated file, no changes yet.

The housekeeping pass

AI agents are prolific and messy builders: when asked to change something, they often write a new version and leave the old one behind. That clutter isn't just untidy — it actively harms you, because the next session reads the leftovers too, and sooner or later it "fixes" the dead version of a feature while the live one sits untouched. Housekeeping is also where the files from part two get their audit: docs drift, and backlogs silt up.

Do a housekeeping review of this app.

Check at least:
- Dead code: files, features, or old versions of things that nothing uses
  anymore — including leftovers from earlier attempts at current features.
- The docs: read PROJECT.md and README.md against the actual project, and
  list every place they've drifted from reality.
- The backlog: go through OPEN_WORK.md and flag anything that's already
  done, no longer worth doing, or has quietly become urgent.
- Packages: any third-party dependencies we installed but barely use, or
  that duplicate each other.

List what you'd remove or update, with a one-line reason for each. This
pass is about deleting, so the standing rule applies double: change
nothing until I've approved the list item by item.

An advanced tip while you're tidying: the inspector deserves inspection too. Claude Code has a built-in /doctor command that checks its own installation for problems — worth typing on checkup day, and any time the tool itself starts feeling off.

What belongs in the rules instead

Notice what's not on this page: the style checks, the tests, the scan of dependencies for known vulnerabilities. Those need no judgment — they run in seconds and answer yes or no — so they don't belong in a calendar, they belong in your rules file, running at every save (rule 2 in part three). A mechanical check parked in a monthly slot is eleven months of not looking. That's the whole sorting principle: if it just needs running, make it a rule; if it needs judgment, make it a pass. It's how Groundwork splits its own checks, and it keeps the monthly ritual short enough to actually happen.

Finally: the four passes above are examples, not the complete set. Once the rhythm feels normal, commission the same shape of pass on anything you care about — whether search engines and AI assistants can find and cite your site, whether the app works as well on a phone as on your laptop, whether the signup flow has friction, whether it's usable with a screen reader. Always the same pattern: fresh session, specific checklist, plain-language report, change nothing yet.

Acting on what they find

The reports arrive ranked, so the discipline is simple — one thing at a time, top down:

Take the top finding from the report and fix only that one. Before touching
anything, tell me what you'll change and what could break. When done, run
all the project's checks and confirm they pass.

Expect findings every time — that's the system working, not failing. The passes exist so problems get found by you, on a Tuesday you chose, instead of by an invoice, an outage, or a stranger on the internet.

One of those finders deserves its own article, because the stakes change the day real users arrive: production is not your laptop.