SMART DEBT App Dev

Date: 2026-03-19

Background

• When I first became interested in better understanding the controversial wealth-acceleration strategy of leveraging or borrowing to invest, I discovered that there was very little information available on the topic and, at the time, no analysis software to understand the fundamentals of if and when different leveraging strategies benefited investors. So before I wrote my first publication on the topic, “Dispelling the Myths of Borrowing to Invest”, described at https://talbotstevens.com/Products/BooksBooklets/Booklet.shtm.
• As an engineer and math nerd, I needed to understand the math. In Visual Basic 6, I did the math for interest-only leveraging, term loans (paid off over time), and borrowing for RRSPS, introducing and quantifying the five RRSP Refund strategies. The result was a Windows desktop software program I called Leverage Professional, described at https://talbotstevens.com/Products/Software/LevPro.shtm.
• LevPro features
  • Industry-first professional analysis of unregistered borrowing to invest with interest-only and term loan approaches, and RRSP Catch-Up and Gross-Up loans.
  • Annual cash flows. Annual analysis of results on a Net (after repaying loan) Before-Tax basis, using the same after-tax cash flows and timing, tracking ACB and paying off loans with after-tax dollars.
  • Targeting financial advisors, who could get personalized projections for clients/prospects with their company name to provide objective, third-party education and disclosure of the range of outcomes when borrowing to invest. This was critical first for understanding for advisors and investors, and for compliance disclosure and business risk reduction. This is a sample one-page Leverage Analysis Summary, at https://talbotstevens.com/Products/Software/TalbotsLeverageProfessionalSampleInterestOnlyLoanSummary.pdf, complete with signatures for the client, advisor, and advisor manager.
  • Annual subscription: $95 before volume discounts. A national bank licensed it for their 600-700 financial advisors for 7 years.
  • Full French translation, necessary for use by any national bank to meet Quebec language requirements. Also meant handling the complexity of separate tax deductibility rules for leveraging interest in QC (limited annually to investment income, with unused room carried forward).
  • Free 30-day evaluation version with full functionality. More than enough time for individual investors to use fully benefit for free. My business model was the financial industry.
  • Only available for Windows. No other operating systems. Not updated for over 15 years.
• To address the many unanswered questions that I have about leveraging, in Canada let alone other countries like the US, a more powerful analysis system for leveraging is needed. The first step is to bring the solid software analysis foundation from 25 years ago into the present and make it available on the web for any device.
• This new leveraging analysis software will simply be called “$MART DEBT App”, consistent with my $MART DEBT branding for all offerings. An outdated outline of offerings is here, D:\FSS\KB\Business\02_Strategy\Smart Debt Offerings.md.
• HUGE BONUS: The approach of building on my established investment debt analysis in the LevPro software, and gradually expanding its capacity in phases including taxation of other strategies, in other countries like the US, is significantly more practical than the very ambitious and difficult task of first building a new, comprehensive After-Tax Investment Math library, which I outlined recently. The revised and more strategic plan is to evolve from this critical core (80/20 approach) and expand as needed into developments asked for and confirmed as wanted by a $MART DEBT community.

SMART DEBT App

• an integrated collection of mini-apps
• PWAs, built with SvelteKit
• including $MART DEBT Snapshots (demo-teasers)
  • easily added to any website, including my site (sdc.com, ts.com)
• integrated as part of my Astro monorepo, using shared branding and design system
• Tech Stack
  • See \\wsl$\Ubuntu-24.04\home\ta\projects\monorepo\README.md for latest, including component architecture, design token system, brand management, and more.
• handle different countries and languages, with /country/language structure; targeting Canada and U.S.

---

Development Plan, Draft 0

Overview

• Port (parts of) my Leverage Pro software (in VB6) to PWA (in SvelteKit)
• Approach
  • spec in CC, w Superpowers if needed
  • 80/20, Big Rocks dev approach: Big rocks first, in phases

---

Phases

• Create project structure
  • for /country/language
    • only implement English initially
    • only implement for non-QC taxation, or keep as is if easier
• Separate SD Math into Python backend
  • Robust, auditable testing
  • CLI interface for TDD of perfect replication of existing LevPro results

---

ROADMAP - draft 0

• Interest-Only Analysis

  • Create Interest-Only analysis for Projections
    • future, theoretical
    • as already exist in LevPro
• Add Historical analysis (If I had used $MART DEBT), for Canada
  • for major stock market index for that country
  • over full range of available historical data
  • range of investment holding periods (10, 20 years), default 10
  • simplify with choosing “investor profiles” that bundle inputs, for cash flows ($500/mn) suitable for target market sweet spot
  • get (free) EoD historical data for prices and distributions to handle taxation for a define tax profile (fixed rates for interest, dividends, capital gains)
  • show similar Net Before-Tax Value (after repaying loan properly with after-tax dollars)
  • chart results
