I’ve never tried any of them.

Who wants to take an ice-cold shower first thing in the morning? Who wants to wake up at 4 or 5 if they don’t have to? But the articles got me thinking about what my morning actually looks like.

I don’t get up with an alarm. Usually 6:15 or 6:30. I work my way into the day. Personal hygiene. First cup of coffee. Brain puzzles — Wordle, the crossword, a few others. Second cup of coffee. Some casual reading — sometimes a Substack, sometimes a newsletter, sometimes a book, depending on the mood. Then the gym.

No email. No client problems. No digging into the day’s productivity.

That part is on purpose. If my day starts chaotic, my whole day is whittled away.

So I protect the quiet before the noise gets in.

✳︎ ✳︎ ✳︎

A method to my madness

That same instinct is what made me notice something was off with the rest of my week.

I’ve been building a lot lately. Daily process. Weekly process. Decisions database. AI is the collaborator on most of it — I lean on Claude the way I’d lean on a smart co-worker who has all my context. The systems are supposed to do for the rest of the day what the morning routine does for the start of it: keep the noise out, surface what matters, let me make the call.

But every single thing I’d built lately had a friction point.

Not one of them. Every one.

Projects were starting and never finishing — sitting on a shelf, not abandoned, just stuck. The kind of stuck where you keep meaning to go back to it and don’t.

My first read was the easy one: I’ve outgrown this.

That was wrong.

But I didn’t know it was wrong yet. What I had was two different systems sending the same kind of static, and the only way I could think to start was to type the static into a chat window and see what came back.

Going outside Claude

My first instinct was to burn one of them down. The experiments database had already been shelved. I hadn’t touched it in weeks. I was ready to add the rest to the pile.

I didn’t.

Instead, I went outside my normal partner. Claude has all my context, which is great most days and a problem on this one. Sometimes you need someone without the history. So I opened ChatGPT, pasted in the instructions I’d written for each of my Claude workflows — the actual prompts that drive what Claude does when I run my daily process or my weekly process — and then pasted in documentation of how my brain operates.

Not personality. Mechanics. The way I produce lists badly and evaluate lists fast. The way storage works fine but retrieval breaks. The way I think differently when I’m given options to react to versus a blank page to fill.

ChatGPT told me the instructions were fighting my flow.

Not the instructions themselves. The instructions, for the way my brain works.

That was the moment the processes changed. And ChatGPT was the partner I worked through the refactors with — the workflow instructions and brain documentation already in the context, different shape of input, different shape of output.

✳︎ ✳︎ ✳︎

The prompts that gave me the diagnosis

Each refactor started with a sentence I typed into ChatGPT. Not a question — a noticing. The kind of sentence you write when you can feel something is off but haven’t decided what to do about it yet.

Daily process.

I started with a simple ask. A question on what I’d noticed, without being specific:

The signal: running the daily rhythm felt like pulling teeth.

The daily was supposed to look at where work actually lives — calendar, client logs, project list, decisions — pull from all of them, and funnel the surfacing into one place where I could make a call. Instead, it was inventing tasks. Asking me what I wanted to do today and then double-checking I had the time and energy to do it.

What’s the point of running this if I’m going to do all the work anyway?

That’s the moment a system stops being collaborative and starts being theater.

The core tension underneath: the system was becoming work instead of supporting the work.

Weekly process.

With the daily process sorted, it was time to tackle the next:

The signal: I was trying to step up a level — from weekly to monthly to quarterly — and the review wasn’t a place to think. It was a place where decisions had already been made.

The weekly was supposed to look at what may actually move the needle, name the growth items, and break them into bite-size chunks for the week ahead. What it was doing was producing a tidy summary that closed loops without leaving room to see anything. By the time I read it, the thinking was over.

The core tension underneath: the review was deciding for me instead of helping me reflect.

A status report, not decision support.

✳︎ ✳︎ ✳︎

Two different leaks. And underneath, the same misread.

Outgrown is not the same as never fit

I’d assumed friction in a system meant I’d outgrown it. The system used to fit, and now it didn’t, so the system had to go.

What was actually happening: I’d never fit any of those systems to me in the first place. I’d built them off what other people were doing, off templates that work for other people’s brains, off whatever the latest article or video or thread suggested. Some of it I was conscious of. Most of it I wasn’t.

The friction wasn’t because I’d outgrown it. It was because I’d never adjusted it to how I think.

The thing is, I’d been watching this same pattern play out somewhere else.

When you feed a model junk context, it gives you junk output. The model isn’t broken. The retrieval isn’t broken. The shape of what you fed it is the problem. The whole conversation drifts because the input was the wrong shape from the start.

I was doing that to myself.

My experiments database was structured like a software change log — every decision, every step, every iteration, every detail. Useful if you’re publishing it. Terrible if you’re trying to reorient yourself a week later. Too much information, too much noise, too much minutia. Junk context.

The system was working exactly as designed. The design was the problem.

The shape of someone else’s template

Stay with me on this part for a minute.

I didn’t sit down one morning and decide to build my daily process on someone else’s template. Nobody does. The templates get absorbed the way background noise gets absorbed. A productivity article here. A YouTube workflow there. A thread that walks through how somebody runs their week. You’re not copying any of it. You’re just exposed to it. Then you sit down to build your own version, and the shape that comes out of you is already half-shaped by what you’ve seen.

The daily was supposed to be mine. But the idea of a daily — what one should do, what it should produce, what it should feel like to run — that came from somewhere else. Same with the weekly. Same with the experiments database. I’d built each of them in response to something I’d read or watched, and I’d done it without noticing the inheritance.

That’s the part I missed the first time.

Friction in a system you built yourself reads like I’ve outgrown this because you assume you knew what you were building. But you were never the only architect. The template was in the room with you. Some of what you built was yours. Some of it was the shape of how everyone else does it. And when the friction shows up, it’s almost always at the seam between the two.

The morning routine works because I built it from nothing. No one handed me a 6:15-coffee-puzzles-gym template. I watched what worked, kept what kept, dropped what didn’t. The reason it doesn’t have friction isn’t that I’m gifted at mornings. It’s that there was no inherited shape to fight.

The workflows had inherited shape everywhere. That’s why every one of them leaked.

Each system has a job to protect

Once I could see the inherited shape for what it was, the refactor got obvious. The morning routine protects quiet before noise gets in. The workflows weren’t protecting anything yet — they were just running.

So I asked the question differently for each one. What is this supposed to protect?

Daily — protects energy and capacity.

Look at the calendar. The client logs. The ticket system. The projects I’m working on in both businesses. And the decisions I’m tracking. Pull from all of those, funnel it into one place, and let me make the call on what’s actually getting done today. The run should help me decide, not hand me a list of made-up tasks. If it feels like one more chore in the day, I’ve built it backwards.

Weekly — protects the growth thread.

What actually moved this week? What were the growth items? What are the bite-size next steps for next week? The weekly is supposed to help me see what happened so I can decide what’s next. If it’s handing me the answers before I’ve had a chance to look, it’s the wrong tool for the job.

The refactors weren’t replacements. Neither one got burned down. I just rebuilt them to work the way I actually work.

✳︎ ✳︎ ✳︎

The surprise

Then the experiments database — the one I’d shelved, the one I was ready to burn — turned out to be the rescue.

I started looking at it through the same question: what is this supposed to protect?

And the answer wasn’t every detail of every experiment.

It was the decision I made, and the context I’d need to make a similar one next time.

It wasn’t an experiments database. It was a decisions database with the wrong sign on the door. What I actually needed was something I could come back to, get my bearings, pick up the context without having to remember every detail. And on top of that, something I could pull from when I’m sharing what worked or what didn’t — in an article, a video, or a conversation with someone trying to sort through the same thing.

Experiments → Decision Records.

The data I’d already captured wasn’t wrong. The frame around it was. That covered the records of what I’d already decided. The companion to it came from a different place.

Over the past few weeks, I’d been writing down the questions I kept asking myself when I got stuck — the ones I couldn’t quite shake. I had ten of them scattered across notebooks, Notion pages, and the back of receipts. How do I know what’s truly next? How do I know what work fits the energy I have today? How do I make decisions when my brain reacts faster than it retrieves? Those became the Decision Playground. A small Notion database where I can pull up the right question for the kind of decision I’m trying to make — what direction to head, what signals I’m noticing, what my capacity actually is, what I’m watching, what I’m reflecting on.

When I get stuck on what’s next, I have somewhere to start. When I open a conversation with AI for help thinking it through, I have the right context already shaped.

The system I was about to delete was the one I needed most.

I just hadn’t called it the right thing yet.

Replace, refactor, or refine

The hardest part wasn’t realizing something was off. It was figuring out what to do about it.

I had three options on the table for every system I touched. So do you, the next time something feels off.

Replace — burn it down, build something new in its place. This is the option I almost took. It’s also the option most people take, because friction feels like failure, and the response to failure is start over.

Refactor — keep the bones, rebuild the way it works underneath. The system was doing the right work, but the shape was wrong. You’re not throwing the work out. You’re asking the system to do its job differently.

Refine — small adjustments inside the existing design. Tighten a prompt. Move a field. Reword a question. The lens is right. The system just needs a tune.

Most of what I read online treats these as the same thing. They’re not. Picking the wrong one costs you weeks.

Here’s how I tell them apart now. You can use the same test.

Replace when the purpose is wrong. Not the structure, not the output — the underlying job the system was built to do. If you’ve outgrown the need the system was built for, replace. Note: this is actually rare. Most things you think you’ve outgrown, you haven’t.

Refactor when the purpose is right but the frame is wrong. The system was built for the right reason, but the way it’s structured is off. The experiments database belongs here — the purpose (capture what I’m doing) was right. The frame (changelog) was wrong. Renaming and restructuring revealed what was already there. No new work to invent.

Refine when the purpose and frame are right but the execution is rough. A prompt that produces almost-right output. A field that asks the wrong question. A step that’s in the wrong order. These are small. You’d know in a session whether the refine worked.

The trap is treating everything like a refine when it needs a refactor — because refine feels efficient and refactor feels expensive. Just one more tweak is the most expensive sentence in a stuck workflow. If you’ve made three refines in a row and the friction is still there, you don’t have an execution problem. You have a frame problem.

The reverse trap is treating everything like a replace because the friction makes you angry. Replace is the option that costs you the most work and is right the least often. If you’re reaching for it, slow down. Ask first if the purpose is genuinely wrong, or if you’re just frustrated with the shape.

The systems I refactored this week looked, at first, like they needed to be replaced. None of them did. Yours probably won’t either.

✳︎ ✳︎ ✳︎

What I’m watching for

The refactored systems are running now. The honest test isn’t whether they made sense on paper — it’s whether they hold under regular use, or whether new friction shows up that signals the next misfit. I’m not assuming this is solved.

Friction in a system is a signal worth paying attention to — not a verdict, but information.

✳︎ ✳︎ ✳︎

If you’re sitting on a shelf

If you have a system, a workflow, a tool, a habit, a planner, a recurring meeting — something you’ve quietly stopped using but haven’t replaced — that shelf is data. Whether it’s a Notion database or a paper notebook, the question is the same.

Try this. The same thing I did for the systems above.

1. Write the noticing as a sentence.

Not a fix. Not a question for AI yet. The shape of something is off and I haven’t decided what to do about it. Mine looked like “this feels like a chore to run” and “there’s so much reference to everything else.” The sentence is the signal that something’s there worth looking at.

2. Ask what it’s actually doing for you — not what the label says it’s for.

The honest answer sometimes means rebuilding the whole thing. My experiments database wasn’t just mis-labeled — it was holding the wrong shape of data for the job it was actually doing. Once I saw it was a decisions database, the structure had to change too: different fields, different way of capturing the entry, different way of retrieving it later.

Other times the label is fine and the system itself needs to do its job differently. Daily rhythm was a fine name, but the system was generating tasks when it was supposed to be helping me decide. Weekly review was a fine name, but the system was wrapping things up when it was supposed to be opening them up so I could see them.

Asking what something’s actually for doesn’t always end in new vocabulary. Sometimes it ends in a full rebuild.

3. Before you rebuild, ask what it’s supposed to protect.

This is the question I missed the first time around. A system that doesn’t protect anything is just busywork. A system that protects the wrong thing leaks where it matters. The morning protects quiet before noise. The daily protects energy and capacity. The weekly protects the growth thread.

If you don’t know what your system is supposed to protect, you’ll rebuild the same misfit with new paint.

✳︎ ✳︎ ✳︎

Whether it’s a morning or a workflow, it comes back to the same thing.

Protect what’s important.

The noise will find its way in either way.

✳︎ ✳︎ ✳︎

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

Built for Someone Else: Building workflows that fit your actual business and energy instead of someone else’s blueprint.

One thing to sit with: What system have you quietly stopped using — and is it actually outgrown, or was it never built for the way you work?

✳︎ ✳︎ ✳︎

Thinking Through Something?

If you’re sitting with a decision, workflow, tool stack, or AI process that technically works but doesn’t feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

So I watched my friends get handed theirs. No caveats. They turned sixteen, took the permit test, practiced, got the license. That was the whole path.

Mine had an extra step bolted onto the front. And I was peeved. Genuinely angry about it. Why was the bar set higher for me than for everyone I knew? It took me longer. I was the passenger while my friends were the drivers. I got there eventually. Had the job, got the license. But for a good while I was sure the rule was unfair, and I second-guessed it the whole time. Is this even worth it?

Then I turned twenty-six. I remember the moment. Holy crap, I’m in the next phase, first twenty-five behind me. And I looked back to take stock of what I was grateful for.

The rule was on the list.

The extra step wasn’t a disadvantage. It was the thing that built my relationship with money, with responsibility, with earning what I had.

The harder path hadn’t gotten me to the same place by a slower route. It built something the easy path didn’t build.

I’ve been thinking about that rule a lot lately, because I’m standing in the same spot again. Except this time, nobody set the bar for me. I set it for myself.

This isn’t the first time I’ve caught myself following frameworks built for someone else instead of trusting the path that actually fits.

Three tools, one job

I sat down a short bit ago to settle a question I’d been carrying: I’m paying for three different AIs that can create images (one only creates the images). Do I actually need all three?

So I ran a test. I pulled up a featured image I needed to make, fed each tool a few examples of my own work and my style guide, and wrote a prompt for the scene I wanted. Then I gave the same setup to Nano Banana, to ChatGPT, and to Midjourney. Three tools, same job, head to head.

Midjourney landed it (it being my style). Every time.

The other two missed. Every time. I adjusted the prompt. I changed the references. I tried the tips and tricks everyone swears by, the exact phrasing, the magic words, the structure that’s supposed to produce the perfect image. Nothing got me the look I was after.

And here’s the part I want to be honest about. I didn’t walk away thinking those tools work differently. I walked away thinking what am I doing wrong.

The doubt that wasn’t really about me

That question sent me looking. Not at the tools. At myself.

I took it to Gemini. I took it to ChatGPT. I even took it to Claude. I described what I was doing and asked, more or less, what’s off here? What am I missing? I was sure there was a setting I’d skipped, a technique I hadn’t learned, some obvious thing everyone else knew that I didn’t.

This wasn’t new, by the way. I’ve been with Midjourney since it lived on Discord. And Discord and my brain did not get along. Not the image-making, the finding. Every image I made disappeared into a chat thread, and I’d lose it. I almost left over that. Then they moved to a browser, and that was the change that kept me. So I’d already been through one round of is it me, or is it the tool and stayed.

Then there’s the prompting itself. Midjourney V7 and V8 are, functionally, two different engines. The way I asked V7 for an image is not the way V8 wants to be asked. I had to relearn it. And the relearning cut against everything I’d been taught about prompting, because Midjourney doesn’t want instructions. It wants you to set a scene. You don’t tell it to do X, Y, Z. You give it creative input and let it interpret.

That’s a hard hump to get over when every other tool has trained you to be precise and literal.

If you read DigiNav Compass Signal, you’ll stop second-guessing your AI and automation decisions because you’ll have a way to tell what actually fits your business from what’s just noise.

Subscribe now

The expertise is already yours. You just needed a framework to trust it again.

It was never me

Here’s what the rabbit hole finally turned up.

It’s not me. Midjourney isn’t a worse version of ChatGPT or Nano Banana. It’s a different kind of tool. It works in layers. It’s built for artistic interpretation, not instruction-following. So no matter how perfectly I copied the prompting that worked for everyone else, I was never going to get the same result. I was using a different kind of engine to do a different kind of thing.

The doubt was the wrong question. “What am I doing wrong” assumes there’s a right way I’d failed to find. There wasn’t. There was just a tool that asks for something different than the popular ones do, and a result, on the other side of that difference, that I couldn’t get anywhere else.

