DEV Community: Build With Jet

I Automated My Morning Routine Into a Single Email

Build With Jet — Sat, 14 Mar 2026 13:31:22 +0000

I Automated My Morning Routine Into a Single Email

Every morning at 7am Pacific, two emails land. One for me, one for my wife. Each one is a personalized daily brief with everything we need to start the day. It costs $0.003 per day to run, and it replaced a 20-minute routine of checking 6 different apps.

The morning chaos before

Here's what my morning used to look like:

Check weather app (is it going to rain? what should the kid wear?)
Check calendar (any meetings before 9?)
Check email for anything urgent
Check market pre-open (I work in investment banking, so this matters)
Check if any packages are arriving today
Tell my wife the weather and kid logistics

That's 6 apps, 15-20 minutes, before coffee. And half the time I'd forget to mention a schedule change or a package arriving.

The dashboard nobody opened

My first attempt was a Notion dashboard. It had everything — weather, calendar, markets, tasks, the works. Beautiful. Comprehensive.

Nobody opened it. Not even me.

The friction of opening a browser, navigating to Notion, finding the right page — it was enough to kill it. I'd default back to checking individual apps because muscle memory is stronger than good intentions.

The insight: the delivery mechanism matters more than the content. An email that arrives at 7am gets read. A dashboard that exists somewhere gets ignored.

What's in the emails

My brief:

Weather forecast with emoji (fastest way to parse weather at 6:58am)
Today's calendar events with times
Pre-market S&P 500 and 10-year Treasury moves
Unread email count + any flagged urgent messages
Package deliveries expected today
Prediction market betting positions summary
Any overnight alerts from my monitoring system

My wife's brief:

Same weather and calendar
Content ideas for her esthetician work (with specific hooks and trending products)
Trending skincare products for her affiliate business
Kid logistics (soccer practice? school events?)
Family calendar conflicts or coordination needed

The key difference: her brief includes business intelligence for her work. It's not just "here's your day" — it's "here's your day, and here are 3 video ideas based on what's trending in skincare right now."

The newsletter noise problem

The hardest part wasn't building the brief — it was taming the inbox. I subscribe to maybe 40 newsletters. Most mornings, 15-20 are sitting unread, and they make the inbox look overwhelming.

The fix: an inbox cleanup job that runs 5 times daily. It auto-labels newsletters, archives low-priority ones, and marks promotional emails as read. By the time the daily brief runs at 7am, the inbox is already clean.

# Simplified inbox cleanup logic
NEWSLETTER_SENDERS = load_known_senders()  # ~200 senders

for email in get_unread():
    if email.sender in NEWSLETTER_SENDERS:
        label(email, 'Newsletter')
        archive(email)
    elif is_promotional(email):
        mark_read(email)
        label(email, 'Promo')
    # Everything else stays in inbox for the brief to surface

The LLM decides what's promotional using Haiku 4.5. It costs about $0.001 per email classification. For 20 emails a day, that's $0.02/day. Not zero, but close enough.

ThreadPoolExecutor: 52 seconds to 12

The original brief took 52 seconds to generate because it was serial — fetch weather, then calendar, then emails, then markets, then format, then send.

Obvious fix: do the fetches in parallel.

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor(max_workers=6) as executor:
    weather_future = executor.submit(get_weather)
    calendar_future = executor.submit(get_calendar_events)
    email_future = executor.submit(get_email_summary)
    market_future = executor.submit(get_market_data)
    packages_future = executor.submit(get_package_status)
    betting_future = executor.submit(get_betting_positions)

weather = weather_future.result()
calendar = calendar_future.result()
# ... etc

52 seconds down to 12. The bottleneck shifted from API calls to the LLM formatting step, which takes about 4 seconds. The rest is just network latency for 6 parallel API calls.

This matters because both briefs need to go out at 7am. If one takes a minute, the other waits. With parallel fetching, both emails land within seconds of each other.

The $0.003/day math

Here's the actual cost breakdown per day:

Component	Cost
Weather API (Open-Meteo)	Free
Calendar API (Google)	Free
Gmail API (Google)	Free
Market data (Brave Search)	Free
LLM formatting — my brief (Haiku 4.5)	$0.001
LLM formatting — spouse's brief (Haiku 4.5)	$0.001
Inbox cleanup LLM calls	$0.001
Total	$0.003/day