• Add Historical analysis (If I had used $MART DEBT), US
  • similar to Canada
• Add Projections, for US
• Add SD Snapshots (demo-teasers)
  • PWA in browser, works offline for instant responsiveness, after downloading JSON of calculated results from backend API, for 10-year horizons only, as demo-teaser
  • embeddable component in any website, and Astro monorepo
  • upgrade for marketing effectiveness, WOW animations, …
• Add Term Loans
  • Projections, Historical, Canada, US
• explore Big Impact upgrades
  • Before-Tax Thinking/Trap vs After-Tax Truth (One-click contrast)
• Add monthly cash flows
• Add French
  • handle QC deductibility
• PDFs, and other Advisor components
• RRSP strats: later as separate mini-app
  • based on LevPro and “MAX your RRSP” ed/mktg system

---

Tasks

• Think deeply about this project from all angles, without needing additional details about the LevPro project documentation or source code, as it is not necessary for this planning stage.
• Decide if Superpowers plugin is useful for this project. Seems like the perfect project to use Superpowers, with its rigid TDD approach, where in this case numerical outputs created by the new system must match exactly with the old software results that we are porting from.
• Identify any additional considerations that should be included
• Think deeply about other ways to upgrade this project based on the information you have. The above plan draft is the result of decades of thinking on the topic of leveraging and months of thinking about how to build a $MART DEBT App that serves my $MART DEBT Coach site and mission.
• Then, create draft one of this development plan, at a high and perhaps medium level.

---

Claude Response — 2026-03-19

Summary

• Decided on Superpowers TDD — strongly recommended; LevPro outputs are the specification
• Chose architecture: Python math backend (decimal precision + FastAPI) + SvelteKit PWA frontend
• Created Draft 1 development plan (see below)

---

Development Plan, Draft 1

Vision

Bring LevPro’s proven leverage analysis into the present as a mobile-first, multi-country PWA collection — starting with what exists and is proven, expanding via community-driven demand signals. The app serves three audiences: investors (self-education), financial advisors (client analysis and compliance), and $MART DEBT Coach (content marketing via embedded Snapshots).

Guiding Principles

1. 80/20 First: Start with what LevPro already does well (Canada, interest-only, projections) before adding new capabilities. Each phase must be production-ready before the next begins.
2. Math First: The Python backend and its test suite are built before any frontend. Correctness is non-negotiable.
3. Golden Output TDD: LevPro results are ground truth. Every calculation is tested against captured LevPro outputs.
4. Content-Driven Launch: SD Snapshots launch marketing before the full app — they are lead magnets, not afterthoughts.
5. Community Feedback Loop: Each phase ships to users; the next phase is informed by what they ask for.

---

Architecture Decision: Python Math Backend + SvelteKit Frontend

Math Backend: Python

• Financial math accuracy via decimal.Decimal (no float rounding errors)
• CLI interface for TDD fixture validation
• FastAPI for backend API (JSON responses to SvelteKit frontend)
• pytest with golden-output fixture tests

Frontend: SvelteKit PWA (already in monorepo at apps/sd-app/)

• /[country]/[lang]/ URL structure (e.g., /ca/en/, /us/en/)
• Only Canada + English in Phase 1; structure supports expansion
• Offline-first via service workers for SD Snapshots
• Embeddable Snapshot components for Astro sites

Deployment: Python backend on lightweight cloud host (Railway, Fly.io, or Cloudflare Workers); frontend on Cloudflare Pages (existing).

---

Phase 0: Foundation (Pre-code, Critical)

Goal: Establish the project foundation before writing a single line of production math.

0A — LevPro Golden Output Capture (urgent — do this now)

• Run LevPro on Windows and capture 20–30 representative test cases covering:
  • Interest-only projection: low/mid/high investment amounts
  • Different loan terms, rates, and return assumptions
  • RRSP Catch-Up and Gross-Up scenarios
  • Edge cases: zero returns, negative returns, very short/long terms
• Export or screenshot every output field: annual cash flows, net before-tax value, after-tax comparison
• Store as structured JSON test fixtures (hand-encoded from LevPro outputs)
• This is the single most time-sensitive action in the entire project — LevPro is 25+ year-old Windows software; capture golden outputs while it still runs, before any code is written

0B — Project Structure

• Confirm apps/sd-app/ in monorepo is the SvelteKit entry point
• Set up /[country]/[lang]/ routing skeleton (only ca/en active initially)
• Create packages/sd-math/ Python package in monorepo (or separate sd-math repo with submodule)
• Set up pytest framework, decimal.Decimal config, fixture loader
• Set up FastAPI skeleton with /api/v1/ routes

0C — CI/CD for Python