The bar I set for myself

This is where the license rule came back to me.

At sixteen, the higher bar was handed to me. My parents set it; I just had to clear it. What I’m doing with Midjourney is the same shape, an extra step everyone around me skips, except now I’m the one holding the bar. Nobody’s making me take the harder path. I’m choosing it.

And I could have not chosen it. I could have settled. I could have taken the popular tool, accepted images that were fine, and told myself the difference didn’t matter. That would have been easier. It would have cost me less time and less relearning.

But I’d be making everyone else’s process. I’d be taking something that works for me, something people recognize, something they see and know is mine, and trading it for a result I don’t actually want, just because the path to it is smoother.

The license rule taught me what that trade costs. The easy version gets you the license. It doesn’t build the thing the harder version builds. My images are distinctive because I stayed on the harder path long enough for them to become mine. That’s not stubbornness. That’s the higher bar doing exactly what a higher bar does.

You don’t have to pick just one tool

Staying with Midjourney does not mean I’ve sworn off the other tools. That’s the part I don’t want misread.

Look at any of my articles. The featured image is Midjourney. But the infographics, the step-by-step visuals, those aren’t, because right now Midjourney can’t handle heavy text the way ChatGPT and Nano Banana can. I use Perplexity and Tally for research. I use Claude to think and draft. I use Midjourney for one kind of image and Chat for another. It’s the same instinct behind coming back to the tool that actually worked after testing the alternatives.

Holding a higher bar doesn’t mean forcing one tool to do everything. It means knowing which result you’re protecting, and being honest about where another tool genuinely does the job better.

The bar isn’t loyalty to a tool. It’s loyalty to the result.

Before you switch

Every time a new tool drops, the comparison articles start, and the question underneath them is always the same: should you switch? It’s easy to let that question turn into doubt about every choice you’ve already made.

So here’s a better one to sit with.

What does your current tool produce that you’d genuinely miss if you switched, and is that thing the result you actually want, or just the result you’re used to?

If the honest answer is nothing, I’d be fine, then switch. The new tool might be the better fit, and there’s no higher bar worth holding for its own sake.

But if there’s something real there, a result that’s yours, that you’d lose, that you worked to build, then the doubt isn’t telling you anything true. It’s just noise from watching everyone else take the smoother path. You already cleared the harder one. That was the point.

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

Built for Someone Else: Building workflows that fit your actual business and energy instead of someone else's blueprint.

Thinking Through Something?

If you're sitting with a decision, workflow, tool stack, or AI process that technically works but doesn't feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

My Monday morning starts the way most of my days begin: I open the Chief of Staff dashboard to prepare for what’s ahead.

But last Monday, I opened it and something still felt off. I couldn’t put my finger on it. Not broken-off. Not useless-off. Just off.

The more I sat with it, the more I realized — the last couple of weeks I’d been wrestling with a few friction points in my day-to-day operating system. Or, as I like to call it, the Chief of Staff. The rhythms. The weekly commitments. The reworking of the email triage journey, which you can read about in past articles. All of it feeding into the dashboard, helping me make the most of my energy, not just my time.

And I knew something had to give. What it was, I wasn’t quite sure yet.

Part of the process, and to me the best part, is finding the breaks to create the fixes. But these breaks were personal. Harder to see the forest through the trees.

Because the outcome wasn’t just about what would work or cause friction. It was about whether I was willing to show you the messiest parts of the process to get there. The parts that are sometimes the most difficult to put out in public, because you might look at them and say, “Isn’t this what she tells us not to do?”

Short answer: yes. That would be the very thing I’d tell you not to do.

But taking your own advice isn’t always the easiest pill to swallow.

So this past week, I just took a step back. I stopped following all the things I’d been doing. I stopped running the daily rhythm. I didn’t do any weekly commitments because I just needed to clear my mind of where those friction points were. I didn’t stress about whether I needed to check my emails or not. I just lived in the moment and went through the processes.

And that’s when I realized I was still unconsciously following everyone else’s wins and game plan. The piece bringing it all together — the dashboard I’d built — was the piece I was building based on what I’d seen from everyone else.

Hi, I'm Lee. I help solo business owners get clear on AI and automation decisions before they commit — no hype, no hustle, no borrowed playbooks.

New here? Find the room that fits → No Foundation Yet → Lost In Translation → Built For Someone Else → The Last Mile

Subscribe now

Nothing was broken

Nothing was broken. That’s the part that took me the longest to name.

The daily rhythm worked. The weekly commitments worked. The email triage worked. They were all working. They just weren’t working right. Not 100%. Not for me.

The daily rhythm and the weekly commitments are good processes. I rely on them. But I’d built a dashboard on top of them, beautiful, in Vercel, styled exactly how I wanted, to pull it all together in one place.

And every time I made a change to a Notion space to get the information that mattered most, the dashboard broke. Four version reiterations in. I was using AI to bridge the rhythm builder and the weekly commitments and the end-of-day pulse. Adding tools to fix a tool I’d built to look at the tools I already had.

The email triage I’d built with a Google script and Gemini still had friction. I’d written articles about it. I’d shown people how to set it up. But I was still triaging the triage. The labels weren’t applying right, and I knew CoWork (Anthropic’s desktop agent) could automate it further, but I’d been resisting adding another third-party option to the stack.

Two systems that worked. Two systems that weren’t working right.

Pretty or functional

The dashboard moment is where it cracked open.

I was looking at it, and the question landed: was it pretty, or functional?

It was pretty. It was fun to build. It was the thing everyone was building. But every time I made a change to a Notion database to get the information that mattered most, it broke. And I’d have to fix it. To look at it. In a browser. Signed into a Google account.

Or I could just open Notion.

Here’s the part I was overlooking the whole time: the answer was already in Notion. I just couldn’t see it because I was thinking about design aesthetic instead of usefulness. Notion isn’t as visually appealing as a dashboard I build myself in React and Vercel. I’ll give it that. But Notion has changed. It can do most of what I had the dashboard set up to do. Pull from the same sources, hold the same information, show me the same things.

The dashboard wasn’t solving friction. It was adding a layer on top of the thing that already had my information.

I was doing more work to maintain the watching than I was doing the work itself.

I told you to swap blinders for earphones

Friday I wrote about how to stop feeling like an outsider on AI. About swapping blinders for earphones. Vision wide, volume down. Stop letting the noise drive your decisions.

This week I caught myself with the earphones on and still building the wrong thing.

That’s the part I want to name. Because I think we tell ourselves that if we just fix our inputs, read different people, leave the bubble, stop comparing, we’ll naturally stop engineering for what we’re watching.

We won’t.

You can be in the right bubble, reading the right people, asking the right questions, and still build a dashboard because dashboards are what everyone’s building right now. You can have the earphones on and still hear enough through them to start engineering toward what you’re hearing instead of what you need.

Correcting the inputs isn’t the whole job. It’s the first job. There’s a second job underneath it: catching yourself when you’ve stopped walking your own talk.

When tired is telling you something

I want to be honest about how I got to the recognition, because the version where I just stepped back and saw the truth isn’t accurate.

I stepped back partly because the dashboard kept breaking and I was tired of fixing it. I stepped back partly because triaging the triage was wearing me down. I stepped back because I was tired.

The clarity didn’t come from wisdom. It came from fatigue.

And I think that’s important. Because the reader version of this article would be: Lee took a thoughtful pause and recognized her patterns. The real version is: Lee was tired of maintaining things that weren’t working right, and the tiredness made the question loud enough to hear.

The exhaustion is the signal. If you’re tired of maintaining something that isn’t actually broken, that’s data.

That’s not a personal failing. That’s the gap between what you built and what fits.

What I actually decided

The dashboard: I’m going back to Notion. Not because Notion is better. Because Notion is mine. I’ve been using it for years, I know how to work with it, and it doesn’t break when I change it. The Vercel dashboard was a beautiful experiment. It taught me what I needed to know. I’m not going to keep maintaining it just because I built it. The rhythm and the weekly commitments don’t need a layer on top of them. They just need to keep doing what they already do.

The email triage: I added the third-party tool I’d been resisting. CoWork is now running the triage based on what it knows about me, not on a generic Apple script with stringent rules I was working around. The biggest caveat was setting my MacBook to not sleep, which I solved too. It’s been running for a week. It’s working beautifully.

The pattern shows up in the small calls too. I’ve stuck with Midjourney because it nailed my style, even when everyone was touting Gemini, then ChatGPT, then back again. I use ChatGPT for what it does best, not because someone told me to. And I still second-guess every one of those calls. Was I ahead of the curve, or did I just get lucky by not following the latest craze?

I don’t know. I’m not going to know until later, if ever. The point isn’t being right. The point is making the call from inside my own work instead of from inside the watching.

What isn’t broken but isn’t working right

Here’s what I want to leave you with.

What in your work right now isn’t broken, but isn’t working right either?

Sit with that. Don’t fix it. Don’t optimize it. Just notice it. No big AI prompts or processes. Just you and your gut.

What are you maintaining because you built it, not because it fits?

And then: if you stopped using it for a week, really stopped, would you miss it? Or would you finally see what was actually working, and what you’d just been maintaining?

The first time you correct your inputs, you change what you’re listening to. That’s real work and it matters.

But the second time, and there’s always a second time, you catch yourself building toward what you’re listening to, even when what you’re listening to is good.

I don’t know what you’ll find when you sit with this. I’m not going to tell you what to do with it. The point isn’t to follow my call. It’s to make yours.

That’s the work I’m in right now. Out loud. With the earphones on. Still building the wrong thing sometimes. Still recovering in real time.

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

Built For Someone Else: Building workflows that fit your actual business and energy instead of someone else’s blueprint.

Thinking Through Something?

If you’re sitting with a decision, workflow, tool stack, or AI process that technically works but doesn’t feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

I was scrolling through Substack notes the other morning, the way I do most mornings, when one from Soulful Learning with AI stopped me. She was talking about feeling like an outsider in the conversations. Like she hadn’t been invited to the table.

I sat with that for a minute. Because I’d been feeling exactly that for the last couple of weeks.

The question that had been forming kept poking at me — is Substack turning into another social media platform? All about the likes, the influence, the go-to person? And right behind that question was a conversation I’d had with a friend a few days earlier. About how fast AI is moving. About how easy it is to forget that the corner of the internet you’re paying attention to is just a small slice of a much bigger picture.

That’s when it clicked. The outsider feeling wasn’t about being uninvited.

It was about being in the wrong bubble.

That’s the thing nobody names when you’re feeling behind on AI — sometimes the problem isn’t that you’re behind. It’s that you’re measuring against the wrong bubble.

When the feeling shows up, I pull back

Here’s what I do when the outsider feeling starts to creep in. I pull back. Not all the way out — just back enough to look at what I’m actually consuming and what I’m actually getting from it.

That’s how I found the bakers.

And the digital creators. The illustrators. The graphic artists. The entrepreneurs in completely different industries doing completely different things.

These people aren’t in the AI conversation. They’re not pushing the boundaries of what’s possible with agents or vibe coding or whatever the new term is this week. They’re just doing their own thing. Sharing what they’re working on. No comparison games. No visibility chasing. Just here’s what I made today.

Those are my people. The ones looking inward at what they need, and sharing it outward without performance.

It reminded me of how I run my experiments — not to show off a polished result, but to show the actual mess. The wrong turns. The things that didn’t work. No bow on the package. Just here’s what I tried, here’s what happened, here’s what I’d do differently.

That’s the kind of content I want to read. And the kind I want to make.

Hi, I'm Lee. I help solo business owners get clear on AI and automation decisions before they commit — no hype, no hustle, no borrowed playbooks.

New here? Find the room that fits → No Foundation Yet → Lost In Translation → Built For Someone Else → The Last Mile

Subscribe now

The visible bubble isn’t the whole room

Here’s what I think a lot of us are missing. The small group of AI thought leaders who feel like the whole conversation? They’re not the whole conversation.

They’re a bubble. A loud, visible, very publicly engaged bubble. They’re talking to each other, building on each other’s work, referring each other, pushing each other. From the outside it looks like an exclusive club. From the inside it’s just a small group of people who happen to be jazzed up by the same thing at the same time.

But here’s the part I keep coming back to — most business owners haven’t even touched AI yet. Not from a prompting standpoint, let alone agents or building or vibe coding. Most are still running tried-and-true processes that have worked for years and aren’t quite ready to make the jump.

So the “inside” you’re feeling locked out of? It’s a tiny corner of a much bigger room.

Think about a horse race for a second. You watch the horses come around the track and it feels like the whole sport is in front of you. The jockeys, the horses, the finish line.

But that’s not the whole operation. There are owners. Veterinarians. Stable hands. Trainers. The people who feed and walk and care for those horses every day.

They’re not on the track — but the race doesn’t happen without them.

The visible racers aren’t the whole game. They’re just the part you can see.

Swap the blinders for earphones

Here’s the move I keep thinking about.

When a horse races, they put blinders on. Blinders narrow the field of vision so the horse doesn’t get distracted by what’s happening on either side. Just the track ahead. Just the lane.

That’s what most advice tells you to do when you’re feeling behind. Stay in your lane. Don’t worry about what they’re doing. Focus.

But blinders cut off your vision. You stop seeing what’s around you. You stop noticing the bakers and the digital creators and the entrepreneurs in other industries doing things you might actually want to learn from.

What I want instead is earphones.

Earphones cut down the noise. They don’t narrow your vision. You can still see the whole field — you just turn down the volume on the comparison and the pressure and the I-should-be-doing-what-they’re-doing. You stay aware. You stay curious. You just stop letting the noise drive your decisions.

That’s the shift. Vision wide. Volume down.

What I actually changed about how I read AI content

I want to be specific about what I did, because the philosophy is easy and the practice is the part that actually moves anything.

I cut my AI reading down to the top three or four people. The ones whose work consistently teaches me something I can use, not the ones who make me feel like I’m falling behind. I didn’t unsubscribe from anyone — I just stopped opening everything. Made room.

Then I expanded. Bakers. Illustrators. Graphic artists. Entrepreneurs in industries I’m not in. Small businesses doing things differently.

I went from one bubble to several different ones, and I read all of them in small doses so no single voice gets too loud.

And I stopped — really stopped — comparing what other people were building. The cool things. The boundary-pushing. The “look what I made with this brand-new tool” posts. I let those exist without making them mean anything about what I should be doing.

What replaced the comparison was a different question. What’s one thing I can do today to move my business forward, in a way that makes sense for me and how I actually work?

That question gets me further in twenty minutes than two hours of scrolling ever did.

The question for you

I know this piece is different from what I usually write here. That’s part of why I wanted to write it. Sometimes the most useful thing I can do is step back from the build logs and the experiments and just name what’s actually happening underneath.

So here’s the question I want to leave you with.

If you stopped trying to break into the bubble that’s making you feel outside — who would you read instead?

Sit with that one for five minutes. Look at your feed. Look at who you open every time and who you skip. Look at who you compare yourself to and who you actually learn from.

The outsider feeling is real. It’s just usually pointing at the wrong problem.

You’re not on the outside of the conversation.

You’re just in a different bubble. And there’s nothing wrong with that.

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

Lost In Translation: Untangling the pressure and distorted expectations surrounding AI.

Thinking Through Something?

If you’re sitting with a decision, workflow, tool stack, or AI process that technically works but doesn’t feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

Paper. Pencil. Spreadsheets. Atomic Habits. Notion databases that took me a full weekend to build. Productivity systems borrowed from people whose businesses looked nothing like mine. Every few years a new tool, a new framework, a new promise that this would be the one that finally stuck.

None of them did.

When AI showed up, I thought maybe this was different. I started building what everybody else was building, a chief of staff dashboard modeled on someone else’s flow. I was a few hours in when I caught myself telling Claude, for the third or fourth time, this is not a productivity system.

Claude called me out.

I was piecemealing every impressive build I’d seen on Substack and YouTube and stitching them into exactly the thing I said I didn’t want. A productivity system. A nicer-looking version of every system that hadn’t worked for me before.

So I stopped.

I closed the tabs. I stepped away from the dashboard. And I sat with the question I’d been avoiding for eighteen years: why has none of this ever worked for me?

I wasn’t failing the systems. The systems were built for someone who wasn’t me.

The list wasn’t built for me

The list I’d been chasing wasn’t built for me.

Time blocking. Theme days. Morning routines optimized down to the fifteen-minute increment. Frameworks designed for people who ship the same kind of work every day, content creators, vibe coders, anyone whose output looks roughly the same on Tuesday as it does on Friday.

My work doesn’t look like that. It never has.

