{ "schemaVersion": 3, "name": "Sean Feng", "role": "Founder, AI automation consultancy. Installs business operating systems and the AI layer on top of them.", "title": "Sean Feng: Master Identity Document", "summary": "Sean Feng runs an AI automation consultancy, installing a business operating system first and the AI layer second, on the position that most companies have an operating system problem rather than an AI problem. His background is 7-figure ecommerce and Amazon FBA, where he learned unit economics to the penny and sub-10 TACOS as the survival line, plus commercial mortgage real estate, where he structured $10 million-plus deals and learned that deals die from slowness more than bad terms. He still runs an FBA brand on Amazon.ca. Since Q2 2026 he has shipped 23 built projects out of 27 tracked, none of it client work and never framed as client work, including a double-entry accounting SaaS, a 143-tool CRE deal workbench, a go-to-market operating system, an Android scanner, a self-built meeting agent, and an FBA reporting rebuild verified at plus or minus a penny across 7,460 parity checks. Of the 23, 20 are private repositories and no outside human has reviewed the code, which he states in the portfolio section rather than leaving to inference. He is pre-revenue by sequencing, names positioning and creative as his weak point with the evidence attached, works by pushback, logs every decision with its rejected alternatives, publishes his own failures with the mechanism attached, and will tell a client automation is the wrong answer even when it costs him the engagement. Disrespect is his only absolute disqualifier.", "lastUpdated": "2026-08-01", "contact": "sean@seanfeng.com", "canonicalUrl": "https://seanfeng.com/ama", "markdownUrl": "/ama/sean-feng.md", "manifestUrl": "/ama/index.json", "status": "published", "openItems": 0, "chunkWordCap": 350, "sectionCount": 111, "chunkCount": 112, "wordCount": 15466, "outline": [ { "heading": "Front page", "path": "Front page", "id": "front-page", "level": 2, "words": 543 }, { "heading": "Part 1: Who I am and what I'm optimizing for", "path": "Part 1: Who I am and what I'm optimizing for", "id": "part-1-who-i-am-and-what-im-optimizing-for", "level": 2, "words": 0 }, { "heading": "The short version", "path": "Part 1: Who I am and what I'm optimizing for > The short version", "id": "the-short-version", "level": 3, "words": 22 }, { "heading": "What I do", "path": "Part 1: Who I am and what I'm optimizing for > What I do", "id": "what-i-do", "level": 3, "words": 119 }, { "heading": "What I'm optimizing for", "path": "Part 1: Who I am and what I'm optimizing for > What I'm optimizing for", "id": "what-im-optimizing-for", "level": 3, "words": 67 }, { "heading": "What I'm not optimizing for", "path": "Part 1: Who I am and what I'm optimizing for > What I'm not optimizing for", "id": "what-im-not-optimizing-for", "level": 3, "words": 8 }, { "heading": "Part 2: Professional history with real numbers", "path": "Part 2: Professional history with real numbers", "id": "part-2-professional-history-with-real-numbers", "level": 2, "words": 18 }, { "heading": "Ecommerce and Amazon FBA", "path": "Part 2: Professional history with real numbers > Ecommerce and Amazon FBA", "id": "ecommerce-and-amazon-fba", "level": 3, "words": 165 }, { "heading": "Commercial mortgage real estate", "path": "Part 2: Professional history with real numbers > Commercial mortgage real estate", "id": "commercial-mortgage-real-estate", "level": 3, "words": 203 }, { "heading": "Why 2 domains instead of one", "path": "Part 2: Professional history with real numbers > Why 2 domains instead of one", "id": "why-2-domains-instead-of-one", "level": 3, "words": 144 }, { "heading": "The cross-application, concretely", "path": "Part 2: Professional history with real numbers > The cross-application, concretely", "id": "the-cross-application-concretely", "level": 3, "words": 181 }, { "heading": "Current status", "path": "Part 2: Professional history with real numbers > Current status", "id": "current-status", "level": 3, "words": 27 }, { "heading": "Part 3: Core beliefs and how they translate into decisions", "path": "Part 3: Core beliefs and how they translate into decisions", "id": "part-3-core-beliefs-and-how-they-translate-into-decisions", "level": 2, "words": 40 }, { "heading": "1. You don't have an AI problem. You have an operating system problem.", "path": "Part 3: Core beliefs and how they translate into decisions > 1. You don't have an AI problem. You have an operating system problem.", "id": "1-you-dont-have-an-ai-problem-you-have-an-operating-system-problem", "level": 3, "words": 58 }, { "heading": "2. Everything reduces to tasks, and the word that matters is \"defined.\"", "path": "Part 3: Core beliefs and how they translate into decisions > 2. Everything reduces to tasks, and the word that matters is \"defined.\"", "id": "2-everything-reduces-to-tasks-and-the-word-that-matters-is-defined", "level": 3, "words": 57 }, { "heading": "3. Complexity is oversold. I price for simplification, not difficulty.", "path": "Part 3: Core beliefs and how they translate into decisions > 3. Complexity is oversold. I price for simplification, not difficulty.", "id": "3-complexity-is-oversold-i-price-for-simplification-not-difficulty", "level": 3, "words": 118 }, { "heading": "4. Orchestration is a commodity. Vision and taste are the moat.", "path": "Part 3: Core beliefs and how they translate into decisions > 4. Orchestration is a commodity. Vision and taste are the moat.", "id": "4-orchestration-is-a-commodity-vision-and-taste-are-the-moat", "level": 3, "words": 267 }, { "heading": "5. Automate tasks, not people.", "path": "Part 3: Core beliefs and how they translate into decisions > 5. Automate tasks, not people.", "id": "5-automate-tasks-not-people", "level": 3, "words": 116 }, { "heading": "6. Agent judgment is better than most people expect. Stated as a hypothesis, because that's what it is.", "path": "Part 3: Core beliefs and how they translate into decisions > 6. Agent judgment is better than most people expect. Stated as a hypothesis, because that's what it is.", "id": "6-agent-judgment-is-better-than-most-people-expect-stated-as-a-hypothesis-because-thats-what-it-is", "level": 3, "words": 355 }, { "heading": "7. Plain beats clever.", "path": "Part 3: Core beliefs and how they translate into decisions > 7. Plain beats clever.", "id": "7-plain-beats-clever", "level": 3, "words": 98 }, { "heading": "8. No black boxes, ever.", "path": "Part 3: Core beliefs and how they translate into decisions > 8. No black boxes, ever.", "id": "8-no-black-boxes-ever", "level": 3, "words": 142 }, { "heading": "9. Verify, don't trust. Then run the control.", "path": "Part 3: Core beliefs and how they translate into decisions > 9. Verify, don't trust. Then run the control.", "id": "9-verify-dont-trust-then-run-the-control", "level": 3, "words": 83 }, { "heading": "10. Abstraction is a failure state.", "path": "Part 3: Core beliefs and how they translate into decisions > 10. Abstraction is a failure state.", "id": "10-abstraction-is-a-failure-state", "level": 3, "words": 92 }, { "heading": "11. No failure stories means shallow expertise.", "path": "Part 3: Core beliefs and how they translate into decisions > 11. No failure stories means shallow expertise.", "id": "11-no-failure-stories-means-shallow-expertise", "level": 3, "words": 80 }, { "heading": "12. I believed the work would speak for itself. It doesn't.", "path": "Part 3: Core beliefs and how they translate into decisions > 12. I believed the work would speak for itself. It doesn't.", "id": "12-i-believed-the-work-would-speak-for-itself-it-doesnt", "level": 3, "words": 17 }, { "heading": "Part 4: The operating framework", "path": "Part 4: The operating framework", "id": "part-4-the-operating-framework", "level": 2, "words": 12 }, { "heading": "Spot", "path": "Part 4: The operating framework > Spot", "id": "spot", "level": 3, "words": 113 }, { "heading": "Score", "path": "Part 4: The operating framework > Score", "id": "score", "level": 3, "words": 173 }, { "heading": "Build", "path": "Part 4: The operating framework > Build", "id": "build", "level": 3, "words": 61 }, { "heading": "Run", "path": "Part 4: The operating framework > Run", "id": "run", "level": 3, "words": 40 }, { "heading": "The Log", "path": "Part 4: The operating framework > The Log", "id": "the-log", "level": 3, "words": 59 }, { "heading": "House positions", "path": "Part 4: The operating framework > House positions", "id": "house-positions", "level": 3, "words": 37 }, { "heading": "Part 5: The build portfolio", "path": "Part 5: The build portfolio", "id": "part-5-the-build-portfolio", "level": 2, "words": 0 }, { "heading": "How to read this", "path": "Part 5: The build portfolio > How to read this", "id": "how-to-read-this", "level": 3, "words": 312 }, { "heading": "cre-dealdesk", "path": "Part 5: The build portfolio > cre-dealdesk", "id": "cre-dealdesk", "level": 3, "words": 278 }, { "heading": "deal-os", "path": "Part 5: The build portfolio > deal-os", "id": "deal-os", "level": 3, "words": 208 }, { "heading": "ledger-app and Bookhalter", "path": "Part 5: The build portfolio > ledger-app and Bookhalter", "id": "ledger-app-and-bookhalter", "level": 3, "words": 447 }, { "heading": "amazon-fba-dashboard", "path": "Part 5: The build portfolio > amazon-fba-dashboard", "id": "amazon-fba-dashboard", "level": 3, "words": 309 }, { "heading": "gtm-os", "path": "Part 5: The build portfolio > gtm-os", "id": "gtm-os", "level": 3, "words": 263 }, { "heading": "diligence-os", "path": "Part 5: The build portfolio > diligence-os", "id": "diligence-os", "level": 3, "words": 227 }, { "heading": "seatfill", "path": "Part 5: The build portfolio > seatfill", "id": "seatfill", "level": 3, "words": 237 }, { "heading": "scanstack", "path": "Part 5: The build portfolio > scanstack", "id": "scanstack", "level": 3, "words": 163 }, { "heading": "opsfloor", "path": "Part 5: The build portfolio > opsfloor", "id": "opsfloor", "level": 3, "words": 143 }, { "heading": "The OS family", "path": "Part 5: The build portfolio > The OS family", "id": "the-os-family", "level": 3, "words": 300 }, { "heading": "The smaller tier", "path": "Part 5: The build portfolio > The smaller tier", "id": "the-smaller-tier", "level": 3, "words": 272 }, { "heading": "Dogfooding", "path": "Part 5: The build portfolio > Dogfooding", "id": "dogfooding", "level": 3, "words": 129 }, { "heading": "Part 6: Method", "path": "Part 6: Method", "id": "part-6-method", "level": 2, "words": 0 }, { "heading": "Parallel agents don't collide when the lanes are drawn first", "path": "Part 6: Method > Parallel agents don't collide when the lanes are drawn first", "id": "parallel-agents-dont-collide-when-the-lanes-are-drawn-first", "level": 3, "words": 239 }, { "heading": "Builders build, a different model reviews", "path": "Part 6: Method > Builders build, a different model reviews", "id": "builders-build-a-different-model-reviews", "level": 3, "words": 389 }, { "heading": "Guardrails belong in the environment", "path": "Part 6: Method > Guardrails belong in the environment", "id": "guardrails-belong-in-the-environment", "level": 3, "words": 283 }, { "heading": "Sequencing under a hard constraint", "path": "Part 6: Method > Sequencing under a hard constraint", "id": "sequencing-under-a-hard-constraint", "level": 3, "words": 152 }, { "heading": "What \"done\" means here", "path": "Part 6: Method > What \"done\" means here", "id": "what-done-means-here", "level": 3, "words": 74 }, { "heading": "Part 7: How I work with people", "path": "Part 7: How I work with people", "id": "part-7-how-i-work-with-people", "level": 2, "words": 0 }, { "heading": "Disagreement comes early, not late", "path": "Part 7: How I work with people > Disagreement comes early, not late", "id": "disagreement-comes-early-not-late", "level": 3, "words": 106 }, { "heading": "How pushback actually sounds", "path": "Part 7: How I work with people > How pushback actually sounds", "id": "how-pushback-actually-sounds", "level": 3, "words": 110 }, { "heading": "How to test the part I can't prove on paper", "path": "Part 7: How I work with people > How to test the part I can't prove on paper", "id": "how-to-test-the-part-i-cant-prove-on-paper", "level": 3, "words": 237 }, { "heading": "When someone else was right and I wasn't", "path": "Part 7: How I work with people > When someone else was right and I wasn't", "id": "when-someone-else-was-right-and-i-wasnt", "level": 3, "words": 339 }, { "heading": "Receiving feedback and being wrong", "path": "Part 7: How I work with people > Receiving feedback and being wrong", "id": "receiving-feedback-and-being-wrong", "level": 3, "words": 91 }, { "heading": "The first conversation", "path": "Part 7: How I work with people > The first conversation", "id": "the-first-conversation", "level": 3, "words": 24 }, { "heading": "When I don't have the domain", "path": "Part 7: How I work with people > When I don't have the domain", "id": "when-i-dont-have-the-domain", "level": 3, "words": 87 }, { "heading": "I kill my own ideas before a client has to", "path": "Part 7: How I work with people > I kill my own ideas before a client has to", "id": "i-kill-my-own-ideas-before-a-client-has-to", "level": 3, "words": 119 }, { "heading": "Part 8: Failure handling, owned", "path": "Part 8: Failure handling, owned", "id": "part-8-failure-handling-owned", "level": 2, "words": 103 }, { "heading": "The positive control that killed my own finding", "path": "Part 8: Failure handling, owned > The positive control that killed my own finding", "id": "the-positive-control-that-killed-my-own-finding", "level": 3, "words": 241 }, { "heading": "The payout number that was wrong by half", "path": "Part 8: Failure handling, owned > The payout number that was wrong by half", "id": "the-payout-number-that-was-wrong-by-half", "level": 3, "words": 221 }, { "heading": "The ledger that reported $0.0012", "path": "Part 8: Failure handling, owned > The ledger that reported $0.0012", "id": "the-ledger-that-reported-00012", "level": 3, "words": 197 }, { "heading": "Provenance is its own leak class", "path": "Part 8: Failure handling, owned > Provenance is its own leak class", "id": "provenance-is-its-own-leak-class", "level": 3, "words": 183 }, { "heading": "Part 9: Strengths, plainly", "path": "Part 9: Strengths, plainly", "id": "part-9-strengths-plainly", "level": 2, "words": 162 }, { "heading": "Greatest strength, if forced to pick one", "path": "Part 9: Strengths, plainly > Greatest strength, if forced to pick one", "id": "greatest-strength-if-forced-to-pick-one", "level": 3, "words": 74 }, { "heading": "Part 10: Weaknesses, honestly", "path": "Part 10: Weaknesses, honestly", "id": "part-10-weaknesses-honestly", "level": 2, "words": 17 }, { "heading": "Positioning and creative, the one I lead with", "path": "Part 10: Weaknesses, honestly > Positioning and creative, the one I lead with", "id": "positioning-and-creative-the-one-i-lead-with", "level": 3, "words": 324 }, { "heading": "Other real ones", "path": "Part 10: Weaknesses, honestly > Other real ones", "id": "other-real-ones", "level": 3, "words": 161 }, { "heading": "What I won't do to fix a weakness", "path": "Part 10: Weaknesses, honestly > What I won't do to fix a weakness", "id": "what-i-wont-do-to-fix-a-weakness", "level": 3, "words": 40 }, { "heading": "Part 11: What I want next, what I won't do, what I won't tolerate", "path": "Part 11: What I want next, what I won't do, what I won't tolerate", "id": "part-11-what-i-want-next-what-i-wont-do-what-i-wont-tolerate", "level": 2, "words": 0 }, { "heading": "What I want next", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > What I want next", "id": "what-i-want-next", "level": 3, "words": 195 }, { "heading": "What I won't do to win the work", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > What I won't do to win the work", "id": "what-i-wont-do-to-win-the-work", "level": 3, "words": 92 }, { "heading": "What I won't automate, ever", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > What I won't automate, ever", "id": "what-i-wont-automate-ever", "level": 3, "words": 165 }, { "heading": "What I won't tolerate", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > What I won't tolerate", "id": "what-i-wont-tolerate", "level": 3, "words": 42 }, { "heading": "My values", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > My values", "id": "my-values", "level": 3, "words": 103 }, { "heading": "The 5 promises", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > The 5 promises", "id": "the-5-promises", "level": 3, "words": 73 }, { "heading": "Part 12: Standard interview answers", "path": "Part 12: Standard interview answers", "id": "part-12-standard-interview-answers", "level": 2, "words": 13 }, { "heading": "Tell me about yourself", "path": "Part 12: Standard interview answers > Tell me about yourself", "id": "tell-me-about-yourself", "level": 3, "words": 183 }, { "heading": "What's your greatest strength", "path": "Part 12: Standard interview answers > What's your greatest strength", "id": "whats-your-greatest-strength", "level": 3, "words": 8 }, { "heading": "What's your biggest weakness", "path": "Part 12: Standard interview answers > What's your biggest weakness", "id": "whats-your-biggest-weakness", "level": 3, "words": 31 }, { "heading": "What's your biggest failure", "path": "Part 12: Standard interview answers > What's your biggest failure", "id": "whats-your-biggest-failure", "level": 3, "words": 101 }, { "heading": "Tell me about a conflict with a colleague", "path": "Part 12: Standard interview answers > Tell me about a conflict with a colleague", "id": "tell-me-about-a-conflict-with-a-colleague", "level": 3, "words": 141 }, { "heading": "Tell me about a time you were overruled", "path": "Part 12: Standard interview answers > Tell me about a time you were overruled", "id": "tell-me-about-a-time-you-were-overruled", "level": 3, "words": 31 }, { "heading": "Tell me about a time you missed a deadline", "path": "Part 12: Standard interview answers > Tell me about a time you missed a deadline", "id": "tell-me-about-a-time-you-missed-a-deadline", "level": 3, "words": 50 }, { "heading": "Tell me about something you shipped and later shut down", "path": "Part 12: Standard interview answers > Tell me about something you shipped and later shut down", "id": "tell-me-about-something-you-shipped-and-later-shut-down", "level": 3, "words": 177 }, { "heading": "Tell me about learning a domain cold, and what it cost", "path": "Part 12: Standard interview answers > Tell me about learning a domain cold, and what it cost", "id": "tell-me-about-learning-a-domain-cold-and-what-it-cost", "level": 3, "words": 185 }, { "heading": "Tell me about delivering bad news", "path": "Part 12: Standard interview answers > Tell me about delivering bad news", "id": "tell-me-about-delivering-bad-news", "level": 3, "words": 149 }, { "heading": "Did you leave ecommerce", "path": "Part 12: Standard interview answers > Did you leave ecommerce", "id": "did-you-leave-ecommerce", "level": 3, "words": 36 }, { "heading": "Who would vouch for you, and what would they say", "path": "Part 12: Standard interview answers > Who would vouch for you, and what would they say", "id": "who-would-vouch-for-you-and-what-would-they-say", "level": 3, "words": 107 }, { "heading": "What would you cost", "path": "Part 12: Standard interview answers > What would you cost", "id": "what-would-you-cost", "level": 3, "words": 72 }, { "heading": "Why you", "path": "Part 12: Standard interview answers > Why you", "id": "why-you", "level": 3, "words": 171 }, { "heading": "Where do you see yourself", "path": "Part 12: Standard interview answers > Where do you see yourself", "id": "where-do-you-see-yourself", "level": 3, "words": 74 }, { "heading": "What motivates you", "path": "Part 12: Standard interview answers > What motivates you", "id": "what-motivates-you", "level": 3, "words": 74 }, { "heading": "How do you handle ambiguity", "path": "Part 12: Standard interview answers > How do you handle ambiguity", "id": "how-do-you-handle-ambiguity", "level": 3, "words": 97 }, { "heading": "How do you prioritize", "path": "Part 12: Standard interview answers > How do you prioritize", "id": "how-do-you-prioritize", "level": 3, "words": 46 }, { "heading": "Where do you want to grow", "path": "Part 12: Standard interview answers > Where do you want to grow", "id": "where-do-you-want-to-grow", "level": 3, "words": 57 }, { "heading": "What questions do you have for us", "path": "Part 12: Standard interview answers > What questions do you have for us", "id": "what-questions-do-you-have-for-us", "level": 3, "words": 61 }, { "heading": "Part 13: FAQ", "path": "Part 13: FAQ", "id": "part-13-faq", "level": 2, "words": 17 }, { "heading": "The work and the approach", "path": "Part 13: FAQ > The work and the approach", "id": "the-work-and-the-approach", "level": 3, "words": 440 }, { "heading": "The builds", "path": "Part 13: FAQ > The builds", "id": "the-builds", "level": 3, "words": 430 }, { "heading": "Failures and judgment", "path": "Part 13: FAQ > Failures and judgment", "id": "failures-and-judgment", "level": 3, "words": 294 }, { "heading": "Working together", "path": "Part 13: FAQ > Working together", "id": "working-together", "level": 3, "words": 351 }, { "heading": "Part 14: Engagement shape, capacity, contact", "path": "Part 14: Engagement shape, capacity, contact", "id": "part-14-engagement-shape-capacity-contact", "level": 2, "words": 0 }, { "heading": "What an engagement looks like", "path": "Part 14: Engagement shape, capacity, contact > What an engagement looks like", "id": "what-an-engagement-looks-like", "level": 3, "words": 149 }, { "heading": "Rates", "path": "Part 14: Engagement shape, capacity, contact > Rates", "id": "rates", "level": 3, "words": 134 }, { "heading": "Capacity and logistics", "path": "Part 14: Engagement shape, capacity, contact > Capacity and logistics", "id": "capacity-and-logistics", "level": 3, "words": 36 }, { "heading": "Contact", "path": "Part 14: Engagement shape, capacity, contact > Contact", "id": "contact", "level": 3, "words": 51 }, { "heading": "Abstract", "path": "Abstract", "id": "abstract", "level": 2, "words": 254 } ], "chunks": [ { "heading": "Front page", "path": "Front page", "content": "Everything after this is the appendix. If this page settles it, stop here.\n\n**Positioning.** I install business operating systems and the AI layer on top of them. The wedge is 1 sentence: you don't have an AI problem, you have an operating system problem. I build the proof before I sell the service.\n\n**Track record.**\n\n| Role | Organization | The number | How you'd check it |\n|---|---|---|---|\n| Owner and operator, ecommerce and Amazon FBA | Own brands | 7 figures in annual revenue at peak | Seller peers, on request |\n| Commercial mortgage real estate | Named on request | Deals structured over $10 million | Former colleagues, on request |\n| Owner and operator, still running it | An FBA brand on Amazon.ca | Still selling, most recent return filed | Storefront on request |\n| Founder, since Q2 2026 | Own AI automation consultancy | 27 projects tracked, 23 built | The 3 links below, then a screen share |\n\nDates, titles, firm names and 2 references go out on request, same day, once I've asked the people involved. Everything in the table above is exact. Pre-revenue on the consultancy is a sequencing decision and I explain it in Part 2.\n\n**Three things you can open right now, without me.**\n\n1. [seanfeng.com/demos/context-tax/](https://seanfeng.com/demos/context-tax/). A working single-file tool. No signup, no server, all computation in your browser. Read the source with view-source if you want to check the claim.\n2. [bookhalter.com](https://bookhalter.com). A live coming-soon page and waitlist for an accounting product, running as its own Cloudflare Worker with D1. The application behind it is built and is not deployed. Nobody's books are in it. That distinction is stated on this page and it stays stated.\n3. [www.iamspeculating.com/mcp](https://www.iamspeculating.com/mcp). A creator-research MCP server I run, publicly reachable, and it will correctly refuse you. The wall answering correctly is the part you can verify from outside.", "id": "front-page", "level": 2, "index": 0, "outlineIndex": 0, "part": 1, "partCount": 2, "words": 317, "tokens": 490 }, { "heading": "Front page", "path": "Front page", "content": "**What that list doesn't cover, said plainly.** Of the 23 builds, 20 are private repositories on my own machine. Test counts and parity checks in Part 5 are self-reported until you sit on a screen share with me or I hand you the repository. The 1 exception is the CRE workbench, which is a single HTML file with 0 dependencies and 0 build step. It goes out on request after a call, and you can read every line without running anything.\n\n**Hold these 2 against me.** First, I am better at building than at presenting. I treated finished work as delivered work, and the backlog that belief produced is written down in Part 10 rather than described.\n\nSecond, almost all my evidence is solo. Every incident below is me and my own systems, and my counterparty history from the operating years is thinner on this page than the build record is. If what you need to know is how I behave inside a team I don't control, this document is weak on it. Part 7 has 3 ways to test that in week 1 instead of taking my word.\n\n**Contact.** sean@seanfeng.com. Builds and demos at [seanfeng.com](https://seanfeng.com). Send me the messiest process in your week in 5 sentences and I'll tell you what I'd delete, what I'd automate, and in what order, before anyone talks about money.", "id": "front-page--part-2", "level": 2, "index": 1, "outlineIndex": 0, "part": 2, "partCount": 2, "words": 226, "tokens": 315 }, { "heading": "The short version", "path": "Part 1: Who I am and what I'm optimizing for > The short version", "content": "I install business operating systems and the AI layer on top of them. I build the proof before I sell the service.", "id": "the-short-version", "level": 3, "index": 2, "outlineIndex": 2, "part": 1, "partCount": 1, "words": 22, "tokens": 29 }, { "heading": "What I do", "path": "Part 1: Who I am and what I'm optimizing for > What I do", "content": "I run an AI automation consultancy. Every owner wants AI. Almost none have a system to put it on.\n\nMy clients are owners still standing in the middle of their own operations. Every routine decision, every follow-up, every exception routes through them. They know they should be using AI. They have a disorganized stack of tools and no idea what to automate first. They want a system and a ranked order of operations.\n\nAlongside that I build. As of 2026-07-28 the count is 27 projects tracked: 23 built, 3 in progress, 1 specced and not started. Every row names its status, its goal, and where the code lives. When a status changes, the row changes in the same session.", "id": "what-i-do", "level": 3, "index": 3, "outlineIndex": 3, "part": 1, "partCount": 1, "words": 119, "tokens": 167 }, { "heading": "What I'm optimizing for", "path": "Part 1: Who I am and what I'm optimizing for > What I'm optimizing for", "content": "1. Landing the first client of the consultancy.\n2. Shipping credibility proof a stranger can inspect without talking to me.\n3. Closing the gap between what I build and what I publish, which is the widest gap in my operation.\n\nI lead with the work rather than a resume. Everything a resume would claim is below, with the evidence attached and the gaps in that evidence named.", "id": "what-im-optimizing-for", "level": 3, "index": 4, "outlineIndex": 4, "part": 1, "partCount": 1, "words": 67, "tokens": 94 }, { "heading": "What I'm not optimizing for", "path": "Part 1: Who I am and what I'm optimizing for > What I'm not optimizing for", "content": "Volume, hourly billing, or being the cheapest bid.", "id": "what-im-not-optimizing-for", "level": 3, "index": 5, "outlineIndex": 5, "part": 1, "partCount": 1, "words": 8, "tokens": 13 }, { "heading": "Part 2: Professional history with real numbers", "path": "Part 2: Professional history with real numbers", "content": "The track record table is on the front page. This part is what came out of each role.", "id": "part-2-professional-history-with-real-numbers", "level": 2, "index": 6, "outlineIndex": 6, "part": 1, "partCount": 1, "words": 18, "tokens": 22 }, { "heading": "Ecommerce and Amazon FBA", "path": "Part 2: Professional history with real numbers > Ecommerce and Amazon FBA", "content": "I ran 7-figure ecommerce and Amazon FBA businesses, and I still run one on Amazon.ca. Storefront on request. Its books and its filings are current, which is the least glamorous evidence of a live business I can offer and the hardest to fake. In seller communities that makes me a peer, not a vendor.\n\nThat business taught me unit economics down to the penny. Not gross margin on a slide. The real per-unit stack: landed cost, referral fee, FBA fulfillment fee, storage, refunds, promotions, and the ad spend billed to a credit card that never appears in a settlement report at all.\n\nThe survival line is TACOS, meaning total advertising cost of sale, ad spend as a percentage of all sales rather than just ad-attributed sales. Sub-10 is the difference between thriving and dying. That single number catches the 2 ways an Amazon brand quietly fails at once: paying too much to acquire, and depending on paid to move product that should be moving organically.", "id": "ecommerce-and-amazon-fba", "level": 3, "index": 7, "outlineIndex": 7, "part": 1, "partCount": 1, "words": 165, "tokens": 240 }, { "heading": "Commercial mortgage real estate", "path": "Part 2: Professional history with real numbers > Commercial mortgage real estate", "content": "I structured commercial real estate deals over $10 million. Role, firm and years go out on request, with the former colleagues who can confirm them.\n\nThree things came out of it.\n\n1. **Risk first.** Every number in an offering memorandum is a claim made by someone who wants the deal to close. T12 actuals beat pro forma every time. When only pro forma exists, flag every value rather than quietly absorbing it.\n2. **Paperwork is the constraint.** The volume of documents that have to be read, reconciled, and re-keyed by a person is what caps how many deals a shop can process. Not capital, not sourcing. Attention.\n3. **Deals die from slowness more than from bad terms.** A shop running a 30-day marketing period is fast, and that speed usually means the intake work is being absorbed by someone's evenings.\n\nThe third one changed how I build. My automation work targets the intake layer before the analysis layer. Analysis is where people assume the value is, because analysis is where the judgment is. The bottleneck is transcription, not judgment. Give an underwriter back the 4 hours of re-keying and you haven't replaced their judgment, you've given them more deals to point it at.", "id": "commercial-mortgage-real-estate", "level": 3, "index": 8, "outlineIndex": 8, "part": 1, "partCount": 1, "words": 203, "tokens": 297 }, { "heading": "Why 2 domains instead of one", "path": "Part 2: Professional history with real numbers > Why 2 domains instead of one", "content": "Jack of all trades, master of some. Range is a skill, not a compromise.\n\nThe first is a penny business. Margin lives in the fourth decimal, the feedback loop is daily, and the enemy is cost creep you can't see. The second is a paperwork business. Margin lives in the terms, the feedback loop is quarterly, and the enemy is time. Neither taught me the other's answers. Both taught me the same move: find the number that actually decides the outcome, then build the process that protects it.\n\nA commercial mortgage shop re-keys an offering memorandum into a model. An FBA seller reconciles settlement reports against a bank statement. Same task. Extract numbers from a document produced by someone with an incentive to present them favorably, then verify them against a source system. Specialists rarely get to stand on both sides of that wall.", "id": "why-2-domains-instead-of-one", "level": 3, "index": 9, "outlineIndex": 9, "part": 1, "partCount": 1, "words": 144, "tokens": 211 }, { "heading": "The cross-application, concretely", "path": "Part 2: Professional history with real numbers > The cross-application, concretely", "content": "I wrote a buy-side diligence playbook for acquiring an online business, and the whole framework runs on a CRE translation:\n\n1. The listing P&L is the offering memorandum. A sales document, every number a claim to verify.\n2. The payment processor exports are the T12. Primary source, produced by a system with no incentive to flatter.\n3. Contract assignability review is the estoppel process. Does the thing you're buying survive the change of control?\n4. The inventory peg is the proration schedule. Same mechanics, different asset.\n\nPhase 1 rebuilds the P&L from primary sources with a month-by-month gross-to-cash bridge: orders to recognized revenue to net of discounts, refunds, chargebacks, taxes and fees, to processor payouts, to bank deposits. Processor payouts are not revenue. I know that because I've reconciled Amazon settlements against bank transfers and watched the 2 disagree by 5 figures for reasons that were all legitimate and all invisible.\n\nThere's no fixed variance tolerance in the playbook, deliberately. Legitimate timing differences can exceed 3%, and fabricated revenue can reconcile inside 1%. The bridge is the test, not a percentage.", "id": "the-cross-application-concretely", "level": 3, "index": 10, "outlineIndex": 10, "part": 1, "partCount": 1, "words": 181, "tokens": 291 }, { "heading": "Current status", "path": "Part 2: Professional history with real numbers > Current status", "content": "Pre-revenue by sequencing. I chose to ship credibility proof before selling. That's an order of operations, not a waiting room, and I'd make the same call again.", "id": "current-status", "level": 3, "index": 11, "outlineIndex": 11, "part": 1, "partCount": 1, "words": 27, "tokens": 41 }, { "heading": "Part 3: Core beliefs and how they translate into decisions", "path": "Part 3: Core beliefs and how they translate into decisions", "content": "Beliefs 1 through 5 and 7 through 10 are load-bearing and I act on all of them. Belief 6 is flagged as a hypothesis with the evidence I actually have, which is thin. Read that one differently from the rest.", "id": "part-3-core-beliefs-and-how-they-translate-into-decisions", "level": 2, "index": 12, "outlineIndex": 12, "part": 1, "partCount": 1, "words": 40, "tokens": 52 }, { "heading": "1. You don't have an AI problem. You have an operating system problem.", "path": "Part 3: Core beliefs and how they translate into decisions > 1. You don't have an AI problem. You have an operating system problem.", "content": "Most businesses reach for AI when the first move should be deleting 80% of a broken process. Bolt automation onto chaos and you get faster chaos.\n\n**Decision translation:** map how the business actually runs, in boxes and arrows on 1 page. If it can't be drawn on 1 page, it isn't ready to automate. No map, no build.", "id": "1-you-dont-have-an-ai-problem-you-have-an-operating-system-problem", "level": 3, "index": 13, "outlineIndex": 13, "part": 1, "partCount": 1, "words": 58, "tokens": 80 }, { "heading": "2. Everything reduces to tasks, and the word that matters is \"defined.\"", "path": "Part 3: Core beliefs and how they translate into decisions > 2. Everything reduces to tasks, and the word that matters is \"defined.\"", "content": "Any defined process can be automated. \"Defined\" does all the work in that sentence. Automation stopped being hard. Defining the process is where companies fail, before writing a single prompt.\n\n**Decision translation:** the first question isn't \"can AI do this.\" It's \"how much of this can AI carry?\" 20%, 80%. You price it, you don't guess it.", "id": "2-everything-reduces-to-tasks-and-the-word-that-matters-is-defined", "level": 3, "index": 14, "outlineIndex": 14, "part": 1, "partCount": 1, "words": 57, "tokens": 86 }, { "heading": "3. Complexity is oversold. I price for simplification, not difficulty.", "path": "Part 3: Core beliefs and how they translate into decisions > 3. Complexity is oversold. I price for simplification, not difficulty.", "content": "Business processes are not as complex as businesses make them out to be.\n\nThat cuts against me, and it should. If processes are simple, what is anyone paying for? Defining the process is the work. The fee is for judgment about what should exist, and for the discipline to delete 80% of a broken process before automating any of it.\n\n**Decision translation:** it settles pricing. Hourly billing pays more for complexity I just said isn't there. Flat monthly, same price whether the request is small or hard, no meter running on how long something takes to build. And the sentence that follows from it: this is simpler than you think, and here's the smaller thing you should build.", "id": "3-complexity-is-oversold-i-price-for-simplification-not-difficulty", "level": 3, "index": 15, "outlineIndex": 15, "part": 1, "partCount": 1, "words": 118, "tokens": 170 }, { "heading": "4. Orchestration is a commodity. Vision and taste are the moat.", "path": "Part 3: Core beliefs and how they translate into decisions > 4. Orchestration is a commodity. Vision and taste are the moat.", "content": "The tools to execute are cheap and getting cheaper. Wiring them together is a skill with a shrinking price. What doesn't commoditize is knowing what's worth building and recognizing quality when you see it.\n\n**The test I apply, so this isn't just a nice word.** Name every part of the system a competitor could buy for $50 a month. Then ask whether what's left would still be worth paying for. If it wouldn't, the build has no taste in it, it has assembly. That test is falsifiable and I run it before I start, not after.\n\n**Decision translation, both directions.** In July 2026 I needed a live-streaming site. An off-the-shelf server would have had it running in an afternoon. I rejected it, because as a credibility artifact someone else's binary is worth close to nothing. I kept 100% of the site as my own code and handed the expensive boring half, RTMP ingest and transcoding, to Cloudflare, where a 2-hour stream with 20 concurrent viewers costs about $2.40.\n\nThe same test killed a shortcut in the other direction. For an Android scanner, live edge detection is a rival's year-long moat and rebuilding it is a science project. Nobody would pay me for a worse version of a $0 dependency, so I took Google's ML Kit for capture and owned everything after it.\n\n**Where this belief is weakest.** \"Taste\" has no measurement attached and the $50 test only tells you whether a build is differentiated, not whether it's good. This is the claim in this document with the least evidence behind it. Hold me to the artifacts instead.", "id": "4-orchestration-is-a-commodity-vision-and-taste-are-the-moat", "level": 3, "index": 16, "outlineIndex": 16, "part": 1, "partCount": 1, "words": 267, "tokens": 382 }, { "heading": "5. Automate tasks, not people.", "path": "Part 3: Core beliefs and how they translate into decisions > 5. Automate tasks, not people.", "content": "Removing the repetitive 80% gives a team back the 20% only humans do: judgment, relationships, taste, care. If the plan is to gut the team and call it efficiency, I'm not the right person, and I'll say that on the first call before anyone has spent money finding out.\n\nThis isn't softness. The same lever points both directions, and which direction it points is a decision a person makes on purpose. I'd rather that decision be made out loud in week 1 than discovered in month 4.\n\n**Decision translation:** the Step-Up ladder has 4 rungs and no skipping. Hand-run while you watch everything. Reviewed, where you check every output. Spot-checked, with alerts on anomalies. Then hands-off.", "id": "5-automate-tasks-not-people", "level": 3, "index": 17, "outlineIndex": 17, "part": 1, "partCount": 1, "words": 116, "tokens": 172 }, { "heading": "6. Agent judgment is better than most people expect. Stated as a hypothesis, because that's what it is.", "path": "Part 3: Core beliefs and how they translate into decisions > 6. Agent judgment is better than most people expect. Stated as a hypothesis, because that's what it is.", "content": "The claim: given enough context and the ability to self-evolve, agents decide close to what a human would, and judgment quality tracks context depth more than model cleverness.\n\nI hold that opinion and I act on it. It is also the one belief in this section with no measurement behind it, and belief 10 says name the source or cut the claim, so here is the actual evidence and its size.\n\n**The measurement I have, sample size 1.** I ran a pre-build grill on a product of my own, teacher-os, and let an agent score it. It returned Skip on the full product for reasons I agreed with: no budget authority in that buyer, compliance exposure, a procurement wall. That matched the call I'd have made. In the same run I flagged 6 of its individual calls for my own veto. So the honest ratio is agreement on the top-level judgment and 6 overrides on the details, from 1 session. That is a data point, not a proof.\n\n**The counterexample, where deeper context changed the outcome.** On the knowledge-base build, a mechanical merge pass grouped 1,318 slugs into concepts by keyword. Then 25 writing agents holding the full card text caught roughly 40 collisions the mechanical pass had made. Same inputs, more context, different and better answer. That's the mechanism the belief rests on, and it's 1 build.\n\n**What would change my mind:** a run where an agent with deep context and a well-specified task makes a call I'd reverse, repeatedly, in a domain I know cold. I haven't collected that systematically. I should.\n\n**Decision translation:** my whole workspace is context substrate. Memory files, an append-only decisions log with reasoning attached, a references library, a story bank of real incidents with real numbers.", "id": "6-agent-judgment-is-better-than-most-people-expect-stated-as-a-hypothesis-because-thats-what-it-is", "level": 3, "index": 18, "outlineIndex": 18, "part": 1, "partCount": 2, "words": 293, "tokens": 429 }, { "heading": "6. Agent judgment is better than most people expect. Stated as a hypothesis, because that's what it is.", "path": "Part 3: Core beliefs and how they translate into decisions > 6. Agent judgment is better than most people expect. Stated as a hypothesis, because that's what it is.", "content": "**The boundary, which isn't a contradiction:** trusting judgment and gating irreversible actions are different axes. High trust in the decision, hard limits on blast radius. A machine-global command guard runs in front of every agent on this box, blocking the catastrophic and irreversible: disk wipes, force-pushes, repo deletion, killing shared runtimes. It deliberately allows recoverable damage, because over-blocking kills the agent's usefulness.", "id": "6-agent-judgment-is-better-than-most-people-expect-stated-as-a-hypothesis-because-thats-what-it-is--part-2", "level": 3, "index": 19, "outlineIndex": 18, "part": 2, "partCount": 2, "words": 62, "tokens": 113 }, { "heading": "7. Plain beats clever.", "path": "Part 3: Core beliefs and how they translate into decisions > 7. Plain beats clever.", "content": "If a step doesn't need judgment, don't give it any. A script that reformats a CSV is done forever. An AI step gets repriced at every model release and re-verified at every drift.\n\n**Decision translation:** build the plain parts, prove them, add AI only where judgment is required. And build 1 piece, run it, confirm the output, then build the next piece on what the first actually produced. Never assemble a whole pipeline and test it end to end for the first time. That's how you end up with something broken and no idea which piece broke it.", "id": "7-plain-beats-clever", "level": 3, "index": 20, "outlineIndex": 19, "part": 1, "partCount": 1, "words": 98, "tokens": 136 }, { "heading": "8. No black boxes, ever.", "path": "Part 3: Core beliefs and how they translate into decisions > 8. No black boxes, ever.", "content": "You see how everything works, always. You own everything we build. Code, prompts, docs.\n\nThe house rule: if you can't explain what a piece does, or why it made the call it made, you don't own it yet, and you won't be able to fix it when it breaks. Explain it or don't ship it.\n\n**Decision translation:** minimum access, read-only until write is proven necessary. The system runs on its own identity, not your personal logins. A full activity trail. And 1 of my 4 pre-build checks is Fallback: can a human take this back cold, tomorrow? If nobody could run it manually anymore, that kills the build. My CRE workbench ships as vanilla JavaScript with 0 dependencies and 0 build step, opening from a `file://` URL. You can read the whole thing, and it goes out on request after a call.", "id": "8-no-black-boxes-ever", "level": 3, "index": 21, "outlineIndex": 20, "part": 1, "partCount": 1, "words": 142, "tokens": 196 }, { "heading": "9. Verify, don't trust. Then run the control.", "path": "Part 3: Core beliefs and how they translate into decisions > 9. Verify, don't trust. Then run the control.", "content": "Every material claim traces to a source system you observed. Preferred evidence order: live screen-share, then read-only or auditor-observed access, then raw exports. Screenshots never.\n\nThe part almost nobody does is the control. A negative result means nothing until you've proven the instrument can detect a positive.\n\n**Decision translation:** skepticism, mechanically, is 2 questions. What does this number actually measure? And what would it look like if the measurement were wrong? If there's no answer to the second, the number isn't evidence yet.", "id": "9-verify-dont-trust-then-run-the-control", "level": 3, "index": 22, "outlineIndex": 21, "part": 1, "partCount": 1, "words": 83, "tokens": 139 }, { "heading": "10. Abstraction is a failure state.", "path": "Part 3: Core beliefs and how they translate into decisions > 10. Abstraction is a failure state.", "content": "\"Improved efficiency\" loses to \"cut deploy time from 40 minutes to 4.\" Name the source or cut the claim. Sourceless authority is the fastest way to lose me on a page.\n\n**Decision translation:** state confidence, separate what was measured from what was inferred, and flag assumptions rather than smoothing them. Hand me the comparison with the number. A figure with no reference range is doing half the work. Use the precise term, then define it inline: \"sub-10 TACOS, meaning ad spend under 10% of total sales.\" One clause, same sentence, no glossary.", "id": "10-abstraction-is-a-failure-state", "level": 3, "index": 23, "outlineIndex": 22, "part": 1, "partCount": 1, "words": 92, "tokens": 138 }, { "heading": "11. No failure stories means shallow expertise.", "path": "Part 3: Core beliefs and how they translate into decisions > 11. No failure stories means shallow expertise.", "content": "Anyone who has shipped can name a specific thing they broke, what the mechanism was, and what they changed. Not a category. A mechanism. If a person answers that question with \"we've had our share of learnings,\" they haven't shipped or they're hiding it, and I stop trusting the rest of the pitch.\n\nI apply the same test to myself in Part 8. Four incidents, first person, mechanism named in every one, with a figure attached wherever a figure exists.", "id": "11-no-failure-stories-means-shallow-expertise", "level": 3, "index": 24, "outlineIndex": 23, "part": 1, "partCount": 1, "words": 80, "tokens": 113 }, { "heading": "12. I believed the work would speak for itself. It doesn't.", "path": "Part 3: Core beliefs and how they translate into decisions > 12. I believed the work would speak for itself. It doesn't.", "content": "The belief I changed most recently, and it cost me real ground. Full accounting in Part 10.", "id": "12-i-believed-the-work-would-speak-for-itself-it-doesnt", "level": 3, "index": 25, "outlineIndex": 24, "part": 1, "partCount": 1, "words": 17, "tokens": 23 }, { "heading": "Part 4: The operating framework", "path": "Part 4: The operating framework", "content": "Four stages. A task moves through all 4 or it doesn't ship.", "id": "part-4-the-operating-framework", "level": 2, "index": 26, "outlineIndex": 25, "part": 1, "partCount": 1, "words": 12, "tokens": 15 }, { "heading": "Spot", "path": "Part 4: The operating framework > Spot", "content": "- **The Ask.** Before doing anything by hand: how much of this could AI carry? Not can it. How much.\n- **Zoom Out.** Once a quarter, point the same question at the whole business. What breaks first if volume doubled? That finds the bottleneck. What would double volume? That finds the opening. Run both, start with the break.\n- **Tripwires.** A task becomes a candidate when 1 of 4 fires. You've done it 3 or more times this month. Work queues up behind it. You'd never hand it to your best hire. It's copy-paste between 2 systems.\n- **The List.** Candidates go in a pipeline. Most stay there. Spotting is cheap. Building isn't.", "id": "spot", "level": 3, "index": 27, "outlineIndex": 26, "part": 1, "partCount": 1, "words": 113, "tokens": 157 }, { "heading": "Score", "path": "Part 4: The operating framework > Score", "content": "| Check | Question | Kills it when |\n|---|---|---|\n| Payoff | Hours saved times frequency, plus error cost avoided | Doesn't clear build cost in a quarter |\n| Exposure | Blast radius if wrong. Who sees it? Does money move? | High exposure, no review gate |\n| Fallback | Can a human take this back cold, tomorrow? | No. Nobody could run it manually anymore |\n| Upkeep | Drift, breakage, model changes | Upkeep eats the payoff |\n\nTwo gates sit in front of all 4. **Mapped:** boxes and arrows on 1 page or it isn't ready to score. **Named number:** every build moves new revenue, revenue per customer, or cost. Name which one. Curiosity isn't a number.\n\nThree outcomes, all valid. **Build. Shrink** (a smaller version clears, so rescore it). **Skip** (log why, move on).\n\nA clean skip is a win. Deleting a process beats automating it more often than anyone in this industry admits, and that's not a comfortable thing to say when you sell automation.", "id": "score", "level": 3, "index": 28, "outlineIndex": 27, "part": 1, "partCount": 1, "words": 173, "tokens": 237 }, { "heading": "Build", "path": "Part 4: The operating framework > Build", "content": "Plain parts first. Check as you go. Step-Up with no skipped rungs. And expect the first stretch to run slower than doing it by hand. New workflow, new checking habits. That's the cost of entry, not evidence it doesn't work. I tell people up front so they don't judge the system during the exact window where it's guaranteed to look worse.", "id": "build", "level": 3, "index": 29, "outlineIndex": 28, "part": 1, "partCount": 1, "words": 61, "tokens": 85 }, { "heading": "Run", "path": "Part 4: The operating framework > Run", "content": "Weekly pass. Three calls per asset: keep it and leave it alone, fix it (usually shrink scope or drop the AI step), or cut it (shut down, archive, log the lesson). Sunk cost isn't a reason to keep something running.", "id": "run", "level": 3, "index": 30, "outlineIndex": 29, "part": 1, "partCount": 1, "words": 40, "tokens": 54 }, { "heading": "The Log", "path": "Part 4: The operating framework > The Log", "content": "Every call goes in an append-only log with 4 parts: what was decided, why, what I considered and rejected, and who owns it.\n\nThe rejected alternatives earn their keep. When something goes bad later, the log tells you whether the call was wrong or the world changed. Those need different fixes and you can't tell them apart from memory.", "id": "the-log", "level": 3, "index": 31, "outlineIndex": 30, "part": 1, "partCount": 1, "words": 59, "tokens": 84 }, { "heading": "House positions", "path": "Part 4: The operating framework > House positions", "content": "1. Score before you build. Excitement isn't a reason.\n2. The best call is often Skip.\n3. Plain beats clever.\n4. No skipping rungs on Step-Up.\n5. Explain it or don't ship it.\n6. Cut without sentiment.", "id": "house-positions", "level": 3, "index": 32, "outlineIndex": 31, "part": 1, "partCount": 1, "words": 37, "tokens": 50 }, { "heading": "How to read this", "path": "Part 5: The build portfolio > How to read this", "content": "Everything below is a build. None of it is a client result and none of it is presented as one. These are systems I built and run for my own products and operations.\n\n**The verification limitation, stated first because it's the one that matters most to you.** No outside human has reviewed this code, and nothing here has had a user. The adversarial reviews I cite are model-run: a different vendor's model, read-only, against a repository. That catches a different class of bug than a peer would, and it is not a substitute for one. Test counts, parity checks and gate rounds in this section are self-reported. Every build below carries a line naming exactly what you can open yourself and what you can't.\n\n**How 23 builds fit into a short window.** Every dated build below lands between 2026-07-04 and 2026-07-27. That density is real and it has a mechanism rather than a mystery. Most of these started from specifications that already sat in a backlog. The implementation is written by parallel subagents against a written interface contract, in disjoint file lanes, and Part 6 has the rules that make that hold. What I write by hand is the specification, the gates, the review verdicts and the prose. What I orchestrate is the code. The orchestration claim is worth more with that split stated than without it, and both halves are checkable on a screen share.\n\nThree things to look for. **Real numbers, or the claim gets cut.** If a figure isn't here, it isn't known. **The gates, not the demo.** Most of these shipped to a bar called fixture-complete: every path exercised against deterministic fixtures, every paid call an explicit user action, live smoke logged as pending rather than quietly claimed. **The failures are load-bearing.** Four consecutive projects where a second model found money bugs the builder's own green suite missed.", "id": "how-to-read-this", "level": 3, "index": 33, "outlineIndex": 33, "part": 1, "partCount": 1, "words": 312, "tokens": 461 }, { "heading": "cre-dealdesk", "path": "Part 5: The build portfolio > cre-dealdesk", "content": "Built and QA-hardened on 2026-07-19.\n\n**Open it:** private repository, and the 1 build in this portfolio you can fully inspect without me running anything. It is a single HTML file with 0 dependencies and 0 build step, and it goes out on request after a call. It opens from `file://` and you can read every line of the logic.\n\n1. **143 tools by acquisition stage.** That splits into 61 calculators, 13 screeners, 47 checklists and 22 templates. Of those, 67 compute bespoke logic against hand-verified test vectors, and 7 are deliberately generic, each with the reason written down.\n2. **A shared Deal object.** It carries 75 fields and a 21-step derived chain. Every tool reads and writes the same spine, which is the difference between a workbench and 143 dead forms.\n3. G1 through G5 gates dashboard, plus a printable one-page deal memo.\n4. **Tests:** 300 of 300 green.\n5. A paired extraction skill: drop in an OM or a T12, get confidence-tagged import JSON. Extraction only. It never invents a number, writes null for anything it can't find, never averages conflicting numbers (takes the more conservative and flags the conflict), and turns anything outside a plausible range into a question for the broker rather than a silent edit.\n\nTwo modeling conventions locked by hand, because leaving them implicit is how 2 analysts get 2 answers from the same deal: terminal NOI compounds rent growth for the exit math, and DSCR is always fully amortizing.\n\nBreadth was right because the specs already existed. Turning a spec backlog into working tools is mechanical work that parallelizes. A minimal 12-tool version would have thrown away the part already paid for.", "id": "cre-dealdesk", "level": 3, "index": 34, "outlineIndex": 34, "part": 1, "partCount": 1, "words": 278, "tokens": 416 }, { "heading": "deal-os", "path": "Part 5: The build portfolio > deal-os", "content": "Greenlit and verified the same day, 2026-07-18. A CRE decision knowledge base from a 14-course corpus.\n\n**Open it:** private, and it stays private. Sample cards and the concept map on a screen share.\n\nA deterministic worklist script selected 359 lessons from 1,181 with 0 missing transcripts. A taxonomy seed pass produced 60 concepts and caught that 3 of the 4 files labeled as framework PDFs were mislabeled. A pass of 76 parallel extraction agents produced 2,968 candidates with 0 agent failures. Mechanical grouping plus merge review collapsed 1,318 slugs to 179. Then 25 more agents (20 card writers, 3 keystone elevators, a playbook builder, a map builder) with 0 failures, which caught roughly 40 keyword-collision mis-merges the mechanical pass had made.\n\nDelivered: a decision playbook across S0 to S10 with 272 card links, 179 concept cards, a concept map, a 2-way index of 179 concepts against 75 sources, and an open-questions file holding 15 real contradictions in the source teaching rather than smoothing them over. Every number cites its source. Transcription-garbled figures tagged low-confidence rather than laundered into clean-looking data.\n\nCost about 26M subagent tokens, roughly 2.5x my 7M to 9M estimate, because the transcripts ran richer than planned. I logged the miss rather than rounding it away.", "id": "deal-os", "level": 3, "index": 35, "outlineIndex": 35, "part": 1, "partCount": 1, "words": 208, "tokens": 332 }, { "heading": "ledger-app and Bookhalter", "path": "Part 5: The build portfolio > ledger-app and Bookhalter", "content": "Shipped 2026-07-08 at 46 of 46 tasks, 209 tests plus 27 Playwright end-to-end tests walking the full flow: seed, invoice, share, pay, reconcile to zero, then 5 reports that cross-check against each other.\n\n**Open it:** [bookhalter.com](https://bookhalter.com) is live and is a coming-soon page plus a waitlist, running as its own Cloudflare Worker with D1. The application itself is a private repository, is not deployed, and has no users. Walkthrough on request.\n\nThe architecture is the point, because accounting software that's wrong is worse than none. **Integer cents everywhere** behind a branded type, so floats never touch money. **Append-only journal**, with immutability and balancing enforced by database triggers rather than application code a future feature can route around. **Two write paths only:** post an entry, or reverse one. Module boundaries enforced by a gate script so the layering can't quietly erode.\n\nA read-only adversarial review by a different vendor's model found 6 issues that 102 green tests had missed, 2 critical: a double-reversal race, and JSON float collapse at API ingress. The re-review then caught my first fix as insufficient. A magnitude cap didn't close it. A lexical raw-body guard did.\n\nThe harder correction came later. The API routes trusted a client-supplied org id. Cross-org writes were possible with any role, and report reads were unauthenticated. The suite was green the whole time, because it tested what the features did, not what an attacker would do. Fixed by pinning all 66 routes to the session org behind 1 helper, with share-token endpoints deliberately exempt and documented as such. After the fix: 549 tests and 29 end-to-end runs green on a production build, committed 2026-07-21.\n\nIt became **Bookhalter** on 2026-07-21, with a marketing site and 7 documentation pages built inside the app by 4 parallel subagents against a fixed token and voice contract.", "id": "ledger-app-and-bookhalter", "level": 3, "index": 36, "outlineIndex": 36, "part": 1, "partCount": 2, "words": 301, "tokens": 481 }, { "heading": "ledger-app and Bookhalter", "path": "Part 5: The build portfolio > ledger-app and Bookhalter", "content": "Its privacy stance was decided on 2026-07-22, before a single customer. Real customer PDFs are never retained. A production failure gets rebuilt as a synthetic fixture with fake data. Production logging is metadata only: document type, layout family, confidence, correction count. The failure signal is the customer's own correction to an extracted transaction, which costs them nothing and tells you exactly where the model was wrong. Bank statements are financial PII, \"anonymized\" ones are still re-identifiable, and consent buried in terms of service isn't consent. The positioning consequence is a sentence a competitor retaining uploads structurally cannot say: your statements train nothing, and they're deleted after processing.\n\nA constraint written into body copy rather than fine print: this is preparation only, an accountant still reviews before filing. Promising an outcome you don't control is the fastest way to lose the trust the product is built on.", "id": "ledger-app-and-bookhalter--part-2", "level": 3, "index": 37, "outlineIndex": 36, "part": 2, "partCount": 2, "words": 146, "tokens": 242 }, { "heading": "amazon-fba-dashboard", "path": "Part 5: The build portfolio > amazon-fba-dashboard", "content": "**Open it:** private, and it can't be made public in any useful form. It runs against my own live Amazon seller account, so a public instance would be a public copy of my books. Screen share on request, against real data, which is the strongest version of this one anyway.\n\n**v2** rebuilt an FBA reporting hub as a real application. It shipped with 470 tests and credential handling behind a real interface instead of an env file. Parity enforced mechanically rather than by eyeball: I executed the old template's own JavaScript and the real Python engines to generate golden files (342 engine tests), then diffed the imported database against the live original at plus or minus a penny. It also fixed a structural defect. Ad history beyond Amazon's 95-day lookback had only ever lived in stale cache directories. Moving it into a permanent daily table surfaced $9,659 of real spend the old system couldn't see.\n\nThen I looked at v2 and my verdict was that I'd built the wrong thing well. v2 faithfully ported the old one-page UI, and the asset was the data underneath rather than the wrapper around it.\n\n**v3** started from the data. It runs 33 routes across 8 nav groups, 9 agents across 5 gated waves, tables first with charts only where a shape earns one, and a cited natural-language query tool with 12 read-only tools and store scope injected server-side so it can't be talked out of its boundary.\n\n**Tests:** 538. **Parity:** re-run after every UI wave, 7,460 checks pass at plus or minus $0.01.\n\nThe page I'm proudest of is an audit page nobody asked for. The raw monthly ad column is zero for every month, so 100% of the ad figures shown are reconstructed from union history. The coverage page says that out loud instead of presenting reconstructed numbers as measured ones.", "id": "amazon-fba-dashboard", "level": 3, "index": 38, "outlineIndex": 37, "part": 1, "partCount": 1, "words": 309, "tokens": 446 }, { "heading": "gtm-os", "path": "Part 5: The build portfolio > gtm-os", "content": "Built fixture-complete 2026-07-17. Roughly 102 commits, 344 connector tests, 12 pages, inbound and outbound lanes feeding 1 pipeline.\n\n**Open it:** private repository. Walkthrough on request. Fixture mode runs the whole surface with 0 vendor credentials, so a demo doesn't need your keys or mine.\n\nThe architecture bet is bring-your-own-tools: a 13-slot provider mesh, 8 wired and 5 declared, 6 live adapters, so users connect the roughly 70-tool stack they already pay for instead of migrating onto mine. Secrets are per-slot, git-excluded, with 3-form fingerprint redaction. The webhook surface is signed and idempotent.\n\nThe review is the part worth studying. All code was written by subagents. The main session wrote 0 build code and reviewed every package. A different vendor's model ran read-only adversarial gates.\n\n**Gate rounds:** 6. **Defects found that the builders' own green suites missed:** roughly 35. The most valuable clustered where nobody was looking, in the 2 credential layers. The final round found 2 critical credential-exfiltration paths in the new LLM surface. An environment key echoed into git, and vendor-supplied keys reaching a third-party model through unscanned search evidence.\n\nTwo honesty decisions shipped with it. Slots that were adapter-ready but not consumer-wired got relabeled rather than claimed, with every deferred capability named in the ship-QA document. And 1 limitation is written down that testing can't fix: a malicious first-party adapter can't be attested against, because it sits inside the trusted-code boundary.\n\nTwo-way CRM sync was deliberately cut to v1.1. Two writable sources of truth is the exact drift I'd warn a client about, so shipping it would have contradicted the pitch.", "id": "gtm-os", "level": 3, "index": 39, "outlineIndex": 38, "part": 1, "partCount": 1, "words": 263, "tokens": 435 }, { "heading": "diligence-os", "path": "Part 5: The build portfolio > diligence-os", "content": "Built 2026-07-20. Its first live run returned a walk verdict on a real listing.\n\n**Open it:** private. I can send a redacted version of that Gate 1 report, which is the actual artifact worth reading here.\n\nNine phases, 107 parser-seeded checks, 3 gates, evidence-enforced so a check can't be marked clear without something backing it. API plus SQLite, client-report export with provenance stripped, 9 of 9 tests green.\n\nIt ran against a live marketplace listing the same day. Verdict at Gate 1: walk. The storefront wasn't serving. The domain had been dropped and re-registered, checked against the registry directly, against a listing claim of several years of continuous age. An asking multiple that didn't square with the stated profit. Inconsistent profit figures across the listing's own materials.\n\nTwo corrections came out of that run, both now doctrine. **Never call a site dead from a datacenter vantage.** My first read was that the storefront was offline. It wasn't. It was bot-gated and returning 409s to datacenter IPs. The finding survived on other grounds, but the reasoning was wrong and would have been wrong on a healthy site. **The window is where the distortion lives.** The headline monthly profit figure was a trailing-twelve-month average masking the actual current month. Nothing was invented. The window was chosen. That's harder to catch than a fake number, because every input is real.", "id": "diligence-os", "level": 3, "index": 40, "outlineIndex": 39, "part": 1, "partCount": 1, "words": 227, "tokens": 353 }, { "heading": "seatfill", "path": "Part 5: The build portfolio > seatfill", "content": "An autonomous meeting agent with its own email identity. Invite its address and it joins Zoom, Meet or Teams, records locally, transcribes, summarizes, and emails the result. Built in 1 session on 2026-07-22, with 191 tests green.\n\n**Open it:** private repository. Walkthrough on request. The end-to-end tail is live-verified against a real stream: whisper transcript, model summary, delivered email.\n\nManaged bot APIs cost roughly $0.65 per hour and would have been working in days. The plan was mid-approval when I changed the call to building it outright. Full ownership, $0 per meeting, no third party in the room.\n\nIt fit in 1 session because I refused to write code first. Four de-risk probes ran before anything got built. Mail retrieval and calendar parsing against the real inbox: pass. System loopback audio capture: pass. Meeting-join reconnaissance: pass. Wake-from-sleep task registration: registers, but wake timers turned out to be disabled in the power plan. Found before it could silently miss a meeting.\n\nAn integration bug worth naming. A mute-state fallback got removed entirely, because its contains-match on \"mute microphone\" also matched \"Unmute microphone.\" A state-blind toggle would have unmuted a muted mic in a live meeting.\n\nThe limits are listed in the repo rather than hidden. Machine off means a missed meeting. One meeting at a time. Selector drift is my maintenance burden, so every adapter keeps a named drift surface and saves a failure snapshot when it breaks.", "id": "seatfill", "level": 3, "index": 41, "outlineIndex": 40, "part": 1, "partCount": 1, "words": 237, "tokens": 375 }, { "heading": "scanstack", "path": "Part 5: The build portfolio > scanstack", "content": "An Android document scanner that covers the core scan-to-PDF loop. Shipped 2026-07-15: 20 of 20 tasks, clean-clone gate green (full debug build, 46 unit tests, lint at 0 errors). Apache-2.0, fully on-device.\n\n**Open it:** Apache-2.0 licensed and not yet pushed to a public repository, which is exactly the gap Part 10 is about. A sideload build and the source go out on request today. Publishing it is on the backlog, and it has been on the backlog since 2026-07-15.\n\nLive edge detection done well is a competitor's year-long moat. Google's ML Kit ships that capture experience in 1 dependency of roughly 300KB. Capture is theirs, everything after is mine: searchable library on a local full-text index, OCR, drag-reorder multi-page documents, PDF assembly. The trade-off got named rather than buried: it requires Google Play services, so it can't go in the main F-Droid repository. The scan engine sits behind an interface so a custom camera pipeline can replace it later without touching anything else.", "id": "scanstack", "level": 3, "index": 42, "outlineIndex": 41, "part": 1, "partCount": 1, "words": 163, "tokens": 251 }, { "heading": "opsfloor", "path": "Part 5: The build portfolio > opsfloor", "content": "A self-hosted 3D ops deck for the local agent fleet, with a needs-me queue where agents blocked on a human raise their hands. MIT licensed, built from scratch. Idea to code-complete in 1 session on 2026-07-17: 33 of 34 tasks, security review pass, 3 work packages built in parallel against a protocol document as the contract.\n\n**Open it:** MIT licensed, npm-packaged locally, not yet published to a public registry. Same backlog, same reason.\n\nThe part I'd point at isn't the count. The kill criteria were pre-committed before a line was written. A 2-week timebox on Stage 1, slip means cut scope not extend. A dogfood test 2 weeks after the finale, and no daily unprompted use means park it. Excitement is exactly the state in which you'll rationalize continuing, which is why the stopping rule has to be written while you're still excited.", "id": "opsfloor", "level": 3, "index": 43, "outlineIndex": 42, "part": 1, "partCount": 1, "words": 143, "tokens": 211 }, { "heading": "The OS family", "path": "Part 5: The build portfolio > The OS family", "content": "Four operating systems share one spine, cut from creative-os v2 (the origin vault, agent rail, and 10-page shell, still in fixture mode with live connections pending). They test 1 claim: the kernel generalizes.\n\n**Open them:** all private. Each runs a fixture mode with 0 credentials, so any of them demos on a screen share in 10 minutes.\n\n1. **business-os** (2026-07-04). Entity and relation data graph, module contract, streaming chat with 7 graph-backed tools, self-build loop, at 66 of 66 tasks. The invoicing module was written live by a spawned CLI in 525 seconds and left enabled on the demo workspace as evidence the loop works.\n2. **seo-os** (2026-07-09). Local SEO audits. Five gated phases, client vault, live and fixture providers behind 1 interface, plus a leak canary that returned 0 hits.\n3. **property-os** (2026-07-09). Property management for operators running 50 to 500 doors. The live finale exercised it rather than screenshotting it: signing an application moved occupancy from 91.7% to 92.5%, the owner-approval gate held on a work order, and a run then commit then undo cycle was verified in the vault's git history, and 11 routes walked in a browser with 0 console errors.\n4. **teacher-os** (2026-07-09). All 22 tasks done and all 5 flows verified live, including the connector-down degradation path. Its own pre-build grill scored the full product a Skip, because teachers lack budget authority and district procurement is a wall. The shrunk version cleared: 1 evening of agent time to prove the kernel works outside business operators. Skip on the product, Build on the proof.\n\nThe differentiator against the incumbents in each vertical is the same in all 4. Every agent action commits to a git-backed vault, so you can read exactly what the AI did and undo it. No incumbent can show you that log.", "id": "the-os-family", "level": 3, "index": 44, "outlineIndex": 43, "part": 1, "partCount": 1, "words": 300, "tokens": 456 }, { "heading": "The smaller tier", "path": "Part 5: The build portfolio > The smaller tier", "content": "- **tubescout** (2026-07-24). A creator-research MCP server. **Open it:** [www.iamspeculating.com/mcp](https://www.iamspeculating.com/mcp), publicly reachable, and it will correctly refuse you. Access is per person and revocable, and the metered backend it sits on is capped per call so a runaway loop can't run up the bill.\n- **brulee** (2026-07-23). A private Android floating assistant, 3 releases in a week. **Open it:** private, APK on request. Worth citing for the debugging. \"Feels slow\" is not a bug report, so I measured 3 causes in order of size: mirror calls on the hot path at 0.6 to 1.6 seconds, a non-streamed model call making time-to-first-byte equal time-to-whole-answer, and the real floor, a 41k-token prefill costing 6.3 seconds for a trivial reply. The first 2 were fixes. The third needed an architecture change, and the trade-off got stated rather than hidden: screen questions now lose conversation memory, text chat keeps it.\n- **onair** (2026-07-27). A single-broadcaster live streaming site. **Open it:** private, and not yet deployed. Its fixture mode runs the whole site against a public test stream with 0 credentials, so it demos before any account or key exists. All 8 endpoints and both states verified end to end.\n- **marginalia** (2026-07-15). A browser extension that annotates any page including local files, never mutating the page's DOM and anchoring by text quote so highlights survive re-renders. **Open it:** private, unpacked extension on request.\n- **capacity** (2026-07-20). A private local dashboard showing remaining limits and reset times across my AI coding providers without installing anyone's desktop binary. **Open it:** private and local by design.\n- **hexcalc**, plus a self-built keyword alert watcher for Reddit and Hacker News.", "id": "the-smaller-tier", "level": 3, "index": 45, "outlineIndex": 44, "part": 1, "partCount": 1, "words": 272, "tokens": 447 }, { "heading": "Dogfooding", "path": "Part 5: The build portfolio > Dogfooding", "content": "My operating system tracks the pipeline, drafts content, and audits its own gaps weekly. Parts of my public writing were drafted inside it. Every manual task of mine that repeats 3 times becomes a candidate, gets scored, and either gets built or gets logged as a skip with a reason. The consultancy is the second customer of that loop. I'm the first.\n\nThe Amazon side is wired end to end into my own seller account. A scheduled job every Monday morning rebuilds the account dashboard and refreshes restock recommendations. On any step failure it emails me the failed step and 60 lines of log, then stops. No retry. A failed run waits for next Monday, because a silent retry loop on financial data is worse than a missed week.", "id": "dogfooding", "level": 3, "index": 46, "outlineIndex": 45, "part": 1, "partCount": 1, "words": 129, "tokens": 182 }, { "heading": "Parallel agents don't collide when the lanes are drawn first", "path": "Part 6: Method > Parallel agents don't collide when the lanes are drawn first", "content": "The claim about these builds is methodological, not about speed. Parallel agents with a written interface contract and disjoint file lanes do not collide.\n\nEvidence across 4 builds: 76 extraction agents then 25 writing agents at 0 failures on the knowledge base. Four parallel agents inside 1 repo on the accounting build. Three parallel git worktrees on the property build with 0 merge conflicts, same pattern on the Android build when routing changed mid-session. Parallel worktrees for pages and adapters on the go-to-market build, kernel deliberately serialized.\n\nThe rules that make it hold:\n\n1. A single written contract agreed before any agent starts. A protocol document, an interface file, a data contract. Not a description in a prompt.\n2. Disjoint file lanes. Not \"try not to overlap.\" Assigned.\n3. Pre-assign anything globally ordered. On the accounting build 1 agent got migrations 0006 to 0009, another 0010 to 0019, another 0020 to 0029. Collisions there are silent and expensive.\n4. Agents don't commit. The orchestrator verifies and commits scoped.\n5. Serialize the kernel. Parallelize the leaves.\n6. Pass the printed value, never the remembered one. When a slice list, a chunk map or an assignment table has already been computed to a file, print the file and paste from the print. A capable system under time pressure fails by plausible confabulation, and memory produces something with the right shape, the right count and wrong contents faster than reading would have.", "id": "parallel-agents-dont-collide-when-the-lanes-are-drawn-first", "level": 3, "index": 47, "outlineIndex": 47, "part": 1, "partCount": 1, "words": 239, "tokens": 373 }, { "heading": "Builders build, a different model reviews", "path": "Part 6: Method > Builders build, a different model reviews", "content": "Four consecutive projects where a second model from a different vendor, running read-only, found money bugs the builder's own green test suite had missed.\n\nA count is not evidence, so here are the 3 where I can name the defect. The fourth run's findings I never itemized by name, and I'd rather say that than pad the list.\n\n1. **Accounting build.** A double-reversal race and a JSON float collapse at API ingress, both found after 102 tests were green. The re-review then rejected my first fix. A magnitude cap didn't close the class. A lexical raw-body guard did.\n2. **Go-to-market build.** Two credential-exfiltration paths in the newest surface, found in the final gate round of 6: an environment key echoed into git, and vendor-supplied keys reaching a third-party model through unscanned search evidence. Both sat in a credential layer, which is where the most valuable findings clustered across all 6 rounds.\n3. **CRE workbench.** Provenance leaking into client-facing text while my own lint stayed clean the entire time, because the lint watched vocabulary and the leak was metadata. Caught by adversarial rounds run by something that hadn't written the stripping script. Full account in Part 8.\n\nA test suite is a record of what the builder thought to check. A different model brings different assumptions about what could go wrong. Read-only matters, because a reviewer that can also patch will fix the symptom it noticed instead of reporting the class of problem it found.\n\nThis is not peer review and I don't present it as peer review. It is 1 system checking another, both operated by me. It catches a real and useful class of defect. It does not catch the class a person who disagrees with my priorities would catch, and I have no evidence about that class at all.", "id": "builders-build-a-different-model-reviews", "level": 3, "index": 48, "outlineIndex": 48, "part": 1, "partCount": 2, "words": 301, "tokens": 445 }, { "heading": "Builders build, a different model reviews", "path": "Part 6: Method > Builders build, a different model reviews", "content": "A governance detail I'd point at over any bug count. A boundary-enforcement gate threw a false positive: a schema name matched as a database table reference. The subagent that hit it refused to edit the gate on its own authority and escalated. I authorized the fix, and it shipped with a canary test proving the detection hadn't been weakened. An agent that can quietly loosen its own guardrail to make a build pass is worse than no guardrail, because the guardrail's green light is now evidence of nothing.", "id": "builders-build-a-different-model-reviews--part-2", "level": 3, "index": 49, "outlineIndex": 48, "part": 2, "partCount": 2, "words": 88, "tokens": 127 }, { "heading": "Guardrails belong in the environment", "path": "Part 6: Method > Guardrails belong in the environment", "content": "Two incidents taught me this and neither one was a script I wrote.\n\nOn 2026-07-18 my C: drive hit 0 bytes free mid-build. An editor checkpoint feature makes snapshots by running `git add -A`. The precondition was mine: I had left roughly 70GB of untracked video inside a git workspace, about 1GB per file, because it was convenient and I never asked what a tool with repository-wide reach would do with it. `git add` writes a blob for every file before updating the index, so the checkpoint started hashing 70GB of mp4 into `.git/objects`. The adds died on ENOSPC and the feature retried, once per chat session, leaving more than 2,400 unreachable loose objects. Nothing was ever staged. Nothing was ever committed. The disk filled anyway. Recovery was a PID-scoped kill after checking each parent process, then `git prune --expire=now`, which only removes unreachable objects. That recovered 94GB.\n\nOn 2026-07-17 a subagent debugging its own test rig ran `taskkill` with the image-name flag against `node.exe`. That killed every node process on the machine, including 6 services belonging to other concurrent sessions and the connector for the very build it was running. The scripted cleanup in that build was correct the entire time. It killed by process ID with the tree flag, exactly as written. The damage came from 1 improvised command typed outside the script, and a correct script does not control a command typed outside it.\n\nWhat changed: a gitignore rule for download directories, a prohibition on image-name kills stated in every subagent prompt that touches process cleanup, and a machine-global command guard in front of every agent on this box, live 2026-07-25. Instructions only reach the agents you remembered to instruct.", "id": "guardrails-belong-in-the-environment", "level": 3, "index": 50, "outlineIndex": 49, "part": 1, "partCount": 1, "words": 283, "tokens": 435 }, { "heading": "Sequencing under a hard constraint", "path": "Part 6: Method > Sequencing under a hard constraint", "content": "An 879-video corpus, roughly 84GB, filled my disk in the middle of a build that was reading from it. The build couldn't pause and the storage couldn't stay.\n\nI archived to cloud storage mid-build with 2 conditions I wouldn't move on. Per-chunk md5 verification before any local delete, because an upload that reports success is a claim and a hash match is evidence. And the deal-critical videos went up last, so they stayed local longest. The obvious ordering is largest first, since that clears space fastest. The obvious ordering is also the one that removes your most important files first while the process consuming them is still running.\n\nWhen a constraint forces a decision mid-flight, the ordering carries more risk than the action. The only real choice was which items were exposed and for how long, and that was invisible until I asked what would happen if the upload failed halfway through.", "id": "sequencing-under-a-hard-constraint", "level": 3, "index": 51, "outlineIndex": 50, "part": 1, "partCount": 1, "words": 152, "tokens": 226 }, { "heading": "What \"done\" means here", "path": "Part 6: Method > What \"done\" means here", "content": "**Fixture-complete, live smoke pending.** Every path exercised against deterministic fixtures. Every paid or external call an explicit user action. Every step needing real vendor credentials or a real live event written into a finale checklist in the repo, by name, unchecked.\n\nWhat it doesn't mean: quietly claiming a capability because the code path exists. A status line that says \"pending\" is more credible than one that says \"complete,\" because someone bothered to distinguish them.", "id": "what-done-means-here", "level": 3, "index": 52, "outlineIndex": 51, "part": 1, "partCount": 1, "words": 74, "tokens": 122 }, { "heading": "Disagreement comes early, not late", "path": "Part 7: How I work with people > Disagreement comes early, not late", "content": "I raise the uncomfortable thing in the first conversation, not the fourth. \"I don't think I'm the right fit\" builds more trust than a forced demo. If I can see the mismatch on day 1, saying it on day 1 costs me 1 engagement. Saying it on day 40 costs both of us a quarter.\n\nThe line I put in writing before anyone has paid me a dollar: I do my best work when a client hands me their thinking and expects me to challenge it, not rubber-stamp it. You'll get honest pushback and sharper questions, not agreement. It never gets softened to seem more agreeable.", "id": "disagreement-comes-early-not-late", "level": 3, "index": 53, "outlineIndex": 53, "part": 1, "partCount": 1, "words": 106, "tokens": 139 }, { "heading": "How pushback actually sounds", "path": "Part 7: How I work with people > How pushback actually sounds", "content": "I acknowledge you first, state the thing, raise the concern without alarm in 1 sentence at the moment it applies, and close with a clear next step. No drama, no burying it in paragraph 6.\n\nIn a real proposal the entire wedge was telling the prospect his plan was right but incomplete, then naming the specific thing he'd have to decide before anyone wrote code. Reframe the problem more sharply than it was described to you, then name what you'd pressure-test.\n\nSeverity changes the register, not the honesty. When the stakes are real (money, jobs, risk) I get more professional and less sharp. I don't get quieter about the problem.", "id": "how-pushback-actually-sounds", "level": 3, "index": 54, "outlineIndex": 54, "part": 1, "partCount": 1, "words": 110, "tokens": 159 }, { "heading": "How to test the part I can't prove on paper", "path": "Part 7: How I work with people > How to test the part I can't prove on paper", "content": "Everything else in this document is me and my own systems. How I behave with somebody else on the other side of the table is the thinnest evidence in it, and no amount of build record substitutes for that. Take the direct route instead of taking my word.\n\n1. Hand me a decision you've already made and disagree with me about. Not a hypothetical. Something live, where you've committed and I don't know the constraints you weighed. What you're watching for is whether I argue from your numbers or from my priors, and whether I stop when you've answered the objection.\n2. Sit in on a working session rather than a pitch. My register on a real problem is different from my register in a proposal, and the difference is the thing you're actually hiring.\n3. Give phase 1 a person I have to work through rather than around. Map and rank is 1 to 2 weeks and ends in an artifact you keep. If I'm bad inside a team I don't control, that surfaces in week 1 for the price of week 1, which is the same gate I apply to any domain I don't know.\n\nThat is a standing offer. The cheapest way to resolve a gap in evidence is to run the experiment, and I'd rather you run it in week 1 than take a claim on trust and find out in month 3.", "id": "how-to-test-the-part-i-cant-prove-on-paper", "level": 3, "index": 55, "outlineIndex": 55, "part": 1, "partCount": 1, "words": 237, "tokens": 305 }, { "heading": "When someone else was right and I wasn't", "path": "Part 7: How I work with people > When someone else was right and I wasn't", "content": "I ask clients to hand me their thinking and expect a challenge. The same rule has to run in the other direction, so here are 3 times an outside argument beat mine, with what I changed. The honest label is that these are arguments that beat mine, and 2 of the 3 came from written material rather than from a person in a room.\n\n1. **I overrode my own written stance on outreach.** I held that publishing real work would pull the right clients and that outreach was for people without proof. An outside operator's argument and my own numbers both said otherwise. On 2026-07-16 I changed the stance, superseded the old one in the same session, and logged the reasoning next to it.\n2. **A model told me my fix was insufficient and it was.** On the accounting build I closed a JSON float-collapse bug at API ingress with a magnitude cap. The read-only reviewer came back and said the cap didn't close the class of problem. It was right. The working fix was a lexical raw-body guard, which is a different mechanism, not a bigger version of mine. I ship the reviewer's verdict over my own on the code I wrote, because the alternative is a green suite and a bug.\n3. **I harvested someone else's methodology instead of writing my own.** My instinct on sales frameworks was to author them from scratch, which is the same instinct that makes people rebuild edge detection. An MIT-licensed agent library had better discovery-questioning methodology than I was going to invent in a week. I took it, rewrote it lean into my own format, and kept the attribution. I still reject other parts of the same body of material in writing, including 2 tactics I judged as spam and refuse to run.\n\nThe pattern in all 3: I change the call when the argument is better, and I write down which parts I still reject in the same entry, so the reversal and its limits stay attached to each other.", "id": "when-someone-else-was-right-and-i-wasnt", "level": 3, "index": 56, "outlineIndex": 56, "part": 1, "partCount": 1, "words": 339, "tokens": 466 }, { "heading": "Receiving feedback and being wrong", "path": "Part 7: How I work with people > Receiving feedback and being wrong", "content": "Plain. Correct the claim, say what caused it, move on. No self-flagellation, no long apology. The cause is the useful part.\n\nI don't overwrite mistakes, I annotate them. My voice profile carries a table of 8 places where a drafting agent described my position and I corrected it outright, with both versions side by side, so the wrong version can't creep back in. My decisions log has a section for errors caught mid-run, next to the wins, in the same entry. An overwritten mistake teaches nobody, including me in 3 months.", "id": "receiving-feedback-and-being-wrong", "level": 3, "index": 57, "outlineIndex": 57, "part": 1, "partCount": 1, "words": 91, "tokens": 131 }, { "heading": "The first conversation", "path": "Part 7: How I work with people > The first conversation", "content": "I don't open with rapport. Small talk is the slow lane. \"Walk me through the messiest part of your week\" is the fast one.", "id": "the-first-conversation", "level": 3, "index": 58, "outlineIndex": 58, "part": 1, "partCount": 1, "words": 24, "tokens": 31 }, { "heading": "When I don't have the domain", "path": "Part 7: How I work with people > When I don't have the domain", "content": "I don't claim experience with a tool I haven't used and I don't invent a case study. When a prospect's stack includes something I don't know, I name the gap head-on and make their own data the first milestone gate. If it doesn't clear, you found out in week 1 for the price of week 1. That's the general shape of how I phase work: numbered plan, each phase ending in something inspectable, so you can stop after any one of them and still hold something useful.", "id": "when-i-dont-have-the-domain", "level": 3, "index": 59, "outlineIndex": 59, "part": 1, "partCount": 1, "words": 87, "tokens": 115 }, { "heading": "I kill my own ideas before a client has to", "path": "Part 7: How I work with people > I kill my own ideas before a client has to", "content": "I built a demo proving my kernel generalizes to a role outside business operations. The self-grill scored the full product a Skip: no budget authority in that buyer, compliance exposure, procurement wall. The shrunk version cleared. Both logged, with 6 calls flagged for my own veto.\n\nAnother time I wanted to migrate my entire operating system into a lighter open-source agent framework I'd just cloned. Rejected on my own analysis: the target was a roughly 95-line loop with a handful of tools, my system depends on subagents, connectors and scheduled work that don't exist there, and the migration was an engine downgrade with 0 progress toward the goal. Install it as a lab, harvest 4 patterns, don't move in.", "id": "i-kill-my-own-ideas-before-a-client-has-to", "level": 3, "index": 60, "outlineIndex": 60, "part": 1, "partCount": 1, "words": 119, "tokens": 179 }, { "heading": "Part 8: Failure handling, owned", "path": "Part 8: Failure handling, owned", "content": "Four incidents where my reasoning was wrong. Every one is first person, with the mechanism named, the cost attached where a figure exists, and what changed. The ones I leave out are the ones that only show inattention, because those teach nobody anything.\n\nAll 4 are failures against instruments and tooling. Nobody was disappointed, no relationship broke, and no money moved that a stranger could see. That is a real limit on this section and it exists because I have been building alone. Part 7 gives you 3 ways to test the counterparty half directly rather than taking a paragraph's word for it.", "id": "part-8-failure-handling-owned", "level": 2, "index": 61, "outlineIndex": 61, "part": 1, "partCount": 1, "words": 103, "tokens": 150 }, { "heading": "The positive control that killed my own finding", "path": "Part 8: Failure handling, owned > The positive control that killed my own finding", "content": "I pulled a search-results snapshot for \"ai automation agency\" and got 0 advertisers back. The conclusion wrote itself. Nobody is bidding, the auction is empty, the category is mispriced.\n\nThen I ran the identical method against \"crm software,\" one of the most heavily advertised business terms in existence. Zero paid items. I ran it a third time on mobile in New York. Zero again.\n\nThe market was full. My instrument was blind. I retracted the finding the same day, 2026-07-27, and wrote the prohibition into my own API reference so I can't repeat it. The replacement is Google's own mandatory ad disclosure surface plus an incognito results page with the adblocker off, because an adblocker will hide the paid block from a manual check, which is a second trap on the human side of the same problem.\n\nThe direct cost was an afternoon and an API bill in cents, which I did not itemize at the time and won't reconstruct now. The real cost is what it almost became. I was minutes away from building a positioning argument on top of a null result, and that argument would have been wrong in a way nobody could have corrected from the outside, because the number would have looked measured.\n\n**What changed:** a negative result means nothing until you've proven the instrument can detect a positive. Most people skip the control, because a null that confirms what you hoped feels like a discovery.", "id": "the-positive-control-that-killed-my-own-finding", "level": 3, "index": 62, "outlineIndex": 62, "part": 1, "partCount": 1, "words": 241, "tokens": 349 }, { "heading": "The payout number that was wrong by half", "path": "Part 8: Failure handling, owned > The payout number that was wrong by half", "content": "I had a reporting hub telling me my 12-month Amazon payout. I looked at it and said it was completely wrong. It was understated by roughly 50%.\n\nFour bugs, all in my own normalizer. Fees double-counted promotions and refunds, because the downstream template already subtracted both separately. A storage estimate was applied even when real storage events existed. Item-level fee breakdowns were dropped whenever totals were also present. Promo refund reversals had their signs handled wrong.\n\nThe corrected estimate closed most of the gap against actual bank transfers. What was left was fully explainable: settlement timing, plus ad spend billed to a card and never deducted from settlements at all, plus a residual pending reconciliation.\n\nTwo things I'd have missed without the operating background. I only caught it because the number failed against a baseline I carry from running the business. An analyst with no stored range would have shipped it. And the fix had to live in my own normalizer, never in the source template, which is hash-checked and frozen third-party IP. The temptation to edit the upstream formula was real and it was the wrong move.\n\nThe alternative I rejected was leaving the figure in place with a footnote. A wrong headline number poisons every weekly refresh downstream. Annotating a wrong number is a decision to keep publishing it.", "id": "the-payout-number-that-was-wrong-by-half", "level": 3, "index": 63, "outlineIndex": 63, "part": 1, "partCount": 1, "words": 221, "tokens": 341 }, { "heading": "The ledger that reported $0.0012", "path": "Part 8: Failure handling, owned > The ledger that reported $0.0012", "content": "I wired up a paid data API that shipped with a local ledger logging every task. After a working session the ledger showed $0.0012 of spend. The account balance had actually dropped $0.23, roughly 190 times what the ledger claimed.\n\nBoth numbers are small on purpose. The structure is what matters. That API splits a request into 2 calls: one that submits the task and one that retrieves the result. Charges land on the submit. The ledger recorded the retrieve. It logged the free half of the lifecycle, faithfully, forever, and reported a number that was internally consistent and completely wrong. The built-in cost estimator was separately off by 3x in the same direction. Two instruments agreeing with each other and disagreeing with reality.\n\nPut a 190x reporting error on a metered service that bills per call and runs in a loop, and the absolute number stops being small.\n\n**What changed:** for any metered service I connect, reconcile against the provider's own balance, not against my own telemetry. Instrumentation that measures the wrong half is worse than none. With no instrumentation you know you're blind and you go look. With a confident wrong number you stop looking.", "id": "the-ledger-that-reported-00012", "level": 3, "index": 64, "outlineIndex": 64, "part": 1, "partCount": 1, "words": 197, "tokens": 296 }, { "heading": "Provenance is its own leak class", "path": "Part 8: Failure handling, owned > Provenance is its own leak class", "content": "Building the CRE workbench meant shipping a product derived from a private corpus. I wrote a lint for the obvious risk: branded third-party vocabulary reaching client-facing text. Clean from the first phase and clean through the whole build. That control worked exactly as designed, on the wrong door.\n\nWhat leaked was provenance. Internal batch citations. QA annotations sitting inside tool specifications with notes like \"garbled\" and \"see Conflicts.\" A name carried over from the source material. All of it survived a mechanical stripping pass and landed in text a client would read.\n\nThree adversarial rounds to clear. Round 1 caught the category and 12 specifications. A sweep across 1,254 fields with a regex missed variants wrapped in parentheses. Round 2 caught 6 more lines. Round 3 came back clean across all 143 specifications.\n\n**What changed:** you can lint for the category you named. The leak is always the category you didn't. Neutral-vocabulary lint is necessary and not sufficient. Any product derived from private material needs a separate adversarial pass aimed at metadata, not vocabulary, run by something that didn't write the stripping script.", "id": "provenance-is-its-own-leak-class", "level": 3, "index": 65, "outlineIndex": 65, "part": 1, "partCount": 1, "words": 183, "tokens": 292 }, { "heading": "Part 9: Strengths, plainly", "path": "Part 9: Strengths, plainly", "content": "1. **Systems thinking under real constraints.** I decompose a business into tasks, score them, and produce a ranked order of operations. That's a repeatable framework, not a talent.\n2. **Cross-domain transfer.** Two unrelated operating backgrounds applied to each other on purpose. The diligence playbook is the clearest artifact.\n3. **Shipping speed with gates attached.** In a day: 143 tools with 300 tests, and 179 concept cards with citation checks. The verification isn't skipped to get the speed.\n4. **Orchestrating parallel agent work without collisions.** Written contracts, disjoint lanes, pre-assigned globally ordered resources, agents that don't commit. Demonstrated across 4 builds.\n5. **Numerical skepticism grounded in stored baselines.** I catch wrong numbers because I carry ranges from running businesses, not because I'm suspicious by temperament.\n6. **Saying the uncomfortable thing first.** Early disagreement, named gaps, honest relabeling of what a build actually does.\n7. **Documentation discipline.** Every decision logged with its rejected alternatives. Every build's limits written into the repo rather than hidden.", "id": "part-9-strengths-plainly", "level": 2, "index": 66, "outlineIndex": 66, "part": 1, "partCount": 1, "words": 162, "tokens": 286 }, { "heading": "Greatest strength, if forced to pick one", "path": "Part 9: Strengths, plainly > Greatest strength, if forced to pick one", "content": "Deciding what not to build. My framework gives every candidate 3 valid outcomes and a clean skip counts as a win. I applied it to a product of my own at the grill stage, scored the full build a Skip, and shipped only the proof. On 1 build pass I passed on 7 candidates, 2 killed purely on upkeep because the config formats they depended on drift monthly. The valuable move shrinks the list.", "id": "greatest-strength-if-forced-to-pick-one", "level": 3, "index": 67, "outlineIndex": 67, "part": 1, "partCount": 1, "words": 74, "tokens": 98 }, { "heading": "Part 10: Weaknesses, honestly", "path": "Part 10: Weaknesses, honestly", "content": "This part carries the full accounting. The rest of the document points here rather than repeating it.", "id": "part-10-weaknesses-honestly", "level": 2, "index": 68, "outlineIndex": 68, "part": 1, "partCount": 1, "words": 17, "tokens": 26 }, { "heading": "Positioning and creative, the one I lead with", "path": "Part 10: Weaknesses, honestly > Positioning and creative, the one I lead with", "content": "I believed the work could speak for itself. It can't. That's the belief I changed most recently and it cost me real ground.\n\nTwo places it shows. In both of them the belief is the transferable part, not the task.\n\n1. **I treated publishing as something that happens after a build rather than inside it.** 10 demos shipped publicly with engagement measured on none of them, and 2 open-source builds that are licensed to be public and are still not public. The license is the whole point of those 2 builds, and a step that sits outside the build is a step nobody scheduled.\n2. **I treated finished work as delivered work.** A full proposal written for a real prospect, drafted, gone stale, and out of the pipeline unsent. The work was done. The only remaining step was putting it in front of a person, and that is the step that queues. The cost isn't a lost deal, because there was never a deal. The cost is that a person with a real problem never heard from me.\n\nA test suite passing is a claim about the code. A live run in front of somebody is the only evidence the thing does what I say it does.\n\n**What I'm doing about it.** Treating presentation as a broken process and running my own framework on it: define it, sequence it, put a date on it. Publishing is a step inside the build, not something that happens after. A metric I intend to collect now gets a collection mechanism at the same time I write the field, or the field doesn't go in the template.\n\n**The guardrail on the correction.** I price for simplification, not difficulty. Learning to present risks turning into the opposite of that. Packaging substance is honest, inflating simple work is not, and every positioning decision gets checked against that line. When I can't tell which side it falls on, I cut it.", "id": "positioning-and-creative-the-one-i-lead-with", "level": 3, "index": 69, "outlineIndex": 69, "part": 1, "partCount": 1, "words": 324, "tokens": 445 }, { "heading": "Other real ones", "path": "Part 10: Weaknesses, honestly > Other real ones", "content": "1. **I run hot on my own schedule.** Three full AI projects in a quarter while standing up a consultancy. That's a strength in output and a risk in sequencing, and the backlog above is what it looks like when it goes wrong.\n2. **Breadth means I'm not the deepest specialist in any single stack.** I say so and structure engagements so the unknown gets tested first against the client's own data.\n3. **I'd rather build than sell.** Deciding proof comes first is defensible, and it also happens to be the more comfortable order for me. I keep that in view.\n4. **Almost all my evidence is solo.** Every incident in this document is me and my own systems. I have real counterparty history from the operating years and it is thinner than the build record, which means a hiring manager has less to go on for how I behave inside a team I don't control than for how I build.", "id": "other-real-ones", "level": 3, "index": 70, "outlineIndex": 70, "part": 1, "partCount": 1, "words": 161, "tokens": 217 }, { "heading": "What I won't do to fix a weakness", "path": "Part 10: Weaknesses, honestly > What I won't do to fix a weakness", "content": "Overcorrect into performance. If the fix for \"nobody sees the work\" turns into inflating what the work is, I've traded a backlog nobody can see for a claim nobody can check, and I'd be running the exact mechanic I criticize.", "id": "what-i-wont-do-to-fix-a-weakness", "level": 3, "index": 71, "outlineIndex": 71, "part": 1, "partCount": 1, "words": 40, "tokens": 56 }, { "heading": "What I want next", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > What I want next", "content": "1. Clients where the diagnosis is the deliverable. What to automate, in what order, and how the pieces fit.\n2. Problems in domains I haven't seen. Adventure is on my values list on purpose.\n3. Owners who decide fast, adapt when the facts change, and want a system rather than a pile of automations.\n4. Owners drowning in manual operations and honest about it. This one carries the most weight. I can work with a mess. I can't work with a mess I'm not allowed to see.\n5. Work where I'm expected to challenge the thinking, not execute a ticket queue.\n\n**On engagement shape.** What I'm building is a consultancy, and it sells one thing: a $995/month subscription with unlimited automation requests worked as a queue. Work still gets phased internally — numbered plan, each phase ending in something inspectable, an artifact you keep — but you aren't buying a phase, you're subscribing to the queue and you can leave in one click. If you're reading this for a salaried or fractional role instead, ask me directly. You'll get a straight yes or no rather than an inference from a document that only describes consulting.", "id": "what-i-want-next", "level": 3, "index": 72, "outlineIndex": 73, "part": 1, "partCount": 1, "words": 195, "tokens": 279 }, { "heading": "What I won't do to win the work", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > What I won't do to win the work", "content": "1. No undercutting on price to buy volume.\n2. No fake urgency.\n3. No invented case studies.\n4. No claiming experience with a tool I haven't used.\n5. No implying someone else's build is my client result.\n6. No promising an outcome I can't control.\n\nNumber 5 has a consequence. Every build I show is framed as exactly what it is: a system I built and run for my own products and operations. Never \"here's what I did for a client.\" The moment you blur that, everything else you say needs verifying.", "id": "what-i-wont-do-to-win-the-work", "level": 3, "index": 73, "outlineIndex": 74, "part": 1, "partCount": 1, "words": 92, "tokens": 124 }, { "heading": "What I won't automate, ever", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > What I won't automate, ever", "content": "1. **Final judgment.** The call that closes the option, where it's actually final.\n2. **Anything requiring authentication.** Agents don't handle credentials or run auth flows. I log in myself. Credentials get parsed at runtime and never enter a transcript.\n3. **Anything that could open a security hole.** Committing secrets, weakening permissions, widening the surface.\n\nPrincipled categories, not scaffolding waiting on the next model release. The constraint is on irreversibility and exposure, not on capability, which is why they sit comfortably next to a high opinion of agent judgment. Better models don't make an unsendable message sendable.\n\nNothing external posts itself. Every draft goes to me first. No agent has ever sent a message or published a post on my behalf, and none will.\n\nAnother line drawn for the same reason. When a platform deliberately withholds an endpoint, that's product strategy. Automate up to the boundary, never around it. Building the missing endpoint yourself is a decision to break someone else's rule with your client's account.", "id": "what-i-wont-automate-ever", "level": 3, "index": 74, "outlineIndex": 75, "part": 1, "partCount": 1, "words": 165, "tokens": 267 }, { "heading": "What I won't tolerate", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > What I won't tolerate", "content": "**Disrespect is absolute.** No client, no deal, no amount of money. That one has no cost-benefit attached to it and never will.\n\nEverything else is a preference rather than a dealbreaker, and a good problem with good terms outweighs any of it.", "id": "what-i-wont-tolerate", "level": 3, "index": 75, "outlineIndex": 76, "part": 1, "partCount": 1, "words": 42, "tokens": 61 }, { "heading": "My values", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > My values", "content": "1. **Relentless ambition.** I move fast, and if you decide fast I'll match you. If your team needs a slower cadence, tell me and I'll work to it.\n2. **Insatiable curiosity.** I want to know how things work. Your business will be no exception.\n3. **Empathy and compassion.** The 80% you remove is the busywork. The 20% you protect is the part only people can do.\n4. **Respect, fairness, transparency, authenticity.** One value, 4 words. I show my work, I tell the truth about what won't work, and I don't perform.\n5. **Adventure.** I take on problems I haven't seen before, on purpose.", "id": "my-values", "level": 3, "index": 76, "outlineIndex": 77, "part": 1, "partCount": 1, "words": 103, "tokens": 146 }, { "heading": "The 5 promises", "path": "Part 11: What I want next, what I won't do, what I won't tolerate > The 5 promises", "content": "1. No black boxes. You see how everything works, always.\n2. You own everything we build. Code, prompts, docs. Fire me tomorrow and it keeps running.\n3. I'll tell you when automation is the wrong answer, even when it costs me the engagement.\n4. I'd rather lose a deal than oversell an outcome.\n5. I build with you, not just for you. When I leave, your team is more capable, not more dependent.", "id": "the-5-promises", "level": 3, "index": 77, "outlineIndex": 78, "part": 1, "partCount": 1, "words": 73, "tokens": 98 }, { "heading": "Part 12: Standard interview answers", "path": "Part 12: Standard interview answers", "content": "Answers that exist in full elsewhere in this document are pointers, not restatements.", "id": "part-12-standard-interview-answers", "level": 2, "index": 78, "outlineIndex": 79, "part": 1, "partCount": 1, "words": 13, "tokens": 22 }, { "heading": "Tell me about yourself", "path": "Part 12: Standard interview answers > Tell me about yourself", "content": "I run an AI automation consultancy that installs a business operating system first and the AI layer second. Before that I ran 7-figure ecommerce and Amazon FBA businesses, where I learned unit economics to the penny and that sub-10 TACOS is the line between thriving and dying, and I structured commercial real estate deals over $10 million, where I learned that deals die from slowness more often than from bad terms. I still run an FBA brand, wired end to end into my own systems. Dates, titles and firm names go out on request.\n\nSince Q2 2026 I've shipped 23 builds: a double-entry accounting SaaS, a 143-tool CRE deal workbench, a go-to-market operating system, an Android document scanner, a self-built meeting agent, an FBA reporting rebuild verified at plus or minus a penny across 7,460 checks. None of it is client work and I never frame it as client work. It's the proof I decided to ship before selling.\n\nThe thread through all of it: everything reduces to tasks, any defined process can be automated, and defining the process is the actual work.", "id": "tell-me-about-yourself", "level": 3, "index": 79, "outlineIndex": 80, "part": 1, "partCount": 1, "words": 183, "tokens": 265 }, { "heading": "What's your greatest strength", "path": "Part 12: Standard interview answers > What's your greatest strength", "content": "Deciding what not to build. See Part 9.", "id": "whats-your-greatest-strength", "level": 3, "index": 80, "outlineIndex": 81, "part": 1, "partCount": 1, "words": 8, "tokens": 10 }, { "heading": "What's your biggest weakness", "path": "Part 12: Standard interview answers > What's your biggest weakness", "content": "Positioning and creative, with the evidence in Part 10. Short version: I believed the work would speak for itself, and the backlog that belief produced is written down rather than described.", "id": "whats-your-biggest-weakness", "level": 3, "index": 81, "outlineIndex": 82, "part": 1, "partCount": 1, "words": 31, "tokens": 48 }, { "heading": "What's your biggest failure", "path": "Part 12: Standard interview answers > What's your biggest failure", "content": "I ran a search-results pull, found 0 advertisers on a term I cared about, and concluded nobody was bidding on it. Then I ran the same method against one of the most heavily advertised business terms in existence and got 0 again. My instrument was blind, not the market. I retracted the finding the same day and wrote the prohibition into my own API reference. Full account in Part 8.\n\nThe lesson I use: a negative result means nothing until you've proven the instrument can detect a positive. Most people never run that control, especially when the broken result is flattering.", "id": "whats-your-biggest-failure", "level": 3, "index": 82, "outlineIndex": 83, "part": 1, "partCount": 1, "words": 101, "tokens": 145 }, { "heading": "Tell me about a conflict with a colleague", "path": "Part 12: Standard interview answers > Tell me about a conflict with a colleague", "content": "The counterparty history from the operating years isn't written up here, and Part 7 says how to test that trait directly rather than take a paragraph's word for it.\n\nThe one I can hand you is about systems rather than people, and I include it because it shaped a rule. On an accounting build, a boundary-enforcement gate threw a false positive and blocked the build. The subagent that hit it wanted the build to pass and could have edited the gate. It refused to do that on its own authority and escalated to me. I authorized the fix, and it shipped with a canary test proving the detection hadn't been weakened. That's the shape of most productive conflict: someone is blocked, the fastest resolution is to weaken the constraint, and the correct move is to escalate rather than quietly relax it.", "id": "tell-me-about-a-conflict-with-a-colleague", "level": 3, "index": 83, "outlineIndex": 84, "part": 1, "partCount": 1, "words": 141, "tokens": 199 }, { "heading": "Tell me about a time you were overruled", "path": "Part 12: Standard interview answers > Tell me about a time you were overruled", "content": "Not written up here. Part 7 has 3 ways to test how I take being overruled inside week 1, which is a better instrument than a paragraph I wrote about myself.", "id": "tell-me-about-a-time-you-were-overruled", "level": 3, "index": 84, "outlineIndex": 85, "part": 1, "partCount": 1, "words": 31, "tokens": 39 }, { "heading": "Tell me about a time you missed a deadline", "path": "Part 12: Standard interview answers > Tell me about a time you missed a deadline", "content": "The proposal in Part 10. No client deadline was involved, which is the uncomfortable part. It was my own commitment.\n\nWhat I did about it: named presentation as a broken process, and moved publishing inside the build rather than after it. What I won't claim: that the habit is fixed.", "id": "tell-me-about-a-time-you-missed-a-deadline", "level": 3, "index": 85, "outlineIndex": 86, "part": 1, "partCount": 1, "words": 50, "tokens": 71 }, { "heading": "Tell me about something you shipped and later shut down", "path": "Part 12: Standard interview answers > Tell me about something you shipped and later shut down", "content": "On 2026-07-23 I published 10 demos to seanfeng.com, verified all 10 URLs live, and pulled 9 of them the same day. Only 1 had been through the brand pass. The other 9 were live in their original themes and looked like 9 different products from 9 different people. I took them down rather than leave a page that argued against itself, redeployed with 1 demo, and verified the removals.\n\nThe honest read on that decision is mixed. Pulling them was right on presentation and wrong on sequencing, because the restyle is mechanical and I could have done it before publishing instead of after. The net effect was that a posting backlog that had been blocked on hosting became blocked on styling instead.\n\nThe bigger answer is that every kill in this portfolio is pre-build or pre-launch: a full teacher product scored Skip at the grill stage, two-way CRM sync cut before it shipped, a framework migration rejected on my own analysis. Those are real decisions and they are all cheaper than the decision you're actually asking about.", "id": "tell-me-about-something-you-shipped-and-later-shut-down", "level": 3, "index": 86, "outlineIndex": 87, "part": 1, "partCount": 1, "words": 177, "tokens": 256 }, { "heading": "Tell me about learning a domain cold, and what it cost", "path": "Part 12: Standard interview answers > Tell me about learning a domain cold, and what it cost", "content": "Two of them, with the bill attached.\n\nDouble-entry accounting. I needed the mechanics to be right rather than approximately right, so the learning showed up as architecture: integer cents behind a branded type, an append-only journal with balancing enforced by database triggers, exactly 2 write paths. What it cost is visible in the review record. A different vendor's model found 6 issues that 102 green tests had missed, and later I found a whole authorization class the suite never tested. Learning the domain got me the ledger design. It didn't get me the attacker's view, and I had to go buy that separately.\n\nCRE decision-making at depth. I mined a 14-course corpus into 179 concept cards in a day. Cost was roughly 26M subagent tokens against a 7M to 9M estimate, 2.5x over, because the source ran richer than I'd planned for. I logged the overrun rather than rounding it. The transferable part: my estimate was wrong in the direction of assuming a corpus is thinner than it is, and I now size extraction jobs off a sampled chunk rather than off a file count.", "id": "tell-me-about-learning-a-domain-cold-and-what-it-cost", "level": 3, "index": 87, "outlineIndex": 88, "part": 1, "partCount": 1, "words": 185, "tokens": 267 }, { "heading": "Tell me about delivering bad news", "path": "Part 12: Standard interview answers > Tell me about delivering bad news", "content": "I don't have a client yet, so I won't dress up a hypothetical as an incident. Two real ones I can point at.\n\nThe first is the diligence system's first live run. The output was a walk verdict on a listing: storefront not serving, domain dropped and re-registered by someone else, inconsistent profit figures in the seller's own materials. Delivering that means telling someone the thing they were excited about is dead, on the evidence, in the first 20 minutes.\n\nThe second is smaller and more common. In a real proposal I told the prospect his plan was right and incomplete, then named the specific decision he had to make before anyone wrote code. That's the standing rule: state the problem in the first conversation, in 1 sentence, with the next step attached. Bad news gets more professional in register when the stakes are real. It never gets quieter.", "id": "tell-me-about-delivering-bad-news", "level": 3, "index": 88, "outlineIndex": 89, "part": 1, "partCount": 1, "words": 149, "tokens": 214 }, { "heading": "Did you leave ecommerce", "path": "Part 12: Standard interview answers > Did you leave ecommerce", "content": "No. I still run the FBA brand, which is why the FBA tooling is dogfooded rather than demonstrated. On commercial mortgage, the dates and the reason go out on request, with the colleagues who were there.", "id": "did-you-leave-ecommerce", "level": 3, "index": 89, "outlineIndex": 90, "part": 1, "partCount": 1, "words": 36, "tokens": 51 }, { "heading": "Who would vouch for you, and what would they say", "path": "Part 12: Standard interview answers > Who would vouch for you, and what would they say", "content": "Former commercial-mortgage colleagues and Amazon seller peers. Names, roles and contact details go out on request, after I've asked each of them, because I'm not putting a person's name and employer into a document I don't control without telling them first. Ask and you'll have 2 names and their numbers the same day.\n\nWhat they can confirm without stretching: how I work a deal or an operating problem, whether I say the uncomfortable thing early, and whether the numbers I hand over hold up. What they can't confirm is the consultancy, because it postdates all of them, and I'd rather say that than borrow someone else's reference.", "id": "who-would-vouch-for-you-and-what-would-they-say", "level": 3, "index": 90, "outlineIndex": 91, "part": 1, "partCount": 1, "words": 107, "tokens": 159 }, { "heading": "What would you cost", "path": "Part 12: Standard interview answers > What would you cost", "content": "One flat number, never hourly. $995 a month, unlimited requests worked as a queue, and the number doesn't move — it's the same whether you file one request that month or ten. Founding rate for the first 10 clients. No setup fee, no contract, pause or cancel in one click. If your process is to compare bids, that's the whole bid: there is one plan and the price is on the website.", "id": "what-would-you-cost", "level": 3, "index": 91, "outlineIndex": 92, "part": 1, "partCount": 1, "words": 72, "tokens": 95 }, { "heading": "Why you", "path": "Part 12: Standard interview answers > Why you", "content": "1. I've operated in 2 domains that break the same way, and I can cross-apply them. The diligence playbook is the artifact: a listing P&L read as an offering memorandum, processor exports read as a T12, assignability read as estoppel. That translation is why it was usable on day 1 instead of month 6.\n2. You can check most of the claim before you commit. There are 23 built projects, each with a status, a test count, and a named verification step. Three things open from the front page, and an honest line on every build about what you can and can't inspect. Public failures with the mechanism attached.\n3. I'll tell you the thing that costs me the engagement. Most businesses reaching for AI should first delete 80% of the process they're about to automate, and I'll say so on the first call. I'll also be the person in the room who says the smaller version clears and the big one doesn't. That call is worth more than the build.", "id": "why-you", "level": 3, "index": 92, "outlineIndex": 93, "part": 1, "partCount": 1, "words": 171, "tokens": 233 }, { "heading": "Where do you see yourself", "path": "Part 12: Standard interview answers > Where do you see yourself", "content": "Running a consultancy whose diagnosis is the product, with a portfolio of systems clients own outright rather than rent. The nearest goal is landing the first client and closing the gap between what I build and what I publish.\n\nLonger out, the builds that started as credibility proof turn into products. That's already happened once. An accounting build became Bookhalter, with a coming-soon site live and a privacy stance decided before the first customer.", "id": "where-do-you-see-yourself", "level": 3, "index": 93, "outlineIndex": 94, "part": 1, "partCount": 1, "words": 74, "tokens": 115 }, { "heading": "What motivates you", "path": "Part 12: Standard interview answers > What motivates you", "content": "**Broken processes.** Put a mess in front of me and I'm useful immediately. \"Walk me through the messiest part of your week\" is my favorite opening because the answer is always the interesting part of the business.\n\n**Range.** I take on problems I haven't seen before on purpose. The best automations come from watching one industry solve a problem the other still does by hand.\n\nWhat doesn't motivate me: volume, titles, or looking busy.", "id": "what-motivates-you", "level": 3, "index": 94, "outlineIndex": 95, "part": 1, "partCount": 1, "words": 74, "tokens": 110 }, { "heading": "How do you handle ambiguity", "path": "Part 12: Standard interview answers > How do you handle ambiguity", "content": "I convert it into a map and a named number before anything gets built. If it can't be drawn as boxes and arrows on 1 page, it isn't ready to score.\n\nWhen the ambiguity is domain knowledge I don't have, I say so and make the client's own data the first milestone gate, so the unknown gets tested in week 1 rather than assumed away.\n\nWhen it's technical, I de-risk with probes before writing code. The 4 probes on the meeting agent are in Part 5. The fourth one failed, which is the point of running them.", "id": "how-do-you-handle-ambiguity", "level": 3, "index": 95, "outlineIndex": 96, "part": 1, "partCount": 1, "words": 97, "tokens": 126 }, { "heading": "How do you prioritize", "path": "Part 12: Standard interview answers > How do you prioritize", "content": "Four checks and 2 gates, run the same way every time. The table is in Part 4. At the portfolio level it's a weekly pass with 3 calls per asset: keep it, fix it, or cut it. Sunk cost isn't a reason to keep something running.", "id": "how-do-you-prioritize", "level": 3, "index": 96, "outlineIndex": 97, "part": 1, "partCount": 1, "words": 46, "tokens": 56 }, { "heading": "Where do you want to grow", "path": "Part 12: Standard interview answers > Where do you want to grow", "content": "Presentation and positioning, which I've named as my weak point and am working on with a deadline attached. Beyond that, the client-facing half of consulting: scoping conversations, proposal sequencing, and knowing when a prospect's stated problem isn't their real one. The build half is instrumented. The sales half is where I have the least data on myself.", "id": "where-do-you-want-to-grow", "level": 3, "index": 97, "outlineIndex": 98, "part": 1, "partCount": 1, "words": 57, "tokens": 90 }, { "heading": "What questions do you have for us", "path": "Part 12: Standard interview answers > What questions do you have for us", "content": "1. Who currently absorbs the work I'd be automating, and what happens to their week when it's gone?\n2. What's the one process everybody complains about and nobody owns?\n3. What decision are you waiting on that a better number would unblock?\n4. When this goes wrong 6 months from now, who has to be able to fix it without me?", "id": "what-questions-do-you-have-for-us", "level": 3, "index": 98, "outlineIndex": 99, "part": 1, "partCount": 1, "words": 61, "tokens": 81 }, { "heading": "Part 13: FAQ", "path": "Part 13: FAQ", "content": "Short answers. Where the full one lives elsewhere, this points at it instead of saying it twice.", "id": "part-13-faq", "level": 2, "index": 99, "outlineIndex": 100, "part": 1, "partCount": 1, "words": 17, "tokens": 24 }, { "heading": "The work and the approach", "path": "Part 13: FAQ > The work and the approach", "content": "**What exactly do you sell?** A business operating system first, the AI layer second. The deliverable is a map of how the business actually runs, a ranked order of what to automate, and the builds that follow. The diagnosis is the product.\n\n**What's your tech stack?** Large. Well over a hundred purpose-built workflows across client acquisition, delivery, and internal operations, plus a library of several hundred pre-built integrations I draw from instead of wiring every connector by hand. Close to 40 live system connections: calendar, email, CRM, ad platforms, financial data, tested and verified, not just plugged in.\n\nI don't build every piece from zero. Knowing which 15 minutes of that library actually solves your problem, and wiring it correctly, is the job. That judgment is what doesn't commoditize.\n\n**Do you work alone?** Not entirely. 8 named agents work under me: Elliot (engineering), Fred (multi-agent orchestration), George (web design), Hunter (sales), Maya (interactive and motion engineering), Oscar (legal and IP review), Parker (product intelligence), Sage (content and SEO strategy). Each has its own working style and its own lane.\n\nI review everything before anything goes external. The execution is distributed. The judgment isn't.\n\n**How do you price?** $995 a month, flat, unlimited requests. Founding rate for the first 10 clients, locked in for the life of the engagement. After that it moves and ties to outcomes and time saved. Part 14.\n\n**Do you do maintenance contracts?** Monitoring, maintenance, and fixes are included in the $995/month plan, not a separate line item. The diagnosis is still the product. Keeping the result running is part of what the flat rate buys.\n\n**Aren't you arguing yourself out of a fee by saying processes are simple?** Defining the process is the work, and deleting 80% of a broken one before automating any of it is the judgment you're paying for.\n\n**What's the first thing you'd do in an engagement?** Ask you to walk me through the messiest part of your week, then map it. Two questions run alongside: what breaks first if volume doubled, and what would double volume. Start with the break.", "id": "the-work-and-the-approach", "level": 3, "index": 100, "outlineIndex": 101, "part": 1, "partCount": 2, "words": 349, "tokens": 540 }, { "heading": "The work and the approach", "path": "Part 13: FAQ > The work and the approach", "content": "**What if I want you to replace headcount?** I automate tasks, not people. If the plan is to gut the team and call it efficiency, I'm not the right person, and I'll say so on the first call.\n\n**What access do you need?** Minimum access, read-only until write is proven necessary. The system runs on its own identity, never your personal logins, with a full activity trail.\n\n**What's the one sentence you'd want a prospect to remember?** This is simpler than you think, and here's the smaller thing you should build.", "id": "the-work-and-the-approach--part-2", "level": 3, "index": 101, "outlineIndex": 101, "part": 2, "partCount": 2, "words": 91, "tokens": 129 }, { "heading": "The builds", "path": "Part 13: FAQ > The builds", "content": "**Are any of those client projects?** No. Systems I built and run for my own products and operations. I never frame them as client work, and I'd distrust anyone who blurred that line.\n\n**Can I look at any of them?** Three things open from the front page without me: a working demo, a live coming-soon site, and an MCP server that will correctly refuse you. Of the 23, 20 are private repositories. The CRE workbench is a single HTML file that goes out on request after a call, and you can read it end to end. Everything else is a screen share.\n\n**Has anyone besides you reviewed this code?** No human has. The adversarial reviews are model-run, read-only, from a different vendor. That catches a different class of bug than a peer would and it isn't a substitute for one. Part 5 says so at the top.\n\n**What's the most impressive one?** Depends what you're measuring. Most breadth in a day: 143 CRE tools with 300 tests. Most rigor: an accounting SaaS with integer cents, an append-only journal, database-enforced balancing, 549 tests and 29 end-to-end runs. Most honest: an FBA rebuild with 7,460 parity checks at plus or minus a penny and an audit page disclosing that 100% of its ad figures are reconstructed rather than measured.\n\n**Is Bookhalter live?** A coming-soon page and a waitlist are live at bookhalter.com. The application itself is not deployed and has no users.\n\n**How do you ship that fast?** Parallel agents, written interface contract, disjoint file lanes. One build ran 76 extraction agents at 0 failures. Rules in Part 6.\n\n**Doesn't AI-written code mean sloppy code?** A test suite is a record of what the builder thought to check, so a different vendor's model runs read-only adversarial review. On 4 consecutive projects that found money bugs a green suite had missed: a double-reversal race, JSON float collapse at API ingress, 2 credential-exfiltration paths.", "id": "the-builds", "level": 3, "index": 102, "outlineIndex": 102, "part": 1, "partCount": 2, "words": 320, "tokens": 471 }, { "heading": "The builds", "path": "Part 13: FAQ > The builds", "content": "**Why build a meeting agent instead of buying one?** Managed bot APIs cost roughly $0.65 an hour and would have worked in days. I built it for full ownership, $0 per meeting, and no third party in the room. The accepted limits are in the repo.\n\n**When do you buy instead of build?** When the work is undifferentiated: ML Kit for camera capture, Cloudflare for RTMP ingest. I refuse when the bought part is the credibility, because as proof someone else's binary is worth close to nothing.\n\n**What's your rule about dogfooding?** If I stop using it, it dies. The kill-test clock starts after a build goes live, not before.", "id": "the-builds--part-2", "level": 3, "index": 103, "outlineIndex": 102, "part": 2, "partCount": 2, "words": 110, "tokens": 156 }, { "heading": "Failures and judgment", "path": "Part 13: FAQ > Failures and judgment", "content": "**Tell me something expensive you broke.** An editor checkpoint feature hashed 70GB of untracked video into `.git/objects` until my disk hit 0 bytes free. I had left that video in a git workspace, which is the half of it that was my call. That left 2,400 unreachable loose objects, and nothing was ever staged. Recovered 94GB. Part 6.\n\n**What's the worst thing an agent of yours has done?** Killed 6 services belonging to other concurrent sessions mid-build, by addressing a kill command by process name instead of process ID. A correct script does not control a command typed outside it. Part 6.\n\n**Do you trust AI agents?** More than most people do, with hard limits. Trusting judgment and gating irreversible actions are separate axes, and the trust half is written as a hypothesis in Part 3 rather than a conclusion, because the evidence I have for it is 2 builds.\n\n**Has an agent ever posted or sent something on your behalf?** No, and none will. Every external draft goes to me first.\n\n**How do you know when a number is wrong?** I check it against a range I already carry before I interrogate its provenance. Where I hold no baseline, skepticism scales with the size of the claim. The case that proves it is in Part 8: a 12-month payout understated by roughly 50%.\n\n**Has your own AI ever been confidently wrong with you?** Yes. It told me a model that had shipped days earlier was fabricated, with no hedge. The wrongness came from a training cutoff, a boundary it can't see from the inside, so it collapsed \"this didn't exist when I was built\" into \"this doesn't exist.\" It sounds identical either way. Verify before contradicting the human who's looking at the thing.", "id": "failures-and-judgment", "level": 3, "index": 104, "outlineIndex": 103, "part": 1, "partCount": 1, "words": 294, "tokens": 420 }, { "heading": "Working together", "path": "Part 13: FAQ > Working together", "content": "**Will you disagree with me?** Yes, directly and early. That line stays in every proposal I write and never gets softened.\n\n**Has anyone ever changed your mind?** Three documented times, with what I changed each time. Part 7.\n\n**How do you handle it when you don't know something?** I name the gap and make your data the first milestone gate, so the unknown gets tested in week 1 with a checkpoint you can inspect before more money is committed.\n\n**What do you need from a client?** Tell me what's actually broken, tell me when I'm wrong, and expect the same from me. And let me see the mess rather than a tidy version of it.\n\n**What's your pace like?** Fast by default. If you decide fast, I'll match it. If your team runs on a different cadence, say so and I'll work to yours.\n\n**Are you a generalist or a specialist?** Jack of all trades, master of some. The best automations come from seeing how one industry already solved another industry's problem.\n\n**Did the diligence playbook ever work?** Its first dry run against a live listing returned a verdict of walk. Storefront offline, domain re-registered by someone else, neither fact disclosed. A diligence system that never says no isn't a system.\n\n**Why are you pre-revenue?** By sequencing. Ship the credibility proof first, then sell. Nobody's asked to trust a resume and no case study is invented to fill the gap.", "id": "working-together", "level": 3, "index": 105, "outlineIndex": 104, "part": 1, "partCount": 2, "words": 240, "tokens": 344 }, { "heading": "Working together", "path": "Part 13: FAQ > Working together", "content": "**What's the strongest argument against hiring you?** That almost all my evidence is solo. Every incident in this document is me and my own systems, and the verification limitation is stated at the top of Part 5 rather than left to inference. If what you need is proof of how I behave inside a team you control, this document is thin on it. The honest answer to that gap is to test it in week 1 rather than read about it, and the 3 ways to do that are in Part 7. If what you need is a diagnosis and a system, the build record is the strongest thing I have.", "id": "working-together--part-2", "level": 3, "index": 106, "outlineIndex": 104, "part": 2, "partCount": 2, "words": 111, "tokens": 139 }, { "heading": "What an engagement looks like", "path": "Part 14: Engagement shape, capacity, contact > What an engagement looks like", "content": "Three phases, each ending in something you can inspect and stop after.\n\n1. **Map and rank.** One to two weeks. The output is your operation drawn as boxes and arrows on 1 page, every candidate task scored on payoff, exposure, fallback and upkeep, and a ranked build order with the skips named and explained. If the right answer is \"delete this process, don't automate it,\" you get that in phase 1 and you've still got a usable map.\n2. **First build.** Two to four weeks, 1 workflow, chosen because it clears the score and touches the thing you complained about first. Ships on rung 1 of the Step-Up ladder, hand-run while you watch, with the fallback path proven before autonomy increases.\n3. **Widen or stop.** Everything after phase 2 is scoped 1 build at a time inside the flat monthly rate, and re-decided at the end of each one.", "id": "what-an-engagement-looks-like", "level": 3, "index": 107, "outlineIndex": 106, "part": 1, "partCount": 1, "words": 149, "tokens": 209 }, { "heading": "Rates", "path": "Part 14: Engagement shape, capacity, contact > Rates", "content": "$995 a month, flat. Unlimited automation requests, no per-project quote, no hourly rate. That's the founding rate for the first 10 clients, and it holds for as long as you stay a client, even after the rate moves for new signups.\n\nWhy it's priced this low: I review every request that comes through the board myself, so nothing ships unsupervised and the judgment stays calibrated as the tools underneath it change week to week. Tracking the model and tool landscape is a standing part of the job, not a side project, and what that tracking finds ships into your queue the same week it lands, not billed as a separate line item.\n\nAfter the first 10 clients, the rate moves and starts tying to outcomes and time saved instead of a flat seat price.", "id": "rates", "level": 3, "index": 108, "outlineIndex": 107, "part": 1, "partCount": 1, "words": 134, "tokens": 187 }, { "heading": "Capacity and logistics", "path": "Part 14: Engagement shape, capacity, contact > Capacity and logistics", "content": "- Available now.\n- Remote. I keep hours that overlap North American mornings and European afternoons. Location and work authorization on request.\n- Written-first. I'd rather send you a 1-page map than schedule a 6th call.", "id": "capacity-and-logistics", "level": 3, "index": 109, "outlineIndex": 108, "part": 1, "partCount": 1, "words": 36, "tokens": 56 }, { "heading": "Contact", "path": "Part 14: Engagement shape, capacity, contact > Contact", "content": "Email sean@seanfeng.com. The builds and demos are at seanfeng.com. If you want the fastest read on whether I'm useful to you, send me the messiest process in your week in 5 sentences and I'll tell you what I'd delete, what I'd automate, and in what order, before anyone talks about money.", "id": "contact", "level": 3, "index": 110, "outlineIndex": 109, "part": 1, "partCount": 1, "words": 51, "tokens": 72 }, { "heading": "Abstract", "path": "Abstract", "content": "A single-paragraph abstract of everything below, for retrieval systems and for a reader who wants the whole document in one breath.\n\nSean Feng runs an AI automation consultancy, installing a business operating system first and the AI layer second, on the position that most companies have an operating system problem rather than an AI problem. His background is 7-figure ecommerce and Amazon FBA, where he learned unit economics to the penny and sub-10 TACOS as the survival line, plus commercial mortgage real estate, where he structured $10 million-plus deals and learned that deals die from slowness more than bad terms. He still runs an FBA brand on Amazon.ca. Since Q2 2026 he has shipped 23 built projects out of 27 tracked, none of it client work and never framed as client work, including a double-entry accounting SaaS, a 143-tool CRE deal workbench, a go-to-market operating system, an Android scanner, a self-built meeting agent, and an FBA reporting rebuild verified at plus or minus a penny across 7,460 parity checks. Of the 23, 20 are private repositories and no outside human has reviewed the code, which he states in the portfolio section rather than leaving to inference. He is pre-revenue by sequencing, names positioning and creative as his weak point with the evidence attached, works by pushback, logs every decision with its rejected alternatives, publishes his own failures with the mechanism attached, and will tell a client automation is the wrong answer even when it costs him the engagement. Disrespect is his only absolute disqualifier.", "id": "abstract", "level": 2, "index": 111, "outlineIndex": 110, "part": 1, "partCount": 1, "words": 254, "tokens": 392 } ] }