Kira: Someone in our Slack asked me last week — "How do you manage client deliverables when you're literally never awake at the same time as your clients?"
Santi: You don't. That's the whole point.
Kira: Right, but seriously — she's in Bali, her biggest client's in New York, her contractors are spread across Eastern Europe and Latin America. She's waking up to forty-seven Slack messages every morning, half of them are "urgent," and by the time she responds, the client's already asleep again.
Santi: And she's probably doing what everyone does — trying to be online twenty hours a day, setting alarms for client calls at three AM, burning out in paradise.
Kira: I did that. My first year nomading, I had this fintech client in Sydney. I was in Guatemala. Every single touchpoint required me to either stay up until two AM or wake up at five. I lasted exactly six weeks before I fired them.
Santi: You fired an MRR client because of time zones.
Kira: I fired a two-thousand-dollar-a-month client because I was trying to run synchronous ops across a sixteen-hour time difference. Which was stupid, because the actual work — content audits, AI workflow setup, deliverable packaging — none of that needed real-time communication.
Santi: None of it. Look — here's what actually happened when I fixed this. I went from spending twelve hours a week in client coordination to spending ninety minutes. Same number of clients. Better delivery scores. And the entire system runs whether I'm online or offline, whether I'm in Lisbon or whether I'm on a boat with no signal.
Kira: Okay but here's what you're not considering — most people hear "async delivery" and think it means slower delivery. Like you're trading speed for flexibility.
Santi: No! It's faster! When you have intake forms auto-creating scoped tasks, contractors getting auto-assigned based on their time zones and skills, AI doing the QA before anything ships — the work moves twenty-four seven. Your client submits a request at midnight their time, by the time they wake up, it's already in progress.
Kira: Without a single Slack notification waking you up at four AM.
Santi: By the end of this episode, you'll have a complete AI client delivery system — intake forms that auto-scope work, timezone-aware task routing, AI-powered QA checks, and weekly status packs that send themselves at nine AM client time. All running while you're offline.
Kira: We're shipping two full stacks with exact pricing, the prompts for AI status generation, and the fallback plan for when your OAuth tokens expire mid-flight.
Kira: The problem isn't actually time zones. The problem is that we're trying to run twenty-first century businesses with twentieth century communication patterns.
Santi: Slack is synchronous by design.
Kira: Slack is chaos. I mean, imagine you're running five active client projects. Each client expects responses within a few hours. Your contractors need answers to keep working. Everything feels urgent because everything's in the same channel with the same red notification badge.
Santi: And you end up being the bottleneck. Every decision, every clarification, every approval — it all routes through you because you haven't built the system to run without you.
Kira: So let's fix that. And we're going to start with something GitLab figured out years ago — if you want true async operations, documentation has to be your single source of truth. Not Slack threads. Not email chains. Not "hey, what did we decide about this?" messages at two AM.
Santi: GitLab runs a two-thousand-person company with zero required meetings. Zero. Their entire engineering AI team does weekly async updates using a template — date, risks, blockers, progress. No status calls. No check-ins. Just written updates that anyone can read anytime.
Kira: And here's the important part — they don't just document decisions. They document the context around decisions. Why they chose option A over option B. What constraints they were working with. So when someone joins the project three months later, they don't need a two-hour onboarding call.
Santi: This is exactly what we're building today. A system where every client request flows through a predictable pipeline — intake, scoping, assignment, execution, QA, delivery, documentation. And each step can happen without you being online.
Kira: Let me paint the picture of what this actually looks like. Tuesday morning, you wake up in Mexico City. Your client in Singapore submitted a request for a new AI workflow eight hours ago while you were sleeping. By the time you open your laptop, the request has already been scoped into three subtasks, assigned to your contractor in Poland who's been working for the last four hours, and the first deliverable is already in QA.
Santi: The client got an auto-confirmation when they submitted. They'll get their weekly status pack at nine AM their time — which is Tuesday evening for you. And you haven't touched any of it.
Kira: You haven't touched it, but you can see everything. Every decision is logged in Notion. Every task has a clear owner. Every deliverable has a QA checklist. The system is transparent, traceable, and it runs without you.
Santi: Okay, let's look at the actual numbers here. Stack A — the low-code version using tools most of you already have. Tally for intake forms, Notion for project management, Slack for comms, Zapier to connect everything.
Kira: Tally's free tier actually works fine for this, but let's assume Pro at twenty-four dollars a month for the custom domains and advanced logic. Notion Plus for two users — twenty dollars. Slack Pro for three people — twenty-two dollars. Zapier Professional — twenty dollars. We're talking about, what, eighty-six dollars a month base cost?
Santi: Eighty-six dollars to run five active clients with near-instant intake processing. Because here's the thing — Zapier's webhook triggers are instant. Not polling every fifteen minutes like the free tier. Instant. Client submits the form, webhook fires, Notion task gets created, Slack notification goes to the assigned contractor. Under sixty seconds end-to-end.
Kira: Under sixty seconds assuming Notion's API doesn't hit rate limits.
Santi: Three requests per second average. That's Notion's limit. So yes, if you're processing fifty forms simultaneously, you'll hit issues. But for normal operations — five to ten clients, maybe twenty requests a day — you're fine. Build in exponential backoff just in case.
Kira: And this is where people usually mess up. They build the happy path — form to task to notification — but they don't build for failure. What happens when Zapier can't connect to Notion? What happens when your OAuth token expires? What happens when—
Santi: When Slack's API returns a 429 because you tried to schedule forty messages in five minutes?
Kira: Exactly. Slack has limits. Thirty scheduled messages per five-minute window per channel. A hundred and twenty days maximum schedule-ahead. These aren't suggestions — hit them and your automation breaks.
Santi: So you build with limits in mind. Queue messages. Spread them out. Use different channels for different message types. And — this is critical — always have a manual fallback.
Kira: Let's talk about the human layer, because this is where async delivery actually succeeds or fails. You need three things: clear roles, explicit SLAs, and what Doist calls "vacation mode" expectations.
Santi: Doist makes Todoist. Fully remote, fully async. They built a feature into their internal tools that literally shows when someone's unavailable — not just "away" but "do not expect a response." It changes how people communicate. Instead of "hey, quick question," it becomes "when you're back, could you..."
Kira: And that mental shift is everything. Your clients need to know that immediate responses aren't the default. Your contractors need to know they can work their own hours without apology. And you need to know that taking a day offline won't break anything.
Santi: Here's what we do — every message gets tagged with a response tier. Tier one: actual emergencies, production is down, client can't access their system. Four-hour response SLA. Tier two: blocking issues, contractor needs clarification to continue. Twenty-four-hour SLA. Tier three: everything else. Forty-eight to seventy-two hours.
Kira: And you publish these SLAs. Put them in your contracts. Put them in your onboarding docs. Put them in your email signature. Because the moment a client knows what to expect, they stop treating everything as urgent.
Santi: 37signals has this beautiful line in their communication guide — "Real-time sometimes, asynchronous most of the time." They default to long-form written updates attached to the actual work. Not floating in Slack. Not buried in email. Attached to the project, where anyone can find it.
Kira: Which brings us to the weekly status pack. This is the heartbeat of async delivery. Every Tuesday at nine AM client time, they get a comprehensive update. What got done, what's in progress, what's blocked, what decisions need their input.
Santi: And here's where AI changes everything. Generating these status packs used to take me two hours every Monday. Now? Six cents. Six cents of GPT-4o mini tokens to synthesize a week of Notion tasks, pull out the highlights, flag the risks, and format it for Slack.
Kira: Walk me through the actual prompt.
Santi: Simple. You feed it three things — completed tasks with titles and owners, any logged decisions, and links to deliverables. The prompt says: "Synthesize a weekly client update. Include overall status — green, yellow, or red with one-sentence reason. Three to five shipped items with links. Top three risks if any. Next steps. Keep it under one hundred eighty words, no emojis."
Kira: No emojis.
Santi: No emojis. Professional, scannable, actionable. The AI draft takes thirty seconds. Human QA takes maybe ninety seconds. Compare that to writing from scratch — five minutes per artifact minimum.
Kira: So for three clients with five deliverables each, you're saving over an hour per week just on status updates. At typical agency rates, that's a hundred-fifty to two hundred dollars of time saved. Every week.
Santi: Now let's talk about Stack B — the code-first approach. This is for when you need more control, lower variable costs, or when you're running more than ten active clients.
Kira: The architecture's different here. Instead of Zapier connecting everything, you're running n8n on a six-dollar DigitalOcean droplet. Supabase for your database at twenty-five dollars a month. Still using Notion and Slack for the interfaces, but now you're hitting their APIs directly.
Santi: The beauty of n8n is the timezone handling. You can set each workflow to run in the client's timezone. No math. No "wait, is it DST in New York but not in Phoenix?" nonsense. You just set the workflow timezone to "America/New_York" and your Tuesday nine AM trigger fires at Tuesday nine AM New York time.
Kira: Even when you're in Bali and have no idea what time it is in New York.
Santi: Exactly. And because you're self-hosting, you're not paying per operation. That six-dollar VPS can run hundreds of workflows. Thousands of operations. Your only variable cost is the API calls themselves.
Kira: Let's see the data flow. Client fills out your intake form — you can still use Tally or build your own with Supabase. Webhook hits your n8n instance. n8n writes to Supabase, creates the Notion tasks, checks contractor availability, assigns based on skill match and timezone, sends the Slack notification, and logs everything.
Santi: But here's what's different from Zapier — error handling. In n8n, you can build a completely separate error workflow. If any step fails, instead of just stopping, it triggers your error handler. That can retry with backoff, log to a different system, notify you directly, or even fall back to a manual process.
Kira: Show me a real failure scenario.
Santi: OAuth token expires. Happens all the time. Your automation tries to create a Notion task, gets a 401 invalid grant error. In Zapier, the Zap just fails. Maybe you get an email. In n8n, your error workflow catches it, pauses the main workflow, sends you a notification with a re-auth link, and queues the task for retry once you've reconnected.
Kira: And the client never knows there was an issue.
Santi: The client never knows. Their request is still processed. Maybe it takes four hours instead of four minutes, but it happens. No "sorry, our system was down" emails. No emergency fixes at two AM.
Kira: This is what I mean by building for resilience. Every integration will break eventually. APIs change. Rate limits hit. Tokens expire. The question is: does your system handle it gracefully, or does everything catch fire?
Santi: Let's talk about the actual code for a second. The research doc included a Node.js script for generating and scheduling these status packs. It's maybe fifty lines of actual logic. Pulls tasks from Notion, formats them, calculates the next Tuesday at nine AM in the client's timezone, and schedules the Slack message.
Kira: Fifty lines to replace a two-hour weekly task.
Santi: Fifty lines. And once it's running, it just... runs. Every week. Every client. Perfect timing. No manual work. The only human touchpoint is the QA check before it sends.
Kira: And this is the important part — you still need that human QA. AI can summarize tasks and format updates, but it can't read the room. It doesn't know that the client just had a bad quarter and mentioning budget overruns would be poorly timed. It doesn't know that deliverable three is technically done but you're not happy with the quality yet.
Santi: So we use what I call "AI-first, human-final." AI does the heavy lifting — gathering data, formatting, initial draft. Human does the judgment call — is this accurate? Is this appropriate? Is this what the client needs to hear right now?
Kira: It's the same principle for the whole delivery system. Automation handles the repetitive parts — intake, routing, scheduling, formatting. Humans handle the creative parts — strategy, problem-solving, relationship management.
Santi: Let's run through some edge cases, because this is where most async systems break. DST changes. Your client's in New York, you're in Lisbon, and suddenly their nine AM Tuesday update shows up at ten AM because one of you switched to daylight saving and the other didn't.
Kira: The worst.
Santi: The fix is simple but not obvious. Always store and calculate times in the client's timezone, not yours. Don't try to do timezone math yourself. Use a library like Luxon or Moment that handles DST transitions. And test it. Actually test it. Set your system clock to the day before DST and make sure your scheduled messages still fire correctly.
Kira: Another edge case — the client who doesn't actually want async. They say they do, they sign the contract with the SLAs, but then they're sending "urgent" messages every day expecting immediate responses.
Santi: You train them out of it. First week, you respond to everything quickly. Second week, you start batching responses. Third week, you're at full SLA timing. They learn that urgent doesn't get faster responses, it just gets flagged as urgent. And if everything's urgent, nothing is.
Kira: Nothing is urgent in Lisbon.
Santi: But seriously — you have to be disciplined about this. The moment you break your own SLAs, respond to that "quick question" at eleven PM, you've trained them that the SLAs are negotiable.
Kira: What about the technical edge cases? Notion returns a 429 rate limit error. Slack's scheduler is full. The webhook payload is malformed.
Santi: Retries with exponential backoff for rate limits. Queue systems for scheduling conflicts. Schema validation for webhooks. And — this is critical — monitoring that actually tells you when things fail. Not just error logs. Actual notifications. "Hey, this client's status pack failed to generate three weeks in a row."
Kira: Because silent failures are worse than loud failures.
Santi: Way worse. A client who gets an error message knows something went wrong. A client who gets nothing assumes you forgot about them.
Kira: Let's talk about the Lisbon Test. Can you run this entire system from a café in Lisbon with sketchy wifi?
Santi: The Lisbon Test. Okay, requirements: Everything must work on a single laptop with intermittent connection. No dependency on being online at specific times. No single points of failure that require immediate intervention.
Kira: Stack A passes if you've set up the error notifications properly. Zapier runs in the cloud, Notion and Slack are cloud services. As long as you can reconnect OAuth tokens when needed, you're good.
Santi: Stack B is even better. Your n8n instance is running on a VPS. It doesn't care if your laptop is online. It doesn't care if you're on a boat with no signal. It just runs.
Kira: The only thing that requires you is the weekly QA check. And even that — you could delegate to a trusted contractor if you really needed to be offline.
Santi: Which brings us to the nuclear option. The "I'm trekking in Nepal for two weeks" protocol. You pre-generate two weeks of status updates based on the project plan. You set up auto-responses explaining you're offline. You designate an emergency contact. And you trust the system.
Kira: You've done this.
Santi: I've done this. Took a ten-day sailing trip in Croatia. No internet except for maybe an hour every three days when we docked. Clients got their updates. Contractors kept working. I came back to completed projects and happy clients.
Kira: And how much revenue was flowing while you were sailing?
Santi: Twenty-eight thousand MRR. Twenty-eight thousand dollars of recurring revenue running through automated systems while I was learning to tie bowline knots.
Kira: This is the dream, right? This is why we became nomads. Not to work from beaches — that's actually terrible, sand gets in your keyboard — but to have the freedom to be offline. To be present. To have a business that serves your life, not the other way around.
Santi: And it's not even that hard to build! We're talking about, what, a weekend to set up the basic system? Another weekend to add the error handling and monitoring? Maybe a month to really dial it in for your specific workflow?
Kira: A month to buy back your life.
Santi: Look — here's what nobody tells you about async delivery. The first two weeks are harder than synchronous. You're documenting everything. You're training clients. You're finding all the edge cases. But week three? Week three you wake up and realize you haven't checked Slack in two days and nothing's on fire.
Kira: I had this moment in Guatemala. It was a Thursday morning, I was at this coffee farm in Antigua, completely offline, and I suddenly realized — my clients don't actually know where I am. They don't know what time zone I'm in. They don't know if I'm working today or not. And they don't care, because the work is getting done.
Santi: That's freedom.
Kira: That's the whole point of everything we're building. Not to work less — honestly, I probably work the same hours — but to work when and where it makes sense for your life.
Santi: So let's make this real. What's the first step someone should take? Like, they're listening to this, they're convinced, they have five clients and forty-seven daily Slack notifications. Where do they start?
Kira: Start with the intake form. Today. Before you do anything else. Create a simple Tally or Typeform that captures what the client needs, when they need it, and what success looks like. Stop taking requests through Slack DMs.
Santi: Every request goes through the form. No exceptions. "Hey, can you just quickly..." Nope. Form. "I know this is small but..." Form. "Sorry to bother you but..." Form.
Kira: And here's what happens — within a week, the quality of requests improves dramatically. When clients have to actually write out what they want, they think about it more. Half the time they realize they don't actually need it. The other half, they give you enough context to actually deliver it.
Santi: Second step — document your first three decisions. Not everything. Just the next three decisions you make. Why you chose this approach. What you considered. What constraints you're working with. Put it in Notion, tag it to the project, move on.
Kira: Third step — set up one automated status update. Pick your easiest client. Every Tuesday, they get a bullet list of what got done this week. Doesn't have to be fancy. Doesn't have to be AI-generated. Just consistent.
Santi: And watch what happens. That client stops asking for updates. They stop wondering what's happening. They stop feeling like they need to check in. Because they know that Tuesday at nine AM, they'll know everything.
Kira: It's such a small thing, but it changes the entire relationship dynamic.
Santi: From reactive to proactive. From chaotic to predictable. From "are you working on my stuff?" to "I know you're working on my stuff."
Kira: So here's what we built today — a complete async delivery system that runs twenty-four seven across any time zone. Intake forms that auto-scope work. Timezone-aware routing. AI-powered status packs that cost six cents instead of two hours. And the whole thing works whether you're in Lisbon, on a boat, or completely offline.
Santi: The counterargument is real though. Async can become async hell if you're not careful. Long threads that never resolve. Decisions that take weeks instead of hours. Clients feeling disconnected.
Kira: Yeah, that's fair. Which is why you need escape hatches. Keep one biweekly sync for anything that's genuinely stuck. Use "AI-first, human-final" so nothing ships without a quality check. And if a status pack shows red for two weeks straight, offer the client a call.
Santi: But for ninety percent of your delivery work — the stuff that's eating twelve hours a week right now — async is faster, better, and lets you actually live the nomad life you signed up for.
Kira: Your action item: Go to the show notes right now. Download the Notion template, the intake form structure, and the Node.js script for auto-scheduling status packs. Pick one client and implement just the intake form this week.
Santi: One form. One client. Watch how it changes everything.
Kira: This is The Stateless Founder.
Santi: See you next Tuesday.