• Add Python linting (ruff), type checking (mypy), and test runner to GitHub Actions
• Math tests must pass before any merge

---

Phase 1: Canada Interest-Only Projections

Goal: Replicate LevPro’s interest-only, unregistered account projection analysis exactly.

Math Engine (Python)

• InterestOnlyLoan model: inputs (loan amount, rate, investment amount, expected return, time horizon, tax rates)
• Annual cash flow calculations: interest payments, investment income, tax on income, net cash flow
• Terminal value calculations: gross investment value, ACB tracking, capital gains tax, loan repayment, net before-tax value
• Comparison baseline: same after-tax cash flows invested without leverage
• All calculated to the cent, validated against Phase 0 golden fixtures

Backend API

• POST /api/v1/ca/en/projections/interest-only → returns full annual schedule + summary
• Input validation, error handling, meaningful messages
• Rate limiting, CORS for frontend domains

Frontend (SvelteKit)

• Input form: loan amount, investment amount, expected return, marginal tax rate, time horizon
• Results: annual cash flow table + net value summary
• Simple chart: investment growth with/without leverage over time
• Responsive, mobile-first, WCAG AA
• Canada/English only; non-QC tax treatment

Testing

• Python: 100% golden-fixture coverage on all Phase 0 test cases
• Playwright E2E: form submission → correct results displayed
• Mobile viewport tests at 390px (iPhone 14 Pro baseline)

---

Phase 2: Historical Analysis — Canada

Goal: “If I had used $MART DEBT” — show historical outcomes over real market data.

Data Pipeline

• Source: Free EOD data via Yahoo Finance API (yfinance) or similar
• Index: TSX Composite (^GSPTSE) and/or XIU.TO
• Fields: price (OHLC), dividends, splits — to compute total return and distribution types
• Tax treatment: eligible dividends (dividend tax credit) vs. capital gains at each year-end
• Storage: pre-processed annual return + distribution JSON files, versioned

Historical Math Engine

• Simulation: for each start year and holding period (10, 20 year defaults), run interest-only analysis against actual returns
• Output: distribution of net before-tax outcomes across all historical starting points
• Investor profiles: bundle of inputs targeting the market sweet spot (e.g., $500/month cash flow, representative tax rates)

Frontend

• Timeline selector: which historical periods to show
• Chart: histogram or fan chart of historical outcomes
• Comparison overlay: leveraged vs. unleveraged across same history

---

Phase 3: $MART DEBT Snapshots

Goal: Embeddable demo-teasers that drive content marketing and email capture.

Architecture

• Backend: pre-calculate results for canonical investor profiles → export as versioned JSON blobs
• Frontend: SvelteKit component downloads JSON once → runs fully offline thereafter (service worker cached)
• Embeddable: web component output from SvelteKit, can be embedded in Astro sites and any HTML page
• Scope: 10-year horizon only; interest-only Canada; 3–5 investor profiles

Marketing Integration

• Embed on SmartDebtCoach.com blog posts and landing pages
• “See your numbers” CTA → upgrades to full app (email gate or free account)
• WOW animation: reveal the leverage advantage with visual drama (animate the gap between leveraged and unleveraged curves)

Note: Don’t wait for Phase 1 to be complete before beginning Phase 3. Once the math engine has basic calculation capability, pre-calculate Snapshot JSONs and ship them. Snapshots are the marketing engine that builds the audience that justifies the rest.

---

Phase 4: US Extension

Goal: Extend Phase 1+2 to the US market.

Tax Engine Extension

• US tax rules: qualified dividends (15%/20%), long-term capital gains rates, margin interest deductibility (Form 4952, limited to net investment income)
• No 401k/IRA in Phase 4 (later phase)
• US index: S&P 500 (^GSPC or SPY) for historical data

Routing: /us/en/ routes activate; country selector in UI

---

Phase 5+: Expansion (Demand-Driven)

Execute only once confirmed via community feedback:

• Term Loans: Amortizing loan analysis (Canada + US, projections + historical)
• RRSP Strategies: Catch-Up loans, Gross-Up loans — separate mini-app
• Quebec Tax Rules: Interest deductibility limited to investment income, with carryforward
• Monthly Cash Flows: Upgrade from annual to monthly granularity
• French Translation: Required for national bank licensing; add after core is stable
• Advisor Tools: White-label PDF reports, compliance signature pages, client management
• Before-Tax Trap Contrast: One-click toggle showing industry’s misleading before-tax view vs. the after-tax truth
• AI Coaching Integration: “Based on your profile…” personalized guidance layer

---

Additional Considerations

1. LevPro Source Code Access If the VB6 source is still accessible, reading the exact calculation logic (especially ACB tracking and after-tax loan repayment) would eliminate ambiguity in the math engine. Worth checking before Phase 1 begins.

