I Build Products.
You Own Them.

I Built an MBOX Converter in 30 Minutes with Claude

A client needed to migrate Google Vault email exports to Outlook. The problem: Google exports in MBOX format. Outlook needs EML files. There's no native converter.

Instead of searching for paid tools or complicated scripts, I built one myself. Here's exactly how.

The Problem

Google Vault exports emails as .mbox files—a format from the 1970s that bundles thousands of emails into a single file. Outlook can't read it. Neither can most email clients.

The client had 50,000+ emails to migrate. Manual conversion wasn't an option.

The Solution: 82 Lines of Python

The core converter is embarrassingly simple:

def convert_mbox(mbox_path, output_dir):
    mbox = mailbox.mbox(mbox_path)
    count = 0
    for msg in mbox:
        # Create filename from date + sender + subject
        filename = f"{date}_{sender}_{subject}.eml"
        with open(output_dir / filename, 'wb') as f:
            f.write(msg.as_bytes())
        count += 1
    return count

Python's mailbox module does all the heavy lifting. Each email in the MBOX becomes a separate .eml file that Outlook opens natively.

Making it User-Friendly

A command-line script wouldn't work for a non-technical client. I needed a native Mac app with drag-and-drop support.

Problem: Python's tkinter wasn't available on my system. Solution: AppleScript wrapper calling the Python backend.

-- AppleScript handles GUI
set selectedFiles to choose file
-- Python does the conversion
do shell script "python3 converter_core.py " & quoted form of filePath

Compiled with osacompile, it becomes a proper .app that lives in the Applications folder.

Results

Key Lessons

• Standard libraries are powerful. Python's mailbox module handled all the MBOX parsing—no external dependencies.
• AppleScript + Python = native Mac apps. When GUI frameworks don't cooperate, hybrid approaches work.
• Build small, ship fast. The client didn't need a beautiful app. They needed their emails converted today.

The full code is open source. If you're migrating from Google Vault to Outlook, reach out—I'll share the app.

→ Request the MBOX Converter App (free)

Multi-Tenant Slack Bot: One App, Three Workspaces

We had three Slack workspaces that needed the same IT support bot. The naive approach: deploy three separate apps. The smart approach: one app that handles all three.

The Problem

Each workspace needed identical functionality: create Jira tickets from Slack, route by type, track SLAs. But maintaining three codebases is a nightmare. Updates mean three deployments. Bugs mean three fixes.

The Architecture

workspace_config = {
    "T01XXXX": {"name": "Main", "jira_project": "IT"},
    "T02XXXX": {"name": "Target", "jira_project": "TG"},
    "T03XXXX": {"name": "Longeron", "jira_project": "LG"}
}

def get_workspace(team_id):
    return workspace_config.get(team_id)

The bot extracts team_id from every Slack event, looks up the config, and routes to the right Jira project. One codebase, one deployment, three workspaces.

Results

Key Lessons

• Multi-tenancy from day one. Even if you start with one client, architect for many.
• Config over code. New workspace = new config entry, not new deployment.
• DigitalOcean caches secrets. Updating app specs doesn't update encrypted values—check runtime logs.

98% Cost Reduction: Optimizing AI API Calls

Our AI-powered email monitor was burning through $100/month in API costs. After one debugging session: $2/month. Here's the fix.

The Problem

The monitor processed 400+ tickets every 5 minutes. Four AI functions—all using Claude Opus (the most expensive model). Every ticket, every run, full AI analysis.

The Fix

# Before: Opus for everything ($15/$75 per million tokens)
model = "claude-opus-4"

# After: Haiku for simple tasks ($0.25/$1.25 per million)
model = "claude-3-5-haiku"

# Plus: Cache already-processed tickets
if ticket_id in processed_cache:
    return cached_result

Two changes: downgrade model for simple binary classifications, cache results so we don't re-process.

Results

Key Lessons

• Not every task needs the biggest model. Simple yes/no classifications work fine with smaller models.
• Cache before calling. If you've already done the work, don't do it again.
• Check your logs. The fix was obvious once we saw the call patterns.