Some days I disappear into an experiment for six hours. Some days are quick. Answering clients, clearing the inbox, moving small things forward. Some days my brain wants to think and refuses to do anything else. Some days I need to be outside before I can sit down at all.

But every productivity system I tried assumed I’d show up the same way every morning. So I kept trying to become that person. I’d follow the routine for two weeks, and then something would shift, a rough night, a heavy stretch of client work, a week where I needed to think more than do, and the system would collapse.

Then I’d blame myself. Start over. Try again.

The piece I missed for years: I wasn’t failing the systems. The systems were built for someone who wasn’t me.

The AI version of this is louder. Automate this. Schedule that. Hand off the things that waste your time. The list got longer and the assumption stayed the same. Your day is a stack of repeatable tasks waiting to be optimized. What you need is more output, faster.

I kept trying to map myself onto it anyway. Because that’s what trying every system teaches you to do. You assume the next one will work if you just follow it correctly.

Why productivity systems don’t work for me (and maybe you)

I went back to the question I’d been avoiding: why has none of this ever worked for me?

The answer wasn’t you haven’t found the right system.

The answer was you’ve been asking the wrong question every time you sit down.

Every system I’d tried started in the same place: what do I need to get done today? Open the list. Pick the next thing. Move it forward. Check it off. Repeat.

The question sounds productive. It feels productive. But it assumes something that isn’t true. That today is interchangeable with yesterday, and that what I’m capable of right now is the same as what I was capable of when I built the list.

Some days I sit down with a list of seven things and I’m clearheaded enough to move through five of them before lunch. Other days I sit down with the same list and the first item takes me three hours because my brain is somewhere else and I won’t admit it.

The list doesn’t know the difference. The list never knew the difference.

What I actually needed to ask, before I touched the list at all, was a different question:

What kind of day is this?

Not what’s on the calendar. Not what’s overdue. What’s the shape of the day in front of me. What’s my energy, what’s my capacity, what’s pulling at my attention before I’ve even started.

That’s a decision question, not an output question. And no productivity system I’d ever tried had asked it.

Building a decision system instead of a productivity system

So I started building something different.

Not a productivity system. A decision system. Something that started with the question I’d been skipping, what kind of day is this, before it asked me anything about what to do.

I called it the Daily Pulse.

The first thing it asks isn’t what’s on the list. It’s an inner check. How am I feeling. What’s my energy. Did I sleep. What’s already pulling at my attention before I’ve sat down. Then it asks what’s on the calendar. What commitments are non-negotiable today, what’s flexible, what could move if the day calls for it.

Only then does it look at the work.

The order matters. Because if you ask the work first, the work always wins. Every list I’d ever built worked that way. Open the list. Pick the next thing. Don’t think about whether you have it in you to do that thing, just do it. By the end of the day, half the items would be checked off and I’d feel like I’d been hit by a truck and not be able to tell you why.

The Daily Pulse reads the day before it touches the work.

That’s the part AI can’t do for me. Claude can build the dashboard. Claude can pull from my calendar, my notes, my Notion databases. Claude can do almost every part of this faster than I can. But Claude cannot tell me what kind of day I’m having. Only I can answer that. And until that question is answered, every other question downstream of it is the wrong question.

That was the reframe.

Use AI for the work you can outsource. Don’t outsource the read.

Five flags, not a grid

The Daily Pulse needed a way to know what was getting starved.

Not a productivity grid. Not a list of tasks sorted by priority. A way to see, across a week, where I was pouring everything in and where I’d gone quiet. Because I already knew what happened when I didn’t watch for that. I’d disappear into a stretch of heavy client work and come up three weeks later having not read a book, not gone outside, not talked to anyone outside of a deliverable thread.

So I gave it five categories.

Build, Think, Learn, Grow, Live.

Build is the work. Experiments, client deliverables, anything I’m shipping. Think is thinking on my own, without AI in the room. Learn is consumption that gets tested and applied, not just stockpiled. Grow is the relationships, the people I work for myself partly so I can show up for. Live is the body, the outside, the rest, the things that aren’t work and aren’t trying to become work.

The categories aren’t a schedule. They’re flags.

If a week is heavy in Build and Learn and Grow has gone untouched, the system says so. Not here’s what to do about it. Just, hey, you haven’t touched this in five days, are you good with that? Sometimes the answer is yes. Sometimes the answer is no, that’s why I feel like garbage and don’t know why.

That distinction was the whole point. I didn’t want a system that picked my work for me. I wanted a system that called me out when I was about to repeat a pattern I already know costs me.

That’s the part most productivity systems get backwards. They optimize for what you do. The Daily Pulse optimizes for what you’d otherwise miss.

If you want to test what this feels like before you build anything, here’s a prompt you can paste into Claude or ChatGPT to try it once:

I want you to help me read my day before I plan it. Ask me four questions, one at a time, waiting for my answer before moving on:
1. How am I feeling today, physically, mentally, emotionally?
2. What's already on my calendar that I can't move?
3. What's pulling at my attention before I've even started?
4. Looking at the work I could do today, which of it actually matches the day I just described?
Don't suggest a schedule. Don't optimize anything. Just help me see the day clearly before I decide what to do with it.

Run it once. See if the answer to question four surprises you.

If it does, you’ve already learned the thing the Daily Pulse took me weeks to figure out: the read comes before the plan, every time.

Just because you can build it

I spent eighteen years trying to find the system that would finally work for me.

What I needed wasn’t a better system. It was a better question.

The Daily Pulse isn’t the point of this article. It works for me because it was built around the way I read a day, the categories that keep my week balanced, the inner check that matches my energy patterns. If you copied it move for move, it would feel like wearing somebody else’s shoes.

But the question I had to ask before I could build it, that one’s worth borrowing.

Every list you’re staring at right now, the AI playbook, the productivity stack, the chief of staff dashboard, the framework that promises to finally get you organized, every one of those was built by someone else for the way they work. That’s not a flaw. That’s just what it is.

The question isn’t whether you can build it. You probably can. AI has made it easier than ever to clone someone else’s system in an afternoon.

The question is the one I should have asked a long time ago:

Just because you can build it, does it apply to you?

Sit with that for five minutes before you build the next thing. Before you automate the next task. Before you copy the next dashboard from a tutorial.

If the answer is no, you’ve just saved yourself another two weeks of trying to fit into someone else’s shape.

If the answer is yes, build it. But build it from your own questions, not theirs.

If you’re stuck between I should be doing more with AI and I don’t know what’s mine to build, that’s the gap I help close. Book a call and we’ll get clear on what’s worth building for you specifically, and what’s just somebody else’s good idea.

Sitting down with my morning coffee, it was time to go through the Action folder so I could set my day. But once I opened it, I could feel a new anxiety building.

This wasn’t supposed to happen anymore. I’d spent weeks getting the email triage dialed in — the cadence, the folders, the rules. I’d written about it. Publicly. The inbox was finally clean. I’d stopped compulsively refreshing Gmail to make sure I hadn’t missed something from a client. For the first time in a long time, email wasn’t running me.

But the Action folder was heavy.

A hefty WordPress migration that needed to go on the schedule, sitting above a two-minute yes-or-no for a different client, sitting above three emails I’d been circling for days, sitting above a vendor follow-up I’d promised on Tuesday. All flat. All the same visual weight. No way to tell at a glance what was a quick reply and what was going to eat two hours.

I sat there with my coffee and the familiar voice started up. Is this actually working, or did I just move the mess?

I tried to shake it off and be practical. Google Tasks was right there — same ecosystem, free, one click. I sent a handful of action items over and watched them land as context-free one-liners. No sender. No subject. No link back to the thread they came from. Just “follow up re: site” sitting next to “approve invoice” with nothing to tell me which was which or which mattered more.

They got stuck there. And I could feel the doubt spreading backward — if the Action folder isn’t working, maybe the triage isn’t working. Maybe the article I’d just written was premature. Maybe I’d built another system that looked clean on the surface and fell apart the second real work hit it.

That was the moment. Not the full folder. The fear that the thing I’d just told everyone was working was about to prove me wrong.

Gemini’s First Three Answers Missed

I opened Gemini.

Normally when I’m thinking through a problem, I go to Claude. That’s where I do most of my work. But this problem lived inside Google Workspace — the email, the folders, the triage rules — and I wanted the answer to live there too. Gemini is built into Workspace. If the answer was a script or a Sheet or some other Google-native piece, Gemini was already standing in the right room. So I went there instead.

I started by explaining what I wanted. A way to see what was in the Action folder at a glance. Enough context on each item to know whether it was a two-minute reply or a two-hour task. Nothing heavy. Nothing that added another login or another platform.

Gemini’s first response pointed me at a third-party ticket system.

Then, when I said no, it offered a lightweight project management setup in a separate app. Then a “productivity ticket system” built on top of something I’d never used. Every suggestion pulled me out of Workspace and into someone else’s ecosystem — another login, another subscription, another tool to learn and maintain for what should have been a small fix.

I pushed back. Told it I wasn’t leaving Google Workspace. The whole point of going to Gemini was that the answer should live where the problem lived.

Then it suggested a form.

The logic on paper wasn’t bad — a form clients could submit requests through, feeding a clean intake pipeline. Except my clients have been emailing me for years. Some of them for over a decade. I’m in the middle of rebuilding half my business right now. The last thing I need is to send a note to a long-term client that says “hey, instead of just emailing me like you always have, can you fill out this form.”

I pushed back again. The email isn’t the problem. The email is what’s working. The problem is what happens after the email hits the Action folder.

Eventually Gemini landed on the right neighborhood — what if we built this in a Google Sheet with a script running in the background?

Yes. That.

So I told it to build the spreadsheet.

What came back was a poor man’s version of what I actually needed. The columns were generic. The structure was thin. The drop-downs were missing context that anyone who’d worked an inbox for a week would know needed to be there. It was the kind of output that looks like a solution until you try to use it.

I stopped it. Told it I’ll build the spreadsheet — I just need the thinking behind it. Tell me what columns, tell me why, tell me what should be a drop-down and what should be free text. I’ll do the rest.

That shift was small but it mattered. I stopped letting Gemini execute and started letting it think with me. The columns got sharper. The drop-down logic got specific. When I mentioned that a single email thread often contains three separate asks — the original request, my clarifying question, the client’s reply — it handled it cleanly by numbering each email within the thread so nothing got lost.

But every useful piece of that system came on the other side of me saying no, not that.

Why AI Keeps Giving Generic Answers

Somewhere between the third pushback and the spreadsheet rewrite, it hit me.

Gemini wasn’t failing. I was expecting it to fail well — to read my mind, to know my business, to understand why I didn’t want a form and why I wasn’t leaving Workspace and why Google Tasks wasn’t enough.

It couldn’t know any of that. I hadn’t told it.

Every answer that missed was an answer built on the context I’d given it, which wasn’t much. “Help me organize the Action folder.” That’s not a brief. That’s a wish. With a brief that thin, of course the first swing was a third-party ticket system — that’s what the internet says to do when someone says “I need to organize tasks.” Gemini was reflecting the average answer to the average version of my question.

The work wasn’t in getting Gemini to be smarter. The work was in getting myself to be clearer.

Once I said it out loud — the triage is working, the email is working, the friction is specifically what happens after an email hits the Action folder, I’m not willing to leave Workspace, I’m not willing to ask clients to change how they contact me — the suggestions got smaller and sharper. Not because Gemini got better. Because the question got better.

I wasn’t waiting for a tool smart enough to figure me out. I was the bottleneck.

That’s the piece I keep forgetting and keep relearning. Every time I’ve had a frustrating conversation with an AI, I’ve gone back and looked at what I actually gave it to work with, and nine times out of ten the answer is not much. A vague goal. No constraints named. No mention of what’s already working, what’s already built, what I’d walk through fire to protect and what I’d happily throw away.

The AI can’t infer any of that. It’s not watching me work. It’s not sitting in my inbox. It doesn’t know I’ve been in the middle of rebuilding my business for months and the last thing I have bandwidth for is retraining my clients on how to reach me. It knows what I type.

So the recognition wasn’t about Gemini. It was about me finally seeing that the friction I kept feeling in AI conversations wasn’t the AI — it was the gap between what I knew about my own work and what I was willing to say out loud.

Staying in the Ecosystem That Already Works

Here’s what I used to believe about solving problems with AI: the goal is to find the right tool, then give it the task, then let it build.

That’s not quite right. The goal is to find the tool that lives closest to where the problem actually is, then bring it into your process instead of asking it to invent one for you.

The Action folder problem lived inside Google Workspace. The email, the folders, the triage rules, the clients themselves — all of it was inside Workspace. So the answer needed to stay inside Workspace. Not because I’m loyal to Google. Because every time a solution asks you to leave the room where the problem is happening, you pay a tax. You pay in logins. You pay in subscriptions. You pay in context-switching. You pay in one more place to check, one more system to maintain, one more thing that can break on a Tuesday when you don’t have the energy.

The system you need is the one that fits the process that’s already working. Not the one that replaces it.

Because here’s the other piece — I could have walked this exact problem into Claude Code and built an agent. I could have stood up something in CoWork that watched my inbox and wrote cards to a board. I could have turned an Action-folder problem into a multi-system architecture project and spent the next three weeks getting it just right.

That would have been using somebody else’s system. It would have been me reaching for the most impressive answer instead of the most fitting one. And fitting matters more than impressive. Fitting is what you actually use six months from now.

Staying in Workspace wasn’t a compromise. It was the whole point. The triage already worked there. The clients already lived there. The emails already lived there. Adding a Sheet that talks to Gmail via a small script didn’t add a new system — it extended the one I was already running.

And there’s a quiet bonus waiting at the end of that choice. Everything I’m building in Workspace speaks Google’s API natively. When I’m ready to bring this into the Chief of Staff dashboard I’m building, the data’s already in a format that can be pulled in cleanly. I didn’t have to plan for that. I got it for free by staying in the same neighborhood.

The System: A Sheet, a Script, and What It Actually Does

What I ended up with is almost embarrassingly simple.

A Google Sheet. A script running quietly in the background. That’s it. That’s the whole system.

The Sheet has columns for the things I actually need to see when I look at the Action folder: who’s asking, the subject line (which effectively becomes the ticket name), the priority, the thread number, a link back to the original email, and any links the email itself contained — a Dropbox folder, a Google Doc, a shared asset.

When a thread has multiple back-and-forths, each email in the thread gets its own number, so the context doesn’t collapse into a single flat row. The ask, my clarifying reply, and the client’s response each get their own line.

Drop-downs handle the categories where I was going to type the same thing over and over — priority, status, client. Everything else stays free text so the Sheet doesn’t fight me when a specific email needs a specific note.

The script is what makes it actually work. It watches what hits the Action folder and populates the Sheet in the background. I don’t have to touch it. I don’t have to maintain it. It runs on Google’s infrastructure, inside the same ecosystem where the problem was.

And here’s the quiet payoff I didn’t fully see coming — because every action item is now captured in the Sheet, I can actually archive the email. The folder gets lighter. Nothing gets lost. The ask isn’t waiting in Gmail for me to remember it’s there; it’s already on the list, with context, ready to be worked. The email stops being the holding pen and goes back to being what it was supposed to be — the delivery mechanism.

And because the data lives in a Sheet, I was able to plug it directly into the daily rhythm I run every morning in CoWork. Instead of opening Gmail and scrolling the Action folder to figure out what the day looks like, I open the Sheet view inside my rhythm and see everything at a glance — sorted, prioritized, with context. The Sheet became a feed into a system I was already running, without me having to build any new connective tissue.

The pieces that fit tend to keep fitting. The pieces that don’t, don’t.

What I didn’t end up with matters just as much. I didn’t end up with a ticket system in ClickUp. I didn’t end up with a form for clients to fill out. I didn’t end up with an agent running in the background that I’d have to babysit every time Google changed an API. I didn’t end up with a Notion database that would have been beautiful and unused by month two.

I ended up with the smallest thing that does the job. And the smallest thing that does the job is the thing I’ll still be using a year from now.

None of this is to say the system is finished. It isn’t. I’ll tweak the columns as I notice what I’m actually using and what I’m ignoring. I’ll adjust the drop-downs when I realize a category is too broad or too narrow. I’ll probably find a piece of context I keep wanting that isn’t captured yet, and I’ll add a column for it. That’s how any process improves — the same way you refine an SOP, the same way you tighten up any part of the business.

What the automation piece gives me isn’t a finished product. It gives me a way to remove the friction of sorting and prioritizing so I can actually see what the next refinement should be. The system is version one. The point is that it works now — and because it fits, I can keep making it better without starting over.

The Skill Is the Pushback

All of this started because Gemini tried to send me somewhere else — another platform, another form, another system — and I said no.

