All work
PrototypeSynthetic data

AI-Assisted Build / Project note

MountFlow

A working shop-operations prototype connecting customer intake, multi-specimen work orders, deposits, production status, notes, history, and search.

Stage
Functional validation prototype · Synthetic data
Primary users
Taxidermists / Outfitters / Studio administrators

Evidence first

What is proven, what I changed, and what remains open.

A 90-second evidence map for hiring review. Synthetic product views explain mechanics; they never count as outcome proof.

Verified now
A functional multi-route browser prototype with deterministic demo data across intake, specimen-level work, status, deposits, notes, history, search, and dashboard visibility.
Next evidence gate
Operator discovery and usability evidence before backend, authentication, communications, or AI assistance investment.
01

User / workflow evidence

Supported synthesis

The prototype models specialist studios that coordinate complex physical jobs through paper, spreadsheets, messages, and memory; direct operator interviews remain the next validation step.

02

Product decision

Verified record

I made each specimen the atomic operational record inside a customer work order and deliberately validated the deterministic workflow before adding AI.

03

AI / system boundary

Verified record

Current behavior is deterministic. Reminders, note summaries, search assistance, and communication drafts remain future hypotheses until the operator record and workflow earn validation.

04

Evaluation → change

Supported synthesis

The working prototype provides a concrete discovery surface for testing intake, multi-specimen state, deposits, history, and exception visibility; no operator test result is claimed yet.

05

Outcome / boundary

Verified record

The browser prototype exists. Production deployment, customers, backend, authentication, and active AI capability are not claimed.

AI product decision record

The choices behind the product, architecture, and release gate.

Prove the operational data model before adding intelligence; a trustworthy record is the prerequisite for useful AI.

01

AI fit

Verified record

Do not use AI in the current core; validate intake, specimen state, deposits, history, and exception visibility first.

The highest-risk assumption is whether the studio's work is modeled correctly, not whether notes can be summarized.

Alternative consideredLeading with an assistant would hide a weak operational record behind fluent copy.

02

Knowledge & context

Verified record

Use structured customer, work-order, specimen, payment, and history records rather than RAG.

The workflow depends on exact current state, dependencies, and timestamps.

Alternative consideredSemantic retrieval may help later with notes and search, but cannot replace transactional truth.

03

System architecture

Supported synthesis

Keep a conventional vertical application with clear entities and routes; integrate only after operator workflow validation.

Simple architecture makes discovery findings easier to translate into the product model.

Alternative consideredMCP, agents, and cross-system automation are premature before customers, backend, and integration jobs exist.

04

Evaluation & release

Supported synthesis

Test operator task completion, state errors, exception visibility, and whether the atomic specimen model matches real work.

The prototype exists to uncover workflow and information-architecture failures before scaling.

Alternative consideredFeature count or an AI demo would not validate the operating model.

Evidence I still need from the private project record3 open items
  1. 01

    Operator interview and task-observation findings.

  2. 02

    Usability completion and error evidence for intake and status changes.

  3. 03

    Which workflow changed after operator feedback.

Verified = direct approved recordSupported = defensible synthesisReported = source receipt pendingDesigned = future test or control

The product bet

Vertical workflow software for taxidermy and outfitting operations

A working vertical-software prototype that proves disciplined product scoping before adding AI.

Specialist studios often manage complex physical work through paper, spreadsheets, messages, and memory, increasing errors and obscuring status.

Primary user
A specialist studio operator managing complex physical jobs across customers and multiple specimens.
Trigger
A customer arrives with one or more specimens requiring intake, deposits, production steps, communication, and delivery.
Inputs
Customer details, specimen records, services, measurements, deposits, notes, dependencies, and status history.
Product action
Create one customer work order with specimen-level records, track state and money, preserve history, and expose operational exceptions.
Output
A searchable work record, production queue, deposit status, timestamped history, and delivery checklist.
Decision enabled
What work is ready, blocked, overdue, awaiting payment, or ready for customer communication.

