Mobile View

This content is fully accessible on mobile, but the desktop version still carries the full windowed experience.

Ogden, Utah

Daenon Janis

Daenon Janis in a flight simulator setup

Executive Summary

Forward-Deployed AI Product Engineer

I build trusted AI workflow software across product, data, integrations, and security. I work best where founders and operators need someone to find the real problem, shape the product surface, wire the systems, and mentor non-technical teams into practical AI use.

SecurityI've built SOC 2 compliant organizations and software from startup bootstrap through series A
Zero to OneAI and internal tools shipped for operator workflows
Real SolutionsProduct proofs: Ludflow, MCPViews, DecidR

AI Product Proofs

AI Products & Founder Work

Three product proofs show the through-line: AI becomes useful when it is connected to real context, systems, review, and decisions.

Ludflow, MCPViews, and DecidR MCP are the clearest signals that I can find the wedge, design the workflow, build the product surface, and keep trust visible as the system becomes real.

LudflowCommercial product thesis for grounded AI context
MCPViewsOpen-source interface layer for agent workflows
DecidRDecision and workflow layer for AI-native execution

Commercial product thesis

Ludflow

Ludflow is a platform for AI documentation, data governance, and grounded MCP context and provides the document storage to decisions and projects in the DecidR MCP platform.

AI documentationData governanceGrounded contextKnowledge systems

Public technical proof

MCPViews

MCPViews is an open-source desktop companion for agent interfaces, plugin-aware review flows, and richer work surfaces than plain chat while improving token efficiency and providing portable workflows and instructions with token optimized bread crumb rule discovery.

Open sourceAgent UIReview workflowsRenderer system

Workflow and decision layer

DecidR MCP

DecidR MCP is a project management and governance tool for use with AI enabled teams. Built to work and integrate with any AI tools that support MCP, users can work with AI while asynchronously collaborating with their team members. It proves how I think about keeping context, implementation, and stakeholder buy-in connected so AI-assisted execution does not drift away from accountability.

AI-native teamsDecision workflowsExecution contextApproval systems

Product signal

The pattern these products prove

Across the three products, the theme is not a model wrapper. The work is about giving AI reliable context, explicit review surfaces, and enough product structure that people can trust the result.

That is the kind of role I am aiming at: founder-level product ownership where discovery, interface design, integration plumbing, and trust decisions stay connected.

  • Ludflow connects business knowledge to docs, schemas, code, and AI context.
  • MCPViews turns agent output into reviewable interfaces instead of only chat text.
  • DecidR MCP keeps decisions, approvals, implementation context, and execution in the same loop.

Consulting & Mentoring

Technical Guidance for Non-Technical Teams

I help founders, operators, and domain experts turn early product ideas into buildable, reviewable, reasonably secure software without pretending everyone on the team needs to become an engineer.

The through-line across BitBooks and No Food Cravings is practical translation: requirements, prototypes, issue reporting, release discipline, documentation, and security choices made legible to teams with limited technical experience.

MVP coachingHelped non-technical product owners shape safe first versions
Release disciplineCoached dev to staging to production workflows with safeguards
Team fluencyMade requirements, bugs, risks, and tradeoffs understandable

Founder coaching

No Food Cravings

Provided technical guidance and product coaching for a non-technical product manager building an MVP around a health and behavior-change idea. The work focused on making the first version realistic, secure enough for early learning, and understandable to the person responsible for the product.

  • Translated the idea into an MVP scope with clearer product boundaries and implementation priorities.
  • Coached practical security, account, data, and deployment choices so early experiments did not create avoidable risk.
  • Helped the product owner evaluate AI-assisted development output, review tradeoffs, and keep momentum without losing control of the product.
MVP scopingFounder coachingSecurity basicsAI-assisted build review

Team enablement

BitBooks

Provided product and technical delivery structure for a team of accountants, Bitcoin-focused stakeholders, and non-technical contributors. The role was to make the work concrete enough that the team could define requirements, inspect prototypes, report issues, and move changes through environments with confidence.

  • Created structure for requirements definition, prototype review, mockup feedback, and issue reporting.
  • Coached the team through dev, staging, and production release expectations with documentation and checkpoints.
  • Helped establish safeguards for identifying bugs, regressions, and vulnerabilities despite limited engineering depth on the team.
Requirements shapingPrototype reviewBug reportingRelease safeguards

Operating style

How I mentor teams into technical work

A lot of useful software starts with people who understand the domain better than they understand the implementation path. My role in these projects was to make that path visible: what should be built first, what needs review, what can wait, and where security or deployment risk should slow the team down.

I treat mentoring as part of delivery. Requirements, mockups, bug reports, deployment notes, and vulnerability checks are not overhead; they are the shared language that lets non-technical teams participate in building safer software.

  • Turn vague ideas into product slices the team can reason about.
  • Give non-technical stakeholders enough technical literacy to make better tradeoff decisions.
  • Use documentation and release checkpoints to keep MVP speed from turning into invisible risk.

OPERATING PROOF & CURRENT EMPLOYMENT

Ivy Energy

I am currently employed at Ivy Energy handling: security, data, integrations, internal tools, and AI adoption work carried through real production constraints.