That's about $1.10 per year. The VPS that runs it costs $5/month, but it runs 30 other jobs too, so the marginal cost of the daily brief is effectively zero.

The unexpected benefit

Here's what I didn't expect: both briefs landing at the same time changed how we start our day.

Before, I was the information bottleneck. "Do we have anything tonight?" "Is it going to rain?" "When's soccer?" Now my wife has her own brief with her own calendar view, her own content ideas, her own business intelligence. She doesn't need to ask, and I don't need to remember to tell her.

The briefs also became a coordination tool. When we both know the day's schedule, we can divide and conquer without a morning logistics meeting. "I saw soccer is at 4 — I'll grab them, you do the grocery run" just happens naturally because we both read the same calendar data.

It also forced us to centralize our calendars. Before this, our calendars were a mess — some stuff split between accounts, kid stuff all over the place. Making the brief useful meant getting all events into one system. The automation created the organizational discipline I never had motivation to build on its own.

How to build your own

If you want something similar, here's my honest advice:

Start with email delivery. Don't build a dashboard. Send yourself an email. You'll actually read it.
Use the cheapest LLM that works. Haiku 4.5 formats the brief perfectly. You don't need Opus for "make this weather data readable."
Parallelize from day one. Serial API calls are the silent killer of morning automations. If your brief takes 60 seconds, it drifts later as you add sections.
Build for two people. Even if you're single, think about what a second person would want. It forces you to make the system modular instead of hardcoded.
Run it for a week before adding features. My first brief had 12 sections. I cut it to 7 after realizing I was skimming half of them. Less is more at 7am.

The whole thing is about 400 lines of Python, runs on a $5 VPS, and has been solid for over a month. It's the single automation I'd rebuild first if I had to start over.

Using Notion as a Database Backend for AI Agents

Build With Jet — Sat, 14 Mar 2026 13:31:04 +0000

Using Notion as a Database Backend for AI Agents

I use Notion as the database for my entire AI agent system. Not Postgres. Not SQLite. Not Supabase. Notion. And before you close this tab — let me explain why it actually works, and where it absolutely doesn't.

Why Notion over a real database

The honest answer: my wife can see it.

She runs an esthetician business and does affiliate marketing. She doesn't know what a SQL query is, and she shouldn't have to. But she checks Notion every day. When my AI agent tracks her packages, scouts trending products, or syncs her calendar — she can see all of it in Notion without me building a frontend.

That's the real value proposition. Notion is a database with a UI that already exists. For a solo builder working nights after the kid goes to bed, "I don't have to build a dashboard" is worth more than "I can do JOINs."

The other reasons:

Rich text and relations — I can store a deal memo with formatted text, linked contacts, and file attachments in one record. Try doing that in SQLite.
Free tier is generous — Haven't paid them a cent. API rate limits are the constraint, not pricing.
API is decent — Create, read, update, filter, sort. Covers 90% of what I need.

The 7 dashboards

My Notion workspace has 7 dashboards that update automatically:

Health Dashboard — VPS uptime, last heartbeat, error counts, API usage
Bets — Every prediction with P&L tracking
Deals — Investment deals with status, next steps, key dates
Family — Soccer games, school events, merged calendar
Orders — Package tracking from email receipt to delivery
Garden — 26 seed varieties with germination dates and zone assignments
Home — The meta-dashboard that links to everything

The garden one is my favorite. It tracks when I started each seed indoors, expected germination days, actual sprout dates, and which zone they'll go in. My wife thinks I'm insane for having an AI track my zinnia seedlings. She's probably right.

SDK v3.0 broke everything

In February, the Notion Python SDK shipped v3.0 with a breaking change to database creation. The parent parameter changed from:

# Old (v2.x) - worked fine
parent = {"type": "page_id", "page_id": page_id}

# New (v3.0) - required format
parent = {"page_id": page_id}

No "type" key anymore. The SDK now infers the parent type internally. This broke my template creator, dashboard builder, and sales tracker — basically everything that creates databases programmatically. The error message was useless.

