Updating My Roadmap Tool + Splitting CARL Optimizer | Live Vibe Coding
By Will Melton · May 23, 2026 · 1:25:49 read
Category: Business & Economy
Show: Live Vibe Coding With Will Melton
Two builds today — starting with an upgrade to the product roadmap tool that's been on my list for a while. The roadmap tool inside Spaceport manages every feature, fix, and improvement across the @Xp
Two builds today — starting with an upgrade to the product roadmap tool that's been on my list for a while.
The roadmap tool inside Spaceport manages every feature, fix, and improvement across the @Xponent21 stack. It works. But there's been a gap: nothing in the workflow forces you to think about blast radius before you start building, and nothing enforces a real quality check before a task gets cleared.
We're fixing both of those today.
First, a preemptive step on every task card — before any dev work begins, you declare which internal functions in the app this change will affect. Forces intentionality up front. You're not discovering the impact mid-build or in review, you're mapping it before a single line is written.
Second, a post-step that gates exit from In Review: a regression checklist auto-populated from the functions you flagged in the pre-step. Every affected function becomes a named checkbox. All of them have to be confirmed working before the task can be cleared. No more "it's done" when what you mean is "the main thing works." Everything the change touched has to be verified — explicitly, by name.
Together these two steps close the loop between intention and completion. You said what you were going to affect. Now prove it still works.
That's the first build.
Second: CARL Optimizer gets its own dedicated infrastructure. CARL has been delivering AI content optimization for Xponent21 clients — analyzing published content, identifying gaps between what's on the page and what AI systems reward, surfacing page-level recommendations strategists can act on. That capability is proven.
What's changing is the architecture. Optimization and writing are different functions with different logic, different development needs, and different teams. Keeping them in shared infrastructure puts a ceiling on how fast either one can advance. Splitting them means each tool develops at its own pace — CARL Writes on one track, CARL Optimizer on another, neither constrained by the other.
Both builds today are really about the same principle: **separate concerns, define scope, verify outcomes.** Build with intention.
This is part of the **52 Apps in 52 Weeks** challenge — real Xponent21 infrastructure, built live on camera. No tutorials. No demos. The actual work.
🔧 Stack: Lovable · Supabase · Claude · Xponent21 Central API
🔗 Links:
- Try Lovable (get 10 free credits): https://lovable.dev/invite/S8XSI99
- Xponent21: https://xponent21.com
- Studio hub: https://studio.willmelton.com
- CARL Suite: https://xponent21.com/carl