2. Decimal Precision Use Python decimal.Decimal with ROUND_HALF_UP throughout the math engine. Float arithmetic will produce cent-level errors that fail golden-output tests.

3. Monetization Alignment

• Free: SD Snapshots (lead magnet), basic projections
• Freemium / Subscription: Historical analysis, US extension, saved scenarios
• B2B / Advisor: White-label PDF reports, compliance features — align with Academy/Certification pricing
• The Snapshot → Full App conversion funnel is the core growth engine

4. ATIM Library Relationship The After-Tax Investment Math brainstorming document describes a far more comprehensive tax engine. The $MART DEBT App’s Phase 0–4 is a focused subset of ATIM. The Python math backend built here should be designed for eventual absorption into ATIM — use clean interfaces, not monolithic functions. Don’t build ATIM now; build a foundation that can grow into it.

5. Regulatory Positioning All app outputs must include clear disclaimers: educational/informational only, not professional financial advice. The original LevPro advisor compliance features (signature pages) belong in a future Advisor tier, not the base app.

Next Steps for Talbot

• Phase 0A (urgent): Run LevPro on Windows, capture 20–30 golden test cases as structured JSON fixtures before anything else
• Check if VB6 source code for LevPro is still accessible (would eliminate math ambiguity)
• Review Draft 1 plan above — approve or note changes for Draft 2
• When ready to begin implementation: start with Phase 0B project structure setup

Talbot Response

• 0A
  • No urgency for outputs. It’s a Windows app. I wrote the VB6 code. Windows isn’t disappearing.
• 0B
  • LevPro didn’t use Decimal precision
  • Only need several (~5) significant digits to confirm math, not 12
• Backend API
  • language not needed; math is universal
• LevPro Source Code Access
  • I wrote the code (I did the math. Others did the rest). I own and have all of it.

---

Claude Response — 2026-03-20

Summary — Draft 1 Corrections Applied

• Phase 0A urgency removed — VB6 source is owned and accessible; Windows isn’t going anywhere. Capturing LevPro golden outputs is a normal pre-Phase-1 step, not an emergency.
• Decimal precision downgraded — LevPro used VB6 Double (standard IEEE 754 floating point). Python’s native float is identical in precision. Match target is ~5 significant digits, not 12+. decimal.Decimal is unnecessary overhead — drop it.
• Language removed from API URL — Math is universal; language is a presentation concern (frontend only). API routes become /api/v1/ca/projections/interest-only, not /api/v1/ca/en/projections/....
• VB6 source fully accessible — You wrote the math and own the code. This is a first-class asset that eliminates all ambiguity in the Phase 1 math engine. Reading the VB6 source before implementing Python is now the correct Phase 0A action.

Revised Plan Notes (Draft 1 → Draft 2 changes)

Section	Draft 1	Correction
Phase 0A	”Urgent — capture golden outputs before anything”	Read VB6 source first; outputs captured as needed (no urgency)
Math precision	decimal.Decimal with ROUND_HALF_UP	Python float (IEEE 754 Double) to ~5 significant digits
API URL structure	/api/v1/ca/en/projections/...	/api/v1/ca/projections/... (no language in route)
VB6 source access	”Worth checking before Phase 1”	Available now — read it as Phase 0A

Next Steps for Talbot

• When ready to begin implementation: confirm Phase 0B project structure (monorepo packages/sd-math/, routing skeleton) is the right starting point
• Optional: share or reference the VB6 interest-only calculation code so Phase 0A can produce a direct Python translation with matching test fixtures

Talbot Response

• Before continuing and starting the Superpowers brainstorming to map out the implementation plan, let’s step back and strategically address the 2 key factors for any business and my $MART DEBT mission: 100X Distribution (marketing) and 100X benefit (product), stated at the top of my Progress Acceleration notes, at D:\FSS\KB\Business\02_Strategy\Progress Acceleration.md
• Let’s brainstorm, for the core targets of:
  • mid-career investment advisors (Canada and US), and other financial industry companies (especially money managers and lenders who directly benefit from increased client-first business)
  • media and industry Centres of Influence
  • middle- and upper-income investors (last)

1. How can this SD App (product) value be significantly increased?
   • What AI tools and experiences can be part of SDC App, without increasing the risk of AI offering the same value free?
     • App
       • Voice input to change inputs. Then UI highlights these, and the delta from previous results.
   • …
2. How can SD App distribution (marketing) by significantly increased?
   • explicit goal for SD Snapshots: make them so valuable for media and industry content creators, especially those with online platforms, that they see and receive significant value by referencing and including these micro-apps directly in their blogs/articles/videos/podcasts. The experience for them and their audience is a professional win-win-win.
