There is a specific kind of electricity that comes with being able to build as fast as you can think. Recently, I have been using Cursor, and it has completely reignited my passion for tinkering. After years of directing large-scale product teams, I have found myself back in the driver’s seat, shipping ideas that used to sit dormant in my notebooks.
The most important lesson I have learned in this process is that AI is an insanely powerful partner, but only if your planning is impeccable. If you give an AI tool a vague request, you get a vague result. However, if you provide it with a rigorous framework of information, it can execute with the precision of a senior engineer. This is how I developed my “markdown stack” – a dedicated folder of .md files that define the soul of a project before a single line of code is committed.
My markdown stack
My approach is built on the belief that framing and context are everything. I use a specific set of files to capture what spills out of my head, ensuring the AI is equipped to make something truly good.
-
PRD.md: This is the heart of the project. It provides a comprehensive explanation of what we are building and why. It is initially written by me, for me, but it serves as the ultimate reference point for the AI to ensure we never lose sight of the core purpose.
-
JOURNEYS.md: I map out the “happy path” step-by-step. This is where my UX background comes to the fore; by defining the user journey clearly, I ensure the AI builds features that are intuitive and goal-oriented.
-
STACK.md: This is where we decide on the tools. It is a collaborative process; I often let the AI propose a stack, then I use my experience to poke holes in the logic and tighten the requirements until we have a solid technical foundation.
-
DESIGN.md: Consistency is key for a professional product. This file acts as a written style guide—defining typography, spacing, and colours—so the AI can maintain a high visual standard across the entire codebase.
-
ARCHITECTURE.md: Once the journeys and stack are defined, I work with the AI to map out the system architecture. This ensures the project is built with the same rigour I would expect from an enterprise-grade live broadcast tool.
-
README.md: I treat this as the definitive guide for human consumption. I let the AI keep this updated, explaining the how, what, and why of the project as it evolves.
-
ROADMAP.md: To avoid the trap of building too much too soon, I use a simple list to capture future ideas. It allows the AI to see where we might go next without distracting it from the current build.
Planning as the ultimate technical skill
What excites me most about this way of working is that it validates the things I’ve learned and the ways I work. My ability to code is no longer the bottleneck; my ability to plan, structure information and define constraints is now my greatest technical asset.
When you have your planning together, the “doing” becomes a shared experience between you and the machine. This markdown stack is more than just documentation… it is a way of thinking that allows me to build cool shit at a velocity I never thought possible.
This post marks the start of a series where I will provide a tutorial for each file in the stack (no posts about the files after this means I gave up on the idea). If you are a product person who misses the joy of building, it is time to start planning. The tools are ready for you.