My role requires wearing multiple hats, working with stakeholders across the organization, discovering operational needs and designing solutions tailored to those needs. This includes being involved in multiple teams daily standups, training & onboarding internal users on the uses of new tools. As the sole employee at the company responsible for cyber security I have to balance the line between speed and convenience of operations, and security.

SOC 2Security program built from scratch and maintained
Data layerCore workloads and reporting modernized for downstream use
AI toolsOperational teams coached through secure AI adoption

Operator enablement

AI mentoring and adoption

I have helped non-technical operational teammates use AI in practical ways without treating it as magic. That means teaching where AI is useful, where review is required, what data should not be pasted into tools, and how to turn one-off prompts into repeatable workflows.

  • Coached safe prompting, output review, and sensitive-data handling.
  • Helped operators turn recurring work into reusable AI-assisted workflows.
  • Kept adoption tied to real business systems, not isolated demos.
AI trainingWorkflow designSafe adoption

Impact

Operating outcomes

The strongest outcomes map directly to trusted AI product work:

  • Built and maintained Ivy Energy's SOC 2 program from a blank slate, including controls, evidence, access review, and process ownership.
  • Modernized data movement into Snowflake and downstream workflows so operational data could be used reliably.
  • Integrated Salesforce, Zendesk, Slack, ClickUp, Odoo, Snowflake, and adjacent systems.
  • Coached non-technical operators on secure AI use, output review, sensitive-data handling, and repeatable workflows.

Ivy Energy | 2019 - Present

Work Experience

I started with Ivy Energy in 2019 as a contractor doing web development work, then grew with the company as its needs changed. The role expanded from building useful web surfaces into IT ownership, Salesforce administration, data engineering, AI enablement, and the organizations cybersecurity program.

That path is the best shorthand for how I work: I find the real operational need, take responsibility for the messy middle, and keep learning the systems required to make the work durable.

  • Started as a web development contractor before moving into broader internal systems work.
  • Took on IT and Salesforce administration as the company scaled and needed stronger operational infrastructure.
  • Adopted data engineering, AI enablement, and cybersecurity responsibilities as the trust and workflow surface grew.

AI product layer

AI workflow and product design

I design AI workflows as products: prompts, context, tools, review, and interfaces built around a real job. The goal is not novelty; it is a workflow a person can understand, inspect, and keep using.

MCPAgent interfacesHuman reviewGrounded contextPrompt systems

Operational layer

Data and business-system integration

I work under the product surface where data movement, APIs, warehouses, CRMs, and ERPs decide whether the workflow actually works. This is where many AI tools either become real software or stay a demo.

SQLSnowflakedbtSalesforceZendeskOdooAPIsELT

Trust layer

Secure architecture and compliance

I think about permissions, controls, auditability, deployment risk, and maintainability while the product is still being shaped. That background matters most when AI touches sensitive workflows or production systems.

SOC 2RBACSecure deliveryAuditabilityDeployment risk

Builder layer

Product delivery and operator enablement

I turn vague operator pain into a useful first version, then teach the workflow well enough that a non-technical team can keep using it. I care about the handoff because adoption is part of the product.

TypeScriptReactNext.jsRequirements shapingOperator trainingDocumentation

About Me

Builder Temperament

I like understanding how things work, taking them apart, rebuilding them, and turning curiosity into something useful.

That instinct started with hardware and repair work before it became a career in software, security, data, and product systems.

Family photo of Daenon Janis, Julie Janis, and their child outdoors

Early instincts

Builder temperament

I grew up building computers, repairing phones, chasing new gadgets, and wanting to understand the systems underneath the surface.

Hardware rootsSystems thinkingPractical ownership

Ogden, Utah

Home life

I live in Ogden with my wife Julie, a YA fantasy author, and our son Orion. We also have one more child on the way.

Family lifeCreative homeGrounded ambition

Immersive systems

Flight simulation and VR/AR

I am interested in flight simulation, VR, and AR because they sit at the edge of software, hardware, spatial interfaces, and embodied learning. They are a fun version of the same thing I like professionally: making complex systems understandable enough to operate.

Flight simulationVR / ARInterface design

Outside projects

Lake time and efoil tinkering

I like lake days, efoils, and the practical maintenance side that comes with owning gear that touches water, batteries, firmware, and real-world conditions.

EfoilLake activitiesHands-on repair

House systems

Home lab automation

I enjoy home lab automation because it lets me experiment with infrastructure, monitoring, controls, and reliability in a personal environment where the feedback loop is immediate.

Home labAutomationMonitoring

Power projects

DIY solar and backup power

I have a strong interest in DIY solar and 120/240v backup systems: practical electrical architecture, resilience, safe wiring patterns, and building systems that keep working when all else fails.

DIY solar120/240v backupResilience

Start A Conversation

Contact

For AI product roles, internal platform work, founder-led special projects, or Ludflow/MCP-native conversations, email is the best place to start.

The best-fit conversations start with messy operational problems that need to become secure, usable software.

Primary route

Email

Reach out for AI product roles, internal platform work, founder-led special projects, consulting, or conversations around Ludflow and MCP-native tools.