TREP — Entrepreneurial Ideas Operating Manual

Low-Ego, High-Signal, Exit-Oriented Exploration

These are not startups.
They are problems worth solving with clean engineering and clear exits.

I do not intend to: - Run a company - Be a CEO - Build a lifestyle brand - Grind indefinitely

I do intend to: - Identify real problems - Design elegant solutions - Protect IP - De-risk ideas early - Hand off execution to the right operator - Exit cleanly

This system exists to keep me focused, honest, and efficient.

Getting Started (Choose Your Path)

For non-technical readers

If you just want to read and apply the framework:

• Read the core flow in PROCESS.md
• Use the 15-minute filter in IDEA_INTAKE.md
• Follow the quickstart in NEW_IDEA.md
• See a filled example in ideas/example-idea/

For technical users

If you want a local, reproducible setup:

• Fork the repo so you can pull upstream updates
• Consider making your fork private if you want to keep ideas confidential
• Clone your fork and browse files directly
• Use the templates in ideas/_template/
• Build offline formats: make pdf, make epub, make html

Index

• PROCESS.md - The full idea lifecycle, phases, and kill criteria
• IDEA_INTAKE.md - 15-minute gate to filter ideas early
• NEW_IDEA.md - Quickstart for creating a new idea folder
• 01_ENERGY_BUDGET.md - Weekly constraints and burnout guardrails
• 00_PIPELINE.md - Single-glance state of all ideas
• ideas/_template/ - Canonical templates for idea files and artifacts

1. Core Constraints (Non-Negotiable)

Every TREP idea must satisfy all of the following:

• ❌ No overlap with my day job (contractually or ethically)
• ❌ No requirement that I operate the company
• ✅ Clear, simple revenue model
• ✅ Obvious buyer or acquisition class
• ✅ Low competitive density or weak incumbents
• ✅ IP-defensible (patentable or protectable know-how)
• ✅ Solvable with hard / soft engineering (my strength)

If an idea violates one of these, it is parked or killed.

2. Directory Structure (Shallow, Intentional)

TREP/
├─ 00_PIPELINE.md
├─ 01_ENERGY_BUDGET.md
├─ CHANGELOG.md
├─ CODE_OF_CONDUCT.md
├─ CONTRIBUTING.md
├─ GOVERNANCE.md
├─ IDEA_INTAKE.md
├─ LICENSE
├─ NEW_IDEA.md
├─ PROCESS.md
├─ README.md
├─ WEEKLY_REVIEW.md
├─ ideas/
│  ├─ _template/
│  │  ├─ README.md
│  │  ├─ NOTES.md
│  │  ├─ PROBLEM.md
│  │  ├─ SOLUTION.md
│  │  ├─ MARKET.md
│  │  ├─ RISKS.md
│  │  ├─ IP.md
│  │  └─ artifacts/
│  │     ├─ ELEVATOR.template.md
│  │     ├─ IDEA_README.template.md
│  │     ├─ ONE_PAGER.template.md
│  │     ├─ PITCH_DECK.template.md
│  │     └─ RULES.md
│  └─ idea-<short-name>/
│     ├─ README.md
│     ├─ NOTES.md
│     ├─ PROBLEM.md
│     ├─ SOLUTION.md
│     ├─ MARKET.md
│     ├─ RISKS.md
│     ├─ IP.md
│     └─ artifacts/
│        ├─ elevator.md
│        ├─ one-pager.md
│        └─ pitch-deck.md

Rules: - No idea lives directly in /TREP - Every idea gets its own folder - Artifacts are generated, not improvised

3. New Idea Quickstart (Folder Setup)

1. Create a folder: ideas/idea-<short-name>/
2. Copy everything from ideas/_template/ into it
3. Fill out the idea README.md (state + summary)
4. Run the 15-minute gate in IDEA_INTAKE.md
5. Proceed to NOTES.md only if it passes

4. Exit-Focused (What That Means Here)

This framework assumes I am not the long-term operator. Every idea must have a plausible acquirer, a clear revenue path, and a defendable wedge (IP or speed). If that is not true, the idea is parked or killed early.