I found the fix by reading the SDK changelog. The migration guide was buried in a GitHub discussion, not the docs. An hour of debugging for a one-line fix.

No webhooks — and how I deal with it

This is Notion's biggest limitation: no webhooks. You can't say "when this database changes, call my endpoint." You have to poll.

My approach uses different intervals based on time-sensitivity:

# Fast (every 5 min): Orders + Health dashboards
# Medium (every 15 min): Deals + Family dashboards
# Daily (8am): Full rebuild of all dashboards
# 12-hour: Complete refresh of everything

It's wasteful compared to webhooks. Every poll costs an API call even if nothing changed. But for a personal system with 7 dashboards, the cost is negligible — roughly 200 API calls per day total.

Rate limits and the workaround

Notion's API rate limit is 3 requests per second. Sounds fine until you're updating 26 garden plants, each needing a page update with 5 properties. That's 26 API calls, and at 3/second you need ~9 seconds minimum.

My fix is boring but effective:

import time

NOTION_RATE_LIMIT = 0.35  # seconds between calls (slightly > 1/3)

def notion_request(method, url, **kwargs):
    time.sleep(NOTION_RATE_LIMIT)
    response = method(url, headers=headers, **kwargs)
    if response.status_code == 429:
        retry_after = int(response.headers.get('Retry-After', 1))
        time.sleep(retry_after)
        response = method(url, headers=headers, **kwargs)
    return response

A fixed delay between every request, plus retry-on-429. Not fancy. Bulk updates are slow. But it never hits rate limits, and for background automation, "slow but reliable" beats "fast but occasionally fails."

What I'd do differently

If I were starting over, I'd still use Notion — but I'd add a local SQLite cache for time-series data. The bet history doesn't need to live in Notion. It needs somewhere I can run analytics on it. Right now, to calculate win rate, I have to query Notion for every record, page through results, and compute it in Python. A local database would make that instant.

I'd also structure databases more carefully upfront. I have some where I'm storing JSON blobs in a rich_text property because I ran out of property types. That's a code smell that means "you should have used a real database for this part."

But for the core use case — dashboards that humans look at, data that benefits from rich formatting, and a system where the builder and the users are the same household — Notion genuinely works. It's not the right tool for everything. But it's the right tool for this.

How I Run 31 Automated Jobs on a $5/month VPS with Claude and systemd

Build With Jet — Fri, 13 Mar 2026 12:31:09 +0000

How I Run 31 Automated Jobs on a $5/month VPS with Claude and systemd

I run 31 automated jobs and 3 always-on services from a single $5/month Hetzner VPS. They handle everything from morning brief emails to weather betting to inbox cleanup. Here's how I got here, what broke along the way, and why systemd beat everything else I tried.

Why systemd, not cron

I started with cron. Everyone starts with cron. And for simple stuff — run this script at 8am — it's fine. But the moment you need:

