People ask me how I "find time" to post a Reel every day while running two studios, doing client work, and building products. The honest answer: I don't find time. I engineered the system so it barely takes any.

Every Reel I post follows the same 4-part formula. Not because I'm lazy — because constraints are the whole game.

## The Formula: Death Statement, Pain, Speed, CTA

Every script I write starts with what I call a **Death Statement**. Something that stops the scroll. Not clickbait — a genuine, uncomfortable truth about the viewer's situation. Something they've been avoiding.

Then comes Pain Agitation. You don't just name the problem — you make them feel it. The gap between where they are and where they want to be. The wasted hours, the money left on the table, the competitor who's already doing it.

Speed Solution is where you deliver. Not a 47-step framework. One clear, actionable idea they can use today. The faster the perceived path to value, the more they trust you.

**And finally: the Authority CTA.** Not "follow for more." A keyword CTA that triggers a ManyChat automation — they comment a word, they get a resource, and now they're in your funnel. Every Reel is a micro-conversion machine.

> A Reel isn't content. It's a 30-second sales page with a beat drop.

## Why Daily Is Non-Negotiable

I don't treat Reels as optional. It's not the "frog I eat first" — it's the baseline. Like brushing your teeth. You don't skip it because you had a hard day.

**The compounding effect is real.** Day 1 feels pointless. Day 30, you've got a library. Day 90, people start reaching out because they "keep seeing you everywhere." That's not luck — that's volume plus consistency plus a system that doesn't depend on inspiration.

## The AI Layer

Here's the part most people miss: I use AI workflows to handle the repetitive parts. Hook generation, caption variants, hashtag research, thumbnail concepts — all of it feeds through my pipeline so I can focus on the actual 60 seconds of content.

I'm not creating from scratch every day. I'm executing a system every day. There's a massive difference.

## Start Before You're Ready

If you're waiting until your lighting is perfect, your editing is polished, or your "brand is defined" — you're procrastinating with extra steps. Post the ugly one. Post it today. Refine tomorrow. The algorithm rewards consistency over perfection, and so does your audience.

The formula works. The daily habit works. The only thing that doesn't work is waiting.

The non-negotiable daily habit and the 4-part script structure behind every one.

I Post a Reel Every Single Day. Here's the Formula.

Most designers I know start with a Figma file. Open a frame, pick some colors, start pushing rectangles around. And look — that works. Until it doesn't.

I start with a PRD. Not a fluffy "product brief" or a Notion page with three bullet points. A real, numbered, MoSCoW-prioritized requirements document with TypeScript interfaces, ASCII wireframes, error states, and acceptance criteria checklists. 130+ requirements is my baseline, not my ceiling.

## The Problem With Designing First

When you jump into Figma before defining what the product actually needs to do, you're making architecture decisions with your visual cortex. You're choosing layouts before you know what data flows through them. You're picking animations before you know what states exist.

**The result? Beautiful screens that fall apart the moment a developer asks "what happens when the API returns an error?"**

Every redesign, every "wait, we didn't think about this," every sprint that goes sideways — most of them trace back to a missing requirement, not a missing mockup.

## What a Real PRD Looks Like

My PRDs follow a specific format: every requirement gets a unique ID, a MoSCoW priority (Must / Should / Could / Won't), and clear acceptance criteria. I include ASCII wireframes — not because they're pretty, but because they force you to think about information hierarchy without getting seduced by visual polish.

I define TypeScript interfaces before I design a single component. If I know the shape of the data, I know the shape of the UI. Everything else is styling.

> A PRD isn't a bureaucratic artifact. It's a decision log. Every line is a choice you made before the pressure hit.

## The Build Order That Follows

Once the PRD is locked, everything cascades: Types and state first. Then the layout shell. Then Must-Have features, working from inputs to processors to outputs. Integration. Polish. Error hardening. QA against the acceptance criteria you already wrote.

**No guessing. No "I think the client wanted..." conversations. No redesigns.**

## Why This Matters for You

If you're hiring a designer or building a product, ask one question: *"Show me your PRD."* If they don't have one, they're improvising. Sometimes improvisation works. But when you're shipping something real — with users, with money on the line, with a deadline — you want the person who did the thinking before they opened the design tool.

That's what I do. The PRD is the product. Everything after it is execution.

Thinking in Public

I Post a Reel Every Single Day. Here's the Formula.

Why I Write 130-Requirement PRDs Before Touching Figma