# Pattern: Anti-impulse Decision Rules (R1-R10) > Rules that prevent the operator-over-builds-instead-of-sells pattern. For solo founders who code, the temptation is always to build instead of sell. These rules, enforced by automation, fix that. ## The rules ### R1. Hardware lot purchase guard Do NOT buy a refurbished hardware lot if ANY of: - Existing inventory > 8 units of same category - Pre-sales coverage < 50% (i.e., orders waiting on stock) - Last 5 lots averaged > 60 days on shelf ### R2. Pre-purchase justification (write before clicking buy) 1. Why this lot? (specific clients waiting? Or "looked cheap"?) 2. Projected sell-through (units × weeks to clear) 3. Holding cost (3%/mo capital tied + storage) 4. GO / NO-GO: if projected net ROI < 30% OR sell-through > 90 days → NO ### R3. Frequency cap Max 1 lot purchase per week. New opportunity? Wait until next Monday. ### R4. Client acceptance Accept new client only if EITHER: - Recurring potential ≥ €100/mo (3-month commit), OR - One-time margin ≥ €500, OR - Strategic referral source (unlocks network) ### R5. Minimum billable rate €75/hour for ad-hoc work. Below that, decline politely. ### R6. Daily time budget - 4h cash generation (outreach, calls, quotes, sales conversion) - 2h delivery (existing client work) - 1h admin (invoicing, follow-up) - 1h learning/infra (NOT during cash window) ### R7. Morning protection **No infra/code work before 14:00 on weekdays.** Morning = cash + delivery only. ### R8. Build justification Before building anything new, ask: "Which paying client needs this RIGHT NOW?" - Unclear → do not build. - Clear → log it as a feature request with client name + proceed. ### R9. Use-it-or-archive If a tool isn't used by operator OR a client within 2 weeks of building, archive it. ### R10. Cash before code (umbrella) Every Friday: if sales hours < infra hours that week, the week failed and resets next Monday. No exceptions. ## Enforcement via automation ### R10 — ActivityWatch + Friday-Wrap email `scripts/atlas_activity_export.py` reads ActivityWatch event log, classifies into 6 categories: - sales (Asana, WhatsApp Web, mail compose, Atlas Chat/Command/HUD) - delivery (VSCode/Claude on existing-client work, WordPress admin) - infra (Claude Code, terminal, GitHub, Docker, config files) - admin (Inkomsten xlsx, Odoo, bank statements) - learning (YouTube courses, BiSL/certification material) - other Output JSON includes `r10_pass` boolean. Friday-Wrap email shows verdict. ### R1-R3 — Browser calculator `web/atlas-command.html` has a "BUY?" tab. Inputs: lot price, units, category, pre-sales %. Outputs: GO/NO-GO verdict + holding cost + net ROI calculation per category baselines. ### R5/R8 — Atlas Reminders `scripts/atlas_reminders.py` daily schtask. Triggers conditional emails: - 26th of month → savings pots check - 14d + 3d before BTW deadlines - 1st of month → Inkomsten xlsx update reminder - 5 juni + 25 nov → vacation booking reminder - 1 mrt + 15 apr → IB aangifte prep ## Why these rules After 12 months of building infrastructure that produced €5K annual revenue (vault: 200+ project files, ~15 paid client events = 13:1 build:sell ratio), the founder needed rules that prevent willpower-based discipline. Rules survive willpower. Automation survives both. ## Customize The numbers (€100/mo, €500 margin, 4h/2h/1h/1h budget) are Atlas-specific. Adjust to your context. The structure (one umbrella + nine specific rules + automated enforcement) is the transferable pattern.