Public-safe product demonstration

A complete workflow, without protected data.

The names, records, amounts, dates, scores, and thresholds inside this surface are fictional. The product logic is the point.

MountFlowCraft production ledger
Simulated product scenario
Public-safe reconstruction

A fictional preservation studio receives a shoulder-mount request and needs one traceable record from intake to delivery.

Primary user
Studio coordinator
Decision enabled
Keep customer expectations, specimen custody, craft work, and delivery aligned.
01 / Intake

Create one trusted record at the handoff.

Customer preferences, condition notes, custody acknowledgement, and reference photos enter the same job record.

Synthetic work orderNorth Ridge / shoulder mount
Pose
Left turn
Finish
Natural habitat
Custody
Studio
Condition documentedAwaiting approval
  1. Intake
  2. Work order
  3. Production
  4. Delivery
Intake note

Reference photos and condition notes stay with the item.

Accountable ownerStudio coordinator
Decision at this stageAccept the item and confirm the requested outcome.
Illustrative acceptance benchmarkNo job advances without customer approval and intake condition notes.

Customers, specimens, dates, and production records are synthetic. This is a public-safe workflow demonstration.

AI operating model

Separate assistance, control, and accountability.

01

Product controls

Work-order structure, specimen identity, statuses, deposits, dependencies, history, and required fields.

02

AI assists

Future reminder, note summarization, search assistance, and customer-communication drafts after workflow validation.

03

Human owns

Craft decisions, production sequencing, price, customer promise, exception handling, and final delivery.

Product decision and trade-off

AI features are attractive, but the real product risk is whether the shop's operational record is modeled correctly.

Product choice
Make each specimen the atomic record inside a customer work order and validate the deterministic workflow first.
Rejected alternative
Leading with an AI assistant before intake, status, deposits, and history are trustworthy.
Product consequence
The prototype becomes a credible discovery surface and future AI has a durable operating context.
Representative failure mode

A status update at the customer level hides that one specimen is blocked while another is ready.

Designed control

Specimen-level state, dependency and deposit checks, timestamped events, and a customer-level roll-up.

Illustrative acceptance benchmark

every job state can be traced to one specimen, one owner, one timestamp, and one next action before delivery.

Founder-builder product craft

The leadership pattern in its appropriate form.

This case is not retroactively enlarged into a Director mandate. It shows which product-lead behaviors were already present at this scope.

Product craft

Translated an unfamiliar vertical workflow into a concrete multi-route prototype.

Leadership seed

Used coding agents as a delivery team while retaining scope, information architecture, and acceptance responsibility.

What it foreshadowed

Director-ready judgment appears in sequencing: validate the operating model, then invest in intelligence and scale.

My role

Product founder and AI-assisted builder defining the workflow, information architecture, page system, and product direction.

Evidence boundary

Impressive because the boundary is clear.

Actual project evidence

A functional multi-route browser prototype exists with deterministic demo data, intake, statuses, deposits, notes, history, search, and dashboard visibility.

  • Built a functional multi-route validation prototype with deterministic demo data.
  • Connected intake, status changes, deposits, notes, timestamped history, search, and dashboard visibility.
  • Created a concrete test surface for operator discovery without implying production deployment.
Simulated for comprehension

Customers, specimens, prices, dates, and the walkthrough record are fictional.

Not claimed

No production deployment, customer adoption, backend, authentication, or active AI capability is claimed.

What I shaped

  • Made each specimen the atomic operational record inside a larger customer work order.
  • Directed coding agents to build and verify the browser prototype.
  • Deferred backend, authentication, and AI features until the core operator workflow earns validation.

Next validation gate

  1. 01

    Conduct operator interviews

  2. 02

    Test intake usability

  3. 03

    Explore reminders and communication assistance

Return to the collectionBuilds and ventures