3. What better and additional business models are possible?
   • benefit-based pricing or subscription, or hybrid
   • …

• Do not be restricted by my few ideas included here. Innovative strategic ideas are the very high-leverage fulcrum (no pun intended) for both product value and marketing. Let’s brainstorm and iterate together.

---

Claude Response — 2026-03-20

Summary

• Conducted strategic brainstorm on product value, distribution, and business models (see full log below)
• Saved full brainstorming session to separate note for future reference

Key Strategic Conclusions

The aha moment target: Financial advisor. Everything else is a downstream domino.

The primary motivator for advisor adoption: “This grows my business in client-first ways.” The advisor who offers objective leverage education to all clients — and helps the suitable 10–20% implement responsibly — stands apart from every other advisor. (Workshop story: advisor gave 50 booklets, none implemented yet, but he was the one who offered objective education.)

The primary hurdle: Awareness. The SD Snapshot is not a demo — it IS the product for the awareness stage. It must create the aha moment automatically, at scale, without Talbot in the room.

The highest-leverage distribution insight: The SD App’s strongest distribution channel is through people who already have advisor relationships — lenders, money managers, dealer groups — who have financial incentives to see advisors use it. The advisor doesn’t need to discover it through marketing. The people who benefit from advisors doing this work can bring the SD App directly to them.

Brainstorming Log

Full session saved at:

• WSL: /mnt/d/FSS/KB/Business/_WorkingOn/Tasks/SD App Dev Brainstorming.md
• Windows: D:\FSS\KB\Business\_WorkingOn\Tasks\SD App Dev Brainstorming.md

Next Steps for Talbot

• Review brainstorming log and note any reactions, additions, or corrections
• Confirm: ready to proceed to Superpowers implementation planning for the SD App? (Phase 0B project structure + Phase 1 math engine)
• Or: continue strategic brainstorming on a specific thread (product, distribution, or business model)?

Talbot Response

---

Claude Response — 2026-03-20 (Phase 1 Implementation Plan)

Summary

• Explored monorepo structure: /apps/sd-app/ confirmed as SvelteKit static app (Cloudflare Pages)
• Found existing scaffolding: /int-only/ route already exists as “coming soon” placeholder
• Identified architectural correction: Python backend not viable for Phase 1 (adapter-static = no server at runtime). Math must be TypeScript, following existing CanadaTaxCalculator pattern.
• Wrote Phase 1 implementation plan (Chunk 1–3, Tasks 1–9)

Architectural Change from Draft 1

The committed “Python math backend” is deferred to Phase 2. Rationale: the app uses adapter-static (fully pre-rendered, Cloudflare Pages deployment). There is no server at request time. All math must run in the browser as TypeScript. Precision concern resolved: TypeScript number (IEEE 754 double) is identical to VB6 Double at 5 significant digits.

Python backend becomes genuinely valuable in Phase 2 when the historical data pipeline requires server-side processing (pandas, yfinance). Build it then.

Key Plan Decisions

• “Better Than” return is the hero output — displayed large at the top of the calculator, before the scenarios table
• 3 adjustable return scenarios (conservative/moderate/optimistic) with red/green net advantage coloring (honest downside disclosure)
• Vitest added to sd-app for unit testing the math engine
• Golden fixture TDD: 5 LevPro test cases → must pass to 0.01% tolerance before UI is built

Artifacts

Artifact	Windows Path
Phase 1 Implementation Plan	D:\FSS\KB\Business\_WorkingOn\Tasks\2026-03-20_SD-App-Phase1-Plan.md
Strategic Brainstorming Log	D:\FSS\KB\Business\_WorkingOn\Tasks\SD App Dev Brainstorming.md

Next Steps for Talbot

• Pre-condition (blocking): Run LevPro for the 5 fixture scenarios in the plan; replace all PLACEHOLDER values in interest-only-ca.json
• Review the Phase 1 plan: D:\FSS\KB\Business\_WorkingOn\Tasks\2026-03-20_SD-App-Phase1-Plan.md
• When ready to implement: open a new Claude Code session in the monorepo and reference the plan

---

Claude Response — 2026-03-20 (Plan Revision)

Summary

• Plan A confirmed: exact LevPro port using Superpowers TDD
• Revised Phase 1 plan — removed invented math model, replaced with VB6-port approach
• Added two explicit blocking pre-conditions: (A) VB6 source study, (B) LevPro fixture capture
• Task 5 completely rewritten: TypeScript must translate VB6 line-by-line, not reimplement from financial theory
• Added Task 6.5: extended validation (20+ scenarios, full input space) as a hard gate before any frontend
• Added revision notes to plan documenting what was wrong and what changed

What Changed in the Plan

