Topic
Security
Security treated as part of the plan, not a review that happens once and gets forgotten. These pieces cover where an access rule should live so a new feature cannot forget it, what a continuous security pass catches that a quarterly one does not, and what to check before trusting code — AI-written or otherwise — with real data.
-
Sep 5, 2026 Start here For AI-coders
The informed way to code with AI inside a company
You may have been at this for a week or a year. Either way, code you ship with AI inside a company is judged on five things, and none of them is speed. Here is how to answer all five.
-
Sep 5, 2026 Note For AI-coders
Why I put the authorization rule in the database, not the app
Multi-tenant ticketing with row-level security, and why "you can only see your own company's tickets" belongs below the application code.
-
Sep 5, 2026 Note For companies
Seven questions to ask anyone selling you AI
The vendor has a demo. You need answers. Seven questions that separate an AI feature from an AI liability, and what a good answer sounds like.
-
Sep 5, 2026 Note For both
A security pass that runs whether or not anyone remembers
Scheduled scans, nightly dependency matching, findings as tickets, fixes as reviewed pull requests. The shape of a security practice for a small team that ships with AI.
-
Sep 5, 2026 Note For companies
The app is the visible part
Companies that build or buy an AI feature usually stop at the feature. Three invisible parts decide whether it is an asset or a liability, and none of them is optional.
-
Sep 5, 2026 Note For companies
The employee who can now build apps
Someone in your company who is not an engineer has built something the business now relies on. It is an opportunity and the biggest new risk in most small firms. What to require before you rely on it.
-
Sep 5, 2026 Note For both
Where the rule lives
"You can only see your own company's tickets" is one sentence. Where a team chooses to enforce it decides whether the next feature can forget it. A story about moving a rule below the code, told for people who will never write a database policy.
-
Sep 5, 2026 Playbook For companies
An AI policy in one page
A template for the rules part of an AI plan, written to be followed rather than filed. Fill in the named tools and the named person and it is done.
-
Sep 5, 2026 Playbook For AI-coders
A continuous security pass for small teams
Scheduled static scanning, database advisor sweeps, a bill of materials matched nightly against vulnerability data, findings routed into tickets with a draft fix. What it catches, what it does not, and the order to build it in.
-
Sep 5, 2026 Playbook For both
The infrastructure around the app
A homework checklist for anyone building an application a business will rely on, and for the leader deciding whether to let them. The app is the easy part; this is everything else.
-
Sep 5, 2026 Playbook For AI-coders
Reviewing code you did not write
The review pass I run on everything an AI coding tool produces: what to read first, the mistakes that show up most, tests as the contract, and how to keep context so the next session does not repeat the last.
-
Sep 5, 2026 Build For both
A client portal where every client sees only their own work
A ticketing system with a client portal and tenant isolation enforced in the database itself.
-
Sep 5, 2026 Build For both
A continuous security pass across a dozen live applications
Scheduled scans and sweeps that turn findings into tickets and fixes into reviewed pull requests.