The pushback is the part I want you to keep.

Not the spreadsheet. Not the script. Not the Google Workspace ecosystem. Those are mine. Yours might look nothing like this. Yours might live in Notion, in Airtable, in a stack I’ve never used. The specific tools are almost beside the point.

What matters is the posture. The willingness to interrupt the AI’s first answer and say no, not that — and then take the extra minute to explain why. The willingness to stay in the ecosystem that’s already working for you, even when the suggestion is to leave it. The willingness to describe your actual process out loud, including the parts that are messy and the parts you’re not willing to change, so the AI has something real to work with.

Most of the time, the friction I feel in an AI conversation isn’t the AI. It’s that I haven’t made the gap between what I know about my work and what I’m willing to say out loud small enough yet.

So here’s the question I want to leave you with:

When was the last time you pushed back on a solution that was recommended?

Sit with it for a minute. Not to answer it for me. Not to reply. Just to notice.

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

Built For Someone Else: Building workflows that fit your actual business and energy instead of someone else’s blueprint.

Thinking Through Something?

If you’re sitting with a decision, workflow, tool stack, or AI process that technically works but doesn’t feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

Chances are you’ve already tried at least one tool that promised to make your life easier — and quietly abandoned it three weeks later. You’re not alone. Over half of small business owners are experimenting with AI but never committing. And 82% of the smallest businesses say AI simply “isn’t applicable” to them.

That’s not a technology problem. That’s a translation problem. And that’s what this is about.

I went to Vo-Tech in high school mostly because I wanted a hands-on learning experience. Cooking was where everything clicked — not just the process of making food, but the chemistry behind it. The measuring. The way combining the right ingredients in the right order creates something that didn’t exist five minutes ago. Sometimes it was really tasty. Sometimes it bombed epically. Either way, I understood what happened and why.

The plan was culinary institute after graduation. James Beard. The full professional kitchen. I wasn’t just dreaming — I was training.

Then came the blind taste test. Mandatory for admission, no way around it — and they couldn’t guarantee there’d be no seafood in it. With my allergy, that took me completely out of the game. Not a maybe. Not a workaround. Just like that, the award-winning culinary path was off the table.

But that path closing didn’t mean it was the end of my love for cooking.

This was the recalibration moment. A moment of — okay, this door is shut, so where do I go now? The Culinary Institute was the plan. James Beard and the awards were the destination. And neither of those was happening now.

It stings when you’ve been working toward something specific.

But what I knew I wasn’t going to do was decide that cooking was broken for me — or that I’d wasted my time training for something that didn’t pan out. Those skills were still there. The love of it was still there. I just had to figure out what cooking actually looked like without a classically trained chef in a restaurant at the end of the road.

Long story short, I never stopped cooking.

The classically trained path closed, but cooking stayed open. I still cook for friends, family, my husband, different events. Sometimes small meals, sometimes big ones. Sometimes I just open the fridge, look at what’s in there, and make something cohesive out of it.

And nobody has ever looked at a meal I made and said, “Whoa, I can’t believe you never went to culinary school.”

Because the goal was never about the restaurant or the awards. When I create a meal, it allows me to be part of the experience. That was always the point.

So I just had to figure out which version of cooking actually fit into my life.

AI automation works the same way.

Right now, every piece of content out there is pointing you toward the restaurant — full automation, removing yourself from the process. It’s all about building agents and sub-agents, AI-scheduled tasks, letting AI run while you sleep. Let AI do the work so you can scale, grow, and be everywhere at once.

But that’s not what you actually need for your business. Because as a creative and as a solo entrepreneur, you need to be part of the process — not completely removed from it or paralyzed by it.

This is the part that’s real, and one of the things nobody is talking about.

There are different levels of AI involvement, and the level that fits your business should come from your actual needs, your processes, and honestly, how much of yourself you want to keep in the work. Not from whatever framework someone built to showcase their expertise or sell you a tool.

Some people will want to run the restaurant with a full staff. Others just want to cook a cohesive dinner with what they have in their refrigerator. Those are different goals, and neither one is wrong.

So let’s break it down into the simplest terms first.

The Pantry — What’s Already on Your Shelf

Step one of AI automation for solo business owners: know what you have before you buy anything else.

In the AI world, this is your stack. The tools you’re already paying for or using for free — ChatGPT, Claude, Gemini, Perplexity, Canva, whatever’s already open in your browser on any given day. The subscriptions you signed up for with good intentions. The free tiers you’re dabbling in.

This is what the industry calls your AI tooling or your model layer — the raw ingredients sitting on the shelf. And just like a real pantry, most people have more in there than they realize. The problem isn’t that the pantry is empty. It’s that nobody’s taken inventory.

Before you can cook anything, you need to know what you have. That’s it. That’s the whole pantry step.

The question at this level: What AI tools am I actually using right now — and what am I paying for that I haven’t touched in three weeks?

The Recipes — The Things You Already Do Well

Where AI assistance (not full automation) fits into your existing business processes.

Recipes are your repeatable processes. The tasks you do regularly, in roughly the same order, that produce a reliable result. Writing a newsletter. Responding to client inquiries. Putting together a proposal. Onboarding a new client. These are your recipes.

Here’s the thing about recipes you’ve been making for years: some of them are so ingrained that you move through them on autopilot. You don’t notice what’s in them anymore — which means you also can’t see what could be improved or where AI could genuinely help. You’ve always done it that way. It works. End of story.

But other recipes are ripe for a shortcut. And this is where AI assistance — not automation, assistance — actually fits. Think of it like buying a rotisserie chicken from the grocery store instead of roasting your own. The meal still gets made. You’re still cooking. You just didn’t spend two hours on the part that didn’t need two hours.

In practice, this looks like using AI to draft a first pass, generate an outline, summarize a long document, or repurpose something you already created. You’re still in the kitchen. You’re still making the meal. You’re just not doing every single step from scratch.

The industry calls this: AI-assisted workflows, co-pilot tools, or prompt-based automation. It sounds complicated. It’s just a smarter grocery run.

The Meal Plan — Coordinating Across the Week

This is what most AI agent advice is actually talking about — and where solo owners need to decide how far to go.

A meal plan is sequencing. It’s not one dish — it’s how the dishes connect across a stretch of time. Monday’s roast chicken becomes Tuesday’s soup. The prep you do on Sunday makes Wednesday easier. Things flow into each other with intention.

In your business, this is where scheduling and coordination come in. What runs when, in what order, triggered by what. Some meal plans are simple — a sticky note on the fridge that says what you’re cooking each day of the week. Others are full meal delivery services: planned, packaged, and dropped at your doorstep on a schedule.

This is the level most AI agent content is talking about — automated workflows, scheduled tasks, multi-step sequences that run with minimal input from you. Tools like Zapier, Make, n8n, or CoWork live here. So do the AI agents and sub-agents everyone is building in public right now.

And here’s where the all-or-nothing trap springs: most of the content skips straight to “build the full meal delivery service” without asking whether you actually need it.

“A sticky note on the fridge is a meal plan too. It doesn’t need to be a subscription box.”

The question at this level: Which sequences in my business actually benefit from running on their own — and which ones need me in the loop?

The Leftovers — What Actually Survived

The most important step in any AI workflow: testing what works, ditching what doesn’t, and letting your results guide the next decision.

This is the most underrated part of the whole framework, and the one nobody talks about.

After every meal, you find out what actually worked. What got eaten. What got pushed to the side of the plate. What you’d make again and what you’d quietly retire. That feedback doesn’t stay in the kitchen — it goes back into the pantry, informs the next recipe, shapes the next meal plan. This is how the whole thing gets better over time.

In your business, this is your testing and iteration layer. It applies whether the process is automated or manual, yours or borrowed. What did the automation actually save you? What did it break? What did you think would be easier that turned out to be more complicated? What small thing ran quietly in the background and genuinely freed up your week?

The industry calls this: Retrospectives, feedback loops, iteration cycles. Which — fair. But leftovers is more honest. Some things survive the week and get better. Some things go in the trash. Both are useful information.

I’m in the middle of this right now. And I can tell you exactly where I drew the line — and why.

My Content Lab pipeline — the process I use to research and write every article — sits firmly in the Recipes layer. The creativity is the work. My experiences, my take, the hands-on-ness of it. That’s not something I can hand off to AI, or to anyone else, and still have it be the same thing. The moment I remove myself from that process, I’ve handed off the thing that makes it worth reading.

“If I outsource the recipe, I’m just serving someone else’s food.”

Same goes for my chief of staff dashboard. That lives at the Meal Plan level — it’s how I sequence and coordinate my week. But if I hand that completely over to a process, it becomes about productivity. And managing my energy, not my task list, is the whole point. I’m not willing to trade that.

But here’s where the Leftovers come in. My CoWork automations — subscription tracker, daily news recap — those run on a schedule and do their thing without me. I kicked them off, I tested them, and I know what they do. They free up bandwidth without removing me from anything that matters. They survived. I’d repeat them. That’s how I know they belong in the kitchen.

That’s my line. Not a framework someone handed me — mine. Built from figuring out what I actually needed to stay in the work, and what I was fine letting go.

So here’s the question I want you to sit with.

What’s actually in your pantry right now?

Not what you think you should have. Not what someone else’s stack looks like. What do you actually have on the shelf — the tools you’re using, the processes you’ve already built, the tasks you do on repeat every single week?

And from that — is there one dish worth making? One recipe that could use a shortcut, one part of your meal plan that could run on its own without you losing anything that matters?

You don’t have to build the restaurant. You just have to know what you’re cooking and why.

If you’re feeling stuck between “I should be doing more with AI” and “I don’t even know where to start,” that’s exactly the conversation DigiNav is built for.

If you’re a paid subscriber, the next section is for you.

I put together a practical framework for actually running a project once you know what’s in your kitchen — without losing the thread, without starting over every session, and without burning the kitchen down. It’s the how behind everything we just talked about. You’ll find it below.

Read more

For years I believed the template was the answer.

Use a structure. Follow the framework. Pick the writers you admire and reverse-engineer how they do it. The advice made sense — consistency, clarity, repeatability. So I built templates. Then I found better templates. Then I borrowed frameworks from writers whose work I admired and mapped my ideas onto their shapes.

And the information wasn’t bad. It was boring and incomplete.

I love to paint but a trained painter I am not. And for years I would use those paint by numbers kits. You know the ones — printed canvas, numbered sections, every color pre-assigned. They even give you brushes. Generic ones, but brushes.

At first it’s frustrating. Staying inside all those tiny little spaces. Then it gets efficient. Then it gets robotic. You’re not being creative — you’re just the person following the numbers.

That’s what the template was doing to my writing process.

The real problem wasn’t that the ideas were bad or the content was weak. It was that my articles were missing the best parts — the lessons, the snafus, the messy parts.

Most writing advice lives at the endpoints. Here’s the problem. Here’s the output. A to D, clean and straight.

Nobody shows you B and C.

What Happened When I Handed AI the Blueprint

Every week I would sit down to “write” the article.

I’d hand AI the brain dump — the build log, the experiment notes, some random thoughts I’d captured through the week. And from that pile of raw material, it would outline and draft the article. Based on the template.

Here’s what I didn’t notice for a while: the information was getting pared down to fit the tidy little spaces. The riffs didn’t make it in. The creative insights got smoothed over. The “oops, here’s where it went sideways and here’s how I adjusted” moments — gone. And the real failures? The ones rooted in my own mindset? Those definitely didn’t survive the template.

It wasn’t robotic. It wasn’t sloppy. You couldn’t look at it and say “an AI wrote this.”

But it was missing the only thing that made it worth reading — the experiences that only someone going through it could articulate. The part where I second-guessed myself at step three. The detour that turned out to matter more than the destination. The small realization that only shows up when you’re in the middle of something messy and paying attention.

The template didn’t know those parts existed. So it left them out.

The Better Template That Still Didn’t Work

So I did what made sense. I went looking for a better template.

I pulled some of my favorite writers. The ones whose articles felt effortless to read, whose structure seemed to carry you forward without you noticing. I asked AI to help me analyze what they were doing and build something better. Maybe it was a flow problem. Maybe the gaps just needed different sections.

Same thing happened.

I’d finish a draft and find myself rewriting large chunks of it. Not because the words were wrong exactly — but because they weren’t landing on the things that actually happened. The real texture of the experiment. What I was actually feeling at step three when it wasn’t working the way I expected. The adjustment I made that wasn’t in any plan but turned out to matter.

The words were there. They just weren’t making the cut.

And that’s when I finally looked at the right problem.

It wasn’t the structure of the template. It wasn’t the writers I was borrowing from. Templates don’t work for the way my creative process works — and more importantly, they don’t have room for the things that happen between step one, step two, and step three. The pivot that only makes sense if you were there. The failure that wasn’t a failure, it was information. The moment where the whole direction shifted because of something small that a template would never think to ask for.

That’s not a gap you can restructure your way out of.

Structure Isn’t a Template — Here’s the Difference

So I ditched the templates.

And then I just sat there.

Because the templates weren’t just a writing problem — they were also my process. Without them I had a pile of raw material and no clear path through it. I still needed to get from the brain dump to a published article without spending three times as long rewriting everything. I still wanted AI in the mix. I just needed it to stop making decisions that weren’t its to make.

That’s when I realized I’d been confusing two things that aren’t the same.

Templates and structure. I’d been using them as interchangeable words for the same idea.

They’re not.

A template tells you what goes where. Section one is this. Section two is that. Hit these beats in this order at roughly this length. It’s a paint by numbers canvas — the decisions are already made before you sit down.

Structure is different. Structure is just a flow of information. A guide, not a cage. You still know where you’re going. You just get to find your own way there.

The messy middle — the detours, the pivots, the things that only make sense because you were in them — those fit inside structure. They never fit inside a template.

And if you’ve ever handed a process over to a framework and wondered why the result didn’t feel like you — you already know what I’m talking about.

You’re Not Doing It Wrong. You’re Using Someone Else’s Process.

For as long as most of us can remember, we’ve been taught to follow the blueprint.

Funnels. Frameworks. Content templates. Launch sequences. There’s a proven path for almost everything in business — and following it is how you get results. Do X, then Y, then Z. Hit these steps in this order. Success is a system.

And for a lot of people, it works. The map gets them where they’re going.

But what about the ones whose minds need to work through things differently? What about the off-roads — the detours that don’t show up on the map but turn out to matter? What about the person who learns by going sideways first, or needs to feel their way through the middle before the beginning makes sense?

The map still gets everyone to the same place, technically.

It just doesn’t account for how some of us actually travel.

And borrowed confidence — following someone else’s proven path — looks exactly like best practice right up until the moment you notice what it cost you to get there.

How to Know When a Template Is Working Against You

So how do you know when a template is working for you — and when it’s working against you?

Start here. These aren’t a framework. They’re just honest questions worth sitting with (and a few simple one-line prompts) to help you think it through.

Does finishing the draft feel like something you would say or do? If it’s not reflecting the whole story, you need to ask yourself why it feels off and if it helps or confuses the audience.

Are you rewriting large sections after the draft is done? Not polishing. Rewriting. If you’re regularly putting back parts that got cut to fit the template, the template is editing your voice. And your audience will see that.

Does the output sound like you — or like a version of you that cleaned everything up? There’s a difference between clear and sanitized. If you read the draft out loud and it doesn’t feel like you, chances are it’s not.

If any of those land, you’re not doing it wrong. You’re just working with a tool that was built for someone else’s process.

The next step isn’t finding a better template. It’s figuring out what structure actually fits how your mind works — and that looks different for everyone.

My brain has always run at full speed. Some people call it ADHD tendencies. I prefer to think of it as superdrive.

For as long as I can remember, someone was telling me to focus, slow down, do one thing at a time. Teachers. Managers. Myself, on a good day.

Now I use AI daily, and honestly? It can be just as scattered. There’s no one to rein me in when a session goes sideways — when I’ve asked four different questions, chased three tangents, and somehow ended up somewhere completely unrelated to where I started.

Until I built myself a mirror.

It started with an article from Mia at . Her framework is smart — she breaks down what’s actually hiding inside every AI session and makes a compelling case that most of us save the wrong thing. We file the polished draft and lose the moment our thinking actually shifted.

She’s right. But I was sitting here building something slightly different, and I think it’s worth naming why.

Mia’s framework asks: what did the session produce worth keeping?

The thing I kept bumping into was a different question: was I clear, honest, and focused going in?

Those are not the same problem.

I spent a session this week designing a debrief process. It started as “let me capture AI breakthroughs” and wandered through Mia’s hierarchy, through knowledge systems, through Obsidian structures — until I stopped and said out loud: we’re thinking about this all wrong.

