Private product and company

Ludflow

Ludflow came from a recurring operational failure pattern: subject matter experts knew the problem, but the requirements handed to engineering were too vague to build from. The result was slow discovery, bad handoffs, and abandoned internal projects.

The product ties together business concepts, real system metadata, written process knowledge, and MCP-friendly AI context so teams can describe work in plain language without losing the technical truth underneath it.

For a founder or executive, this is the core signal: I do not treat AI product work as a model wrapper. I care about the workflow, the source of truth, the review surface, and the trust model that lets people rely on the output.

• Connects business language to source systems, docs, schemas, and code reality.
• Aims to make AI context auditable and useful across technical and non-technical teams.
• Shows commercial product thinking around a concrete operational pain point.

Open-source product and ecosystem wedge

MCPViews

MCPViews started from a simple frustration: AI tooling was becoming more capable, but the interface layer was still too dependent on plain text. Many real workflows wanted tables, diagrams, structured review, and richer interaction.

I built MCPViews as a local rendering layer where agents can request the right interface, push only the minimum state, and let renderers or plugins fetch the rest through their own APIs.

The product proof is not just technical taste. It shows how I think through a workflow, design an interface layer, and build a tool that makes AI-assisted work easier to understand and review.

Decision and workflow layer in the Ludflow ecosystem

DecidR MCP

DecidR MCP extends the same product thesis into planning and execution. It is built around the idea that AI-native teams need decisions, architecture context, approvals, and implementation work to stay connected as work moves asynchronously.

That matters because many AI workflows fail at the coordination layer, not the model layer. DecidR is my answer to that gap: keep the important decisions attached to the work so teams can move faster without losing accountability.

• Built for AI-native collaboration rather than ticket-only project management.
• Connects decisions, documentation, implementation context, and stakeholder review.

Data Engineer & Senior IT Security Solutions Architect | 2020 - Present

Current work at Ivy Energy

My role at Ivy sits at the intersection of data engineering, security architecture, and internal product delivery. I get pulled into work that spans departments, touches critical systems, and cannot be cleanly owned by a single narrow specialty.

That has meant maintaining compliance and security obligations, modernizing database and analytics infrastructure, building integrations across operational systems, and helping teams outside core engineering ship software that materially improves how they work.

What I actually own

Scope and responsibility

• Owned SOC 2 readiness and ongoing compliance through real controls across engineering, operations, access management, vendor review, evidence collection, and process ownership.
• Migrated core workloads off older systems and modernized the data layer so operational and product data could move cleanly into Snowflake, reporting models, automations, and downstream workflows.
• Built production integrations and sync workflows across Salesforce, Zendesk, Slack, ClickUp, Odoo, Snowflake, and other business-critical internal systems.
• Created secure internal apps and AI-assisted workflows for teams that needed working software quickly without creating avoidable product, data, permission, or deployment risk.
• Defined the practical trust model around internal tools: who can access the workflow, what data it touches, where review is required, how it is deployed, and who owns it after launch.
• Translated between technical and non-technical teams so operator pain could become deployable software instead of getting stuck as a vague request.

Founder and executive signal

Why this matters for AI product work

AI product work fails when it ignores the operating environment around the model: permissions, data quality, review loops, system boundaries, user adoption, and ongoing ownership. Ivy gave me years of practice with exactly those constraints.

That is why I am most interested in roles that combine product usefulness, secure architecture, data systems, and practical delivery rather than narrowing into a single specialty.

Using AI as a real software layer

AI workflow and product design

I do not think about AI as calling a model and hoping for the best. The interesting work is designing how prompts, context, retrieval, tool use, human review, and interfaces fit together into something reliable enough to matter.

That is why MCPViews, Ludflow, and DecidR all focus on grounded context, reviewable output, and workflow shape. The product question is always: what does the user need to trust this, and what system context does the AI need to be useful?

• MCP-native interfaces and tool ecosystems
• Prompt and context design tied to workflow quality
• Human-in-the-loop review patterns for higher-trust AI systems
• Clear judgment about when not to use an LLM

The systems underneath the product

Data and business-system integration

I am comfortable working where the real operational complexity lives: relational databases, warehouses, vector stores, reporting models, API integrations, and the vendor systems teams use every day.

That has included moving data from Postgres and internal systems into Snowflake, reshaping architecture to lower cost and improve maintainability, and building integrations across Salesforce, Zendesk, Slack, ClickUp, Odoo, and adjacent business tooling.

• SQL, warehouse modeling, and downstream reporting for business use
• Relational, document, cache, and vector database patterns
• API integrations and sync workflows across internal and vendor systems
• CRM, ERP, support, and product operations fluency

Speed with a trust model

Secure architecture and compliance

I do not treat security as something to paste on after the product exists. I naturally think about access, controls, auditability, data handling, deployment boundaries, and who owns the system after launch.

That background is especially useful for AI-enabled internal tooling because the fastest path is rarely the safest long-term path, and the safest path still has to let the business move.

• SOC 2 controls across departments for a maturing software company
• RBAC, code review, vulnerability scanning, and operational controls
• AWS, Kubernetes, load balancing, security groups, and deployment fundamentals
• Secure delivery patterns for internal tools touching sensitive data

Turning ambiguity into shipped software

Product delivery and communication

I am strongest when the workflow is messy, the requirements are incomplete, and the team needs someone who can talk to people closest to the pain, define a useful first version, and ship it.

That includes choosing the right stack for the job instead of forcing every problem into the same shape. I care about UI and UX because even strong internal software fails if people do not want to use it.

• Product shaping with founders, operators, and semi-technical stakeholders
• Web, backend, desktop, and mobile product thinking in the same delivery loop
• Fast first versions followed by architectural hardening
• Documentation and explanation that reduce ambiguity instead of adding more

Before it was a job

Builder temperament

I was always drawn to new technology, but I was never satisfied just being a consumer. I wanted to know how the thing worked, how to fix it, and how to make it better or make it mine.

That curiosity still shapes how I approach product work. I like getting close enough to the real system to understand the constraints, then building something that makes the next round of work easier.

Communication style

How I work with people

A lot of my work depends on listening carefully to people who are close to the problem but are not traditional software builders. I like helping them articulate what is broken, tightening the logic, and turning the result into something technical teams can build from.

That is one reason founder and early-stage environments make sense for me. I enjoy broad ownership, clear writing, and staying close enough to the details that strategy still turns into shipped systems.

The chapter I am in now

Family and home life

Family life matters a lot to me, and it has added a different kind of perspective to ambition, work, and how I think about the future.

Julie being a YA fantasy author means our home has a fun mix of technology, storytelling, product ideas, and creative work happening under the same roof. It is a good reminder that building things can take a lot of forms.