// signals
In May, I audited my own portfolio the hard way: 88 Drive items read by hand, 18 projects triaged through live question-and-answer. It produced a sharp snapshot of what I’d built and what was worth investing in. Then the session ended and all of it froze into a static markdown file. A few weeks later I shipped a system that keeps that intelligence live. It took one week and 1,189 tests.
Intelligence that freezes is intelligence you lose
The May discovery was good work, and it had a shelf life measured in days. A handover document is a photograph of a moving thing. Every repo I pushed, every commission I took, every idea I parked made the snapshot a little more wrong, and there was no cheap way to refresh it short of running the whole audit again. The problem wasn’t the analysis. It was that the analysis had nowhere to live.
So I wrote a PRD for the thing that should hold it: The Foundry. Its one-line job: turn RandomSynergy’s ideas into investable, documented, decided assets, and do it continuously instead of once.
What the cockpit actually does
Every studio idea, repo, and commission gets profiled against 19 required fields, each carrying its own provenance and confidence. I can see where a fact came from and how sure the system is about it. From there it runs a 9-criterion weighted scorecard plus an AI memo, then routes the project to one of 7 dispositions: investment portfolio, FOSS, personal, client commission, parked, dropped, or studio credibility. The documents investors ask for (business plans, one-pagers, pitch decks) get generated from that same profile data, not retyped from memory.
The honest caveat: it’s an internal tool. foundry.randomsynergy.xyz serves a login page marked “authorized access only.” There’s no public demo, and there won’t be one in v1. This is infrastructure for running the studio, not a product I’m selling yet.
One week, two agents, 1,189 tests
Planning started July 3. It was in production by July 10. In between was a ~180-task development plan and a multi-agent build I ran as Fable-orchestrates, Opus-executes: one model holding the plan and sequencing the work, another writing the code against it. That split is why a week was enough: the orchestration never lost the thread, and the execution never had to hold the whole map in its head at once.
I don’t trust a fast build without proof it works. So it shipped with 1,189 tests green behind a 6-job CI: Pint, Pest running against real pgvector, the frontend, a palette check, Playwright end-to-end, and an egress tripwire that fails the build if the code reaches for a network endpoint it shouldn’t. For a system wired into a self-hosted LLM gateway, that tripwire is the difference between “probably safe” and “the pipeline won’t let it be otherwise.”
Stack, for the record: Laravel 13, Livewire 4, PHP 8.4, Postgres 17 with pgvector, and every AI call routed through a self-hosted LiteLLM gateway.
Prove it cheaply before you trust it
Fast doesn’t mean fragile. An adversarial 4-mission security audit found 6 serious issues (including a secret-env leak in the agent runner and an SSRF hole in URL ingestion), all fixed and independently re-verified. Backups run nightly: a Postgres dump plus a data tarball, 7-day and 4-week retention, copied offsite. And I didn’t just configure restore. I ran the drill and brought the system back from a backup. A restore you’ve never rehearsed is a hope, not a backup.
The takeaway
This is the method, not a one-off. Build the capability once. Prove it cheaply (with real tests, a real audit, a real restore drill) before it carries any weight. Then graduate what works. The Foundry earns its keep by running the studio; if the evaluation engine holds up here, the same engine graduates to the enterprise and public-sector work where the stakes are higher, already battle-tested. That’s the whole thesis in one build: the technology changes, the discipline doesn’t. Intelligence that freezes is a liability. I’d rather build the system that keeps it live.