I Was Ready to Burn It Down. I'm Glad I Didn't.
How to tell whether a system is outgrown, ill-fitting, or just needs a tune — and why most of what you've labeled 'outgrown' isn't.
I’ve read a lot of articles about the 5 a.m. ritual. The ice-cold shower. The ten things you have to do before you do anything else to become productive.
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.
✳︎ ✳︎ ✳︎
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
✳︎ ✳︎ ✳︎
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:
“This is one of my daily tasks using a skill in Claude but something is off with it. It’s like a chore to run it. Can you help me sort it?”
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:
“I want to focus on the month-end and quarter reviews from weekly recaps, but there’s so much reference to everything else. I don’t know if this belongs here or if it’s already decided for me.”
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.
Continue the conversation:
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.
I’ve definitely blamed the tool or the system when the real issue was that I built it around someone else’s way of working.
The inherited template point is the part I keep coming back to. We pick up these ideas of what a workflow, review, or database is supposed to look like, then wonder why it feels like a chore.
“What is this supposed to protect?” is the question I’d steal from this. That gets past the productivity theater pretty fast.