Personal Methodology

Beyond Following the Process

You have spent four levels learning a process: research, synthesize, ideate, prototype, validate, ship. You have learned to use AI agents, stage prompts, manage quality, and orchestrate a crew. These are powerful tools. But they are not yours yet.

A personal methodology is what happens when you take everything you have learned and reshape it to fit the way you think. Not every step will matter equally to you. Some you will expand. Some you will skip. Some you will combine. Some you will invent from scratch.

This is not laziness or shortcuts. This is mastery. A beginner follows the recipe. A cook improvises. A chef creates their own recipes. You are moving from cook to chef.

A methodology is not a set of rules you follow. It is a set of principles you have internalized. You do not consult the checklist anymore — you feel when something is missing.

What Is a Methodology?

A methodology is your codified approach to turning ideas into reality. It answers: How do I start a project? How do I make decisions when I am stuck? How do I know when something is good enough? How do I recover when things go wrong?

Everyone has an implicit methodology. You already have habits, preferences, and instincts about how to work. The difference is whether those habits are examined. An unexamined methodology is full of accidental patterns — things you do because you have always done them, not because they serve you.

An examined methodology is intentional. You know what you do, why you do it, and when to deviate. You can explain it to someone else. You can teach it. You can improve it.

Finding Your Patterns

Start by looking at what you already do. Think about your last three projects. What did you do first? Where did you get stuck? What did you skip that you should not have? What did you spend time on that did not matter?

Look for patterns across projects. Maybe you always start by building something before you plan. Maybe you always over-research and under-build. Maybe you skip testing and regret it. Maybe you are great at starting and terrible at finishing.

These patterns are not flaws — they are data. Your methodology should work with your tendencies, not against them. If you always want to build first, make that the first step — but add a short planning check before you start. If you over-research, set a time limit. Work with your nature, not against it.

The Components of a Methodology

Every methodology needs these elements:

Starting rituals. What do you do at the beginning of a project? Open a document and write the problem statement? Sketch on paper? Talk it through with an AI agent? Have a consistent beginning so you never waste time figuring out how to start.

Decision frameworks. When you are stuck between two options, how do you choose? Feasibility vs. impact? Fastest vs. best? Simplest vs. most flexible? Having a default framework means you spend less time deliberating and more time doing.

Quality standards. What does "good enough" mean to you? For some people, pixel-perfect CSS is non-negotiable. For others, functional correctness matters more than visual polish. Know your standards so you know when to stop.

Recovery patterns. What do you do when things go wrong? When the code is a mess, the deadline is close, and nothing works? Some people rewrite from scratch. Others debug methodically. Others step away and come back fresh. Know your pattern.

Finishing rituals. How do you close a project? Deploy and move on? Write a retrospective? Clean up the code? Share what you built? A consistent ending prevents projects from lingering unfinished.

Documenting Your Methodology

Write it down. Not as a rigid procedure manual — as a living reference that captures your current best thinking about how you work.

Keep it short. One page. A list of principles, not a rulebook. "Start every project with a one-paragraph problem statement." "Prototype before planning in detail." "Commit after every working change." "Review my own code after stepping away."

Put it somewhere you will see it. The top of your CLAUDE.md. A sticky note on your monitor. The first page of your project notebook. A methodology that lives in a drawer is not a methodology — it is a historical document.

Revise it quarterly. Your methodology should evolve as you evolve. What worked six months ago might not work now. What seemed unnecessary might now feel essential. The methodology is alive.

Methodology and AI

AI agents amplify your methodology. If your methodology is strong, agents execute it faster and more consistently than you could alone. If your methodology is weak, agents amplify the weaknesses.

Encode your methodology into your CLAUDE.md files. "Always start by reading the existing code before modifying it." "Write a commit message that explains why, not what." "Ask me before adding dependencies." These are not just rules for the agent — they are your methodology, externalized.

The agent becomes a practitioner of your methodology. It follows your principles even when you are not watching. Over time, you develop a feedback loop: the agent reveals where your methodology is unclear (because it makes surprising choices), and you refine the instructions. The methodology gets sharper through use.

Evolving Through Practice

A methodology is not designed in a workshop. It is discovered through practice. You try something. It works or it does not. You adjust. Over time, the adjustments accumulate into a coherent approach.

The danger is ossification — clinging to a methodology that no longer serves you because it is familiar. The tools change. The problems change. You change. A methodology that was perfect for building static sites might be wrong for building complex applications. A methodology developed before AI agents will need revision after them.

Schedule time to question your own methodology. What would I change if I started from scratch? What am I doing out of habit? What have I learned recently that should change how I work? The willingness to question your own process is what keeps a methodology alive.