You Don't Need To Know How It Works
The real barrier to consistent creation isn't knowledge - it's friction
I don't know how APIs work.
I mean, I sort of know. I can explain the concept in a way that would make a developer wince.
But the technical details? The actual mechanics of data passing between servers?
Completely over my head.
And yet, this morning I sent a three-minute voice note to Telegram from my phone.
That voice note got transcribed, fed into an AI newsletter writer that pulls style guidance from a vector store of writers I admire, converted to HTML, given a title, transformed into a Google Doc, and sent to me as a Telegram preview.
When I approve it, it schedules automatically to Substack.
The whole thing took about an hour to set up.
I have no idea how half of it actually works.
But what I do know is that friction is the only thing that actually matters.
The Lie We Tell Ourselves About Expertise
We've convinced ourselves that understanding equals capability. That you need to comprehend the underlying mechanisms before you can leverage them.
It's bullshit.
You don't need to understand internal combustion to drive a car.
You don't need to know TCP/IP protocols to send an email.
And you don't need to be able to code an API from scratch to use one.
The real skill - the one that separates people who build things from people who talk about building things - isn't technical knowledge.
It's tenacity.
It's knowing the right questions to ask.
It's being willing to pull information from different sources and feed it to tools that can do the heavy lifting.
I gave Claude Code all the information it needed about Substack's unofficial API.
I told it I wanted to host it on Railway. It walked me through every step.
When something didn't work, I described the error, and it told me how to fix it.
The whole time, I was maybe 30% sure what I was actually doing.
But here's the thing - it doesn't matter.
The Friction Thesis
There's this idea floating around productivity circles that motivation is unreliable and systems are everything. That's partially true, but it misses the deeper point.
Systems don't work because they're clever. They work because they remove friction.
Every point of friction is a decision point. Every decision point is an opportunity to quit. String enough of those together, and you're guaranteed to stop doing the thing you said you wanted to do.
Want to write daily? Great. Now ask yourself:
• Do you have to open a blank document? • Do you have to think about formatting? • Do you have to manually publish? • Do you have to remember to do it?
Each one of those is a place where future-you can say "eh, maybe tomorrow."
The real trick to regular content creation - or doing anything regularly - isn't discipline. It's making the thing so frictionless that NOT doing it feels harder than doing it.
I can now publish a newsletter by talking to myself in the morning and tapping a button in Slack. The friction went from "sit down, open laptop, stare at blank page, wrestle with words, format, upload, schedule" to "record voice note, tap approve."
What do you think I'm more likely to do consistently?
The Tools Are Already Here
You can do absolutely anything you want these days if you just know the correct tools.
That sentence sounds like hype. Like one of those "change your life with this one weird trick" lines. But it's actually just... true.
• N8n connects things. • Claude and other AI coding assistants write code. • Railway hosts it. • Vector stores remember context. • APIs talk to each other. • Voice transcription turns thoughts into text.
All of these tools exist. Most of them are free or cheap. All of them are accessible to someone who doesn't have a computer science degree.
The barrier isn't technical anymore. The barrier is:
• Knowing the tools exist • Being willing to look stupid while learning them • Having enough tenacity to push through the inevitable "this isn't working" moments • Asking the right questions instead of trying to understand everything
I spent an hour fumbling around with APIs I barely understood, feeding error messages to an AI assistant, following instructions I only half-comprehended. And now I have a system that turns my morning brain dumps into scheduled Substack posts.
The alternative was continuing to "wait until I had time to write properly" - which meant writing once a month if I was lucky.
Whether Anyone Wants To Read It Is Another Thing
I can now consistently produce nearly-daily posts about whatever I'm thinking about.
But do people actually want to read them?
Maybe not. Probably not, if we're honest.
But when it comes to creation, consistency is the foundation that everything else builds on.
You can't improve what you don't ship. You can't find your voice if you only speak once a month. You can't build an audience if you disappear for weeks at a time.
The quality question is important. But it's step two. Step one is always: can you actually do the thing regularly?
Most people never make it past step one. They're still stuck optimizing their process, waiting for the perfect moment, convincing themselves they need to understand more before they start.
Meanwhile, someone else is shipping. Learning. Iterating. Getting feedback. Building an audience not because they're better, but because they showed up.
The friction-removal approach flips this. Instead of relying on motivation to overcome resistance, you remove the resistance. Then consistency becomes the default, not the achievement.
The Real Power Of The Stack
My setup is kind of absurd when you think about it:
Telegram receives the voice note
N8n orchestrates the workflow
OpenAI’s Whisper API converts speech to text
A Supabase vector store trained on writers I like informs the style
Claude writes the newsletter
Another process converts it to HTML and creates a title
Google Docs stores the draft
Telegram notifies me for approval
The Substack API (that I'm somehow self-hosting despite not really understanding how) schedules the post
It's a Rube Goldberg machine of modern creation tools.
But that's exactly the point. Each tool does one thing well.
The magic is in connecting them - and you don't need to understand the internals of each component to make the connections.
You just need to know:
• What you want to accomplish • What tools might help • How to ask for help when you're stuck • When to keep pushing vs when to try a different approach
That's it. That's the whole skill set.
Your Three-Minute Voice Note
This whole newsletter came from a three-minute voice note. I was probably walking around my house, talking to myself about this system I'd just built, processing the slight disbelief that it actually worked.
In the past, that thought would have evaporated.
Maybe I'd have jotted down "write about friction removal" in a note that I'd never look at again.
Maybe I'd have meant to write it up "this weekend when I had time."
Instead, it became this. Automatically.
With about two minutes of approval time on my end.
That's not me bragging about the system. It's me pointing out that the distance between thinking something and sharing it can be a voice note and a button press.
What could you ship if that was your baseline?
If the act of having a thought and publishing it was nearly frictionless?
Not all of it would be good. Some of it would be half-baked. But some of it - maybe just 10% - would connect. Would resonate. Would be the thing that makes someone think "oh, I should try that."
And you'd never know which 10% it would be unless you shipped all of it.
The Question Isn't "How Does This Work?"
The question is: what am I not doing because there's too much friction?
What newsletter aren't you writing because opening a blank page feels too heavy?
What product aren't you building because the technical requirements seem too complex?
What creative project is sitting in your head because the gap between idea and execution is too wide?
Now ask: what tools exist that could narrow that gap?
You don't need to build the tools. You probably don't even need to understand them deeply. You just need to know they exist, be willing to fumble around with them, and be tenacious enough to push through the "I have no idea what I'm doing" phase.
That phase doesn't last as long as you think. And on the other side is something that just... works. Even if you can't quite explain how.
Start With One Friction Point
You don't need to build my entire system. You probably shouldn't - it's custom to my specific workflow and neuroses.
But you can identify one friction point in something you want to do regularly. One place where resistance lives.
Then ask: what tool could remove this?
• Using voice notes instead of typing • Setting up a template so you don't start from blank • Automating the publishing step • Creating a system that reminds you instead of relying on memory
Start there. Remove one point of friction. See what changes.
Then remove another.
Pretty soon you'll have built something that looks complex from the outside but feels effortless from the inside. You might not understand every component. You definitely won't be able to explain it to a developer without them cringing.
But it'll work. And you'll ship.
And that's the only thing that actually matters.
The invitation
Find your biggest friction point.
The one thing that consistently stops you from doing what you said you wanted to do.
Then spend an hour - just one hour - being tenacious about finding a tool that could remove it.
You might be surprised what you can build when you stop trying to understand everything and start focusing on removing the resistance between intention and action.
Now if you'll excuse me, I need to go send a voice note.