5. Template Rule

The files in ideas/_template/ are the only allowed starting point. Artifacts in an idea folder must be generated from those templates, not invented from scratch.

6. Idea Lifecycle (Lightweight but Real)

Ideas move through states, not vibes.

States

• SEED — interesting, unvalidated
• SHAPING — problem & solution are clear
• SCREENING — market, IP, and exit sanity check
• INVESTOR-READY — pitchable in 1–2 meetings
• PARKED — not dead, not now
• KILLED — documented and done

State is recorded in the idea’s README.md.

7. The Idea README (Single Source of Truth)

Every idea has a README.md.
If it’s not here, it doesn’t exist.

# <Idea Name>

**State:** SHAPING  
**Owner:** Ryan  
**Last Updated:** YYYY-MM-DD  

## One-Sentence Summary
<Plain English. No jargon. If this is hard, stop.>

## Why This Exists
- What problem is real?
- Who feels it acutely?
- Why it hasn’t been solved cleanly yet

## What I’m Optimizing For
- Fast validation
- IP clarity
- Obvious acquirer interest
- Minimal personal operational burden

## What I’m Explicitly Not Doing
- Running ops
- Fundraising marathons
- Consumer brand building

## Current Questions
- ?
- ?

---

## 8. Open Source Notes

- See `LICENSE` for usage terms
- See `CONTRIBUTING.md` for how to propose improvements
- See `CODE_OF_CONDUCT.md` for community standards
- `ideas/example-idea/` is fictional and for reference only

---

## 9. Docs and Releases

- Docs landing page: `docs/index.md`
- Release checklist: `RELEASE.md`
- Local builds: `make pdf`, `make epub`, `make html`

# TREP Process
## Getting Ideas Out of My Head and Onto Paper (Without Lying to Myself)

> This process exists to **externalize thinking**, not to force progress.
>  
> Speed is not the goal.  
> Clarity is.

---

## Guiding Principles

- Ideas decay when left in my head
- Writing reveals weak thinking quickly
- Early structure prevents late rework
- Killing ideas early is a success, not a failure
- This process protects **time, energy, and integrity**

---
## Phase 0 — Mental Quarantine

**Goal:**  
Create distance between the idea and my identity.

**Rule:**  
An idea is not “mine” until it survives writing.

**Actions:**
- Create a folder:  
  `ideas/idea-<short-name>/`
- Copy templates from:  
  `ideas/_template/`
- Do **not** pitch it to anyone yet
- Do **not** name it cleverly
- Do **not** research competitors yet

**Output:**  
Empty folder + blank files

---
## Phase 1 — Brain Dump (Unfiltered)

**Goal:**  
Get the idea out of my head *without organizing it*.

**File:**  
`NOTES.md`

**Prompt:**
- What keeps bothering me about this?
- Where have I seen this problem in the wild?
- Who complains about this (explicitly or implicitly)?
- What would a “dumb but effective” solution look like?
- Why does this feel solvable by *me*?

**Rules:**
- Bullet points only
- No editing
- No structure
- No judgment

**Timebox:**  
20–30 minutes max

**Stop when:**  
My head feels quieter.

---

## Phase 2 — Problem Crystallization

**Goal:**  
Decide whether the *problem* is real before designing anything.

**File:**  
`PROBLEM.md`

**Questions to answer (plain English):**
- Who has this problem?
- How often does it occur?
- What happens if it’s not solved?
- Who pays the cost?
- How is this handled today?

**Hard Check:**
If I cannot explain the problem in **5 sentences**, stop.

**Outcome:**
- Clear problem → continue
- Vague, aesthetic, or hypothetical → park or kill

---

## Phase 3 — Solution Sketch (Resist Over-Engineering)

**Goal:**  
Describe the solution without building it.

**File:**  
`SOLUTION.md`

**Questions:**
- What does the solution *do*?
- What does it explicitly *not* do?
- What is the key technical insight?
- What makes this difficult for others?

**Rules:**
- No diagrams yet
- No implementation details
- No tech stack decisions