What I actually wanted wasn’t a knowledge capture system. It was a mirror.

Something that would show me, at the end of a thinking session, how I showed up. Did I have too many asks going at once? Did I drift off on a tangent that went nowhere useful? Was I actually thinking something through — or was I using the conversation to avoid deciding?

That’s not a breakthrough journal. That’s a coaching log.

Here’s the distinction that crystallized for me:

Mia’s framework is output-oriented — it helps you extract what the session produced.

What I built is input-oriented — it helps me evaluate how I used the session.

Both matter. They’re just solving different problems.

The output framework catches the breakthrough after it happens. The input framework catches the bad habit before it becomes a pattern. And for those of us who use AI daily as a thinking partner, the input side is where a lot of invisible time gets lost — not to bad tools, but to unfocused sessions, validation loops, and scope creep that looks like productivity.

The debrief I landed on is simple. At the end of a general thinking session, Claude observes five things: how focused the session was, whether tangents were useful or distracting, whether I was thinking or seeking validation, whether it reached a real conclusion, and whether the complexity matched the actual size of the problem.

Then I react. Then we write one or two sentences — the honest version — and I log it in Obsidian.

No elaborate capture system. No tagging taxonomy. Just a running record of how I think, so the patterns can eventually show themselves.

I won’t know what my patterns are for a few weeks. That’s kind of the point.

If you’re a daily AI user, you probably already have some version of Mia’s problem — great sessions that evaporate because you didn’t catch what shifted. Her debrief prompt is worth using.

But if you’ve also had that feeling of closing a tab and realizing you can’t quite account for the last 45 minutes — that’s the other side of the same issue. Not what you failed to save. How you showed up in the first place.

That’s worth paying attention to too.

If this resonates, here’s a short prompt to start your own end-of-session habit:

“Look back at this conversation and tell me: how focused was I, did I go on any tangents, and was I actually thinking or just seeking validation?”

Paste it at the end of any session that felt a little sideways. See what comes back.

And if you’re finding your AI sessions are doing more wandering than working, that’s exactly what I help with. Book a session today.

P.S. If you haven't read Mia Kiraki's original piece on catching AI breakthroughs, it's worth your time. Her framework is what sparked this one. Read it here.

If you missed the first two parts of this series, here’s the short version: I built a Google Apps Script to triage my inbox into three folders — Action Items, Read Later, and Noise — so I could stop treating email sorting like a productivity win and start dealing with the thing underneath it: the compulsive checking, the constant context switching. Part one covers the concept. Part two covers the build. This one is about what happened during testing — and what I kept getting wrong.

The script was running. Emails were moving. And I was still opening my inbox every hour or so to check on it.

Not to take action. Not because something felt urgent. Just to watch. To make sure it was doing what I told it to do.

That’s the moment I should have caught myself. I’d handed off the job — and then immediately started looking over its shoulder.

When Two Tools Are Running and Neither Is Enough

When the script wasn’t sorting things right, my first instinct was to run the same instructions through CoWork and see if it could do better. It could, in a way. CoWork read context well. It pulled from my Stripe customer list, identified who actually needed a response, and — this was the part that surprised me — it could explain why it was categorizing something the way it was.

But it couldn’t label. Couldn’t archive. Couldn’t do the actual mechanical job the script was built to do.

So for a stretch, I had both running. CoWork doing the reasoning. Google Script doing the moving. Two tools covering for each other’s gaps.

That’s not a solution. That’s a workaround.

And it told me something: the script wasn’t the problem. The instructions were.

The Brief Was the Problem, Not the Script

I’ve been hired as a consultant with ambiguous instructions. More than once.

It doesn’t just frustrate you — it makes it impossible to do the job well. You deliver something, and it’s wrong, but not because you’re bad at the work. The brief was bad. You built exactly what you were asked to build. It just wasn’t what they actually needed.

That’s what I did to my script.

I gave it instructions that were clear enough to get started but not specific enough to get it right.

When emails landed in the wrong folder, my instinct was to pull everything back and handle it myself. What I should have done was look at the instructions and figure out where they weren’t clear enough.

The other side of that analogy matters too. When you hire someone — or something — for their expertise, you have to trust that the expertise can do the work. Hovering doesn’t improve the output. It just signals that you didn’t actually hand off the job.

What I Actually Fixed

So I stopped looking at what the script was doing and started looking at what I’d told it to do.

I took CoWork’s reasoning — how it was categorizing, why it was making the calls it made — and fed that back into Gemini alongside the current script. Here’s what this tool understands about context. Here’s what it’s getting right. Now fix the script to match.

I added the Stripe customer list so the script had the context it was missing. Names and email addresses it could recognize, not just patterns it was guessing at.

I dropped the hourly recap entirely. It felt like a safety net — proof the system was working — but it was just noise. Subject lines and folder names with no explanation of the decision behind them. Once the script had better instructions, I didn’t need a report. I needed to trust the output.

And I changed the frequency. Every hour was recreating the exact problem I was trying to solve — constant interruption, constant context switching, just automated instead of manual. Four times a day:

• 8:00 am

• 12:00 pm

• 4:00 pm

• 9:00 pm

Enough to stay current. Not enough to give myself permission to check in between.

Before You Check the Output, Check the Instructions

The script is still running. Still working through the occasional sorting quirk. Triggers needed resetting at one point — a minor fix, easy to solve, and Gemini walked me through it clearly enough that someone with no coding experience could have handled it too.

But it’s working. Not because I found a better tool. Because I finally gave the tool I had instructions good enough to succeed.

Before you check whether the automation is working, check your gut — and check the instructions. Were they clear enough for the agent to actually do what you needed? If the output is wrong, that’s the first place to look. Not the inbox. Not the tool. The brief.

It’s the same question worth asking before you automate anything: have you defined the job clearly enough for someone else to do it?

Think about it the same way you would hiring a consultant or a contractor. You bring them in for their expertise. You give them the direction. And then you trust them to do the work — because hovering over their shoulder doesn’t make the output better. It just means you never actually handed off the job.

Your automation works the same way. Give it clear enough instructions, then let it run. If you haven’t, no tool is going to fix that for you.

If you’re working through something similar — an automation that’s half-working, instructions that aren’t landing, or just the general discomfort of letting a system do something you’ve always done yourself — that’s exactly the kind of decision DigiNav is built to help you think through. Start here.

Habits are hard to break. Whether it’s over-checking your email inbox or overindulging in your favorite dessert, it’s something you know isn’t doing you any good but you do it anyway.

I’ve been building a Chief of Staff dashboard for the past few weeks — using AI to pull information into one location so I can concentrate on what needs my attention.

The goal was to not have 10+ tabs open trying to figure out where that one piece of information is or was. I’m making progress, but the email section was the weak link.

Three boxes showing unread counts — inbox, WPSS, read later — and a link to go triage, which was basically a link right to the main inbox. Displayed as just numbers. No intelligence behind them.

I could see how much was waiting. I couldn’t see what kind of waiting. Action items looked the same as plugin update notifications. A client question sat next to a Substack digest.

To actually do anything useful, I still had to open Gmail and sort through everything myself. Which meant I was checking email to figure out if I needed to check email.

That’s the problem I needed to solve before the dashboard could do its job.

Before the Script: Cleaning Up 18 Years of Gmail Labels

It didn’t just start with an automation of my inbox. I had to start with the folder system that was 18 years in the making. 50+ Gmail labels accumulated over many years of running a WordPress agency and building a consulting business. All part of the chaos.

There were emails from clients who hadn’t been active in years. Others were duplicates with slightly different names. A few were things I couldn’t even remember creating, and some folders had zero messages in them.

You can’t automate a mess. If a script is going to sort emails into useful buckets, those buckets need to exist first and they need to make sense.

Knowing that I would be overwhelmed trying to organize all of that folder mess, I went to Claude AI and asked it to help me make heads or tails of the folder structure and how I could streamline it. I also took into account that now, with AI, it’s easier to find emails just by asking the AI to sort for you or by using the search function in Workspace.

And here’s where the reorganization ended:

• WPSS/ — agency wind-down, all client-related threads in one place

• DigiNav/ — consulting, content, audience conversations

• Life/ — personal, receipts, subscriptions, tax stuff

• Utility labels (underscore-prefixed so they sort to the top of the sidebar):

  • _Action Item — needs a response or decision

  • _Read Later — worth reading when there’s time

  • _Processed — the script’s audit trail

This is the non-glamorous work that people don’t talk about. It took a full session with Claude to sort through the chaos. But the upside was that it only took a few hours of conversation, as opposed to weeks of trying to figure out what was where and how to reorganize it.

Why I Used Gemini and Google Apps Script

So I moved the conversation from Claude to Gemini. The AI piece — sorting emails by judgment, not just pattern matching — wasn’t going to happen with Gmail filters or manual checking. But making that sorting automatic wasn’t clear until I started working inside Google’s ecosystem.

The reason for Gemini was simple: it lives inside Google Workspace. And there were some non-negotiables I wanted to make part of the process:

• Read Gmail natively

• Write a script that would automatically trigger

• Set those triggers to be time-based

• Not add another app that wasn’t already in the flow of tools I use

Gemini suggested the Apps Script approach. A script that runs on a timer, reads unread emails, uses AI to classify them, and applies the right labels. I set it to run every hour.

From there, the script would sort emails into three buckets:

• Action Items — anything that needs a response or a human decision

• Read Later — content worth reading when I have time

• Noise — notifications, plugin updates, form submissions, system alerts with zero human attention value

And the best part — Gemini correctly wrote the script based on best practices. It also gave me step-by-step instructions to not only install the script but to run the tests. I already knew how to do that, but if that’s not something you’re familiar with, Gemini can walk you through the whole process too.

Testing the Email Triage Script

The first test run put everything into Action Items. Every email. The rules weren’t specific enough about what counted as noise or read-later, so the script defaulted to the safest bucket. If you don’t tell AI what noise looks like, it assumes everything matters.

So I tightened the rules. Got very specific about what counts as noise:

• WordPress plugin update notifications

• Automated form submissions

• System alerts with no required action

And what counts as read-later:

• Newsletters and articles

• Informational updates with no response needed

The pendulum swung the other way. Everything landed in Read Later. Noise got a few scraps. Action Items was nearly empty.

Then there was the archiving problem. The script was archiving emails before the labels fully applied. Emails were disappearing — no inbox, no folder, just buried in Gmail’s archive. The fix was the same one from my earlier manual triage: label first, pause, then archive.

The _Processed folder became the safety net I didn’t know I needed. Every email that went through the script got tagged. When the counts didn’t add up or a category felt light, I could open that folder and see exactly what the script had done. It wasn’t just a label — it was the audit trail that let me refine the rules without losing anything and without reverting to checking the inbox myself.

The Anxiety of Letting Go

The system was working. The rules were dialed in. Emails were sorting into the right buckets every hour. And I still felt anxious about it.

The inbox was nearly empty, and my brain read that as something’s broken.

It wasn’t. It was working. The script was processing every hour, which meant email never had a chance to pile up the way it did when I was checking three or four times a day.

I was so used to seeing a wall of unread messages — and sorting through it as a kind of productivity ritual — that an empty inbox felt like a system failure.

I was getting in my own way. I’d second-guess how the script sorted things because I wasn’t the one making the call. I’d peek at the inbox to see if something got missed.

The whole behavior I was trying to automate away, I was recreating in a different form.

After a few more test runs, I looked at the Processed folder, confirmed the sorting was accurate, and made a conscious decision: stop opening the inbox. Go to the folders. Work from there.

That sounds simple. It was the hardest part of the entire build.

What the Email Triage Dashboard Looks Like Now

With the triage script running and the folder structure in place, the Today tab on my dashboard finally had what it needed.

Before: Generic unread counts. How much is piling up.

Now: Three intentional boxes:

• Action Items (red) — what needs a response

• Read Later (blue) — what’s worth reading when I have time

• Substack (purple) — engagement and reading, on its own schedule

Each box links directly to the Gmail label view. I go to the bucket that matches the energy and time I have.

Fifteen minutes between tasks? Check Action Items, knock out quick replies. Slower afternoon? Open Read Later and catch up on content. Ready to engage? Head to Substack and spend time on the conversations that matter.

The email section went from the weakest part of the dashboard to the piece that makes the rest of it work. Because now I’m not spending the first twenty minutes of my day sorting. I’m spending it deciding what to act on.

And with the triage running, the obvious next question was whether AI should handle the responses too.

The Line I Chose to Keep

I considered having AI draft responses. That’s the natural next step, right? Triage the email, then generate a reply so all you do is review and send.

I pulled back. Not because I think there’s anything wrong with it — plenty of people use AI for email drafting and it works for them.

But for the way my brain operates, I need to be fully present in the ask. When someone emails me a question, I need to read it, understand the context, figure out whether it’s technical or logistical or relational. That’s where I serve my clients and colleagues. If AI drafts the response, I’m reviewing words instead of understanding the need.

The triage handles sorting. The responding stays human.

That’s not a limitation of the system. It’s a design decision about where AI helps and where I need to stay in the loop.

What Automating Email Triage Actually Taught Me

Making the most of the tools that were already in my ecosystem was the gold of this whole experiment. Google Workspace, Gemini, and Apps Script were all sitting there waiting to just be connected and used. I didn’t need a new platform or another paid automation tool or the added expense of another AI platform.

But really the tools were secondary. Before any of that mattered, I had to organize what I was automating. 18 years of folders and labels wasn’t a system. It was sediment. Cleaning that up was the unglamorous foundation that made everything else possible.

And through all of this, the hardest part wasn’t the technical build. It was the behavioral changes:

• Trusting the system

• Trusting it enough to stop checking email

• Recognizing that an empty inbox means the automation is working, not that something’s broken

• Knowing where to draw the line between what AI handles and what stays mine

The script is still in testing mode. I need to give it time to work out any of the other kinks. I’m letting it run and watching how it’s sorting and adjusting based on the edge cases that come up. That’s how it should work. Not a launch-and-forget deployment, but building trust — with the system and with myself.

If you’re thinking about automating email triage, start here:

1. Figure out your buckets. What are the three folders that would cover 90% of your inbox?

2. Clean up the mess first. You can’t automate labels that don’t make sense.

3. Use what you already have. If you’re in Google’s ecosystem, the tools are already there.

4. Give yourself permission to feel uncomfortable. An empty inbox will feel wrong at first. That’s the system working, not failing.

The script is the easy part. Changing how you interact with your inbox is the real work.

This is part of an ongoing series documenting the build of a Chief of Staff dashboard — a personal command center for managing two businesses. The email triage was the missing piece that unlocked the Today tab.

Previous in this series:

What are the three folders that would cover 90% of your inbox? Reply and tell me — I’m curious how different they are from mine.

I’ve been building a Chief of Staff dashboard for the past few weeks. It’s my command center for managing the daily operational stuff that keeps both businesses running (and me sane). But there was one piece I kept stalling on: email triage.

I knew I wanted AI handling it. I just couldn’t figure out what that actually looked like.

Then I read ’s 4 Levels of AI Automation on Build to Launch. She breaks down the different levels of automation, from “AI reads your stuff and sorts it” all the way up to fully autonomous agents making decisions on your behalf.

But the line that stopped me wasn’t about the framework. It was this: “I wanted AI to read my inbox for me.”

That was my problem. Stated plainly, without overcomplicating it.

The One Level of Email Automation That Actually Matters

Jenny breaks automation into four levels. The one that matters here is the first: AI reads your email, separates it into categories, and you deal with what’s left.

That’s it. No agents making decisions on your behalf. No complex workflows routing data between platforms. Just sorting.

Her article is written for people choosing between automation platforms.

Builders evaluating which tool fits which job. Most of us aren’t making that decision. We’re trying to figure out what we can do with the tools already sitting in front of us.

That gap is where this gets interesting.

AI Email Triage Without the Fancy Tools

You don’t need a workflow engine to get Level 1 email triage. If you’re in Google’s ecosystem, you already have what you need.

I took Jenny’s concept to Gemini because it’s native to Gmail.

The idea was simple:

• write a script that reads my unread emails,

• uses AI to classify them into three buckets (action item, read later, noise),

• labels them, and archives them out of the inbox.

It was not a clean process.

During the testing — a simple click-the-Run-button process — I had to adjust and readjust because some emails were getting lost in the void.

Turns out, if the script archives a message before the label fully sticks, the email ends up homeless.

No inbox, no folder.

Archived in a catch-all folder with every other email you’ve ever kept. The fix that finally worked was suggested by Gemini: label first, pause two seconds, then archive.

Here’s what my inbox looks like now. Clean. Empty, actually.

