Part of the Inner Agility thesis. This post shows how three phases of work align to the Layers of Resolution architecture — each phase builds on what the previous one proved. Read the thesis →
Every project has a tension between what you are building now and where you want to end up. Build too narrowly and you paint yourself into a corner. Build too broadly and you never ship. JE-PFM sits at an interesting point in this tension: we have a mature domain platform with 148 components across 11 financial domains, a SaaS framework ready for production, and a vision for AI-driven UI composition that is ambitious enough to feel unreasonable. The roadmap is about connecting those three realities in the right order.
We track all of this through an SDLC pipeline in Obsidian — a set of numbered directories where ideas flow from vision to spec to active work to completion. Each phase of the roadmap corresponds to documents moving through that pipeline. It is not a Gantt chart. It is a living system where the plan evolves as we learn.
Two Repos, One Product
Before the roadmap makes sense, you need to understand how the codebase is organized, because the architecture is the roadmap's backbone.
pfm-platform is a pnpm monorepo containing 11 financial domains, each built with a strict 3-layer architecture: data-access hooks wrapping Supabase queries, feature hooks containing business logic, and UI components built with Material UI. Every domain — accounts, transactions, budgets, tags, imports, expenses, goals, alerts, notifications, users, and partners — follows this pattern identically. The 34 packages are published to GitHub Packages as versioned npm modules that any application can consume.
je-pfm is a separate repository built on a Next.js 16 SaaS framework. It provides the production infrastructure that pfm-platform deliberately does not: authentication flows, billing integration, team-based multi-tenancy, internationalization, admin dashboards, and the full application shell with routing, navigation, and layout.
The product is what happens when these two repos merge at runtime. JE-PFM installs pfm-platform's published packages, wraps them in the SaaS framework's application shell, and you get a production-ready personal finance application where every financial feature is a composable, independently-versioned module.
There is also a third piece: je-pfm-oneshot, a Vite single-page application living inside pfm-platform that consumes 24 of the domain packages directly. It was originally built as a proof of concept — feed the JE-PFM specification to an AI and see if it can produce a working app. It succeeded, which validated the architecture. Now it serves as a rapid prototyping environment where we can test new ideas without the complexity of Next.js server-side rendering.
Phase 1 — Finish JE-PFM
This is where we are right now. The domain layer is built. The SaaS framework is ready. The gap is the integration between them.
The immediate work is a sequence of four proof-of-concept projects, each validating a different assumption about how the pieces fit together. We track these as documents in 2-on-deck/ in our Obsidian pipeline, with explicit dependencies between them so we never build something that relies on unproven ground.
The first POC takes a single domain page — Budgets — and renders it inside the je-pfm Next.js shell. This sounds simple, but it exercises every integration concern simultaneously: installing pfm-platform packages from GitHub Packages, configuring Next.js to transpile them, bridging the authentication systems so MakerKit's Supabase session flows into pfm-platform's data hooks, and confirming that Material UI components render cleanly inside a Tailwind CSS layout. If Budgets works, every domain works, because they all follow the same pattern.
The second POC generates a machine-readable catalog of all 148 UI components. Each component gets a name, a domain, a category (list, form, chart, card, summary, dashboard), a description of what it does, and its props interface extracted from TypeScript declarations. This catalog becomes the AI's vocabulary for later phases, but it also serves as an immediate documentation asset — a single JSON file that describes the entire visual surface of the platform.
The third POC builds an AI chat prototype inside je-pfm-oneshot. When a user toggles to admin mode, a red pencil icon appears. Clicking it opens a chat panel where the user describes a page layout in natural language. The AI, given the component catalog as context, interprets the request and returns a composition spec — a JSON object listing which components to render and in what arrangement. The prototype then renders those actual components with real data as a live preview.
The fourth POC takes the composition spec format that the AI chat establishes and builds a dynamic page loader that can assemble pages at runtime from JSON configuration files. This is the infrastructure that turns the AI chat from a demo into something usable — the AI's output becomes a page that persists without requiring a code change or rebuild.
After these POCs validate, the remaining Phase 1 work is wiring all seven JE-PFM domains into the production je-pfm app, migrating the Supabase schema from the pfm-platform project into je-pfm's project so everything runs against a single database, and running a full QA pass with real financial data.
When Phase 1 completes, we have a production SaaS application that people can sign up for, import their bank data, manage accounts and transactions, track budgets and expenses, and use the platform day to day. That is the minimum viable product. Everything after this builds on top of it.
Phase 2 — Build iCashflow
iCashflow is the analytical engine that transforms JE-PFM from a record-keeping tool into a decision-making tool. The question it answers is deceptively simple: given your current financial patterns, what happens next?
The architecture uses a four-layer data model that we have been designing in parallel with Phase 1 work. The first layer — import — already exists in pfm-platform. It handles file upload, format detection (CSV, OFX, QBO, QFX), parsing, merchant normalization, and auto-categorization with confidence scoring. The 64 hand-tuned categorization rules came from real bank transaction data and cover everything from coffee shops to payroll deposits.
The second layer is the cashflow engine. It takes categorized transactions and detects recurring patterns: bills that hit on the same date each month, income streams with consistent amounts, subscriptions with small variance. The detection algorithm requires at least three occurrences per merchant with less than 30 percent variance in timing or amount — the same threshold used by institutional aggregators. From these patterns, the engine projects forward: here is what your next 30, 60, 90 days look like if nothing changes.
The third layer is the scenario engine, and this is where iCashflow gets distinctive. It uses a "Git for your financial future" metaphor. Your current projections are the main branch. A what-if scenario is a branch that inherits all the rules from its parent and adds overrides. What if I take a second job? Branch from main, add an income rule. What if I cancel three subscriptions? Branch, override three expense rules. What if the house sells in June? Branch, add a one-time event. Each scenario computes independently, and you can compare them side by side.
The fourth layer is visualization projections — precomputed outputs optimized for rendering. Timeline charts showing multiple scenarios as overlapping curves. Waterfall charts breaking down monthly cash flow by category. Bill calendars showing upcoming obligations. Sankey diagrams tracing where money flows from income sources to expense categories.
There is also a stretch goal here: a Google Sheets extension that connects to the iCashflow engine. The original motivation for the entire project was a personal spreadsheet used for monthly cash flow tracking. The spreadsheet worked — it answered the "can I afford this?" question — but it was rigid. You could not branch scenarios, you could not import bank data automatically, and projections were manual formulas. Bringing iCashflow back to the spreadsheet as an extension would close the loop: the same analytical power, accessible from the environment where the financial thinking started.
Phase 3 — Pencil Workflow
This is the vision that drives everything else, even though it will be the last thing built. The idea started as an Excalidraw sketch — literally drawn while thinking out loud — and it describes a fundamentally different relationship between users and the software they use.
The core interaction is this: a user is looking at the Budgets page and thinks, "I wish I could see an expense breakdown chart right here, above the budget list." Instead of filing a feature request and waiting for a developer to implement it, the user clicks a pencil icon, types their wish in natural language, and the system composes a new page layout from existing components. The user sees a live preview, approves it, and the page updates. No deploy. No code change. The user spoke a feature into existence.
What makes this more than a toy demo is the component catalog underneath it. The platform has 148 composable UI components, each with defined props interfaces and data hooks. The AI is not generating code from scratch. It is selecting from a known vocabulary of proven, tested building blocks and arranging them according to the user's intent. The anticipatory preview window — showing matching components in real time as the user types — makes the AI's component vocabulary visible, turning the interaction from a blind prompt into a visual conversation.
The longer-term dimensions of this vision are deliberately left open. Per-user forks where each person's customizations persist on their own branch. Multi-person chat where a team discusses and shapes their application together through conversation. Customer extensions where businesses get their own fork of the platform with customizations maintained by the platform team. These are real possibilities that the architecture supports, but they are Phase 3 ideas — we build toward them, we do not build them yet.
How the Pipeline Connects Everything
Each phase of this roadmap lives in our SDLC pipeline at a different level of resolution.
Phase 3 — the pencil workflow — sits in 0-vision/ as Excalidraw drawings and ideation notes. It is the north star. We reference it to make sure the architecture decisions we make in Phase 1 do not foreclose options we will need in Phase 3. But it is not a specification. It is a direction.
Phase 2 — iCashflow — sits in 0-vision/iCashflow/ as a detailed data model (the four-layer architecture is fully specified) and a CLAUDE.md that describes the technical approach. When Phase 1 completes and we begin Phase 2, these documents will advance to 1-specs/ and then to 2-on-deck/ as active work items.
Phase 1 — JE-PFM — has documents at every stage. The JE-PFM requirements spec with its 63 use cases sits in 1-specs/. The POC execution plan and component catalog sit in 2-on-deck/ as active work. The completed Storybook QA, documentation cleanup, and RLS audit sit in 3-done/archive/ as finished milestones. The reusable Claude Code prompts that help us manage the CI pipeline sit in 4-reference/.
A Claude Code skill called pipeline-manager manages the flow. At the start of any work session, saying "where are we?" produces a status report showing what is active, what is next, what is blocked, and what has gone stale. When a POC validates, saying "mark it as done" moves the document to 3-done/ and updates the dashboard. When a session produces a new artifact — a spec, a catalog, a plan — saying "capture this" files it into the appropriate pipeline stage.
The pipeline is not project management software. It is five numbered directories in an Obsidian vault. But the discipline of flowing documents through stages — from vision to spec to active work to completion — prevents the three phases from bleeding into each other. We work on Phase 1 because that is what is in 2-on-deck/. We do not prematurely build Phase 3 infrastructure because Phase 3 is in 0-vision/ where it belongs. When the time comes, it will advance.
What Matters Most Right Now
If you are evaluating JE-PFM today, the honest answer is: we are in Phase 1. The domain layer is mature and well-tested. The SaaS framework is production-grade. The integration between them is underway. The four POCs are sequenced and the first one — getting a pfm-platform page rendering inside je-pfm — is the immediate next step.
What gives us confidence in the roadmap is not a timeline or a Gantt chart. It is the architecture. Because every domain is a self-contained package with a clean API, Phase 1 integration is a wiring exercise, not a rewrite. Because the UI components are individually exported and composable, Phase 3's dynamic page composition is a selection-and-arrangement problem, not a code-generation problem. Because the data model for iCashflow is already designed with its four-layer progression, Phase 2 can build incrementally on top of Phase 1's import engine.
The roadmap is ambitious. We know that. But every phase builds on what the previous phase proved, and nothing in the later phases requires us to throw away what we built earlier. That is the one thing we are unwilling to compromise on.
Follow the development on GitHub. The entire SDLC pipeline, including the component catalog and POC execution plan, is in the docs/pfm-platform/ directory.