Part of the Inner Agility thesis. This post documents the first use of the decomposition pipeline on an app other than JE-PFM. It is also the receipts for the strategic pivot described in "Why We Pivoted". Read the thesis →
Every proof deserves skepticism. We had spent months building JE-PFM's architecture by hand and documenting the pipeline that produced it. But the pipeline had only ever decomposed one app. Was it a pipeline, or had we just produced one good codebase through effort and then written documentation that looked like a pipeline?
The way to find out was to run it on something else.
The Test Case
The old trip-planner app lives at trip.inner-agility.dev. It is a weekend project — two Supabase tables, basic CRUD, enough to plan a real road trip for our Alabama visit at the end of May. No architecture. No layers. No catalog. A vibe-coded app, honestly.
That was exactly what we needed. A small, real, working app with no architecture — the same starting point a future Bridge Builder customer would arrive with.
The Pipeline
The decomposition pipeline is a sequence of prompts, schemas, and templates that turns an input codebase into a 3-layer domain architecture. The output conforms to Layers of Resolution — the architectural pattern we have described in previous posts. In rough order, the pipeline:
- Discovers domains from the existing code and database schema
- Extracts entities and relationships
- Generates use cases and workflows
- Produces component and pages catalogs
- Scaffolds 3-layer packages (data-access → feature → ui-mui)
- Generates tests, Storybook stories, and infrastructure
- Produces a SaaS shell that consumes the packages
For JE-PFM, this had taken weeks of iterative prompt refinement. For the trip planner test, we wanted to see how much of that refinement was transferable.
What Came Out
Six hours of AI work with human domain verification produced tp-platform:
- 11 domains, up from the original 2 tables. The AI identified trips, itinerary, campgrounds, fuel, budget, members, users, and todos — plus room for vehicle, waypoints, and weather as domain evolution candidates.
- 28 database tables, up from 2. The new schema includes business rules, harness coordination tables, and multi-tenancy support.
- 4 packages shipped for the todos domain alone (data-access, feature, ui-mui, shared), each with its own tests. 67 tests in total, all passing, with Storybook stories covering component variants.
- Component catalog and pages catalog — the machine-readable connective tissue that an AI can consume to compose pages.
- A component demo app that works exactly like the original trip-planner, but now running on the decomposed architecture.
The first time the component demo rendered and behaved like the original, we caught ourselves grinning. The pipeline had produced, in a single session, something that would have taken weeks to build by hand.
What Surprised Us
The pipeline did more than we asked. In particular:
Business rules emerged. The original trip planner had two tables and no real business logic. The decomposition produced 28 tables with explicit business rules (trip ownership, member invitations, budget constraints). The AI was pattern-matching from JE-PFM — and because the Layers of Resolution pattern is fractal, the match was reasonable. Trip planning has membership and ownership the same way PFM has accounts and users.
Harness coordination appeared automatically. We had not asked the AI to produce multi-tenancy infrastructure. It produced it anyway, because the pipeline templates include it. That's the pipeline doing its job — customer-facing apps need multi-tenancy, so the templates produce it.
The AI asked good questions. At several points in the six hours, the process paused with a question — "should vehicle profiles support EVs as well as ICE?", "is this a shared trip or personal?", "what's the relationship between campgrounds and itinerary days?". Each question was a genuine domain decision that a human had to make. The pipeline did not pretend to know things it didn't.
What Didn't Work the First Time
Honesty matters here. Not everything was clean:
The infrastructure scaffolding needed re-wiring. The templates were tuned for JE-PFM's specific Supabase/Next.js/MakerKit setup. For tp-platform, we switched to Vite templates, which required rewriting several prompts and templates. This is genuine pipeline maturation — the templates need to abstract over deployment targets, not hard-code one.
Some parts needed hand-holding. The AI got the domain boundaries right but occasionally wandered on naming conventions or file structure. A human had to nudge it back. This will improve as the prompts mature.
The catalog took iteration. The first component catalog had some inconsistencies — two components with slightly different names for the same concept, a few props missing from the declarations. An hour of cleanup after the AI finished.
None of these were blockers. All of them will shorten the next time.
Where This Points
This was the first external test of the decomposition pipeline. It worked. The pipeline is a pipeline, not a one-off.
Which means:
- The full product loop is closer than we thought. If we can decompose someone else's app in hours, the service model — transformation service, then hosted SaaS (Bridge Builder) — is real.
- The strategic pivot was right. Trip Planner is a better first proof vehicle than JE-PFM. Smaller scope, full loop, real product. See "Why We Pivoted".
- Domain evolution is the next test. The pipeline produced tp-platform from scratch. Can it evolve tp-platform — add EV support, add multi-tenancy, add a new domain — without breaking the existing architecture? That's POC 3.5 in the new roadmap.
What's Next for tp-platform
The current tp-platform has the todos domain fully built (4 packages, 67 tests, Storybook, component demo). The remaining seven domains (trips, itinerary, campgrounds, fuel, budget, members, users) are scheduled for completion before the end of May — hard deadline, because the Alabama trip is May 30.
After that, the domain evolution roadmap kicks in. Vehicle becomes polymorphic (ICE + EV). A new charging domain appears alongside fuel. Weather and waypoints get added. Budget learns about charging costs.
Each evolution is a test of the pipeline's ability to evolve a platform in place — which is exactly what Bridge Builder will need to do for customers as their businesses grow.
The component demo for tp-platform is running locally — we'll deploy it publicly once the todos domain is cleaned up and the first real integration with je-tp exists.
The Pipeline is the Thesis
The Layers of Resolution thesis argues that architecture must simultaneously raise abstraction for composition and lower it for learning. This is what that looks like in practice — a pipeline that takes an unstructured app and produces a structured one, where the structure is navigable by both humans and AI.
Every time we run the pipeline on a new app, the pipeline gets better. Every friction point becomes a prompt refinement. Every surprise becomes a new template capability. The pipeline is the thesis made operational.
tp-platform is the first proof that this is a pipeline, not a performance. There will be more.