Part of the Inner Agility thesis. This post documents a strategic pivot — from PFM as the primary proof vehicle to Trip Planner, driven by domain complexity and the need for a smaller, faster loop. Read the thesis →
Editor's note (July 1, 2026): Published as written in April. Sinew's definition has since evolved — rather than renaming hooksai wholesale, its core ideas were reimplemented clean and welded to a deterministic-replay trust layer proven in a separate proving ground. A future post will tell that story.
In our roadmap post a few weeks ago, we described three phases: finish the JE-PFM platform integration, build the iCashflow engine, then deliver the Pencil Workflow — the conversational UI creation vision where users speak features into existence.
That plan was not wrong. It was just scoped for the wrong first win.
This post explains why we pivoted, what the pivot actually is, and why the architecture thesis remains unchanged.
What the Original Plan Assumed
The three-phase plan assumed that JE-PFM — a mature platform with 148 components across 11 financial domains — could carry the entire proof burden. Finish it, add iCashflow, then bolt on conversational UI creation at the end.
We still believe JE-PFM's architecture is the right architecture. The 3-layer domain pattern, the component catalog, the workflow stories, the connective tissue — all of that is proven. We have the receipts in Proving the Generative Cycle.
But proving the architecture is not the same as proving the full product loop.
What the Full Product Loop Actually Is
The thing we are ultimately building is not JE-PFM. It is a service — and later, a hosted product — that takes someone else's vibe-coded app and transforms it into a platform architecture with an AI Chat interface, so they can keep building without hitting the Spaghetti Point around month three.
To prove that loop, we need to do the transformation end-to-end on a domain we can complete in weeks, not months. And then again, and again, until the pipeline is boring.
JE-PFM, with its 11 domains and 148 components, is too large to be the first demonstration of the full loop. It is the right scale for a production flagship, but too much surface area for the first proof.
The Trip Planner Vehicle
We had a personal need — an Alabama road trip at the end of May. We had already built a small trip planner app (two tables, basic CRUD) as a weekend project. And we had the lar-platform tooling — our decomposition pipeline — ready to test on something new.
So we pointed the tooling at the trip planner. Six hours of AI work with human verification later, we had tp-platform: 11 domains, 28 tables, full 3-layer architecture, Storybook stories, a component catalog, the works.
That was the "aha" moment. The pipeline we had been using to rebuild JE-PFM by hand for months had just rebuilt an entire app in an afternoon. Not because trip planning is simpler (it's not — there's vehicle modeling, waypoints, weather, campgrounds, fuel, budget). Because the pipeline was mature enough to do the work.
That changed everything. If we can decompose someone else's app in hours, the full product loop is closer than the three-phase plan assumed. But only if we stop treating JE-PFM as the thing that has to be finished before everything else.
The New Sequence
Instead of finish-JE-PFM-then-iCashflow-then-Pencil-Workflow, the sequence is now:
POC 1 — Domain Decomposer ✅ proven (tp-platform generated from the old trip-planner app)
POC 2 — AI Chat Trip Planner (next). Add AI Chat to tp-platform so the user can say "plan a 3-day side trip from Day 4" and have the app produce structured data that renders through existing components. The UI doesn't change; the data does.
POC 2.5 — Sinew Orchestration (new). Wire our orchestration engine — now called Sinew — into tp-platform. File watchers, chained hooks, permissions gates, skills injection.
POC 3 — Red Pencil (the big one). The generative cycle running live. The user clicks Red Pencil, describes a change, and the page materializes.
POC 3.5 — Domain Evolution via Pipeline (new). Prove the pipeline can evolve a platform, not just create one — add EV support to tp-platform, add multi-tenancy, add new domains.
POC 4 — Bridge Builder (the product). The hosted SaaS where customers connect their GitHub repo and watch the transformation happen.
Then — JE-TP ships as the first public case study.
iCashflow is not cancelled. It becomes a feature expansion of JE-PFM once the full loop is proven on trip-planner. The generative cycle, once working on je-tp, gets applied back to je-pfm.
What Changed (and What Didn't)
What changed:
- The first proof vehicle. JE-PFM → Trip Planner.
- The sequencing. Horizontal (finish one thing, move to next) → layered (prove the loop on smaller scope first, then scale).
- The orchestration engine has a name. Hooksai → Sinew. Same engine, better name. Sinew is connective tissue — which is exactly what it does across layers.
- The product has a name. Bridge Builder. It takes the thesis's closing line — "the architecture is the bridge builder" — and makes it literal.
What didn't change:
- The thesis. The software industry is losing its bridge builders, and the architecture has to become the bridge builder.
- The architecture. Layers of Resolution, 3-layer domains, component catalogs, workflow stories, connective tissue — all still correct.
- The ultimate goal. A hosted SaaS where non-engineers transform their vibe-coded apps and keep building through AI Chat.
- JE-PFM's role. It's Exhibit B (Moderate complexity) in the three-tier proof structure. Still the flagship reference implementation. Still the production proof of the 3-layer pattern.
The Three-Tier Proof Structure
The new Proof page shows three exhibits at three complexity tiers:
- Exhibit A (Easy): JE-TP — Trip Planner. Proves the loop.
- Exhibit B (Moderate): JE-PFM — Personal Finance. Proves the architecture at scale.
- Exhibit C (Complex): JE-HIA — Health Insurance Adjudication. Proves the pattern survives regulated complexity (future).
Three complexity tiers. Three demonstrations that the same architectural pattern works everywhere. That's a more honest story than "here is our one big app, look how cool it is."
Recovering-Health Pace
One more piece of context. Earlier this year I was diagnosed with a heart condition that requires significant downtime for healing. I work every other weekend. Off-weekends are for life away from the keyboard.
This affects the pace. It does not affect the thesis, the architecture, or the eventual product. It means each phase of this plan takes as long as it takes, and that's okay. The POCs are sequenced so that each one is independently valuable — if I shipped POC 2 and nothing else this year, Trip Planner would still be a real product with real users.
The overarching plan — with timelines that slip in favor of health — is documented internally. Externally, the commitment is simple: no dates, just sequence. Bridge Builder is coming. We're taking our time to get it right.
What This Post Supersedes
The JE-PFM Roadmap is now historical. The architecture described there is accurate. The three-phase sequencing has been replaced by the POC sequence above.
Everything else stays.