Drafts as Hub- How AI Helped Me Connect Five Apps on iPad -Part 4
What broke, what I compromised on, what I built and never use.
If you’ve made it this far in the series, you’ve seen the version of my workflow that works. The Daily Log that hits three destinations with one tap. The Cloudflare Workers that let my iPad reach services it shouldn’t be able to. The morning briefing that reads my day to me through AirPods. It all sounds clean and intentional when I describe it in sequence.
This part is about the mess behind that. What broke, what I compromised on, what I built and never use, and what still isn’t solved. I think this might be the most useful part of the series because anyone building something like this will hit the same walls, and knowing where they are saves time.
The Meeting Notes Problem
Meeting notes were the workflow that humbled me. The idea was straightforward - I capture meeting notes in Notion during the meeting, and then the system syncs those notes to Apple Notes and Obsidian so I can access them from any device. Same multi-destination philosophy as everything else in this series.
I started building this in Drafts. Five actions and two Shortcuts. The logic wasn’t that different from my Daily Log or Weekly Note actions - capture content, format it, route it to multiple destinations. But meeting notes are structurally more complex than daily bullets. They have agendas, meeting notes sections, and AI-generated meeting summaries. The formatting requirements for each destination are different. And unlike my other actions where I’m the one triggering them manually, I wanted the meeting note sync to run automatically every weekday morning.
The rest of this article is for paid subscribers. If you want the honest breakdown of what broke, what compromises I’m still living with, and what I’d tell someone before they build a system like this, subscribe below.
It got too complex for Drafts. Not because Drafts couldn’t handle the individual pieces, but because the orchestration of five actions and two Shortcuts interacting with each other became brittle in ways I couldn’t debug easily. So I moved it.
The meeting notes workflow now runs as Python scripts on my MacBook with shell schedulers handling the timing. The scripts pull from Notion’s API, format the content for each destination, and push to Obsidian and Apple Notes. It works. The notes sync, the formatting is right, and I can access my meeting notes from whatever device I’m using.
But it’s not without its own problems.
Apple Notes: The Permanent Compromise
Apple Notes has no API. I’ve said this multiple times in this series, and every time I say it I get a little more frustrated because it’s the single biggest limitation in my entire workflow. The only automated path into Apple Notes is through Shortcuts, and Shortcuts has its own set of problems.
The meeting note Shortcut that runs every weekday morning is buggy. It randomly asks for permission to access Apple Notes even though I’ve already granted it. Sometimes it fails silently and I don’t realize a note wasn’t created until I go looking for it on my iPhone. When that happens I have to re-run the Shortcut manually, which defeats the purpose of automating it in the first place.
And even when the Shortcut works perfectly, there’s a formatting gap I haven’t been able to close. Apple Notes uses rich text internally, and no matter what I do, the content that gets shared from my Python scripts arrives as plain text. The bold headers, the structured sections, the formatting that makes notes scannable - all of it gets flattened. The information is there, but it doesn’t look the way it does in Notion or Obsidian. Yes, I’m aware that Apple made a big deal about implementing markdown formatting for Apple Notes. But, in practice, it only works if you use the manual “markdown import” feature. Another way Apple provides support yet still makes it harder when doing things outside of their ecosystem.
It just works. Only when Apple feels it’s worth implementing, but I digress.
I’ve accepted this. Apple Notes is still valuable as the mobile access point for my meeting notes because having plain text notes on my iPhone is better than not having them at all. But it’s a compromise, and I want to be honest that it’s one of the rough edges I haven’t smoothed out.
The MacBook Problem
Here’s the thing about moving the meeting notes workflow to Python scripts on my MacBook - it works, but it means my MacBook needs to be running. Always. The shell schedulers that trigger the sync scripts need a powered-on machine to execute.
Right now, that’s what I’m doing. My MacBook stays on, the scripts run on schedule, and the notes sync. It’s fine. But it violates the core principle that motivated this entire project - the ability to switch between any device and have everything just work. Having one device that has to stay running to keep the system functioning is exactly the kind of dependency I was trying to eliminate.
In an ideal scenario, those Python scripts would run on a cloud service the way my Cloudflare Workers do. No dependency on a specific device being powered on. I could move between my iPad, my iPhone, and my MacBook without worrying about whether the sync was running. I haven’t built that yet. It’s on the list. For now, the MacBook stays on and I live with the compromise.
The Graveyard of Actions I Don’t Use
I want to be honest about something else. I built a lot of Drafts actions over the course of this project. House project templates, travel planning notes, pet care logs, various experiments with routing content to different combinations of apps. I was on a roll. AI was writing the code, testing was going well, and every new idea felt like it was just one conversation away from being a working action.
Most of those actions sit in Drafts unused.
Not because they don’t work - they do. The code runs fine. The routing works. But there’s a difference between building something because you can and actually needing it in your daily workflow. The house project template was useful exactly once. The travel planning action was clever but I’ve only traveled twice since I built it. Some of the experimental actions were proof-of-concept exercises that proved the concept and then had nowhere to go.
I probably need to do a proper review of everything I’ve created. Go through the full list of actions, figure out which ones I actually run regularly, which ones I could improve, and which ones I should just archive. That’s a project for a few months from now when the system has had more time to settle into its real daily shape rather than the shape I imagined when I was building it.
This is the part of productivity system building that nobody talks about. The building phase is exciting. Describing what you want to an AI, testing the result, fixing bugs, deploying something that works - that’s a rush. But the maintenance phase is different. It’s quieter, less glamorous, and it requires a kind of honesty about what you actually use versus what you thought you’d use. I’m not fully there yet.
The 200 Lines of JavaScript I Can’t Read
I mentioned in Part 2 that the Notion API integration requires a markdown-to-blocks parser that’s about 225 lines of JavaScript. I want to revisit that here because it represents a broader tension in this whole project.
I can’t read that code. Not really. I can look at it and understand the general shape - here’s where it parses bold text, here’s where it handles links, here’s where it builds the block array - but if something broke in the middle of the parser, I couldn’t fix it myself. I’d have to go back to Claude, describe the bug, and wait for a fix.
So far that hasn’t been a problem. The parser works. But I’m aware that I’ve built a system with components I can’t maintain independently. That’s a real risk. If the Notion API changes how it expects blocks to be formatted, I need AI to update the parser. If Drafts changes how its HTTP object works, I need AI to update the actions. I’m not the mechanic. I’m the driver who can describe exactly what’s wrong with the car but can’t open the hood and fix it myself.
For now, that tradeoff is worth it. The alternative was not building any of this and continuing to manually copy text between five apps. I’ll take “works great but I need help maintaining it” over “doesn’t exist” every time. But I want to name the tradeoff because I think anyone considering building something similar should understand it going in.
I also want to be clear I built these for me. No one else. I am sharing my journey so you can hopefully learn from my mistakes and see what works for you.
What I’d Tell Someone Starting This
If you read this series and you’re thinking about building something similar, here’s what I’d want you to know.
Start with the action you’d run most often. For me that was the Daily Log. Get one action working end to end before you build the next one. The patterns you establish in that first action - the template tag bridge, the Shortcuts handoff, the error handling - become the foundation for everything else.
Accept that some things won’t work where you want them to. I wanted everything to run from my iPad. Meeting notes had to move to my MacBook. That’s fine. The goal isn’t ideological purity about which device does the work. The goal is that the information ends up where you need it.
Build more than you need at first, then prune. I don’t regret building actions I don’t use. Each one taught me something about how Drafts works, how APIs behave, or how to describe what I want to AI more clearly. The unused actions aren’t failures. They’re practice. But don’t confuse practice with production. Eventually you need to be honest about what actually earns its place in your daily workflow.
And be honest about the maintenance question. You’re building something you probably can’t maintain alone. That’s okay as long as you know it. AI isn’t going anywhere, and the describe-test-fix cycle works as well for maintenance as it does for initial building. But if you pretend you understand the code when you don’t, you’ll make bad decisions when something breaks.
The exciting thing about where we are currently with AI is it’s allowing those of us who can’t code to code. At the same time, there’s extreme risk when you don’t know what you’re doing. There are already posts in the wild of AI deleting entire projects because people gave it full permission without considering the consequences.
And don’t get me started on OpenClaw: a vibe-coded AI agent that everyone jumped on without thinking. Within weeks of going viral, security researchers found one-click remote code execution exploits, over 42,000 exposed control panels, and hundreds of malicious plugins in its marketplace. It was a security nightmare. And the ending? OpenAI acqui-hired the founder and the project moved to a foundation. Ship fast, break everything, get rewarded anyway.
There’s that Spider-Man phrase: “With great power comes great responsibility.” I wonder how bad it will get before someone says, “Oh shit,” again.
Where This System Is Now
My workflow runs every day. The Stoic Reflection prompts ground my morning and evening. The Daily Log captures everything and routes it to three places with one tap. The Weekly and Monthly notes keep me reflective on longer timescales. The Cloudflare Workers extend my iPad’s reach to services it couldn’t touch on its own. The Morning Briefing synthesizes my day before I’ve looked at a screen. Todoist orchestrates the timing of all of it.
It’s not perfect. Apple Notes formatting is still compromised. My MacBook has to stay on for meeting note syncing. I have actions I don’t use and code I can’t read. The system grew faster than my ability to maintain it, and at some point I need to slow down and clean house.
But it works. And I built it - all of it - without writing a single line of code myself. I described what I wanted, tested relentlessly, fixed what broke, and accepted the compromises I couldn’t avoid. That’s the whole story. Not just the parts that look impressive, but the parts that are still messy and unfinished and real.
That feels right for a series about productivity. The whole point of building a system is to get out of your own way. Mine does that most of the time. And the rest of the time, it reminds me that the work is never actually done.
That’s the full series. Four parts, from the philosophy behind using five apps to the honest accounting of what broke along the way. Let me know what you want to adjust.