Logs that actually persist (not just piped to /dev/null)
Automatic restarts when something crashes
Dependency ordering (don't run the brief until the email scan finishes)
Easy enable/disable without commenting out lines

...cron falls apart. systemd timers give you all of that for free. Each job gets a .service file (what to run) and a .timer file (when to run it). You get journalctl logs, systemctl status, and if something dies at 3am, systemd can restart it without you waking up.

Here's what a typical timer looks like:

# jet-daily-brief.timer
[Unit]
Description=Jet Daily Brief Timer

[Timer]
OnCalendar=*-*-* 14:00:00 UTC
Persistent=true

[Install]
WantedBy=timers.target

# jet-daily-brief.service
[Unit]
Description=Jet Daily Brief
After=network-online.target

[Service]
Type=oneshot
WorkingDirectory=/opt/jet
ExecStart=/usr/bin/python3 -u -m SKILLS.daily_brief
TimeoutStartSec=300
Environment=PYTHONUNBUFFERED=1

The -u flag and PYTHONUNBUFFERED=1 are non-negotiable. Without them, Python buffers stdout when there's no TTY, and your logs show up 20 minutes late (or never). I learned this after spending an hour wondering why a job that clearly ran had zero output in journalctl.

The 3am overnight worker failure

My overnight worker runs at midnight. It handles maintenance tasks — clearing stale data, syncing dashboards, running health checks. One night it silently failed because the Anthropic API returned a 529 (overloaded) and my retry logic had a bug: it retried 5 times with no backoff, hit rate limits, and cascaded.

I woke up to a Telegram message from my heartbeat monitor: "Overnight worker: LAST RUN >24h ago." The fix was embarrassingly simple — exponential backoff and capping retries at 2 instead of 5. But the real lesson was: the heartbeat monitor caught it. Every 30 minutes, a separate timer checks that every other timer actually ran recently. If something hasn't run in 2x its expected interval, I get an alert.

# Simplified heartbeat check
for timer_name, expected_interval_hours in TIMERS.items():
    last_run = get_last_run(timer_name)
    if (now - last_run).hours > expected_interval_hours * 2:
        send_alert(f"{timer_name}: LAST RUN >{expected_interval_hours}h ago")

The OAuth Sunday nightmare

Google OAuth tokens expire. Specifically, if your Google Cloud app is in "testing" mode (which mine is, because moving to production requires a security review I haven't done), tokens expire every 7 days. Every. Seven. Days.

For a while, this meant every Sunday morning my email-dependent services would break. The daily brief would fail. Inbox cleanup would fail. Calendar sync would fail. I'd wake up, re-auth manually, push the new token to the VPS, and pretend it was fine.

The self-healing fix was an OAuth helper that:

Tries the token from the environment variable first
Falls back to the token file if the env var is stale
Runs an hourly sync that refreshes the token before it expires
If all else fails, sends me an alert with a re-auth link

def get_gmail_service():
    creds = None
    # Try env var first (most recently updated)
    token_data = os.getenv('GMAIL_TOKEN_JSON')
    if token_data:
        creds = Credentials.from_authorized_user_info(json.loads(token_data))

    # Fall back to file
    if not creds or not creds.valid:
        if creds and creds.expired and creds.refresh_token:
            creds.refresh(Request())
            # Write back to env for next time
            update_env_var('GMAIL_TOKEN_JSON', creds.to_json())

It's not elegant, but it hasn't broken on a Sunday in 3 weeks. I'll take it.

The real cost audit: $19 to $5/month

When I first set this up, I was spending about $19/month on Anthropic API calls alone. The VPS was $5. Most of the API cost came from three things:

Overnight worker using Sonnet ($7.73/mo) — Switched to Haiku 4.5. It handles maintenance tasks just fine.
Newsletter summaries using Sonnet ($2.83/mo) — Same switch. Haiku summarizes newsletters perfectly.
Telegram bot without prompt caching ($3.50/mo) — Added prompt caching. Cache hit rate is ~70%.

I also evaluated running Ollama locally for the cheap stuff. At $5/month total, it wasn't worth the complexity. The tasks that could run on a local model were already costing pennies on Haiku.

Final breakdown:

Hetzner VPS (CX22, 2 vCPU, 4GB RAM): $5/month
Anthropic API (all 31 jobs + bot): ~$5/month
Total: ~$10/month for a full personal AI operations platform

What still breaks

I'd love to tell you it's bulletproof. It's not.

Python dependency conflicts. The VPS has one Python environment. When I install something for one bot that conflicts with another, both break. I should use venvs. I don't. It hasn't bitten me hard enough yet.

Disk space. 40GB sounds like a lot until you're storing screenshots, audio files, and logs from 31 services. I added a cleanup job to the overnight worker. It deletes files older than 7 days from /tmp.

The VPS itself. It's a single point of failure. No redundancy, no failover. If the host has an outage, everything stops. I have manual fallbacks, but I haven't tested them in weeks.

Me. I'm the bottleneck. When something needs a new feature or a bug fix, it waits until I have time after work and after evening routines. The whole system is one person deep.

Is it worth it?

Absolutely. My morning brief email arrives at 7am with weather, calendar, market data, and a summary of overnight emails. My inbox cleanup runs 5 times a day. Package tracking updates automatically. And I have a bot that can do almost anything the full system can do, from my phone.

The total cost is less than a single SaaS subscription. The total setup time was about 3 weeks of evenings. And the hardest part wasn't the code — it was getting systemd timer syntax right and remembering to add PYTHONUNBUFFERED=1 to every service file.

If you're thinking about doing something similar: start with one timer. Get the daily brief working. Once you see that email land in your inbox every morning without you touching anything, you'll want to automate everything else too.

building ai agents that run 24/7 — and tracking everything in notion. templates dropping soon for an

Build With Jet — Mon, 09 Mar 2026 12:31:12 +0000

building ai agents that run 24/7 — and tracking everything in notion. templates dropping soon for anyone who wants to actually see how this stuff works.

I Run 28 Autonomous AI Agents — Here Are the Free Notion Templates I Built to Track Them

Build With Jet — Sat, 07 Mar 2026 00:12:44 +0000

The Setup

I run 28 autonomous AI agents on a $5/month VPS. They handle everything — email triage, calendar management, weather betting, survey automation, deal tracking, and more.

The hardest part wasn't building the agents. It was tracking them all.

After months of iteration, I built a set of Notion templates that keep everything organized. Now I'm giving them away for free.

What's Included

1. Claude Code Quickstart Kit (Free)

Everything you need to set up a Claude Code agent: CLAUDE.md template, MEMORY.md template, session log database, and a setup guide. If you're starting with Claude Code, this saves you the first few hours of trial and error.

2. AI Cost Calculator (Free)

Track API costs across providers (OpenAI, Anthropic, Google). See exactly where your money goes with per-model breakdowns. I built this because my API bill hit $19/month before I realized which calls were burning cash — now it's $5.

3. Vibe Coder's Project Tracker (Free)

Ship AI-built projects from idea to launch. Pipeline database with status tracking, tech stack tags, and milestone management. I use this to manage the 28 agents and the dozen side projects that spawned from them.

Why Free?

These templates are the foundation of a larger system I'm building. The free versions give you a solid starting point. Premium templates (AgentOps Lite and AlgoTracker) go deeper with multi-database architectures, cross-references, and operational dashboards.

Get Them

All three free templates are available now on the Build With Jet store. Duplicate them to your Notion workspace and start building.

Built by Jet — an AI assistant framework powered by Claude Code.

What are you building with AI agents? Drop a comment below.

I Automated My Morning Routine Into a Single Email

Build With Jet — Fri, 06 Mar 2026 23:21:50 +0000

I Automated My Morning Routine Into a Single Email

The morning chaos before

Here's what my morning used to look like:

Check weather app (is it going to rain? what should Mayer wear?)
Check calendar (any meetings before 9?)
Check email for anything urgent
Check market pre-open (I work in investment banking, so this matters)
Check if any packages are arriving today
Tell Elizabeth the weather and kid logistics

That's 6 apps, 15-20 minutes, before coffee. And half the time I'd forget to tell Elizabeth about the schedule change or the package arriving.

The dashboard nobody opened

My first attempt was a Notion dashboard. It had everything — weather, calendar, markets, tasks, the works. Beautiful. Comprehensive.

Nobody opened it.

Not even me. The friction of opening a browser, navigating to Notion, and finding the right page was enough to kill it. I'd default back to checking individual apps because muscle memory is stronger than good intentions.

The insight: the delivery mechanism matters more than the content. An email that arrives at 7am gets read. A dashboard that exists somewhere gets ignored.

What's in the emails

Travis's brief (mine):

Weather forecast with emoji (yes, emoji — it's the fastest way to parse weather at 6:58am)
Today's calendar events with times
Pre-market S&P 500 and 10-year Treasury moves
Unread email count + any flagged urgent messages
Package deliveries expected today
Kalshi betting positions summary (I run weather/economics prediction bets)
Any overnight alerts from my monitoring system

Elizabeth's brief (my wife's):

Same weather and calendar
Content ideas for her esthetician TikTok (with specific hooks and settings)
Trending skincare products for her affiliate business
Kid logistics (soccer practice? school events?)
Family calendar conflicts or coordination needed

The key difference: her brief includes business intelligence for her esthetician and affiliate marketing work. It's not just "here's your day" — it's "here's your day, and here are 3 TikTok video ideas based on what's trending in skincare right now."

The newsletter noise problem

The hardest part wasn't building the brief — it was taming the inbox. I subscribe to maybe 40 newsletters. Market recaps, tech news, deal alerts, skincare industry stuff. Most mornings, 15-20 of those are sitting unread, and they make the inbox look overwhelming.

# Simplified inbox cleanup logic
NEWSLETTER_SENDERS = load_known_senders()  # ~200 senders

for email in get_unread():
    if email.sender in NEWSLETTER_SENDERS:
        label(email, 'Newsletter')
        archive(email)
    elif is_promotional(email):
        mark_read(email)
        label(email, 'Promo')
    # Everything else stays in inbox for the brief to surface

The LLM decides what's promotional using Haiku 4.5. It costs about $0.001 per email classification. For 20 emails a day, that's $0.02/day. Not zero, but close enough.

ThreadPoolExecutor: 52 seconds to 12

The original brief took 52 seconds to generate. That's because it was serial — fetch weather, then fetch calendar, then fetch emails, then fetch markets, then format, then send.

The obvious fix: do the fetches in parallel.

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor(max_workers=6) as executor:
    weather_future = executor.submit(get_weather)
    calendar_future = executor.submit(get_calendar_events)
    email_future = executor.submit(get_email_summary)
    market_future = executor.submit(get_market_data)
    packages_future = executor.submit(get_package_status)
    kalshi_future = executor.submit(get_kalshi_positions)

weather = weather_future.result()
calendar = calendar_future.result()
# ... etc

52 seconds down to 12. The bottleneck shifted from API calls to the LLM formatting step, which takes about 4 seconds. The rest is just network latency for 6 parallel API calls.

This matters because both briefs need to go out at 7am. If one takes a minute, the other waits. With parallel fetching, both emails land within seconds of each other.

The $0.003/day math

Here's the actual cost breakdown per day:

Component	Cost
Weather API (Open-Meteo)	Free
Calendar API (Google)	Free
Gmail API (Google)	Free
Market data (Brave Search)	Free
LLM formatting — Travis brief (Haiku 4.5)	$0.001
LLM formatting — Elizabeth brief (Haiku 4.5)	$0.001
Inbox cleanup LLM calls	$0.001
Total	$0.003/day

That's about $1.10 per year. The VPS that runs it costs $5/month, but it runs 30 other jobs too, so the marginal cost of the daily brief is effectively zero.

The unexpected benefit

Here's what I didn't expect: both briefs landing at the same time changed how Elizabeth and I start our day.

Before, I was the information bottleneck. "Hey, do we have anything tonight?" "Is it going to rain?" "When's Mayer's soccer?" Now she has her own brief with her own calendar view, her own content ideas, her own business intelligence. She doesn't need to ask me, and I don't need to remember to tell her.

The briefs also became a coordination tool. When we both know the day's schedule, we can divide and conquer without a morning logistics meeting over coffee. "I saw soccer is at 4 — I'll grab him, you do the grocery run" just happens naturally because we both read the same calendar data.

It also forced me to centralize our calendars. Before building the brief, our calendars were a mess — some stuff on my Google Calendar, some on hers, kid stuff split between both. Making the brief useful meant getting all events into a system the brief could query. The automation created the organizational discipline I never had the motivation to build on its own.

How to build your own

If you want something similar, here's my honest advice:

Start with email delivery. Don't build a dashboard. Don't build an app. Send yourself an email. You'll actually read it.
Use the cheapest LLM that works. Haiku 4.5 formats my brief perfectly. I don't need Opus for "make this weather data readable."
Parallelize from day one. Serial API calls are the silent killer of morning automations. If your brief takes 60 seconds, it'll drift later and later as you add sections.
Build for two people. Even if you're single, think about what a second person in your life would want. It forces you to make the system modular instead of hardcoded to your preferences.
Run it for a week before adding features. My first brief had 12 sections. I cut it to 7 after realizing I was skimming half of them. Less is more at 7am.

The whole thing is about 400 lines of Python, runs on a $5 VPS, and has been reliable for over a month. It's the single automation I'd rebuild first if I had to start over.