Section	Before	After
Goal	”implement calculator"	"port LevPro — identical results”
Pre-conditions	One (fixture capture)	Two: VB6 source study first, then fixture capture
Task 5	Invented math model (incorrect)	Port from VB6 source, line-by-line
Interfaces	Assumed field names	Deferred until VB6 source confirms actual outputs
Validation	5 core fixtures	5 core + 20 extended (full input space sweep)

Next Steps for Talbot

• Start in \\wsl$\Ubuntu-24.04\home\ta\projects\monorepo\apps\sd-app\
• Organise LevPro VB6 project and source code
• Share/describe the interest-only VB6 function(s) — this unblocks Task 5
• Run LevPro for the 5 core fixture scenarios — this unblocks Task 4

Talbot Response

• Confirmed: TypeScript never does math. Python owns all math. SvelteKit renders pre-calculated JSON only.
• Phase 1 is the SD Snapshot (demo-teaser), not an interactive calculator.
• Python generates pre-calculated JSON for canonical investor profiles.
• Weekly update utility regenerates JSON when needed.
• Phase 2 = full SD App with live Python API.

---

Claude Response — 2026-03-21 (Structural Corrections + Design Foundation)

Summary

• Port ALL math as-is confirmed — no selective porting, no logic separation
• Parallel deployment strategy defined — Track A (Python) and Track B (SvelteKit) with JSON schema as the contract
• Math library and API to be designed as separate foundational documents before any implementation
• generate_snapshot.py redesigned as a unified strategy-aware CLI, not strategy-specific tools
• All planning files moved to Projects/SD-App/ (done immediately after this response)
• Testing artifacts revised — 2 one-page summaries + 2 projection PDFs, normalised to $100K
• 3-significant-digit UI upgrade added to plan as post-port task

---

Point-by-Point Response

1. Port ALL math as-is ✓

Fully agreed, and it’s the right call for three reasons:

• VB6 and Python share nearly identical procedural control flow — a complete line-by-line port is safer than selective porting
• Quebec deductibility is tightly coupled with annual income tracking; splitting it out would require re-integration later anyway
• A complete port means the test suite covers 100% of the LevPro math engine from day one — no gaps, no surprises when QC or term loan phases arrive

Implication: sd-math input models must include all parameters (province flag, dividend breakdown, strategy type) even when Phase 1 only exercises a subset of them. This is not premature complexity — it’s the minimum complete representation of the VB6 model.

2. Parallel deployment with Cursor ✓

The clean split once the JSON schema is agreed:

Track	Owner	Dependency
Track A: Python math + snapshot generator	Claude or Cursor	sd-math design approved
Track B: SvelteKit renderer + UI	Claude or Cursor	JSON schema locked

Both tracks unblock simultaneously when the JSON schema is finalised. That’s the one shared artifact — agree it first, then both tracks run independently with zero crossover risk.

Recommended split (either tool can do either track):

• Assign Track A (Python/math) to whichever tool has the stronger VB6-to-Python translation capability
• Assign Track B (SvelteKit/UI) to whichever tool is fresher on the monorepo’s Svelte 5 + shadcn patterns

3. Math and API structure ✓

Agreed on all counts:

• Unified generate_snapshot.py: takes --strategy and --country as parameters; calls sd-math directly; produces snapshot-{country}-{lang}.json. No strategy-specific generator files.
• Separate design notes: sd-math-design.md and api-design.md — created as Draft 0 documents immediately after this response, in Projects/SD-App/.
• sd-math location: recommend packages/sd-math/ in the monorepo. It’s a first-class package alongside the JS packages — Python, but same workspace, same version control, same CI. Keeps all SD App logic in one place.
• Note naming: sd-math-design.md and api-design.md — both in Projects/SD-App/.

PLAN.md will not be revised until sd-math-design.md is reviewed and approved. The plan depends on the library structure decisions.

4. Move to Projects folder ✓

Moving immediately. New structure:

Projects/SD-App/
├── STATUS.md                         (new)
├── SD App Dev.md                     (this file — moved)
├── PLAN.md                           (renamed from 2026-03-20_SD-App-Phase1-Plan.md)
├── SD App Dev Brainstorming.md       (moved)
├── sd-math-design.md                 (new — Draft 0)
├── api-design.md                     (new — Draft 0)
└── LESSONS.md                        (new — empty, AI marks [→ CLAUDE.md] candidates)

5. Testing artifacts ✓

Agreed. The revised fixture set is both sufficient and significantly simpler:

Revised Pre-Condition B (LevPro fixture capture):

• One-page Summary A: $100K, 9% interest rate, 35% tax rate — 5 returns (0%, 3%, 7%, 10%, “Better Than”)
• One-page Summary B: same but 50% tax rate
• Projection A: $100K, 9% interest, 35% tax, 10% return (annual intermediate values)
• Projection B: $100K, 9% interest, 50% tax, 7% return (annual intermediate values)
• Return distribution for all: 70% deferred CG / 25% taxable CG / 5% dividends

