Skip to content

NAICS Startup Planning System

Planning system that turns broad startup ideas into structured, traceable business planning steps.

Delivery stage

R&D

Current state

Prototype

My role

Sole architect and full-stack engineer

NAICS planning engine diagram showing dataset, rules engine, plan generation, and exports.

Problem

Founders often start with broad ideas but no repeatable way to turn an industry choice into a realistic plan, staffing model, income assumptions, or startup sequence.

What was built

Built as an offline-first planning engine backed by the full NAICS hierarchy. The system combines rules-based role generation, income modeling, dependency-ordered startup procedures, and explainability views so users can inspect why each recommendation was produced.

Result

Working planning engine with rules-based role generation, income modeling, and explainability views across NAICS hierarchy

How the system was structured

This section shows the operational logic behind the build, not just the user-facing surface.

Key system pieces

Rules engine converts industry data into launch-plan structure.
Explainability layers make the output inspectable rather than magical.
Offline-first runtime keeps the system usable without external APIs.

Core constraint

Explainability: every generated recommendation must trace back to a rule, data source, or constraint, not a black-box model

Stack

Next.jsPrismaSQLiteZodRules EngineSnapshot Tests

Proof status

This page separates what is already visible from what is still being prepared, so the proof layer can grow without pretending unfinished artifacts already exist.

Proof surfaces

Real artifacts stay visible. Missing artifacts are labeled directly so this page stays honest and ready for stronger proof later.

System Walkthrough

Available now

The current walkthrough is grounded in how the rules engine turns category data into traceable planning output.

  • The planning flow shows how an industry choice becomes a generated operating plan.
  • Explainability views make each recommendation inspectable rather than magical.

Architecture / Flow

Available now

The planning engine diagram on this page shows how data, rules, and output generation are connected.

  • NAICS hierarchy feeds the planning engine.
  • Rules engine drives role generation, income modeling, and procedural ordering.
  • Explainability layer exposes why the system made each recommendation.

Operational Surfaces

Available now

The system has clear operator surfaces even though it is still at the prototype stage.

  • Planning outputs can be inspected and exported.
  • Rules trace gives users a way to verify recommendations.
  • Offline-first runtime removes dependence on external APIs for core behavior.

Artifacts & Evidence

Available now

Current evidence is centered on rules, diagrams, and generated outputs.

  • Planning engine diagram on this page.
  • Rules trace supporting explainability claims.
  • Generated plan artifacts available for later inclusion.

Related case studies

More work at a similar delivery stage.

Active Build

Proof surface in progress

Architecture / Flow

The current architecture direction is already clear even though the full artifact set is not published yet.

R&DActive BuildApplied AI & Automation Systems

WeatherForge

Weather-triggered signal and routing system in active development to turn storm activity into usable operational input for StormIQ.

My Role

Sole architect and engineer building the system foundation

Outcome

System boundaries are defined for signal ingestion, normalization, territory relevance, and downstream routing; implementation is in progress

PythonFastAPIGeospatial ProcessingEvent Routing
Read case study
Active Build

Proof surface in progress

Architecture / Flow

The architecture direction is already concrete: stateful orchestration, controlled branches, and explicit review seams.

R&DActive BuildApplied AI & Automation Systems

DGM

Workflow orchestration layer in active development for managing state, decision flow, and human review inside StormIQ.

My Role

Sole architect and engineer building the orchestration layer

Outcome

Execution model is defined for graph-driven workflow state, validation boundaries, and human review seams; implementation is in progress

PythonFastAPIWorkflow GraphsQueue-backed Jobs
Read case study
Back to all case studies