I Killed Three Projects Before Joseph Survived: A Non-Engineer's Three-Month AI Build Log

TL;DR if you're in a hurry

I'm a retail worker in Hualien, Taiwan. Not an engineer. Starting in January 2026, I built four projects with Claude Code: CAIOS, Growth Factory (an AI tools site), BuildHub Patrol, and Joseph. I killed the first three. Joseph — an investment execution agent — went live on 2026-04-20. This post is about why I killed the others. The next post is about why Joseph survived.

---

Series overview

This is part 1 of the "Joseph: zero to go-live" series. All three posts were published the same day. Read in any order, but I'd suggest top-down:

1. [Part 1 — this post] Identity: who I am, why three projects had to die
2. [Part 2] Seven principles I learned working with Claude — spec-driven, boundary-first, decisions that stick
3. [Part 3] From nine DRY RUN failures to go-live — T+2 triple lock, 458 tests, 18 crons, Shioaji pitfalls

---

Confession first: I'm not an engineer

I work at a retail store in Hualien. Day shift. I write prompts at night. I can read Python, follow a git log, but I don't "write code for a living." Three months ago I didn't know what pytest was. Or cron. Or T+2 settlement.

I wanted to use AI to build an investment research system I'd actually use. That sounds romantic. The execution was a lot less romantic — for instance, I killed a project I'd spent two months on.

Four projects, three dead

Results first, explanation second:

Project	Purpose	How it ended	Date
CAIOS	Upper-layer system coordinator (Gateway + Workers + Web + Telegram)	Decommissioned 9 systemd services	2026-04-12
Growth Factory (AI tools site)	Programmatic SEO tool pages, 405+	Pivoted site, deleted all tool pages	2026-04-12
BuildHub Patrol	Early concept, no full repo	Faded from memory	—
Joseph (investment agent)	Automated investment execution subsystem	Still alive	2026-04-20 go-live

CAIOS: did too much, converged too late

CAIOS was my early attempt to "build a brain that coordinates everything" — API gateway, DOA worker, a Next.js web console, Telegram polling. All of it as systemd units on one VM. Sounds cool. Reality: every time I wanted to change anything, I had to first figure out which service, and which three upstream-downstream things it would affect. For a non-engineer, that complexity was past what I could maintain.

On 2026-04-12 I did a system convergence. The report is in consolidation-report-20260411.md — nine systemd units stopped, VM went from 29 services down to 24, about 500MB RSS freed. That wasn't optimization. That was amputation. I slept well that night.

Lesson: The urge to build "an upper-layer coordinator" usually comes from not knowing what the lower layer actually needs to coordinate. Building the frame first and filling in content later often means never filling it in.

Growth Factory: if it doesn't earn, it doesn't earn

Growth Factory was positioned as a "programmatic SEO tool site" — caption generator, bio generator, title generator, hashtag generator, monetized via affiliate links. The README bragged about 405+ programmatic pages, other docs cited 2,400+ tool pages.

The site looked impressive. Traffic was honest. Affiliate click-through was low enough that I started wondering if Google Analytics was broken. On 2026-04-12 I wrote site-pivot-plan.md, decided to kill the whole tools site, and pivot to a personal build log. Only the mascot (Lazy Dino) and color system survived — because I still liked those.

Lesson: "AI tools site" looks like a blue ocean, but any site that wraps an upstream model gets squeezed flat the moment the model gets cheaper and smarter. When I myself didn't use my own tools, that wasn't a market problem. That was me.

BuildHub Patrol: honestly, I don't have enough data

I find scattered mentions in some docs, but no complete repo and no clear record of how it ended. To be honest: it got killed early, and I didn't even write down why at the time. That was my state back then — no records, no docs, kill projects on a whim.

That behavior became part of why Joseph survived.

Why Joseph survived

After three dead ones, the living one.

Joseph is an investment execution subsystem. The earliest commit is 2026-01-26: "Initial commit: Project Joseph v3.3 Ultimate with secure gitignore." From that day to go-live on 2026-04-20 is about three months and 106 commits.

Joseph survived not because I got smarter. Because the three dead projects taught me a few things:

1. Spec first, code second

During the CAIOS era I coded whatever came to mind. Before starting Joseph I wrote JOSEPH_FOUNDATIONAL_RULES.md — ten rules, from "cash-only, no margin" to "all trading parameters read from YAML, no hardcoding." That doc is for Claude Code. It's also for me. With rules, the AI has boundaries to defend.

2. Acceptance criteria as Given/When/Then

Every feature's spec goes into this three-line format:

Given: available cash = 200,000 TWD
When:  scanner detects a ticker with swing score >= 60
Then:  issue buy order; trading log records full reasoning chain
Verify: grep "BUY" logs/trading.log | tail -1

I stole this format from docs/AI協作到AI全自動開發攻略.md. Its opening line: "A spec isn't a document. It's a contract. A spec written well enough lets AI run the whole dev loop on its own." Two months of experiments said that line is real.

3. DRY RUN is a life saver

Before Joseph went live, we ran three DRY RUN batches back-to-back: 4/7–4/10 initial, 4/13 formal, 4/15–4/17 extended. Each batch simulates real orders without placing them. Every batch blew up on something. I'll list all nine failure modes in part 3.

