How I Build
“I do not need to be the strongest person in every discipline. I need to recognize the strongest available thinking, know where my own contribution adds leverage, and build a system in which good judgment becomes repeatable.”
Building 0→1 products requires more than writing code or prompting LLMs. It requires locating the actual point of failure, structuring ambiguous data, and challenging the system until it holds up under real operational pressure.
The 6-Stage Execution Lifecycle
From unformatted inputs to durable operational handoffs. Every project moves through these six disciplines to prevent premature abstraction and silent failure.
Accepting messy operational reality and mapping hard boundaries before prescribing software.
Auditing root failure modes rather than surface complaints. Interviewing edge operators to locate the actual point of breakdown before writing a line of code.
- Upstream input matrices
- Shadow workflow audit
- Boundary & constraint map
Signal (unformatted POS/labor CSVs); Maps With Teeth (traumatic multi-actor handoffs); Lone Wolf (48 municipal territories).
Cross-referencing disparate records to surface meaningful signal, anomalies, and missing context.
Determining what missing record would overturn the current hypothesis. Testing assumptions across edge cases and timeline gaps rather than accepting initial summaries.
- Multi-source correlation ledger
- Anomaly & variance register
- Entity link graph
Message Analysis (native UWP OCR + PyMuPDF regex indexing across 10,000+ records); Signal (labor velocity vs. transactional volume variance).
Translating ambiguous problems into strict schemas, domain boundaries, and decoupled data layers.
Enforcing domain ownership over import convenience. Building decoupled data stores so non-technical operators can manage business parameters without touching code.
- Canonical data schema
- Domain boundary specification
- State transition machine
Maps With Teeth (5 governed domain registries in canon); Lone Wolf (site-data.js decoupled data layer).
Rapidly executing functional software using agentic tools as operational multipliers.
Using agentic development environments to execute the full product lifecycle (scaffolding, testing, responsive design, documentation) while personally establishing invariants and prompt constraints.
- Working production software
- Local-first processing pipelines
- Automated regression tests
Maps With Teeth (26-route Next.js production build); GenSort (in-browser canvas perceptual hashing & JSZip packaging).
Enforcing deterministic calculation, adversarial testing, and human escalation gates for consequential decisions.
Cross-evaluating reasoning models to detect ambiguities. Pressure-testing systems against extreme data spikes, degraded networks, and adversarial inputs.
- Deterministic validation rules
- Cross-model divergence tests
- Human escalation interface
Document Integrity (deterministic parity checks & contradiction preservation); Signal (bifurcated severity vs. confidence model).
Delivering high-leverage outputs, knowing when to stop, and documenting runbooks so systems operate autonomously.
Measuring marginal utility against maintenance overhead. Rejecting architectural gold-plating and authoring concise operational runbooks.
- Prioritized action cards
- Single-source-of-truth runbooks
- Owner-operable admin tooling
Signal (Observation → Mechanism → Evidence → Remediation cards); Context & Muse (packaged client offers, scoped delivery, and operational handoffs).
Agentic Development as Leverage
I use agentic development environments to expand how much of the product lifecycle I can personally execute—from repository analysis and schema design through full-stack implementation, refactoring, and QA.
“The agent is an execution multiplier, not the product owner. I define the objective, constraints, schema invariants, and what is permitted to ship.”
Repository Evidence of Agentic Leverage:
Google Antigravity · Claude · ChatGPT · Gemini · Git/GitHub · Next.js · React · TypeScript · Node.js · Vercel · Python (uv)
AI is an instrument, not an authority.
Outputs are challenged, audited, and returned to the problem rather than accepted because they sound confident.
Ask models to challenge the premise, not only complete the task
Before asking an AI to implement a requested solution, I instruct it to analyze the underlying requirements for hidden assumptions, missing dependencies, and edge-case failure modes.
Compare outputs when model strengths differ
Complex problems move across specialized model architectures. Dedicated reasoning models handle structural logic and constraint verification; extraction and synthesis engines cross-check evidence. Disagreements between models are treated as signals of underlying ambiguity.
Preserve uncertainty rather than forcing false consensus
When source data is incomplete or contradictory, AI must highlight the ambiguity for human review rather than smoothing over discrepancies to generate a plausible-sounding fiction.
Audit against the intended outcome, not output fluency
Polished prose and confident tone are cheap. Defensible reasoning, mathematical parity, and architectural compliance are what actually matter in production.
Separate polished language from defensible reasoning
We never accept an AI output simply because it sounds authoritative. Every assertion must map directly to verified inputs, mathematical calculations, or referenced source records.
Use human review for consequential judgments
In legal forensics, medical protocols, financial decisions, and operational crises, AI proposes and highlights; authorized human operators decide and verify.
Investigate unexpected structurally useful ideas
When an AI surfaces an unexpected angle or unconventional structural framing, investigate it rigorously rather than dismissing it solely because it came from an unexpected direction.
Never let AI confidence substitute for source integrity
If the primary source lacks evidence, the system must report a gap—not invent a bridge.
“Prompt engineer,” “AI whisperer,” “creative technologist,” or “AI visionary.”
The clearest identity is: builder + operator + systems thinker who can move from problem discovery through implementation.