Thoughts
Things we have learned by building, inheriting, repairing, and maintaining software. Each piece makes one argument and stops when the argument is complete.
-
A control nobody has watched fail is not a control
Lessons from a signup-abuse incident on a platform we took over: the previous developer's abuse controls existed in code, passed review, and did nothing. What made them inert, how we fixed them, and the practices we kept.
-
Codebase takeover checklist: what to inspect before accepting a system
A reusable checklist for taking over software from another developer, agency, or team: access, production, data, change safety, dependencies, security, knowledge, and cost. Use it before you agree to own the system.
-
Production-readiness checklist for AI-generated applications
Thirty concrete checks that separate a working AI-generated (vibe-coded) prototype from production software: security, data, failure handling, operations, coherence, dependencies, and ownership.
-
What a good software handover should contain
The seven artifacts an outgoing developer or agency should hand over with a software system: access, environment map, operating manual, architecture notes, decision log, open issues, and a recorded walkthrough.
-
Software needs an owner
Software becomes expensive when nobody clearly owns it. Ownership is a role, not a repository permission, and most struggling systems are missing it.
-
Repair or rewrite?
A rewrite is a conclusion you reach after understanding a system, not a starting point. Most systems proposed for rewrite need an owner, a plan, and a few months of repair.
-
Taking over software after the developer leaves
A practical sequence for inheriting a system whose builder is gone: secure access, understand production, write down what nobody wrote, then change things.
-
AI-built software still needs an engineer
AI changes how code is produced. It does not remove technical responsibility. Software generated quickly still needs someone who understands it and answers for it in production.
-
Maintenance is product work
Most of a product's life happens after launch. Treating maintenance as a cost to minimize is how software quietly degrades and how the best improvements never get made.