This solved one piece of the Chief of Staff dashboard I’ve been building: the triage layer I couldn’t figure out how to automate.

But here’s what the automation didn’t fix: the habit.

Even with everything sorted, I still caught myself checking email whenever time allowed. Treating the triage of email as a badge for productivity honor when it’s really just a bad work habit that needed to be broken.

The sorting is solved. The compulsive checking is the next problem.

Is This Worth Your Time Right Now?

If you’re checking email between client calls whenever time allows, or treating inbox triage like your best productivity process, then yes. This is worth your attention right now.

Not because the concept is hard to implement. It’s not. But because your time and energy are more valuable than sorting emails into folders by hand. The real question isn’t whether you can automate this. It’s whether you’re willing to stop doing it yourself.

Figure out your categories. Find the simplest tool that sorts into them. If you’re in Google’s ecosystem, you already have what you need. The automation is the easy part. Trusting the system enough to stop checking is harder.

Jenny’s full article is here: 4 Levels of AI Automation. It’s worth reading even if you never touch a workflow engine, because the levels help you name what you’re actually trying to build.

Here’s the question worth sitting with: What are the three folders that would cover 90% of your inbox? Action items, read later, and noise worked for me. If you named yours, you’d already have the blueprint for what to automate — and what to stop checking.

This year’s winter jaunt was laid-back St. Augustine, Florida. Getting there and back meant two days in the car — the perfect stretch for catching up on work, reading, and whatever sparks come from hours of uninterrupted road time.

After my turn to drive, I decided to get an article or two into the pipeline. Except the work couldn’t be tackled on my iPad. Pulling out the laptop isn’t usually a big deal, but the computer bag was wedged in the back of the car and getting to it required some gymnastics I wasn’t in the mood for.

That’s where the rubber hit the road on my fancy Cursor content creation process.

The rubber being Cursor. The road being this: every conversation felt like starting from scratch. I was re-explaining myself every time. The context that makes working with Claude feel like working with someone who actually knows me — the memories, the context docs, the way I’ve built up how I operate over dozens of sessions — none of that was there. So while the AI agent was doing its job — technically — I was starting from scratch. Again.

That’s when it hit me: your AI workflow is only as good as what your AI actually knows about you.

Moving from Cursor back to ClaudeAI

The decision to move the full content pipeline out of Cursor had already been made — that part was clear. But mid-migration, something stopped me. The experiment docs were being glossed over and they’re the foundation of every article I write. Get that wrong and everything downstream is shakier than it needs to be.

So before anything else, I dealt with that first.

I had nine experiment files sitting in Cursor as markdown docs. I uploaded them all to Claude, and we assessed the existing Notion database together — what to keep, what to cut, what was missing entirely.

Claude fixed the schema.

The old template sections — Prompts, Inputs, Outputs, Artifacts, Notes, Next Iteration — got replaced with the structure that actually matched how I work: What I Built or Changed, How I Tested It, What Happened, Verdict.

Then the MCP applied all the existing records into the updated database. That’s where it got interesting. The first test run overwrote records instead of updating them. We fixed it and retested. Four rounds before it landed cleanly.

Once the existing data was solid, I added the forward workflow: at the end of any build session, ask Claude to document it directly into Notion. I live-tested this in the same conversation — one API call, all properties and body content written correctly in one shot.

The improvement I didn’t see coming: documenting the build directly through the conversation removes more friction than any tool switch ever could.

The breaking points, or not.

Nothing broke in the technical sense. Which is almost the point.

The friction in Cursor wasn’t loud. It didn’t throw errors or fail visibly. It just quietly required more from me than I realized — more re-explanation, more re-context, more process around the edges. The kind of thing you stop noticing because you’ve adapted around it.

What I didn’t expect was how much I relied on the build notes — the Experiment doc — as the actual foundation of each article. It adds the context, the actual conversation threads from AI and sometimes screenshots.

It was a structural piece that wasn’t getting its due. Cursor’s AI agent didn’t have access to the relationship Claude has built or the conversation memory. That’s not a Cursor problem — it’s just a fundamentally different thing.

Because sometimes broken isn’t when things don’t work, it’s when things are overlooked.

And if I’m honest, I’d been chasing a shinier setup instead of trusting the process I’d already built. The tools that had context — Claude, Notion — were right there. I just had a layer in the middle that didn’t.

If I had to do it again.

Trust the process you already built. Notion had been functioning as my persistent memory all along — storing context, tracking experiments, holding the thread between sessions. Claude had been the thinking partner. Those weren’t gaps to fill with a new tool. They were the foundation worth building deeper into.

I’d stacked a layer on top instead of doubling down on what was working. The switch didn’t require a complicated migration plan. It required recognizing that the combination I was working around was already solving the problem I needed solved.

New and shiny has a cost that’s easy to miss: it starts with zero context. And zero context means starting from scratch. Every time.

Decision one in the bag.

Kill Cursor for content creation. The decision wasn’t about features or capability — it was about context. Notion for persistent memory. Claude for thinking partner and automation. That’s the combination that already knew how I worked.

Cursor wasn’t a bad tool. It was the right tool for a moment that’s passed. The smarter move wasn’t finding something newer. It was recognizing what was already working and doubling down on it.

Notion remembers. Claude thinks and connects. That’s the pairing worth building on.

One more thing worth naming: things move fast in the AI space. What feels like a gap today may not be the stumbling block tomorrow. That’s not a reason to wait — it’s a reason to make decisions based on what’s working now, not what you’re hoping a new tool will eventually solve.

This is Part 1 of a short series on rebuilding the content workflow from the ground up. Getting the experiment documentation right — the soul of every article — was the foundation.

Next up: how the Article CEO workflow sits on top of it, and how the full pipeline runs from first spark to published piece.

One Thing You Can Try Today

Take five minutes and run this prompt against your current workflow:

“I use [tool/s] to do [specific job]. Given what I know about [the other tools I use daily], is this still the right fit — or am I working around it without realizing it?”

You’re not looking for a reason to switch anything. You’re just looking with fresh eyes. The answer might be: this still fits perfectly. That’s a useful thing to confirm too.

I’m big on organization especially when it comes to AI use and conversations. So her guides are always well-organized and specific in a way that makes you slow down and take note even when the technical details aren’t directly relevant to what you’re doing.

I read this one because Cowork is where I’m spending more of my time this quarter, and Karo has a way of laying things out that makes you look at your own setup and think: wait, am I being sloppy about something that matters?

The article covers a lot of ground — connector architecture, permissions, using Notion as persistent memory. Good stuff, worth reading on its own.

But the thing that I got the most out of wasn’t the technical setup of CoWork. It was something simpler underneath it: the names you give your folders are instructions to Claude, not just labels for yourself.

The names you give your folders are instructions to Claude, not just labels for yourself.

Karo’s folder structure is deliberate. Each name signals what Claude should do with what’s inside it. Easy to skim past when you’re looking for the architecture details.

The kind of thing that’s obvious in hindsight and invisible until someone makes it explicit.

Two things I took from Karo’s setup that didn’t require me to build anything new:

Sub-folders beat a flat root. Before reading this, everything except outputs lived in my root folder. One folder. Everything dumped in. It works until it doesn’t — and when it doesn’t, it usually means Claude is filling in gaps you didn’t know you left.

The rename that clarified something I hadn’t noticed. When I ran the article through a conversation with Claude, it flagged one specific thing: my folder called references should probably be called context. I didn’t push back. It made sense immediately.

Here’s why it matters.

References, to me, means sources: supporting documents, things I cite, external material. Context means something different: what Claude needs to understand my world. My voice. My audience. How I think about problems. Those two things were living under the same name, and that name was doing the wrong job.

The practical move is simple: look at your Cowork folder setup and ask whether the names mean what you think they mean to Claude — not just to you. That’s a five-minute audit. It won’t overhaul your system. It might just make it work the way you thought it already did.

If you’re using Cowork and have any kind of folder structure in place, this is worth 20 minutes now. Not to rebuild from scratch — just to look at what you named things, how you’re set up — and whether those names are doing the right job.

If you’re not in Cowork yet, this type of thinking works with other file management best practices. Starting with intentional folder names is a better foundation than cleaning them up later. Either way, go read Karo’s full article. The Notion memory setup alone is worth the time.

Karo’s full article is here:

Product with Attitude

Claude Cowork Guide for Power Users: 50+ Tested Tips on Plugins, Skills, Sub-Agents, and Memory

Read more

3 months ago · 128 likes · 15 comments · Karo (Product with Attitude)

One question to sit with:

In your current Cowork setup, is there a folder named something that made sense to you when you created it — but might mean something different to Claude? That’s your starting point.

A friend of mine loves to bake. Cakes, cookies, those little things she drops off that nobody ever turns down. But somewhere between the job, the side gig, the family and everything else life stacks on top — she was running out of time to do it. The baking wasn’t the problem. The process around it was eating the hours she didn’t have.

So I asked her: why not get ahead of it? Do the prep work in bulk when you have a window. Handle the time-consuming parts in advance, so when the hour finally appears, you’re not starting from scratch — you’re just baking.

She looked at me like I’d said something obvious. And maybe I had.

That conversation stuck. Because I’d been having the same one about my own business — just without the baking. Moving information from one place to another. Updating the same record in two tools. Copying what Claude produced into Notion, over and over.

The baking was fine. The prep work was the problem.

And the fix wasn’t somewhere else. It was already in the room.

The problem wasn’t what I had. It was what was missing between them.

The terminology was never built for you

You’ve probably heard this by now: connect your tools. Automate the repetitive stuff. Let AI handle it. Or maybe it comes with a list — MCPs, APIs, automation workflows. Someone making it sound like the logical next step.

And if you’ve ever looked at those words and thought, that’s not for me, you weren’t wrong to think it. For a long time, connecting apps required reading through developer documentation, understanding architecture, building the integration yourself. The barrier was genuinely technical. The conclusion — this isn’t in my lane — was a reasonable read of the situation.

But here’s what changed: everything around those terms did. The terms are the same. What they require from you isn’t.

MCPs. APIs. Skills. Plugins. These aren’t going away — if anything, you’re going to hear them more. But they’re no longer instructions for developers. They’re descriptions of how a system works. And once you understand what each one actually does, in plain language, the next question stops being can I even do this?

It becomes: where does this fit in what I’m already doing?

That’s a completely different question. And it starts with four definitions.

When Claude does the work... sort of

I had Claude do some of it. Updating records in Notion, pulling information across, and handling the pieces I didn’t want to do manually. And sometimes it was great — exactly what I needed.

Other times, it was inconsistent. Spotty results. Updates that half-landed. A process that worked well enough on a good run and let me down on the next.

The fix existed. I knew that. The problem was getting it to work reliably — and that meant setting things up properly, with the right connections in place.

And here’s why that matters for you — especially if you don’t have a technical background.

The path to fixing it runs through terms like MCPs, APIs, Skills, and Plugins. And for most people, that’s exactly where the conversation ends. Not because the concepts are complicated. Because the words signal: this requires a developer. This is not your lane.

That signal is wrong.

The terminology was built for a technical audience. It wasn’t built to keep you out — it just was never translated for someone who runs a business without a coding background. So you keep copying and pasting. You keep doing the manual steps. Not because you can’t use these tools, but because nobody handed you the plain-language version of what they actually mean.

That’s what this is.

Here’s what happens when the terms click.

You stop asking “can AI do this?” and you start asking “which piece handles this?” That’s a completely different question — and it opens up a completely different set of possibilities.

For me, that looked like setting up CoWork, not Claude Code. Most of the conversation has gone in that direction — it’s the more technical option. CoWork is the everyday version. The one built for exactly this: connecting Claude to the apps and spaces you’re already using, without needing a development background.

What I built was a simple connection. My experiment notes on my hard drive. My Notion workspace. My dashboard. My articles. CoWork became the layer that linked them, so Claude could reach across those spaces without me manually carrying the information between them.

Before CoWork, I had something similar running in regular Claude. And it was inconsistent in a specific way — sometimes it would create or update the Notion records exactly right. Other times, it would stop short and hand me code or text to copy and paste myself.

Which, if you think about it, is just the copy-paste tax wearing a different outfit. The connection between Claude and Notion was missing the piece that makes it reliable — the MCP, the API link. Without that, Claude was doing its best with what it had. Which wasn’t always enough.

The copy-paste process didn’t disappear because I found a smarter workaround. It disappeared because I had the right structure in place. Four terms. Four jobs. Each one handles a specific part of how the system works.

That’s what this understanding makes possible for you. Not a complicated build. Just a clear picture of what each piece does — and suddenly, the question isn’t whether you can do this.

It’s where do you want to start?

The four terms, in plain language

So let’s get into the four terms. Not the developer version. The version that actually makes sense for how you run your business.

MCPs — the hallway.

Your business doesn’t live in one room. It lives in Notion, in your inbox, in your calendar, in the documents on your hard drive. MCP is what builds the hallway between them. Without it, you’re the one carrying information from room to room. With it, the information moves on its own.

APIs — the smart lock.

You’re not handing anyone a key to your house. You’re giving controlled access — a code that works for a specific door, for a specific reason, and can be revoked whenever you want. The house stays yours. You just decided who gets through which door.

Skills — the recipe adapted for who’s cooking.

Same kitchen, same base. But a home cook improvises differently than a baker, who measures everything, because the chemistry matters. Skills are how Claude’s instructions get calibrated for the task at hand. What works for syncing documents is set up differently from what works for writing. Same foundation. Different precision depending on what’s actually being made.

Plugins — the meal kit.

Someone has already figured out the ingredients, the sequence, the portion sizes for a specific dish. You’re not building the recipe from scratch — you’re getting a pre-assembled package designed for one job. A sales plugin is a meal kit for prospecting. A marketing plugin is a meal kit for content.

Skills teach Claude how to cook. Plugins tell it what to make and for whom.

MCPs connect the rooms. APIs control who gets through which door. Skills are the recipe adapted for who’s cooking. Plugins are the meal kit — pre-assembled, one job, ready to go.

The companion piece walks through building each of these layers — what setup looks like, what to do with an API key, and how to build a Skill for a specific task. That’s where the how-to lives.

Here’s what staying manual actually costs.

Not in a dramatic way. Just in the quiet, steady way of doing the same task twice because the tools don’t talk to each other yet. Copying what’s in one place into another. Updating the record. Doing it again next week.

It’s not broken. It just never stops being your job.

The other cost is harder to see. It’s the possibilities that don’t show up because the vocabulary hasn’t landed yet. You can’t ask for a connection you don’t have a word for. You can’t build a system around terms that feel like they belong to someone else’s world.

The copy-paste tax is the visible one. The vocabulary gap is the invisible one. And they compound — the longer the terms feel inaccessible, the longer the manual process continues.

Noticing that friction isn’t weakness. It means you’re paying attention to where your time is actually going — and asking whether it has to.

It doesn’t.

Five things worth taking with you

If you only take away five things from this:

1. MCPs connect your tools. Without the connection layer, you’re the one carrying information between rooms. That’s the copy-paste tax — and it’s optional.

2. APIs are access keys, not developer tools. You give controlled access for a specific purpose. The house stays yours. Access is yours to grant and revoke.

3. Skills are how Claude’s instructions get calibrated for the task. Same base, different precision depending on what’s actually being made. A sync task and a writing task don’t run on the same settings.

4. Plugins are the meal kit. Someone already figured out the ingredients and sequence for a specific job. You’re not building from scratch — you’re deploying something pre-assembled for one purpose.

5. The barrier was never a technical skill. It was unfamiliar language. Once the terms land, the question changes from “can I do this?” to “where do I want to start?”

You’re allowed to find this hard.

Not because the technology is complicated. Because the language around it was built for a different audience — and nobody handed you the translation. So you watched the tutorials, heard the terms, and quietly concluded that this level of setup wasn’t for you.

That conclusion made sense with the information you had.

It’s just not accurate anymore.

The tools are there. The connections are possible. What changes first isn’t your setup — it’s the question you’re asking. And the question changes the moment the terms stop feeling foreign.

So here’s what I want to leave you with: what’s one process in your business where you’re still the one carrying the information? Not a general category — a specific thing. The task you do every week that moves the same data from one place to another, because the rooms aren’t connected yet.

That’s your starting point.

And once the terms land, the next question becomes which tool is the right fit for the job you’re trying to do. That’s a different conversation — and one worth having.

If you want to go further, the companion piece walks through building each of these layers, from what to do with an API key to how to build a Skill for a specific task. That’s where the how-to lives.

I was halfway through an article about Claude Code when I caught myself nodding along to advice about git workflows and terminal commands. Things that have nothing to do with how I actually use AI day-to-day.