**Hard Check:**
If the solution sounds like:
- a platform
- an ecosystem
- an AI-powered anything

Rewrite it.

---

## Phase 4 — Reality Screen

**Goal:**  
Stress the idea against reality *before* falling in love with it.

**Files:**
- `MARKET.md`
- `RISKS.md`

### MARKET.md
Answer honestly:
- Who buys this?
- Who uses it?
- Why would they buy it *now*?
- How many such buyers plausibly exist?
- How do they currently justify spend?

### RISKS.md
List only real risks:
- Adoption friction
- Regulatory exposure
- Technical uncertainty
- IP weakness
- Substitution risk

**Rule:**  
If risks feel uncomfortable, good — keep going.

---

## Phase 5 — IP First Pass

**Goal:**  
Decide if this is an **IP play** or a **speed play**.

**File:**  
`IP.md`

**Questions:**
- What might be patentable?
- What is clearly not?
- What existing products or companies feel adjacent?
- Is this worth a provisional patent discussion?

**Hard Check:**
If there is no defensibility story, the exit must be obvious.

---

## Phase 6 — Compression

**Goal:**  
Reduce everything to investor-readable artifacts.

**Files (in order):**
1. `artifacts/elevator.md` (from `ELEVATOR.template.md`)
2. `artifacts/one-pager.md` (from `ONE_PAGER.template.md`)
3. `artifacts/pitch-deck.md` (from `PITCH_DECK.template.md`)

**Rule:**
- Each artifact must feel *simpler* than the last
- If clarity decreases, stop and go back

---

## Phase 7 — State Decision

**Goal:**  
Decide what happens next — deliberately.

**File:**  
`README.md`

