Vibecode Mortgage Coach
track this build5 steps, step by step0%KINDA · weekend project
The math here is not exotic: amortization schedules, PMI drop-off, points breakeven, net cost after N years, rent versus buy. An agent can build a clean side-by-side scenario comparator with charts and a printable one-pager in a single session, and for a person modeling their own refinance that is genuinely enough. What you cannot one-shot is the part that makes it a business tool: pulling live loan scenarios out of the LOS or pricing engine, compliance-reviewable output your employer will actually let you send to a borrower, and the delivery layer that tracks whether the client opened the presentation. If you are a licensed originator, your DIY version is a scratchpad, not something you put in front of a client. If you are the borrower trying to sanity check what your lender sent you, the DIY version is arguably better because you control the assumptions.
the project pack4 files · fastest path to a working personal build
You are building a lean indie version of Mortgage Coach. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Mortgage Coach indie build ## Goal Build the smallest trustworthy replacement for the core Mortgage Coach workflow for one developer or a tiny team. ## Scope Enter two to four loan scenarios, get amortization schedules, breakeven points and total-cost-over-time charts side by side, then print a one-page summary. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Integrations with loan origination systems, pricing engines and CRMs, so every scenario is typed in by hand - Compliance-vetted presentation output and audit trail, which is the entire reason a regulated lender licenses this instead of using a spreadsheet - Borrower engagement tracking: who opened the presentation, how long they looked, which option they clicked - Polished branded video and mobile presentation formats that agents and borrowers are used to receiving - Someone else maintaining the edge cases: ARMs, buydowns, MI structures, state-specific cost lines If those capabilities are essential, use Mortgage Coach instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build a local, single-page loan comparison tool called "Loan Compare". No backend, no accounts, no telemetry, no external API calls. Stack, non-negotiable: - Vite + React + TypeScript - Tailwind CSS for styling - Recharts for charts - Zod for input validation - Vitest for the math tests - State persisted to localStorage, no server Core data model: a Scenario has name, loan amount, home price, down payment, interest rate, term in months, loan type (fixed or ARM), optional ARM fields (initial fixed period, adjustment cap, lifetime cap, assumed adjusted rate), points paid, lender fees, property tax annual, homeowners insurance annual, HOA monthly, mortgage insurance monthly plus the LTV at which it drops off, and extra monthly principal payment. Build these features: 1. Add, duplicate, rename and delete scenarios. Support 2 to 4 side by side. 2. A pure TypeScript amortization engine in src/lib/amortize.ts that returns a month by month schedule: payment, interest, principal, balance, MI charged, cumulative interest, cumulative cost. Handle extra principal, MI drop-off at the configured LTV using the original home price, and ARM rate steps after the fixed period. 3. A comparison table: monthly payment now, monthly payment after MI drops, total interest, total cost at 3, 5, 7, 10 years and full term, remaining balance at each of those horizons, and net cost after subtracting principal paid down. 4. Charts: cumulative cost over time per scenario, balance over time, and a breakeven chart showing where a higher-points scenario overtakes a lower one. 5. A "what changed" panel that plainly states which scenario wins at each horizon and by how much. 6. A print stylesheet so Cmd+P produces a clean one page summary with the table and the cumulative cost chart. No PDF library. 7. Share by encoding all scenarios into the URL hash, so a link reproduces the comparison with no server. 8. Vitest tests for the engine: a known 30 year fixed schedule, MI drop-off timing, extra principal shortening the term, and an ARM step. Explicitly out of scope: live rate feeds, credit pulls, loan origination system or CRM integrations, e-signature, borrower open tracking, user accounts, any compliance or disclosure language. Put a visible footer: "Estimates only. Not a loan disclosure or an offer of credit." If you ever add anything needing a secret, read it from .env and commit .env.example only. Ship a README with run and test commands and a one paragraph explanation of the amortization assumptions. ## Required capabilities - Node 20+ - a browser - nothing else: no accounts, no API keys, all math runs locally ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a lean indie version of Mortgage Coach. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Mortgage Coach indie build ## Goal Build the smallest trustworthy replacement for the core Mortgage Coach workflow for one developer or a tiny team. ## Scope Enter two to four loan scenarios, get amortization schedules, breakeven points and total-cost-over-time charts side by side, then print a one-page summary. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Integrations with loan origination systems, pricing engines and CRMs, so every scenario is typed in by hand - Compliance-vetted presentation output and audit trail, which is the entire reason a regulated lender licenses this instead of using a spreadsheet - Borrower engagement tracking: who opened the presentation, how long they looked, which option they clicked - Polished branded video and mobile presentation formats that agents and borrowers are used to receiving - Someone else maintaining the edge cases: ARMs, buydowns, MI structures, state-specific cost lines If those capabilities are essential, use Mortgage Coach instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build a local, single-page loan comparison tool called "Loan Compare". No backend, no accounts, no telemetry, no external API calls. Stack, non-negotiable: - Vite + React + TypeScript - Tailwind CSS for styling - Recharts for charts - Zod for input validation - Vitest for the math tests - State persisted to localStorage, no server Core data model: a Scenario has name, loan amount, home price, down payment, interest rate, term in months, loan type (fixed or ARM), optional ARM fields (initial fixed period, adjustment cap, lifetime cap, assumed adjusted rate), points paid, lender fees, property tax annual, homeowners insurance annual, HOA monthly, mortgage insurance monthly plus the LTV at which it drops off, and extra monthly principal payment. Build these features: 1. Add, duplicate, rename and delete scenarios. Support 2 to 4 side by side. 2. A pure TypeScript amortization engine in src/lib/amortize.ts that returns a month by month schedule: payment, interest, principal, balance, MI charged, cumulative interest, cumulative cost. Handle extra principal, MI drop-off at the configured LTV using the original home price, and ARM rate steps after the fixed period. 3. A comparison table: monthly payment now, monthly payment after MI drops, total interest, total cost at 3, 5, 7, 10 years and full term, remaining balance at each of those horizons, and net cost after subtracting principal paid down. 4. Charts: cumulative cost over time per scenario, balance over time, and a breakeven chart showing where a higher-points scenario overtakes a lower one. 5. A "what changed" panel that plainly states which scenario wins at each horizon and by how much. 6. A print stylesheet so Cmd+P produces a clean one page summary with the table and the cumulative cost chart. No PDF library. 7. Share by encoding all scenarios into the URL hash, so a link reproduces the comparison with no server. 8. Vitest tests for the engine: a known 30 year fixed schedule, MI drop-off timing, extra principal shortening the term, and an ARM step. Explicitly out of scope: live rate feeds, credit pulls, loan origination system or CRM integrations, e-signature, borrower open tracking, user accounts, any compliance or disclosure language. Put a visible footer: "Estimates only. Not a loan disclosure or an offer of credit." If you ever add anything needing a secret, read it from .env and commit .env.example only. Ship a README with run and test commands and a one paragraph explanation of the amortization assumptions. ## Required capabilities - Node 20+ - a browser - nothing else: no accounts, no API keys, all math runs locally ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a production product version of Mortgage Coach. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # Mortgage Coach product brief ## Problem The math here is not exotic: amortization schedules, PMI drop-off, points breakeven, net cost after N years, rent versus buy. An agent can build a clean side-by-side scenario comparator with charts and a printable one-pager in a single session, and for a person modeling their own refinance that is genuinely enough. What you cannot one-shot is the part that makes it a business tool: pulling live loan scenarios out of the LOS or pricing engine, compliance-reviewable output your employer will actually let you send to a borrower, and the delivery layer that tracks whether the client opened the presentation. If you are a licensed originator, your DIY version is a scratchpad, not something you put in front of a client. If you are the borrower trying to sanity check what your lender sent you, the DIY version is arguably better because you control the assumptions. ## Product outcome Enter two to four loan scenarios, get amortization schedules, breakeven points and total-cost-over-time charts side by side, then print a one-page summary. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - Node 20+ - a browser - nothing else: no accounts, no API keys, all math runs locally ## Explicit non-goals for v1 - Integrations with loan origination systems, pricing engines and CRMs, so every scenario is typed in by hand - Compliance-vetted presentation output and audit trail, which is the entire reason a regulated lender licenses this instead of using a spreadsheet - Borrower engagement tracking: who opened the presentation, how long they looked, which option they clicked - Polished branded video and mobile presentation formats that agents and borrowers are used to receiving - Someone else maintaining the edge cases: ARMs, buydowns, MI structures, state-specific cost lines ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees. ===== ARCHITECTURE.md ===== # Architecture ## Starting brief Build a local, single-page loan comparison tool called "Loan Compare". No backend, no accounts, no telemetry, no external API calls. Stack, non-negotiable: - Vite + React + TypeScript - Tailwind CSS for styling - Recharts for charts - Zod for input validation - Vitest for the math tests - State persisted to localStorage, no server Core data model: a Scenario has name, loan amount, home price, down payment, interest rate, term in months, loan type (fixed or ARM), optional ARM fields (initial fixed period, adjustment cap, lifetime cap, assumed adjusted rate), points paid, lender fees, property tax annual, homeowners insurance annual, HOA monthly, mortgage insurance monthly plus the LTV at which it drops off, and extra monthly principal payment. Build these features: 1. Add, duplicate, rename and delete scenarios. Support 2 to 4 side by side. 2. A pure TypeScript amortization engine in src/lib/amortize.ts that returns a month by month schedule: payment, interest, principal, balance, MI charged, cumulative interest, cumulative cost. Handle extra principal, MI drop-off at the configured LTV using the original home price, and ARM rate steps after the fixed period. 3. A comparison table: monthly payment now, monthly payment after MI drops, total interest, total cost at 3, 5, 7, 10 years and full term, remaining balance at each of those horizons, and net cost after subtracting principal paid down. 4. Charts: cumulative cost over time per scenario, balance over time, and a breakeven chart showing where a higher-points scenario overtakes a lower one. 5. A "what changed" panel that plainly states which scenario wins at each horizon and by how much. 6. A print stylesheet so Cmd+P produces a clean one page summary with the table and the cumulative cost chart. No PDF library. 7. Share by encoding all scenarios into the URL hash, so a link reproduces the comparison with no server. 8. Vitest tests for the engine: a known 30 year fixed schedule, MI drop-off timing, extra principal shortening the term, and an ARM step. Explicitly out of scope: live rate feeds, credit pulls, loan origination system or CRM integrations, e-signature, borrower open tracking, user accounts, any compliance or disclosure language. Put a visible footer: "Estimates only. Not a loan disclosure or an offer of credit." If you ever add anything needing a secret, read it from .env and commit .env.example only. Ship a README with run and test commands and a one paragraph explanation of the amortization assumptions. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it. ===== AGENTS.md ===== # Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations. ===== OPERATIONS.md ===== # Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Mortgage Coach capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
README.md
# Mortgage Coach indie build ## Goal Build the smallest trustworthy replacement for the core Mortgage Coach workflow for one developer or a tiny team. ## Scope Enter two to four loan scenarios, get amortization schedules, breakeven points and total-cost-over-time charts side by side, then print a one-page summary. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Integrations with loan origination systems, pricing engines and CRMs, so every scenario is typed in by hand - Compliance-vetted presentation output and audit trail, which is the entire reason a regulated lender licenses this instead of using a spreadsheet - Borrower engagement tracking: who opened the presentation, how long they looked, which option they clicked - Polished branded video and mobile presentation formats that agents and borrowers are used to receiving - Someone else maintaining the edge cases: ARMs, buydowns, MI structures, state-specific cost lines If those capabilities are essential, use Mortgage Coach instead of pretending the gap is solved.
AGENTS.md
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan ## Original build brief Build a local, single-page loan comparison tool called "Loan Compare". No backend, no accounts, no telemetry, no external API calls. Stack, non-negotiable: - Vite + React + TypeScript - Tailwind CSS for styling - Recharts for charts - Zod for input validation - Vitest for the math tests - State persisted to localStorage, no server Core data model: a Scenario has name, loan amount, home price, down payment, interest rate, term in months, loan type (fixed or ARM), optional ARM fields (initial fixed period, adjustment cap, lifetime cap, assumed adjusted rate), points paid, lender fees, property tax annual, homeowners insurance annual, HOA monthly, mortgage insurance monthly plus the LTV at which it drops off, and extra monthly principal payment. Build these features: 1. Add, duplicate, rename and delete scenarios. Support 2 to 4 side by side. 2. A pure TypeScript amortization engine in src/lib/amortize.ts that returns a month by month schedule: payment, interest, principal, balance, MI charged, cumulative interest, cumulative cost. Handle extra principal, MI drop-off at the configured LTV using the original home price, and ARM rate steps after the fixed period. 3. A comparison table: monthly payment now, monthly payment after MI drops, total interest, total cost at 3, 5, 7, 10 years and full term, remaining balance at each of those horizons, and net cost after subtracting principal paid down. 4. Charts: cumulative cost over time per scenario, balance over time, and a breakeven chart showing where a higher-points scenario overtakes a lower one. 5. A "what changed" panel that plainly states which scenario wins at each horizon and by how much. 6. A print stylesheet so Cmd+P produces a clean one page summary with the table and the cumulative cost chart. No PDF library. 7. Share by encoding all scenarios into the URL hash, so a link reproduces the comparison with no server. 8. Vitest tests for the engine: a known 30 year fixed schedule, MI drop-off timing, extra principal shortening the term, and an ARM step. Explicitly out of scope: live rate feeds, credit pulls, loan origination system or CRM integrations, e-signature, borrower open tracking, user accounts, any compliance or disclosure language. Put a visible footer: "Estimates only. Not a loan disclosure or an offer of credit." If you ever add anything needing a secret, read it from .env and commit .env.example only. Ship a README with run and test commands and a one paragraph explanation of the amortization assumptions. ## Required capabilities - Node 20+ - a browser - nothing else: no accounts, no API keys, all math runs locally ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden.
.env.example
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
PRODUCT.md
# Mortgage Coach product brief ## Problem The math here is not exotic: amortization schedules, PMI drop-off, points breakeven, net cost after N years, rent versus buy. An agent can build a clean side-by-side scenario comparator with charts and a printable one-pager in a single session, and for a person modeling their own refinance that is genuinely enough. What you cannot one-shot is the part that makes it a business tool: pulling live loan scenarios out of the LOS or pricing engine, compliance-reviewable output your employer will actually let you send to a borrower, and the delivery layer that tracks whether the client opened the presentation. If you are a licensed originator, your DIY version is a scratchpad, not something you put in front of a client. If you are the borrower trying to sanity check what your lender sent you, the DIY version is arguably better because you control the assumptions. ## Product outcome Enter two to four loan scenarios, get amortization schedules, breakeven points and total-cost-over-time charts side by side, then print a one-page summary. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - Node 20+ - a browser - nothing else: no accounts, no API keys, all math runs locally ## Explicit non-goals for v1 - Integrations with loan origination systems, pricing engines and CRMs, so every scenario is typed in by hand - Compliance-vetted presentation output and audit trail, which is the entire reason a regulated lender licenses this instead of using a spreadsheet - Borrower engagement tracking: who opened the presentation, how long they looked, which option they clicked - Polished branded video and mobile presentation formats that agents and borrowers are used to receiving - Someone else maintaining the edge cases: ARMs, buydowns, MI structures, state-specific cost lines ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
ARCHITECTURE.md
# Architecture ## Starting brief Build a local, single-page loan comparison tool called "Loan Compare". No backend, no accounts, no telemetry, no external API calls. Stack, non-negotiable: - Vite + React + TypeScript - Tailwind CSS for styling - Recharts for charts - Zod for input validation - Vitest for the math tests - State persisted to localStorage, no server Core data model: a Scenario has name, loan amount, home price, down payment, interest rate, term in months, loan type (fixed or ARM), optional ARM fields (initial fixed period, adjustment cap, lifetime cap, assumed adjusted rate), points paid, lender fees, property tax annual, homeowners insurance annual, HOA monthly, mortgage insurance monthly plus the LTV at which it drops off, and extra monthly principal payment. Build these features: 1. Add, duplicate, rename and delete scenarios. Support 2 to 4 side by side. 2. A pure TypeScript amortization engine in src/lib/amortize.ts that returns a month by month schedule: payment, interest, principal, balance, MI charged, cumulative interest, cumulative cost. Handle extra principal, MI drop-off at the configured LTV using the original home price, and ARM rate steps after the fixed period. 3. A comparison table: monthly payment now, monthly payment after MI drops, total interest, total cost at 3, 5, 7, 10 years and full term, remaining balance at each of those horizons, and net cost after subtracting principal paid down. 4. Charts: cumulative cost over time per scenario, balance over time, and a breakeven chart showing where a higher-points scenario overtakes a lower one. 5. A "what changed" panel that plainly states which scenario wins at each horizon and by how much. 6. A print stylesheet so Cmd+P produces a clean one page summary with the table and the cumulative cost chart. No PDF library. 7. Share by encoding all scenarios into the URL hash, so a link reproduces the comparison with no server. 8. Vitest tests for the engine: a known 30 year fixed schedule, MI drop-off timing, extra principal shortening the term, and an ARM step. Explicitly out of scope: live rate feeds, credit pulls, loan origination system or CRM integrations, e-signature, borrower open tracking, user accounts, any compliance or disclosure language. Put a visible footer: "Estimates only. Not a loan disclosure or an offer of credit." If you ever add anything needing a secret, read it from .env and commit .env.example only. Ship a README with run and test commands and a one paragraph explanation of the amortization assumptions. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
AGENTS.md
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
MILESTONES.md
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
OPERATIONS.md
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Mortgage Coach capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent · this prompt is generated from the build plan · improve it via PR
Loan officers do not buy this to do arithmetic, they buy it because it turns a rate quote into a story a borrower can act on, and because the output is something their compliance department has already approved for client delivery. The tool also sits inside the workflow: scenarios flow in from the origination and pricing systems, presentations go out through the CRM, and engagement comes back as a lead signal. A self-built comparator gives you the numbers but none of that plumbing, and in a regulated sales process the plumbing is the product.
xIntegrations with loan origination systems, pricing engines and CRMs, so every scenario is typed in by hand
xCompliance-vetted presentation output and audit trail, which is the entire reason a regulated lender licenses this instead of using a spreadsheet
xBorrower engagement tracking: who opened the presentation, how long they looked, which option they clicked
xPolished branded video and mobile presentation formats that agents and borrowers are used to receiving
xSomeone else maintaining the edge cases: ARMs, buydowns, MI structures, state-specific cost lines
Nothing worth pointing at. That's why the prompt exists.
share on X ↗"I just replaced Mortgage Coach with one prompt"
Vibecode Mortgage Coach
Kinda. The core of Mortgage Coach is buildable in a weekend with the prompt on this page, but there are real gaps: Integrations with loan origination systems, pricing engines and CRMs, so every scenario is typed in by hand, Compliance-vetted presentation output and audit trail, which is the entire reason a regulated lender licenses this instead of using a spreadsheet. Read the honest list above before committing.
How much does Mortgage Coach cost?
Mortgage Coach's pricing is usage-based or varies by plan · No pricing page exists (/pricing returns 404); site funnels to 'Reach out to see MortgageCoach in action'..
What do I lose by replacing Mortgage Coach?
Honestly: Integrations with loan origination systems, pricing engines and CRMs, so every scenario is typed in by hand; Compliance-vetted presentation output and audit trail, which is the entire reason a regulated lender licenses this instead of using a spreadsheet; Borrower engagement tracking: who opened the presentation, how long they looked, which option they clicked; Polished branded video and mobile presentation formats that agents and borrowers are used to receiving; Someone else maintaining the edge cases: ARMs, buydowns, MI structures, state-specific cost lines. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to Mortgage Coach?
No mature open-source alternative worth pointing at, which is exactly why the one-shot prompt on this page exists.