Not because the developer stuff was interesting. Because buried underneath all of it was something I’d been wrestling with in my own work. The why behind AI going sideways on me.

This week, I read two genuinely excellent articles. Both about Claude Code, which is a developer tool that lets programmers use Claude directly from their terminal instead of the chat interface most of us use. One is even trying to bridge the gap for non-developers. But even that one assumes you’re writing code, managing files, and running commands.

The ideas underneath all of that? They’re not about code at all. They’re about how to work with AI better. And they apply whether you’re a developer or a business owner typing into Claude’s chat window.

So I dug them out. Here’s what I found.

(The articles, if you want the originals: Practice Makes Claude Perfect by Julia Diez, and Claude Code Skills, Commands, Hooks & Agents Guide by Dheeraj Sharma. Both worth reading if you’re technically inclined.)

It’s not a magic box. It’s a contractor.

Julia Diez opens with a reframe that I keep coming back to: Claude isn’t an assistant. It’s “a brilliant contractor who has no memory between work sessions and can only hold a certain number of things in their head at once.”

“A brilliant contractor who has no memory between work sessions and can only hold a certain number of things in their head at once.”

— Julia Diez

In the developer world, this means creating special files that brief Claude Code on the project before every session. Developers literally write a briefing document that loads automatically so Claude knows what it’s working on, what matters, and what the rules are.

You and I don’t have that automatic setup. But we need the same habit.

Why does AI keep missing the mark even when you’ve used it for months? You’re not briefing each session. Yes, Claude has memory now, and it might remember your name and some preferences.

But that’s not the same thing.

Memory is like knowing your contractor’s phone number. A briefing is sitting down with them Monday morning and saying: here’s what we’re working on this week, here’s what matters, here’s what done looks like.

Why does it drift on longer tasks? You handed over a big job without scoping it. Why do results get worse the longer a conversation goes? The job site got cluttered, and nobody cleaned it up.

I’ve done every one of those things. Still do, when I’m rushing.

The developer fix is a special file. Your fix is simpler: at the start of any significant AI task, take thirty seconds to tell Claude what you’re working on, what matters, what the constraints are, and what “done” looks like. Not a novel. A few sentences of context. The kind of thing you’d tell a smart freelancer on day one.

More instructions actually make AI worse.

This one surprised me.

Developers spend a lot of time writing rules and instructions for Claude Code to follow. Sharma’s article gets into the specifics of how to organize them, where to put them, what format to use. But the insight underneath all that structure is simple and it applies to everyone:

If you’ve ever given AI a detailed set of instructions and watched it nail the first few tasks but get progressively sloppier, there’s a reason. AI can only hold so many rules in its head at once. Add too many and quality doesn’t just drop on the extra ones. It drops across all of them.

Developers discovered this the hard way. They’d write hundreds of lines of instructions and wonder why Claude started ignoring the important ones. The fix was cutting back to only what actually mattered for the task at hand.

Same thing applies when you’re setting up a Claude Project or writing a system prompt. Every vague, redundant, or low-priority instruction isn’t just noise. It’s competing with the things that actually matter.

I’ve been guilty of this. Long system prompts full of “nice to have” preferences that I never pruned. If you’ve noticed your detailed instructions working less well over time, this might be why. Short, specific, high-stakes rules outperform long lists of preferences every time.

Plan before you produce.

Julie writes about a Claude Code feature called “plan mode” that forces Claude to map out its approach before it writes any code. Developers use it because building the wrong thing wastes hours.

You don’t need plan mode. You just need to ask.

Her prompt translates directly: “Before you start, walk me through your approach and flag any assumptions you’re making.”

I’ve started using this in almost every session. The reason it matters isn’t technical. AI, like most of us, defaults to action over thinking. Give it a task and it starts producing. That feels like progress. Often it isn’t.

When you ask AI to plan first, you get two things. It thinks through what it’s about to do. And you get a chance to catch misunderstandings before they become a finished draft heading in the wrong direction.

Diez puts it simply: changing direction during planning costs seconds. Changing direction after the fact costs everything.

Worth trying once before you dismiss it. Next time you have a real AI task, start with “before you begin, walk me through how you’d approach this.” See what comes back. Redirect if needed. Then let it go.

One conversation shouldn’t do everything.

Both articles land in the same place: a general AI loaded up with everything you’ve ever needed performs worse than a focused AI given only what it needs for the task at hand.

Developers solve this by building separate configurations for different types of work. They create specialized setups that load only the rules and context relevant to a specific job.

For the rest of us, it’s simpler than that. Stop asking one conversation to do everything.

I see this with my own work. I’ll start a session doing email drafts, pivot to client research, then ask for a proposal outline. All in the same thread. And then wonder why the proposal feels off.

The fix is almost boring. Start fresh conversations for different kinds of work. If you use Claude Projects, give different types of work their own project instead of loading one up with everything.

Smaller scope, sharper results. That’s it.

What I’m actually taking away

The problems both articles tackle are ones you’ve probably had too. AI that forgets, drifts, underperforms, and goes sideways. Developers just got to the solutions first because their tools forced them to think about it.

Brief it like a contractor. Keep your instructions tight. Ask it to plan before it produces. Stop asking one conversation to hold everything.

Not a technology problem. A workflow problem. And it’s one you can start fixing today.

If any of this shifted how you’re thinking about your own AI use, I’d love to hear what clicked. Hit reply and tell me.

DigiNav Compass is for business owners navigating AI decisions on their own terms. If this helped, forward it to someone who’s been frustrated with their AI results lately.

Inspired by information in: Practice Makes Claude Perfect by and Claude Code Skills, Commands, Hooks & Agents Guide by

Every session started the same way.

Open a new conversation, load the three docs, explain what I was working on, explain how I worked, and explain what I would and wouldn’t do. AI would take it in, do something reasonable with it, and we’d move forward. Then I’d close the tab.

Next session: start over.

This was early, before AI tools had real memory, or right at the edge of it. All three foundation docs were in place by then. The Business Snapshot, the Audience Profile, the Voice DNA. Loaded together, they gave me better output than I’d gotten before. I thought that was the fix.

The problem showed up when I’d ask for help thinking through a decision. The answer would come back technically right, sensible on paper, but wrong in ways I couldn’t always name immediately. Suggestions that ignored a second business I was running. Directions that assumed a work style I don’t have. Boundaries none of the docs had any way of knowing existed. I’d add the missing context manually. The session would improve. I’d close the tab. Next session: start over.

Business, audience, voice: the three docs tell AI about the operation. They say nothing about the person behind it.

Why This Is Harder Than It Looks

The standard advice is to build the three foundation docs and call it done. Business Snapshot. Audience Profile. Voice DNA. It makes sense. You’ve given AI the business context, the audience context, and the communication style. The logic is the same one we use when laying a building foundation: pour it once, get it right, then build on top of it.

The advice isn’t wrong. The three docs do what they’re supposed to do.

What they don’t do is tell AI how you work. Your decision-making style. What drains you. When you do your best thinking. What you’d never agree to, regardless of how sound it looks on paper. The reality of running a second business alongside the first. None of that is in a Business Snapshot. None of it belongs in a Voice DNA doc. It doesn’t have a home yet. The conventional wisdom skips the part nobody talks about: the person behind the operation.

A foundation without the framing that goes on top of it is still just concrete. It’s a starting point, not a finished structure.

What I Tried That Didn’t Work

So I tried the obvious thing first. I went back into the Business Snapshot and added a section. A few lines about how I work best: the hours I protect, the second business, the things I wouldn’t do regardless of what the numbers said. The logic was solid. The Business Snapshot was already the doc I loaded first. If I put the missing context there, it would be there.

It helped for about two sessions. Then the same drift came back. The Business Snapshot was built to describe the operation — the model, the audience, the positioning. When I added personal operating notes to the bottom of it, the doc did what docs do: it held everything without prioritizing any of it. AI would take in the full thing and give more weight to the business description than the three lines about how I work.

I’d patched a doc that wasn’t broken to solve a problem it was never built to solve. And I nearly convinced myself it was working. The sessions weren’t obviously broken. The output was still reasonable. But reasonable isn’t the same as right, and I was still adding the same context manually, session after session, the same way I had been before I touched the Business Snapshot at all.

Half-right output is harder to catch than wrong output. Wrong output is obvious. Half-right looks reasonable until you try to act on it and realize it was built for a version of you that doesn’t quite exist. I had documented the business, the audience and the voice. I hadn’t documented myself. And I’d spent time patching a doc instead of building the one that was actually missing.

What Actually Shifted

What finally changed wasn’t adding more to the three docs. It was realizing the three docs were never built to answer those questions.

Each one was doing its job. The Business Snapshot covered the business. The Audience Profile covered who I was talking to. The Voice DNA covered how I sound. Together they did what they were designed to do, and still left a gap I kept filling manually every single session.

Two things were missing that had names once I looked at them directly. The first: Personal Context. Not communication style (that’s what Voice DNA covers). Operating style. When I do my best thinking. What drains me. My non-negotiables. The behind-the-scenes reality of running two businesses at once. How I actually make decisions, not how I’d describe my decision-making process if someone asked. The difference between those two things is larger than it sounds.

The second: Product/Offer Context. What I’m building toward, whether the offers are fully formed or not. What I’d never build, even if it made sense on paper. What success looks like in 12 months. Without it, every planning session defaulted to what had worked for everyone else before, solutions built on hustle-culture assumptions that had nothing to do with how I wanted to work or what I was actually building toward.

Once both existed, the sessions changed. AI stopped suggesting strategies that required energy I don’t have at the time of day I do most of my work. The rules I’d built around energy and recovery stopped being invisible constraints I had to re-explain every time. Planning had somewhere to land.

I had documented the business. I hadn’t documented myself. Those are two different documents.

The change from here doesn’t arrive all at once.

Build is where you are after the docs are in place. The foundation is real. That’s the table stakes.

Refine is the first few weeks of use. You notice something’s still off, open the doc, update a line. The next session is better. This is the system working, not failing.

The compound is harder to see from inside it. Sessions get easier. You stop re-explaining yourself. The output starts fitting in ways that accumulate quietly.

Operating differently isn’t a destination. It’s what’s already happening if you’ve made it to compound.

Here’s What This Looks Like in Practice

You now know what two docs are missing. While you’re building them, the foundation you already have can handle four plays. Each one pressures a different part of your context so you can see what’s holding and what’s missing. Run them with three docs. Run them again with five. The difference between those two sessions is where the remaining gap shows up.

Play 1: Decision Testing. Run it before committing to anything, new tool, new offer, new direction. It tests a decision against your actual business context instead of general reasoning. Why it matters: a decision that fits your business on paper might not fit how you work or what you’re building toward. Upload: Business Snapshot. Add Personal Context and Product/Offer Context when you have them.

Play 2: Map What You Actually Need. Use it when you know what you’re working toward but can’t see clearly what’s between you and it. It skips the 90-day roadmap and gets to the smallest useful next step. Why it matters: Personal Context shows whether the path forward actually fits how you work; Product/Offer Context gives the mapping somewhere real to land. Upload: Business Snapshot and Audience Profile. Add the two context docs when you have them.

Play 3: Blind Spot Recognition. Use it when the audience feels right on paper but the content isn’t landing the way you expect. It surfaces the gap between your interpretation of their problem and what they’re actually dealing with. Why it matters: knowing what you’re building toward changes which audience blind spots matter most. Upload: Audience Profile. Add Product/Offer Context when you have it.

Play 4: Strategic Reflection. Run it at the end of a month or a project cycle. It finds the patterns in your own work before you build more: what’s emerging, what’s stalling, what question you should actually be sitting with. Why it matters: this play does the most work with the full five docs loaded. Patterns that look like business problems often turn out to be operating problems, and that only surfaces when Personal Context is in the room. Upload: all three docs. Add Personal Context and Product/Offer Context when you have them.

When I run these, what surprises me is how quickly the misfit shows up. The plays don’t need the two extra docs to run. They need them to stop giving you answers that are half right. The companion piece walks through each play in practice: the prompts, the process, and what done looks like. Same format as the starter kit, with interview prompts, synthesis prompts, and what a finished doc actually looks like for Personal Context and Product/Offer Context.

What It Costs to Stay Stuck

Running without these two docs doesn’t stop the work. It just means some of your time and energy go toward compensating for what isn’t documented yet.

Bad output is easy to spot. You see it, you fix it, you move on. Misfit output is different. It looks reasonable. It fits the business. It passes the first read. The problem surfaces when you try to act on it and realize it was built for a version of you that doesn’t quite exist, someone with different hours, different constraints, a different sense of where this is heading. So you correct it manually. Add the context that’s missing. Get a better answer. Close the tab. Next session: same thing.

The energy drain isn’t the bad sessions. It’s what you’re doing in the good ones. Every time you re-explain your working hours, your boundaries, your direction, that’s a doc that doesn’t exist yet doing its work anyway, through you, one session at a time. The work gets done. It just takes more out of you than it should. Without Product/Offer Context, AI defaults to what’s worked before for someone else, in a different kind of business, with different values about how work should feel. The answers point in a direction that isn’t quite yours, and you spend energy steering back each time.

Noticing this friction isn’t a sign that something’s broken. It’s pointing directly at what’s missing.

Key Takeaways

If you take away only four things from this, make them these.

1. Business, audience, voice, and then you. The three foundation docs cover the operation. They say nothing about the person behind it. For a solo business owner, those aren’t the same thing.

2. Half-right output isn’t a prompting problem. It’s a missing-docs problem. If AI keeps coming back with answers that look reasonable but don’t quite fit, the gap is in what hasn’t been documented yet, not in how you’re asking.

3. Two docs fill what the first three can’t. Personal Context captures how you work, not just how you sound. Product/Offer Context gives AI a direction to orient around, rather than defaulting to someone else’s playbook. Both answer questions the foundation docs were never built to answer.

4. The plays work now. They’ll work better with five docs loaded. Run them with what you have. Pay attention to where the answers still feel slightly off. That friction is showing you exactly what to build next.

You’re Allowed to Find This Hard

Building the first three docs is hard in a specific way. You’re answering questions about the business: what it is, who it serves, how it sounds. Those questions have answers, even if they take work to surface.

Personal Context and Product/Offer Context are harder in a different way. They ask you to document how you actually work, not how you’d like to work. To articulate a direction that might not be fully formed yet. To be honest about constraints and non-negotiables that feel uncomfortable to put in writing because putting them in writing makes them real. That’s worth naming. I still catch myself skipping the personal docs when I’m in a hurry, loading three instead of five and then wondering halfway through the session why the output keeps needing correction.

A half-formed direction doc is more useful than no doc. You don’t need certainty to build either of them. You just need enough honesty to give AI something real to work with instead of letting it fill the gap with someone else’s assumptions about how a business like yours should run. Start with one line that’s true. Update it when something shifts. That’s the whole process.

The companion piece covers how to build them: same format as the starter kit, with interview prompts, synthesis prompts, and what a finished doc actually looks like.

Subscribe now

What’s one thing you find yourself re-explaining to AI session after session? Not a business detail. Something about you: how you work, what you need, what you’d never do. Drop it in the comments.

Missed the article? Read the companion piece to “The Workshop I Built Was Wrong.”

Before you start: what your AI context foundation looks like when it’s done

Most people build context docs the wrong way because they don’t know what they’re building toward. So let’s show you the destination before you start packing.

A working AI context foundation isn’t one long document. It’s a folder structure with specific files doing specific jobs. Here’s what that looks like:

Read more

Why your AI output keeps coming back flat

Feedback and interactions were off. Not wrong, just flat.

You know the feeling. Something doesn’t feel right, but you can’t quite put your finger on it. Like making your favorite chocolate cake, following the recipe to a tee, using all your favorite ingredients, and it’s still a little off. Nobody sends it back. They still eat the cake. But it’s not the one they talked about the next day.

That’s what was happening to my writing. One week I had the perfect three layers and everyone raved. The next time, nobody said a word but they still showed up. Comments that circled around something without landing. Shares that were quieter than expected.

So I did the reasonable thing. I opened my Voice and Tone doc and started tightening it. Added more examples of what I didn’t want. Made the language more specific. Documented a few phrases that kept creeping into drafts I didn’t like.

I closed the doc feeling like I’d fixed the recipe. The next article came back the same way.

It took longer than I’d like to admit to figure out what I was actually doing. The voice wasn’t the problem. The structure was. The way I was presenting information (the flow, the sequence, the shape of an argument) wasn’t in my Voice and Tone doc. It wasn’t in any of my docs.

I had a full set of context docs. Business Snapshot. Audience Overview. Product Strategy. Storytelling Guide. All the right ingredients.

None of it answered the question my articles were actually asking.