Set:
```markdown
**State:** SEED | SHAPING | SCREENING | INVESTOR-READY | PARKED | KILLED

Questions: • Is this worth more of my time? • Does this align with my constraints? • Is the next step clear and small?

If no: Park or kill it. Document why.

⸻

Kill Criteria (Use Early, Use Often)

Kill the idea if: • The problem is aesthetic, not operational • The buyer is vague or hypothetical • IP is weak and speed advantage is unclear • It requires me to operate a company • It only works if everything goes right

Killing early is a win.

⸻

Final Reminder

The goal is not to “advance ideas.”

The goal is to discover which ideas deserve existence outside my head.

This process exists to help me tell the difference.

Idea Intake

15-Minute Gate Before Any Real Work

This checklist exists to prevent me from confusing interest with merit.

If an idea can’t pass this in 15 minutes, it does not deserve further attention — yet.

Step 1 — Name It (2 minutes)

• Working name (boring, descriptive):
  • <idea-short-name>
• Date captured:
  • YYYY-MM-DD

Rule:
No clever branding. No metaphors.

Step 2 — One-Sentence Test (3 minutes)

Fill this in without editing:

“This idea addresses experienced by ,
by , resulting in .”

If this feels vague or fluffy, stop.

Step 3 — Constraint Check (5 minutes)

Answer yes / no only.

• ⬜ No overlap with my day job
• ⬜ Does not require me to be CEO/operator
• ⬜ Clear path to revenue
• ⬜ Obvious acquirer category
• ⬜ Potential IP defensibility
• ⬜ Solvable with hard/soft engineering
• ⬜ Feels like a real problem, not a vibe

If any are “no” → park the idea.

Step 4 — Energy Signal (3 minutes)

Answer honestly:

• Does this energize me calmly? ⬜
• Or does it make me restless / fantasize? ⬜

Only calm energy is allowed.

Step 5 — Decision (2 minutes)

Choose one:

• ⬜ Proceed to Phase 1 (Brain Dump)
• ⬜ Park (interesting, not now)
• ⬜ Kill (document why)

If parked or killed, write one sentence explaining why.

Final Rule

If this takes longer than 15 minutes, I am already violating the process.

New Idea Quickstart

Use this when an idea passes the 15-minute gate.

1) Create the folder

ideas/idea-<short-name>/

2) Copy templates

Copy everything from:

ideas/_template/

3) Fill the idea README first

Update:

• README.md (state + one-sentence summary + next step)

If the README is not clear, stop and fix it before doing anything else.

4) Proceed in order

Follow the process in PROCESS.md.

If any phase fails, park or kill the idea and document why.

TREP Energy Budget

I treat TREP like a finite resource, not a hustle.

Weekly Allocation

• Max: 3–5 focused hours
• Zero guilt weeks are allowed

Hard Rules

• No TREP work when exhausted
• No TREP work at the expense of health or family
• No more than 2 active ideas at once

Signs I’m Over-Investing

• Polishing instead of validating
• Writing decks before clarity
• Fantasizing about scale
• Avoiding hard kill decisions

If any appear → pause.

Weekly TREP Review

30-Minute Ritual (Once Per Week, Max)

This review exists to prevent slow drift, sunk-cost fallacy, and idea hoarding.

No skipping. No expanding. No guilt.

Step 1 — Open the Pipeline (5 minutes)

Open: - 00_PIPELINE.md

Scan: - SHAPING - SCREENING - INVESTOR-READY

Ask: - Do these still deserve attention?

Step 2 — Reality Check Each Active Idea (10 minutes)

For each idea not parked or killed, answer:

• What actually changed this week?
• What did I learn that reduced uncertainty?
• What question is still blocking progress?
• Is the next step clear and small?

If nothing changed → flag it.

Step 3 — Energy Audit (5 minutes)

Answer honestly:

• Did I over-invest emotionally?
• Did I polish instead of validate?
• Did I avoid a hard decision?
• Did TREP bleed into rest, family, or health?

If yes to any → reduce scope immediately.

Step 4 — Make Hard Moves (5 minutes)

For each idea, choose one: - ⬜ Advance - ⬜ Pause - ⬜ Park - ⬜ Kill

Update: - Idea README.md - 00_PIPELINE.md

Document why.

Step 5 — Reset Intentions (5 minutes)

Write one sentence:

“Next week, the only TREP work I intend to do is:
<specific, bounded action>”

Nothing else is allowed.

Hard Rules

• Max 2 active ideas at once
• No new ideas during review
• No adding scope during review
• If an idea survives 4 reviews with no movement → park or kill it

Closing Reminder

TREP is not a second job.

It is a disciplined filter for good ideas, not a place to accumulate them.

End review. Close vault. Move on.

Changelog

v0.1.0

• Initial public release of the TREP framework
• Core process, intake gate, pipeline, and templates

Contributing

Thanks for helping improve TREP.

What to Contribute

• Clarity improvements
• Better prompts and questions
• Process refinements

What Not to Contribute

• Generic startup advice
• Hustle or grind mindsets
• Anything that assumes I am the long-term operator

How to Propose a Change

1. Open an issue describing the change
2. Explain the why, not just the what
3. If accepted, submit a PR

Versioning and Commits

This project uses Semantic Versioning with tags like vMAJOR.MINOR.PATCH.

Please use Conventional Commits for changes:

• feat: ... for new capabilities
• fix: ... for bug fixes or corrections
• docs: ... for documentation changes

Governance

TREP is opinionated and maintained by a single owner.

Decision Model

• The maintainer makes final calls
• Community suggestions are welcome via issues and PRs

Scope

• Process and templates only
• No business advice beyond the TREP framework

Contributor Covenant Code of Conduct

Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards

Examples of behavior that contributes to a positive environment for our community include:

• Demonstrating empathy and kindness toward other people
• Being respectful of differing opinions, viewpoints, and experiences
• Giving and gracefully accepting constructive feedback
• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
• Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

• The use of sexualized language or imagery, and sexual attention or advances of any kind
• Trolling, insulting or derogatory comments, and personal or political attacks
• Public or private harassment
• Publishing others’ private information, such as a physical or email address, without their explicit permission
• Other conduct which could reasonably be considered inappropriate in a professional setting

Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at:

INSERT_CONTACT_METHOD

All complaints will be reviewed and investigated promptly and fairly.

Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html

Community Impact Guidelines were inspired by Mozilla’s code of conduct enforcement ladder.