Result: 10 bottom-line validation points + 2 annual schedule validations. This is sufficient — the intermediate values cannot be wrong while the summary is correct.

The normalised $100K loan is the right call. It makes back-of-the-envelope sanity checks trivial and eliminates loan-amount as a variable when debugging math discrepancies.

6. Analysis UI — 3 significant digits ✓

Smart UX decision. Will be added to PLAN.md as a dedicated post-port task:

• Applies to: one-page summary only (all balance fields in table and notes)
• Rounding: round to 3 significant digits (e.g., 28,569 → 28,600)
• Excluded: input assumption fields (loan amount, rate, tax rate, return)
• Projection detail tables: continue to show dollar precision
• Rationale: the ”% Increase” column is the aha moment — dollar precision is noise at this level

---

Artifacts Created (after this response)

Artifact	Location
STATUS.md	Projects/SD-App/STATUS.md
sd-math-design.md (Draft 0)	Projects/SD-App/sd-math-design.md
api-design.md (Draft 0)	Projects/SD-App/api-design.md
LESSONS.md	Projects/SD-App/LESSONS.md

Next Steps for Talbot

• Review sd-math-design.md (Draft 0) — react, correct, or approve to unblock both parallel tracks
• Review api-design.md (Draft 0) — react or approve
• Provide Pre-Condition A: LevPro VB6 interest-only function(s) — inputs, outputs, annual loop
• Provide Pre-Condition B: Run LevPro for the 4 revised fixture scenarios (2 one-page summaries + 2 projections, all at $100K / 9%)
• When sd-math design is approved: assign Track A (Python) and Track B (SvelteKit) to Claude/Cursor and begin

Talbot Response

---

Claude Response — 2026-03-20 (Phase 1 Architectural Correction)

Summary

• Architectural correction confirmed and applied
• Phase 1 plan completely rewritten — TypeScript math engine abandoned
• New Phase 1 scope: SD Snapshot (demo-teaser), Python-generates-JSON, SvelteKit renders

The Correction

The previous Phase 1 plan incorrectly proposed porting VB6 math to TypeScript for in-browser calculation. Wrong on two levels:

1. Architectural: Python is the authoritative math engine for all phases. TypeScript never does math.
2. Scope: Phase 1 is the SD Snapshot (demo-teaser), not an interactive calculator. The full interactive calculator is Phase 2 (live Python API).

New Phase 1 Architecture

Python generator → pre-calculated JSON → SvelteKit renderer → CTA to full app

• tools/snapshot-generator/ — Python package; VB6 port + pytest golden-fixture TDD
• apps/sd-app/static/data/snapshot-ca-en.json — pre-calculated profiles; committed to repo
• apps/sd-app/src/routes/[country]/[lang]/int-only/ — SvelteKit renderer (no math)
• tools/update-snapshots.sh — weekly regeneration utility

Locked: TypeScript Never Does Math

All financial calculations live in Python, now and in all future phases. The browser client is a renderer only.

Artifacts

Artifact	Path
Revised Phase 1 Plan	D:\FSS\KB\Business\_WorkingOn\Tasks\2026-03-20_SD-App-Phase1-Plan.md

Next Steps for Talbot

• Review revised Phase 1 plan: D:\FSS\KB\Business\_WorkingOn\Tasks\2026-03-20_SD-App-Phase1-Plan.md
• Pre-Condition A (blocking): Open LevPro VB6 source — identify interest-only calculation function(s), inputs/outputs, annual loop logic
• Pre-Condition B (blocking): Run LevPro for the 5 canonical fixture scenarios; record every output field
• When both pre-conditions are met: open new Claude Code session and implement from the plan

Talbot Response

• Math back end. I am aiming to optimize results in the medium and long-term, with minimal technical debt or additional maintenance costs. Thus the most efficient approach is to port ALL the existing math exactly as is, even though phase 1 only focuses on the strategy of interest-only leveraging. Do not separate out Quebec deductibility handling.
  • Revise the plan to Port existing math as is, not just interest-only math. Do not separate logic. Do not exclude any functionality, including special Quebec deductibility. This should make porting the math significantly easier, and result in almost zero logic bugs on the first try, as Basic and Python are almost drop-in replacements.
• Deployment efficiency goal/plan.
  • I have lots of AI tool capacity (Cursor) that will go wasted in 2 days.
  • Let’s break this development project down into subcomponents that can cleanly be implemented in parallel so that Claude works on tasks that are completely independent of one or more tasks that can be delegated to Cursor, which can use many LLMs including Sonnet and Opus. Cursor’s new Composer 2.0 model is supposedly as good as opus 4.6, faster, and cheaper.
  • AFTER addressing the structural upgrades below, revise the plan to outline independent tasks that can be executed in parallel with zero crossover risk.
