Architecting Developer Tools That Ship
I am a product manager who ships code. Rather than writing a spec and handing it to engineering, I can carry a feature through the entire lifecycle myself, which removes the translation loss between what a customer needs and what actually ships. It lets me make grounded engineering tradeoffs in the PRD, prototype the hard part before the organization commits to it, and stand behind the code in production.
I run that loop with AI inside it: agentic tooling to prototype, implement, and validate faster than the same work would move by hand. Alongside the shipping, I design agentic orchestration systems and author the internal tooling that lets an entire organization query its data, follow its taxonomy, write consistent product docs, and prototype without friction. This page is the how; the AI-native products it ships, and the outcomes they create, live on the AI & Product page.
The loop I own
These nine stages normally pass through separate hands: sales and delivery, product, design, engineering, QA, and marketing. I can work at any point on this line and step in directly, including into the code, wherever that adds value beyond the usual remit of a senior AI product lead and is the efficient move alongside the work I run in parallel. Closing a handoff myself removes the point where scope and intent usually leak.
Tooling I Built for My Organization
Beyond my own work, I build at the nexus of three AI use cases: building with AI internally to run a faster product process, building with AI to deliver features, and building for AI so it can engage our data as efficiently as a person can. That last piece starts at the data layer: I authored collections of our database (schema, nested arrays, and embedded objects) deliberately structured so both people and our organization's MCP tools can find and query it cleanly.
The harnesses layered on top compress the time spent on research and external validation when weighing a new approach, surface market trends to ground what reasonable success KPIs should be, and let non-technical colleagues engage with the data directly without needing to understand the taxonomic structure underneath it. I author these systems, then teach the organization how to use them.
Database Built for Humans and AI
- — Authored database collections (schema, nested arrays, and embedded objects) designed from the ground up to be cleanly and efficiently queryable
- — Structured so our organization's MCP tools can discover and traverse the data as effectively as a human analyst: one data model, both use cases
Data Access Without the Taxonomy Tax
- — Harnesses that let non-technical colleagues query our product databases in natural language, without needing to understand the underlying taxonomic structure
- — Encoded conventions for our entity model and taxonomy so every query and analysis stays consistent with how the platform is actually structured
Strategy Baked Into the Doc
- — A PRD-authoring harness whose value is the thinking, not the template: it guardrails research, dogfoods our own data, research, insights, and event feeds to inform product direction, and bakes strategic-alignment pillars into every doc
- — Draws on Perplexity through a source-ranking index to pull reliably-estimated market sizing and benchmarks, giving each proposed concept external validity before the organization commits to building it
Frictionless Prototyping
- — A prototype-kit runner that scaffolds on-brand, design-system-aligned apps from named layout presets in minutes
- — Wired to live simulation backends so prototypes exercise real model behavior, not static mocks
Product Analytics
- — Guidance that makes pulling and interpreting product usage data (funnels, retention, adoption) self-serve across the organization
- — Rate-limit-aware patterns so analytics queries stay reliable under real workloads
Judgment, Encoded
- — Distilled the decision heuristics I reason with (probabilistic over point-estimate thinking, inversion, provenance tracking, taxonomy-first decomposition, and a standard of evidence over intuition) into the layer these systems reason on, so the organization's analysis inherits a deliberate method rather than defaulting to whoever happens to be in the room
- — Codifying years of hard-won judgment into rules that hold up under scrutiny is the difficult part; the payoff is a raised floor, where research, brainstorming, and product decisions across the organization now run through the same rigorous lens and get de-risked before they ever reach a roadmap
Source-Ranking Methodology
- — Created the source-ranking methodology that scores evidence on reliability, bias, and depth, which the organization adopted to govern research and data-gathering across products
- — Used internally to de-risk and unbias our outlooks: every claim carries reliable data and clear provenance, rather than resting on whichever source surfaced first
Agentic Development Lifecycle
- — A self-authored agentic SDLC: problem framing and brainstorming to a spec, to a bite-sized implementation plan, to subagent-driven execution with two-stage review, to evidence-based verification before any completion claim
- — A browser-driven UAT and validation engine that tests shipped work against acceptance criteria deterministically, with a human review gate before results are recorded
- — A structured, multi-phase research-investigation methodology that discovers, scores, extracts, and normalizes web sources into cited datasets and dossiers, with autonomous gap-filling iteration
Replatforming the Data Model: Taxonomy v3
While at Liminal, I led the largest single project in the history of the organization, an in-place migration that replaced the platform's entire capability taxonomy across four coordinated threads
The Problem
The platform's capability taxonomy had degraded to the point that salespeople would not put it in front of customers. The model was structurally broken: its tiers were circular (categories at different levels had collapsed into one another), generic (the same capability was attached to unrelated use cases), and drifting (years of free-text names and stale tags had eroded any consistency). Patching the surfaces on top of that data was pointless. The data model itself had to be rebuilt, and every part of the platform that read it had to be migrated.
Thread 1: Foundations and Data Migration
A new multi-tier taxonomy model that cleanly separates the demand side (what customers are trying to accomplish) from the supply side (the solutions and capabilities that meet those needs), rebuilt from the ground up as new database collections.
- — Designed new database collections: schemas, indexes, embedded tag arrays, and migration-lineage keys (a legacy id plus a full snapshot) on every document, so nothing lost its provenance
- — Built an idempotent BigQuery and Airtable to MongoDB ETL that resolves an AI-generated product-to-capability dataset (8,000+ documents) against the analyst taxonomy: dry-run mode, source-of-truth schema validation before any bulk write, per-run reports (unresolved names, splits and merges, confidence scores), and cross-environment count reconciliation
- — Tested schema assumptions against reality and corrected them: a capability-to-solution relationship assumed to be 1:N proved N:N mid-build, forcing a full re-import rather than a workaround
- — Stood up a parallel API namespace that mirrored the legacy request and response contracts, so each consumer could migrate independently without breaking its callers
Thread 2: Backoffice Tooling
- — Rebuilt every internal analyst CRUD surface onto the new model, then rebuilt taxonomy management itself from scratch on the design system: flyout navigation, a shared rule-builder table shell with URL-persisted state, and a multi-step authoring wizard
- — Shipped a server-computed Coverage Matrix with a deliberate data-model call: capability importance is scoped to the use case, not stored flat on the capability, because the same capability matters differently in different use cases
Thread 3: Customer-Facing Migrations
- — Migrated every customer surface reading taxonomy data via a reusable dual-read pattern: parallel fetch hooks behind a flag, with React Query configured so exactly one request fires regardless of flag state, and new types declared with field names identical to the legacy ones so downstream components needed zero changes
- — Eight independent frontend flags gated modules separately; the flagship net-new surface was a data-driven Sankey-style flow diagram mapping customer needs through to the capabilities that satisfy them, a deliberate step up from the accordion the spec called for
Thread 4: Cutover Safety and Discipline
- — Built a poison-pill canary: every in-scope collection was duplicated with its text fields asterisk-prefixed, so any surface still reading the old data lit up visually during cutover and residual dependencies surfaced as an obvious QA signal rather than a silent production leak
- — Cut over consumer by consumer behind a living feature-flag matrix: default-off, per-surface enablement, and rollback by flag with migrated data treated as additive, so no cutover ever required a data restore
- — Held scope discipline: when an architecture decision landed to keep an existing data model rather than build a parallel one, a batch of already-planned work was closed out with zero code written, because it had been gated on that decision landing first
- — Hardened the release across three QA and UAT waves before it reached customers
Impact
Replaced the platform's entire capability taxonomy in place, on a live product, shipped as a flagship platform release, on a rollout where any single surface could roll back independently. It is the clearest proof I can point to that I can own a platform-critical uplift, from data model and ETL through backoffice tooling and every customer surface, all the way to a shipped release.
Open Source Projects
mongodb-mcp-server
github.com/dp-veritas/mongodb-mcp-server
Secure MCP server enabling LLMs to query and analyze MongoDB databases. Safe for production use with comprehensive analytics and relationship discovery.
Key Capabilities
- — 24 Tools: Database discovery, document querying, aggregation pipelines, schema analysis
- — Relationship Discovery: Optimized relationship matrix (10-100x faster queries), graph traversal
- — AutoJoin Feature: Automatic $lookup generation for aggregation pipelines
- — Production-Safe: No write operations, schema modifications, or database changes
Tools
mcp-obsidian-tools
github.com/dp-veritas/mcp-obsidian-tools
MCP server exposing rich tools for querying Obsidian knowledge vaults. Read-only, path-validated security. Compatible with Cursor, VSCode, and Claude Desktop.
Tools
ollama-mcp-agent
github.com/dp-veritas/ollama-mcp-agent
Universal local AI agent connecting Ollama to any MCP server. Query vaults, emissions databases, MongoDB, or any data source through natural language. Supports 7B-30B+ parameter models locally, or 120B-671B+ cloud models. 100% offline capable, 100% sovereign.
Key Capabilities
- — Multi-Domain Queries: Connect multiple MCP servers simultaneously (Obsidian + NZDPU + MongoDB)
- — Intelligent Routing: Automatically selects the right data source based on query domain
- — Privacy-First: Air-gapped capable, no cloud dependencies, all data stays local
- — Model Flexibility: Supports 7B-30B+ parameter models locally, or optional 120B-671B+ cloud models
Use Cases
Join emissions data with research notes, query proprietary databases without cloud exposure, multi-domain analysis workflows