The docs weren’t wrong. They were answering the wrong questions entirely.

Why “more context” is enterprise advice for a small business problem

The standard advice makes sense. Document your context. Give AI your voice, your audience, and your business background. The more it knows, the better it performs. Most of us have heard this, tried this, and watched it work, at least partially.

The advice isn’t wrong. It was just written for a different version of the tools and for a different scale of operation.

The frameworks most of us are following came from developers and prompting experts building large systems. Complex pipelines. Processes that needed every variable documented because the cost of getting it wrong was high. Their rules made sense for what they were doing.

When you apply that logic to a small business, it doesn’t tighten your output. It just gives you more to maintain. The docs grow, the updates pile up, and before long, you’re working on your context docs instead of the thing they were supposed to support.

I was spending more time updating my context docs than actually using them.

The goal was never to document everything. It was to remove the guesswork. Those are not the same job.

The over-documentation trap (and the template spiral that followed)

The problem wasn’t that I needed better docs. It was that I was building the wrong kind.

The original approach made sense. AI needed everything handed to it. It couldn’t hold context between sessions, couldn’t infer what you meant, and couldn’t reason about your business without explicit instruction. So you gave it everything. Voice down to specific phrases you’d never use. Audience down to what kept them up at 3 am. Background detailed enough to onboard a new hire.

I was still following those rules when I built my Content Lab (where all my content work lives) and started laying out my LifeOS dashboard (a personal productivity system I was building in Notion). And for a while, it felt like the right call.

When I finally identified the structural problem with my articles, I did the right thing. I started building writing templates. Specific ones for the actual use cases I was working with: experiments I was running, tools I was testing, and prompts I was stress-testing. Each one had its own shape and flow.

And then I kept adding more.

More templates, more use cases, more variations. No core set to anchor them. So the supporting docs (tone, audience, what to stay away from) got muddy. AI couldn’t figure out which flow to follow, so it defaulted to whatever pattern felt closest. The output got inconsistent in a whole new way.

I still catch myself doing this. Starting a new use case and reaching for a new template instead of asking whether one I already have could do the job.

I had graduated from the wrong foundation to the wrong working layer. Different problem, same root cause: building more instead of building better.

The three-layer AI context foundation that fixed it

What finally changed wasn’t the documents themselves. It was the question I was asking about them.

I had been asking “what’s missing from this doc?” every time something went wrong. Which meant every problem sent me back into the same pile of files, adding more to the docs that didn’t need more.

The better question turned out to be: which layer is this problem actually in?

That’s a different question. And it changes where you look.

A living context foundation isn’t one long document or even a tight set of core files. It’s built in layers, each one doing a different job:

The foundation is who you are, how you sound, and who you’re talking to. Most people have this, at least partially. It’s table stakes, not the finish line.

The working pieces are how you structure and present information. Templates, offer documents, and the shape of how you think through a problem. This is the layer most people skip entirely. It’s also the one that changed my output quality more than anything in the foundation layer.

Your running record is what you’ve tested, what worked, what didn’t, and what you learned. It’s the layer that lets AI push back rather than just execute. Without it, you have a capable partner with no history of how your business actually works.

The foundation tells AI who you are. The working pieces teach it how you think. The running record gives it something to measure against.

When I stopped patching the foundation and started building the missing layer, the output settled. The articles found their shape. The foundation stopped being something I was constantly fixing and started being something I was building on.

How to audit and update your AI context docs

Three shifts worth making, in order:

1. Build in layers, not in length.
Start with your foundation if you don’t have one. If you do have one, look at what’s next. Do you have a writing template, or a document that captures how you structure information? Do you have anything that tracks what you’ve tried and what you learned?

Each layer lives in its own document. Not one long file that keeps growing. A connected set you can open, update, and put back without touching the rest.

2. Review on a rhythm, update only what drifted.
Every few months, unless something significant changes. Open the relevant document, ask AI to review it against what’s new. Sometimes nothing needs updating — and that’s the system working, not the system failing. You’re not looking for what’s wrong. You’re checking whether it still reflects where you actually are.

3. Let AI do the seeing you can’t.
This one surprised me. When I started adding experiment notes to my context — what I was building, testing, learning — AI flagged something I hadn’t noticed myself. I had been telling my agents to break everything down into plain language, no jargon, keep it accessible. But when I wrote those experiment notes, I was writing like I was back in a developer meeting. Project briefs. Technical shorthand. The language of someone deep inside the work.

AI couldn’t reconcile the instruction with the example. And just like that, I couldn’t pretend I didn’t know. My content had been talking at my audience instead of with them — and no amount of audience profiling would have caught it. The problem wasn’t in the profile. It was in how I was showing up in my own docs.

Here’s a prompt you can use to audit a document you already have:

I'm going to share one of my context documents with you.

Once I share it, tell me:
1. Which layer does this belong in — foundation (who I am, voice, audience),
   working pieces (how I structure information, templates, offers), or
   running record (what I've tested and learned)?
2. What's in here that still feels current and accurate?
3. What feels like it was written for an older version of my business?
4. What's missing that would help you act as a real partner, not just a generator?

Don't tell me what to fix yet. Just tell me what you see.

The companion piece walks through building each layer from scratch — what goes in each document, the prompts for creating them, and what they actually look like.

The hidden cost of outdated context docs

Every session where AI guesses wrong, you’re editing. Every month a doc ages unreviewed, you’re re-explaining. Every output that’s almost right but not quite — that’s not a prompt problem. That’s a foundation problem.

The harder cost to see: you can stay busy tweaking docs and feel like you’re making progress. But if the missing layer never gets built, nothing changes. You’re not stuck because you stopped trying. You’re stuck while trying the wrong thing.

That friction you keep feeling isn’t weakness. It’s pointing at exactly what needs attention.

Key takeaways

If you only take away four things from this, make it these.

1. The docs aren’t wrong — they’re answering the wrong questions. More context doesn’t necessarily lead to better results. The goal was never to document everything. It was to remove the guesswork. Those aren’t the same job.

2. You can’t fix a structure problem in a voice document. When output is off, identify which layer the problem is actually in before you touch anything.

3. A living foundation is built in layers, not in length. The foundation tells AI who you are. The working pieces teach it how you think. Your running record gives it something to measure against. Each one is a different document doing a different job.

4. AI can surface contradictions you can’t see from inside. When your instructions and your examples don’t match, AI will find it. Add your experiment notes, your test results, your real work — and let it show you what you’re missing.

Start here: find the layer you’re missing

Most people built their context docs once and moved on. Going back to revisit them feels like admitting they weren’t enough.

They were enough. For then. The tools changed, and the job changed with them. That’s not a failure — it’s just where we are.

The shift that’s actually hard isn’t the tactical one. It’s accepting that something you built carefully and deliberately might need a new layer — not because you did it wrong, but because you’ve outgrown what it was designed for.

You’re allowed to find that hard.

What’s one document or template you built a while back that still makes sense on paper — but you’re starting to suspect isn’t working for where you are now? Not a general category. A specific thing. Drop it in the comments and I’ll tell you which layer I’d look at first.

If you want to build the layers from scratch, the companion piece walks through all three — what goes in each document, the prompts to create them, and what done looks like.

Five Tabs, Three Failed Dashboards, and One Decision

I had five tabs open every morning. Gmail for personal. Gmail for the business. Google Calendar. Google Tasks. And a Notion dashboard I’d built three different times — each version more organized than the last, each one quietly abandoned within weeks.

The data organization in Notion was solid. I’d give it that. But the UI never worked for me, and “organized” doesn’t matter if you stop opening it. Some days it was a forgotten wasteland.

Meanwhile, the real work — triaging two inboxes, checking what’s on the calendar, figuring out what actually matters today — was scattered across tabs I had to manually stitch together every morning. That daily stitching was bogging me down and stressing me out.

Before: five tabs, Notion ignored.
After: one dashboard, one rhythm.

I didn’t need another productivity system. I’d tried that. What I needed was something tailored. Built around how I actually work, pulling from the tools I was already using, structured around my energy and my priorities. Not someone else’s template.

So I built it. Using Claude, Claude Code, and Cursor, I built an AI Chief of Staff dashboard that does what no off-the-shelf tool could: sees everything in one place and helps me structure my day around it.

I’m a developer. I could have mapped this out the traditional way — architecture docs, wireframes, weeks of planning before writing a line of code. But that’s exactly the cycle I wanted to break.

What an AI Productivity Dashboard Actually Does

It connects to the tools I’m already using — two Google Workspace accounts, Google Tasks, Google Drive and eventually Notion — and pulls everything into one screen. Email counts from three sources. Today’s calendar. Tasks. Brain dump notes I’ve captured throughout the day.

Then the AI does the part I used to do manually: it builds my rhythm.

“Build My Rhythm” looks at all of that context — commitments, emails, tasks, my top five priorities for the week, appointments, brain dump notations. Then it generates time-blocked working sessions for the day. Not a task list. Not a project plan. Rhythm blocks. Each one has a purpose, a start time, and an end time. Mode-based, not checklist-based.

Think of it like a chief of staff who reviewed your calendar, scanned your inboxes, checked your priorities and handed you a structured day before your first cup of coffee. Except it costs pennies a day and runs on Claude’s API (an API is just a way for one app to talk to another — in this case, the dashboard asks Claude to think through your day and send back the plan).

The goal wasn’t another task list that would fade away. It was to use my best work times and workflows to structure my day.

Why Generic Productivity Tools Keep Failing

Here’s the pattern I keep seeing — in my own attempts and in conversations with other creators.

You find a tool that’s almost right. Notion’s data organization is genuinely good. Google Workspace handles email and calendar well enough. So you try to make them work together.

You build a Notion dashboard. You set up filters. You create views and databases. And for a while, it feels like progress.

Then you stop opening it.

Not because the system was bad. Because it wasn’t yours. It was someone else’s structure, with your data poured into it. The friction was just high enough that on a busy morning, you’d skip it. And once you skip it twice, it’s over.

My friend hit the same wall. She liked Notion’s organization — same as me — but not the UI or the usability. Someone else’s system almost worked. So she built her own dashboard to solve it.

That’s the part most people miss. The problem isn’t discipline. It’s fit. Generic tools assume a single inbox, a single calendar, and a single way of working. I have two email accounts, newsletter folders, weekly priorities that live in a different system and brain dumps that need to feed into how I plan my day. No off-the-shelf tool handles that — because it wasn’t designed for my workflow.

The problem isn’t discipline. It’s fit.

How I Built a Custom AI Dashboard in Days

I didn’t follow a roadmap. I followed a pattern that kept repeating: figure out what I need, keep what’s already working, and let AI handle the parts I don’t want to spend weeks on.

Step 1: Define what your day actually needs.

Before I touched any code, I mapped out what was stressing me out. Three email sources that needed triaging every morning. A task list of must-dos. The five things I want to accomplish each week to move my business forward. My calendar commitments. And a place to capture ideas throughout the day without breaking flow.

That’s it. Not a feature list — a friction list. What’s slowing me down? What am I forgetting to check? What keeps falling through the cracks?

Step 2: Keep what works. Replace what doesn’t.

Google Workspace was working: email, tasks, docs, calendar. I wasn’t going to replace those. Notion’s data organization was working. I wasn’t going to abandon that either. What wasn’t working was the layer on top: the thing that pulls it all together and makes it usable.

So the dashboard became a lens, not a replacement. It connects to Google’s APIs and shows me unread counts across all three email sources with “Triage →” links that open the right Gmail label. It pulls calendar events from both accounts. It reads my tasks.

Quick Capture writes brain dumps straight to Google Drive with auto date headers and a “Captured Today” count.

The tools stay. The view changes.

Step 3: Let AI build it — and design it.

This is where it got interesting. I saw Kim Doyal’s dashboard and loved the layout— clean and easy to navigate. That was my missing visual reference. So I uploaded a screenshot to Claude and asked it to help me write the proper prompt for how it should be coded.

Claude handled the reasoning and planning. Claude Code wrote the application code. Cursor kept everything in one workspace while I worked. The Claude API powers the daily rhythm generation: “Build My Rhythm” sends all my dashboard data to Claude and returns a structured day, color-coded by category.

Here’s what it actually took: a code editor, a hosting platform, and API access. That’s the infrastructure. The thinking is the part only you can do. What do I need? What’s already working? What should the day look like?

The AI handles the technical translation. You bring clarity to your own workflow.

I went from concept to a working dashboard in days, not weeks. Not because I skipped the hard parts — because the hard part was knowing what I needed. And I already knew that.

Tailored means yours. Your dashboard won’t look like Kim’s or mine. It shouldn’t.

What Building Your Own Dashboard Actually Takes

If you’ve ever written a brief for a contractor — “here’s what I need, here’s how I work, here’s what matters” — you have the skills this takes.

Building a tailored dashboard isn’t a coding exercise. It’s a clarity exercise. Once you know what you need — your inputs, your workflow, your priorities — AI walks you through the build. Step by step. Clear instructions. Each piece connects to the next. Think of it less like programming and more like following an SOP that gets written for you as you go.

Claude, Claude Code and Cursor handle the technical translation. You follow the steps.

What they can’t do is tell you what your morning needs to look like. They can’t decide that you need to triage three email sources before your first creative block. They can’t know that your best thinking happens before noon, or that your weekly priorities need to be visible while you plan your day.

That’s the work. And it’s work you’ve already done — you just haven’t written it down in a way that becomes a system.

The scary part isn’t the technology. The scary part is admitting that the tools you’ve been using aren’t working and committing to something built around how you actually operate. Once you make that decision, the build is the easy part.

Key Takeaways

If you take away only five things from this, make them these.

1. The problem isn’t discipline — it’s fit. If your productivity system keeps becoming a forgotten wasteland, it’s not because you’re lazy. It’s because it wasn’t designed around how you actually work.

2. Start with your friction list, not a feature list. What’s slowing you down? What are you forgetting to check? What keeps falling through the cracks? That’s your blueprint.

3. Keep what works. Replace what doesn’t. You don’t need to abandon Google Workspace or Notion. You need a better layer on top — a lens that pulls it all together.

4. AI makes the build accessible — but only you can define the need. The technical parts are handled. The hard part is knowing what your morning, your workflow, and your priorities actually require.

5. Tailored isn’t one-and-done. Your solution keeps evolving because your work does. Phase 1 ships. Phase 2 fixes and automates. The system grows with you.

The Cost of Staying Scattered

Here’s what staying in the cobbled-together setup actually costs you.

Every morning you spend stitching tabs together is a morning you’re not doing the work that moves things forward. Five minutes here, ten minutes there — checking this inbox, switching to that calendar, opening a Notion page you haven’t touched in a week. It adds up.

Not just in time, but in mental load. By the time you’ve assembled the picture of your day, you’ve already burned through your best energy figuring out what to do instead of doing it.

And every system you’ve abandoned? That wasn’t a failure of discipline. That was a signal. The tool didn’t fit, so you moved on rather than forcing it. The problem is that “moving on” usually means moving to another generic option that will hit the same wall.

That’s the real cost. Not the wasted setup time.

The slow bleed of mornings that never quite start right. The weekly priorities that drift because they weren’t visible when you were planning. The brain dump ideas that never fed back into your rhythm because they lived in a different tool.

You already know what you need. The question is whether you keep adapting to tools that weren’t built for you — or build something that was.

Start With Your Friction List

When nothing fits, build it.

That’s not a slogan. It’s what I did when three versions of Notion dashboards failed. It’s what Kim did when she hit the same wall. And it’s what the tools — Claude, Claude Code, Cursor — are making possible for anyone willing to start with one question: What does my day actually need?

My dashboard pulls from two email accounts, Google Tasks, Google Calendar, Google Drive and soon Notion. It generates rhythm blocks based on my energy, my priorities, and my commitments. Yours won’t look anything like that. It shouldn’t.

Maybe yours needs to surface client deadlines alongside your content calendar. Maybe it needs to track invoices and project status in one view. Maybe it’s simpler — just your top three priorities and today’s calendar, visible the moment you open your browser.

Whatever it is, it starts with your friction list. What’s not working? What are you stitching together every morning? What keeps getting ignored?

I’m still building. Now that Phase 1 is shipped, it’s time to test and find the parts that aren’t quite right. I can already see a few tiny adjustments before I move on to Phase 2, the automation layer that will make it a true chief of staff. Tailored isn’t one-and-done. It evolves because the work does.

If you’re sitting on a version of this problem — tools that almost work, systems you keep rebuilding, mornings that start scattered — I’d love to hear what your friction list looks like. Reply and tell me what’s not working. That’s where it starts.

And if you want help figuring out what your tailored solution could look like, book a quick session and we’ll cut through the noise together.