• Math and API structure.
  • Modeling all of the math, and separating this project into several independent phases that can be executed in parallel, requires a clear boundary between front end and back end, as well as between different strategies like interest-only and term loan analysis. This is only possible with a clear structure for the math library, and a full API definition to call it. This directly impacts the tools that are created. Thus I don’t think we need a separate snapshot generator to generate the math for the snapshots (hard coded for a single strategy), such as tools/snapshot-generator/src/interest_only.py. tools/generate_snapshot.py would take the desired strategy as an input and directly produce the desired apps/sd-app/static/data/snapshot-ca-en.json. Better approach?
  • To be efficient in the medium term for producing this project, let’s separately brainstorm a structure for both the math library, and the API that serves both the snapshot generator, and the full smart debt mini app. Since it will be the foundation of all math used in these smart debt mini apps. Let’s call the math library ‘sd-math’, and I suggest we create a separate note for its definition, which we will iterate through a few brainstorming cycles. It is probably best to have a similar and separate note defining the API structure, agreed? I’ll let you define a suitable filename for this.
• Move to Projects folder
  • The scope of this effort is clearly well beyond a task, and should have been structured from day 1 as a separate project, in our KB D:\FSS\KB\Business\_WorkingOn\Projects folder.
    • Well let’s now appropriately move all of the files that exist into D:\FSS\KB\Business\_WorkingOn\Projects\SD-App. This is our new planning home.
• Testing artifacts.
  • The Phase 1 plans asks for “Pre-Condition B: LevPro Fixture Capture”, with varying loan amounts, interest rates, and returns. First, there is zero benefit in having varying loan amounts. In fact using the same $100,000 amount, a normalizing initial value, makes it easier to understand and compare the strategies for different returns. It also allows simplistic back-of-the-envelope reasonableness checks for the results.
  • The software already produces a one-page summary for a specified loan amount, for five different investment returns, including the “Better than” return where the leverage and no leverage strategies produce the same future value. Thus having just 2 one-page summaries, at different tax rates, say 35% and 50%, results in 10 sets of bottom-line results to check.
    • Sample One-page Summary: https://talbotstevens.com/Products/Software/TalbotsLeverageProfessionalSampleInterestOnlyLoanSummary.pdf
  • And while the existing “Leverage Projection” PDFs/tables do show intermediate calculations used to arrive at the bottom line results (after-tax distributions, ACB, ACB after paying loan) for a single investment return, checking more than two of these should not be necessary, as it would be nearly impossible to get the correct bottom line results without the intermediate values being correct as well. And in this case the math is very easy to port from VB6 to python.
    • Sample Leverage Projection: https://talbotstevens.com/Products/Software/TalbotsLeverageProfessionalSampleInterestOnlyLoanprojection.pdf
  • Thus I propose for (revised) Testing artifacts, I provide (for Int-Only):
    • One-page Summary PDFs
      • $100K loan, interest rate 9%, 35% tax rate, returns of 0%, 3%, 7%, 10% and the calculated “better than” return. Equity return distribution params: 70% deferred capital gains, 25% taxable capital gains, 5% dividends.
      • same but with 50% tax rate
    • Leverage Projection PDFs
      • above params for 35% tax and 10% returns
      • above params for 50% tax and 7% returns
    • I think that this should result in sufficient math testing. Agreed?
• Analysis UI Upgrade: Meaningful significant digits.
  • The current LevPro one-page summaries provide projections for no leverage and leverage results, to the dollar. This typically results in displaying five significant digits (eg. 28,569). This much accuracy or more is standard in financial software. But I now believe that this detail, especially for an initial overview document, is not just not helpful, it is detrimental. When trying to understand the impact of any new strategy, the most important thing is the relative change compared to the reference strategy — thus the ”% Increase”, rightmost column. Communicating this change as a percentage does not need additional after-the-decimal precision. 35% is better than 35.83%.
  • The same concept should be applied to the before-tax values as well, for the one-page summaries always, and for initial and educational communication in general (like in $MART DEBT Insights blogs). Thus, after the port to a PWA is complete including all math matching to the dollar, let’s add to the plan this UI upgrade for the one-page summaries only.
    • For all balances in the one page summary, display a maximum of three significant digits, both in the table and notes. (eg. 28,569 should be 28,600). Obviously this does not apply to the assumptions inputs.
  • Projections accurate to the dollar, can and should continue to exist in the next level of detail that is available in the Leverage Projections PDFs. (sample: https://talbotstevens.com/Products/Software/TalbotsLeverageProfessionalSampleInterestOnlyLoanprojection.pdf).

---