If CAIOS had done DRY RUN, it wouldn't have died so mysteriously. If Growth Factory had a "validate traffic before stacking pages" mechanism, it wouldn't have built 2,400 pages before realizing it couldn't monetize.

4. A triple lock

Before going live, Joseph has what I call a T+2 triple lock — three independent switches. Missing any one, the system refuses to place orders. This is the single most important thing I took away from killing three projects: anything involving money should default to refusing to run. Mechanism details are in part 3.

A few decision moments I can't dress up

2026-04-12: killed two projects in one day

That morning I decided to kill CAIOS. At noon I wrote the pivot plan to kill Growth Factory. In the afternoon I stopped 9 systemd services. I didn't feel good. I felt tired. You kill something you built over two months, nobody claps. Only you know it was the right call.

2026-04-13: shadow_ledger had 33 leftover test trades

That morning I opened the report and saw holding_days=38. Joseph had been running for one day. I traced it for two hours and found an E2E test didn't clean up state, so it wrote fake trades from 2026-03-06 into shadow_ledger.json. That moment I wanted to just stop the whole project.

But killing becomes a habit. I chose to write a FIX_REPORT_0413.md instead — reset the shadow_ledger, fix the HTML-attachment UTF-8 issue, update the cron_wrapper path from the old account to the new one, rerun.

2026-04-18: Telegram fired seven alerts outside trading hours

00:01 in the morning. The bot sent 6 Circuit Breaker alerts + 1 error notification. My own system woke me up. I traced it and found the doc claimed there was a PYTEST_CURRENT_TEST guard, but the code had no such guard. The doc had lied to me for two weeks.

That day I wrote TELEGRAM_LEAK_DIAGNOSIS_20260418.md, spent the day shipping five fixes. Two days later we went live.

2026-04-20: GO

On Saturday 2026-04-18 I delegated the go-live decision to Claude Code. All gates passed — Gate 4 (tech health) 5/5 PASS, Gate 10 (T+2 guards) 3 PASS + 1 expected WARN, Gate 11 (TraderLive live-order capability) 72 tests PASS. Monday 2026-04-20 at 08:00 Taipei time, the boot cron fired, Joseph entered live-observation mode.

That day I still went to work. At the store.

No inspirational closer

I'm not going to tell you "AI makes anything possible." That's ad copy.

What I'll tell you: if you're not an engineer and you want to build a real system with AI, you will kill a lot of things. You'll get woken up at dawn by your own bugs. You'll find on a Sunday afternoon that the docs and the code disagree and you'll want to throw the monitor. None of that goes away. It just becomes part of your day.

Joseph is young. It just entered observation today. It'll probably throw new bugs. But at least I learned one thing: you can kill what you can't finish. You can't lie about it. Killing three projects isn't shameful. Faking a success story is.

Next post: the seven principles I extracted from three months of collaborating with Claude that let the AI actually run the dev loop by itself — not hover over its shoulder.

---

FAQ

Q1: Are you really a retail worker in Hualien and not an engineer in disguise? Really. I can read code, write simple Python. Architecture, testing strategy, settlement logic — I learn those by asking Claude. Not being an engineer actually made me more dependent on "write the spec clearly" — if the spec is fuzzy, whatever the AI makes I can't verify anyway.

Q2: Why did you have to kill CAIOS? Couldn't you refactor? I tried. But refactoring assumes you know what it should become. I didn't. "I want a brain that coordinates everything" translates into a spec that covers everything and defends nothing. When I can't even write the spec, there's no starting point for a refactor. Killing is clearer.

Q3: Will you kill Joseph too someday? Maybe. If I discover it's no longer useful, or its risk exceeds what I can bear, I'll kill it. One thing keeping it alive: its spec is clear, its verification commands are concrete, I can at any moment check whether "it's still doing what it's supposed to."

Q4: Three months from scratch to live trading — too fast? From 2026-01-26 (v3.3 first commit) to 2026-04-20, yes. But the version tag says v3.3 — so v1 and v2 existed before (without full records), so the actual exploration time was longer. Before going live we ran three DRY RUN batches and passed three gates. That's not fast. That's checking everything that could be checked.

Q5: Why not use an off-the-shelf quant platform? I've tried. The issue isn't platform strength, it's that my strategy logic couldn't be fully expressed on a closed platform. Rolling my own has one advantage: when it breaks, I know exactly where it broke. No ticket queue.

Q6: What's step one for a non-engineer who wants to build systems with AI? Not "learn to code." Learn to write specs. A clear spec lets the AI build and lets you verify. How, specifically — see part 2 of this series.

Q7: Are all the numbers and events in this post real? Yes. Every specific number here (nine systemd services, 405+ pages, 106 commits, 458 tests, 18 crons, go-live date) can be verified against the Joseph repo's docs and git log. No fiction in this post; where data is thin (like BuildHub Patrol's ending), I say so explicitly.

Q8: Will Joseph publish holdings or order history? No. None of these three posts disclose specific holdings, entry prices, position sizes, the triple-lock implementation, or API credentials. This is a personal build log, not a signal service. Nothing here is investment advice.

---

Next

Part 2: Seven principles I learned from Claude →

If you're still on this page, you're probably wondering: "OK so, specifically, how do you work with Claude such that it actually runs the loop without you hovering?" That's part 2.