How I Build

I work research-first so that what I build is grounded in real, up-to-date data from reputable professional and expert sources. That is what lets me build compliant, professional, enterprise-grade solutions instead of guessing.

The mistake that taught me the most was starting to build from an idea without doing research first, without even finding out whether it was worth starting. One search prevents ten wasted sessions.

Before I adopted this discipline I was burning too many tokens because I was building without a proper plan and structure. That caused too many iteration cycles that an effective plan would have prevented.

A structured implementation workflow guides the AI and serves as a guardrail for it. No code starts until the requirements and the user flows are written down, reviewed, and approved. This very page had a PRD and an app flow document before a single line of it was written.

Security is a constraint on every line, not a final checklist. It is a professional best practice and I treat it as a requirement for everything I build, so that what I ship is robust, safe, secure, compliant, and useful.

Security is not an afterthought. It is built into each step. Secret scanning and static analysis run on every pull request before anything merges. Every page ships security headers. The database enforces row level security. API keys never reach the frontend; every AI call goes through a serverless proxy that hides the key and forces the model.

This site is zero-dependency vanilla JavaScript because that is what its nature deserves: a light app that serves information about an IT professional's work and expertise, with a few complementary features. Nothing to break, nothing to audit, no supply chain to worry about.

TaskPilot is Next.js and TypeScript because it is more demanding. It is not an app that serves information; it is a SaaS that generates scripts and n8n workflows for sysadmins and IT professionals to automate their tasks. For simple, less demanding apps, zero-dependency vanilla JS is more suitable. For complex, more demanding apps, Next.js and TypeScript.

I learned this the hard way. I did not have a good experience building and deploying with Replit and Firebase; they are a much steeper learning curve compared to Vercel with Supabase. Replit is fine for MVP frontends but gets complicated for backend configuration and deployment. Firebase has many hurdles that Supabase simply does not.

A real session starts with me sharing what I am thinking. I ask Claude to advise and make a plan. I review the plan and approve it. Then Claude does the implementation. I review the output critically and give feedback, and Claude applies it. We iterate multiple times to fix bugs, improve functionality, and do security hardening.

Claude does the heavy lifting on research, implementation, security scans, and proposing fixes and refinements. We co-plan. I approve and review.

AI makes mistakes. I treat its output as a draft and keep iterating to catch the issues and fix them together. The same AI is also very good at finding issues, researching solutions, proposing remediation, and implementing it. The back-and-forth is the method.

Working this way, we have caught and fixed real production bugs, hardened security, refactored the codebase, and kept improving through many pull requests. It is useful, motivating, and it genuinely augments my productivity.

The back-and-forth with AI has turned into skills, memories, routines, and triggers that automate the way I work. I get automatic email notifications and alerts on critical matters: weekly security monitors, dependency audits, and a scheduled workflow that audits Phoenix's own system prompt against the site content and files an issue when they drift.

Working with many agents this way has been genuinely useful and productive. The point is not to remove the human review; it is to make sure the review happens even when I am not looking.